jparris / enso Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/enso
License: Other
Automatically exported from code.google.com/p/enso
License: Other
Enso Readme =========== Enso is an extensible, cross-platform quasimodal linguistic command-line interface written in Python. Building Enso ------------- To build Enso, you need: * Python 2.4 or above This can be found at http://www.python.org. * SCons This open-source, python-based build tool can be found at http://www.scons.org. You'll also need the appropriate prerequisites for your particular platform. Please consult one of the following files: README.osx (Mac OS X) README.win32 (Microsoft Windows) README.linux (Linux and other Un*x-based platforms) Once you've read this file, just run 'scons' from the root directory of the source tree. Running Enso ------------ To run Enso, just excecute the following from the root directory of the source tree: python scripts/run_enso.py Installing Enso System-Wide --------------------------- Enso has a distutils-based install script that can be used to install Enso system-wide, but it currently only works on Linux (see issue 19). To use it, just run python setup.py install
The Cairo and PyCairo versions Enso is currently using are getting a bit
old (at least, on the win32 backend) - they should be updated.
Currently, Enso is using (on Windows):
* Cairo v1.0.4
* PyCairo (unknown old version)
Latest versions are:
* Cairo v1.4.8
* PyCairo v1.4.12
With the newer versions, we'd get things like cairo.show_glyphs and
cairo.set_antialias. And of course, a pretty decent performance boost.
While the API additions may or may not be used, the performance benefits
would be great to have (even if we're not *currently* going anything
intensive).
Original issue reported on code.google.com by [email protected]
on 22 Mar 2008 at 10:44
What steps will reproduce the problem?
1. launching enso with a French keyboard setup
What is the expected output? What do you see instead?
Expected output --> pressing 'a' outputs 'a' and not 'q'
What version of the product are you using? On what operating system?
OS X105
Original issue reported on code.google.com by [email protected]
on 31 Oct 2008 at 2:31
At present, spaces in the quasimode aren't visible in any way; for
instance, while in the quasimode, there's no visual distinction between
typing "google" and "google ". This ultimately creates an invisible mode
of sorts, because there's no visual feedback to tell the user whether
they've typed a space or not, which results in mode errors.
A simple solution would be to replace space characters with
vertically-centered dots in the quasimode, highlighting them appropriately
if they're typed vs. auto-completed.
Original issue reported on code.google.com by [email protected]
on 24 Mar 2008 at 4:48
What steps will reproduce the problem?
1. Install Visual Studio 2005 or above
2. Build
3. Fail with a *lot* of warnings that are treated as errors
What is the expected output? What do you see instead?
As of Visual Studio 2005, CRT secure warnings are enforced unless
_CRT_SECURE_NO_WARNINGS is defined.
What version of the product are you using? On what operating system?
Windows. Visual Studio 2008.
Original issue reported on code.google.com by [email protected]
on 22 Mar 2008 at 6:01
Attachments:
Either the README.win32 needs to be updated or you guys don't want us to
play with Enso.
I looked it up and the only way to get this compiler is to find an old
enough book that would have a trial version in a CD.
Original issue reported on code.google.com by [email protected]
on 30 Oct 2008 at 12:00
What steps will reproduce the problem?
Add the following to your ~/.ensocommands:
class DoSomethingCommand(object):
def __call__(self, ensoapi, target):
ensoapi.display_message( "'do something' target is: %s" % target )
class DoSomethingWithCommand(object):
def __call__(self, ensoapi, target):
ensoapi.display_message( "'do something with' target is: %s" % target )
cmd_do_something = DoSomethingCommand()
cmd_do_something_with = DoSomethingWithCommand()
Then run the command 'do something with blah'.
What is the expected output? What do you see instead?
You should get a primary message that says "'do something with' target is:
blah', but instead you get "'do something' target is: with blah".
Original issue reported on code.google.com by [email protected]
on 28 Mar 2008 at 2:35
The following patch implements a very basic define command using dict as
its backend.
Original issue reported on code.google.com by [email protected]
on 13 Mar 2008 at 5:10
Attachments:
When I use the Help command on Windows, Enso crashes with the following
stack trace:
File "C:\Documents and Settings\Jono\My
Documents\enso-open-source\win32\enso_
win32\input\InputManager.py", line 69, in run
def run(*args): return _InputManager.InputManager_run(*args)
File "C:\Documents and Settings\Jono\My
Documents\enso-open-source\core\enso\e
vents.py", line 283, in onKeypress
func( eventType, keyCode )
File "C:\Documents and Settings\Jono\My
Documents\enso-open-source\core\enso\q
uasimode\__init__.py", line 197, in onKeyEvent
self.__quasimodeEnd()
File "C:\Documents and Settings\Jono\My
Documents\enso-open-source\core\enso\q
uasimode\__init__.py", line 337, in __quasimodeEnd
self.__executeCommand( activeCommand, cmdName )
File "C:\Documents and Settings\Jono\My
Documents\enso-open-source\core\enso\q
uasimode\__init__.py", line 360, in __executeCommand
cmd.run()
File "C:\Documents and Settings\Jono\My
Documents\enso-open-source\core\enso\c
ontrib\help.py", line 122, in run
self.__htmlHelp.view()
File "C:\Documents and Settings\Jono\My
Documents\enso-open-source\core\enso\c
ontrib\help.py", line 97, in view
webbrowser.open( fileUrl )
File "C:\Python24\lib\webbrowser.py", line 43, in open
get().open(url, new, autoraise)
File "C:\Python24\lib\webbrowser.py", line 250, in open
os.startfile(url)
WindowsError: [Errno 3] The system cannot find the path specified:
'file://///C|
/docume%7E1/jono/locals%7E1/temp/ensoHelpowrsjz.html'
INFO [Fri Mar 21 12:24:43 2008 src\InputManager\AsyncEventThread.cxx
L249]: a
sync event thread: quit signal received.
INFO [Fri Mar 21 12:24:43 2008 src\InputManager\AsyncEventThread.cxx
L303]: C
losed invisible window.
Original issue reported on code.google.com by [email protected]
on 21 Mar 2008 at 5:28
What steps will reproduce the problem?
1. Build on Windows, linking to a dynamically loaded runtime other than the
one Python uses
2. Run Enso
3. Fail to start - due to different dynamically loaded runtimes in the same
process (fails with cryptic error message)
What is the expected output? What do you see instead?
At the moment, stuff is built with the dynamically loaded multi-threaded
runtime (compiler switch /MD). It should be built with a statically linked
runtime (compiler switch /MT), so that Enso can be run no matter how Python
was built.
What version of the product are you using? On what operating system?
Windows.
Original issue reported on code.google.com by [email protected]
on 22 Mar 2008 at 6:19
Attachments:
A patch to allow Enso commands to be defined in any file contained within a
certain folder, rather than cramming them all into one .ensocommands file.
This makes it easier to distribute one command alone (just save the file
into your Enso commands folder rather than cut-and-pasting its text into
your existing .ensocommands file).
Original issue reported on code.google.com by [email protected]
on 6 Jul 2008 at 8:58
Attachments:
Running r160 in Ubuntu Hardy Heron, enso fails to start up (output attached
below text). Changing line 36 of the file enso/platform/linux/selection.py:
from enso_linux.utils import *
into
from enso.platform.linux.utils import *
fixes the issue.
#############
#############
INFO:root:Skipping provider enso.platform.osx.
INFO:root:Added provider enso.platform.linux.
INFO:root:Skipping provider enso.platform.win32.
INFO:root:Obtained interface 'input' from provider 'enso.platform.linux'.
INFO:root:Obtained interface 'cairo' from provider 'enso.platform.linux'.
INFO:root:Obtained interface 'graphics' from provider 'enso.platform.linux'.
INFO:root:Entering InputManager.run ()
WARNING:root:Error while loading plugin 'enso.contrib.scriptotron'.
Traceback (most recent call last):
File "/home/pooki/enso-read-only/scripts/run_enso.py", line 23, in <module>
enso.run()
File "/home/pooki/enso-read-only/enso/__init__.py", line 54, in run
eventManager.run()
File "/home/pooki/enso-read-only/enso/events.py", line 205, in run
input.InputManager.run( self )
File "/home/pooki/enso-read-only/enso/platform/linux/input.py", line 354,
in run
self.onInit ()
File "/home/pooki/enso-read-only/enso/events.py", line 230, in onInit
func()
File "/home/pooki/enso-read-only/enso/plugins.py", line 93, in _init
module = __import__( moduleName, {}, {}, [] )
File "/home/pooki/enso-read-only/enso/contrib/scriptotron/__init__.py",
line 3, in <module>
from enso.contrib.scriptotron.tracker import ScriptTracker
File "/home/pooki/enso-read-only/enso/contrib/scriptotron/tracker.py",
line 6, in <module>
from enso.contrib.scriptotron.tracebacks import TracebackCommand
File "/home/pooki/enso-read-only/enso/contrib/scriptotron/tracebacks.py",
line 5, in <module>
import enso.selection
File "/home/pooki/enso-read-only/enso/selection.py", line 64, in <module>
__impl = enso.providers.getInterface( "selection" )
File "/home/pooki/enso-read-only/enso/providers.py", line 137, in
getInterface
interface = provider.provideInterface( name )
File "/home/pooki/enso-read-only/enso/platform/linux/__init__.py", line
58, in provideInterface
import enso.platform.linux.selection
File "/home/pooki/enso-read-only/enso/platform/linux/selection.py", line
36, in <module>
from enso_linux.utils import *
ImportError: No module named enso_linux.utils
Original issue reported on code.google.com by [email protected]
on 9 Jun 2008 at 8:13
setup.py is currently only supported on Linux; we need to get it working on
OS X and Windows.
Original issue reported on code.google.com by [email protected]
on 27 Apr 2008 at 12:10
<alt> text is styled black and on Linux without a compositing manager the
"drop down list" of matching valid_args has a black background, making
<alt> invisible. A mini-patch to make <alt> text not be black.
Original issue reported on code.google.com by [email protected]
on 6 Jul 2008 at 9:01
Attachments:
Since we've agreed to use the PEP-8 style guidelines, somebody needs to go
through the existing Python code and convert it all.
Atul Varma has kindly volunteered, so I'm assigning this to him.
Original issue reported on code.google.com by [email protected]
on 21 Mar 2008 at 5:38
Currently on win32, enso/graphics/font.py uses a hard-coded path to the
Arial font file as an argument to cairo.
This is bad. Not only is Arial a horribly ugly font, but this is win32
specific code in the core and it's a hard-coded path which may be incorrect
on some systems.
What we really want is a mini font registry in the win32 implementation of
cairo. Then the Enso core can simply always pass a font name into cairo
and the win32 implementation of cairo can use the font registry to look up
the path to the font file.
Also, the font that Enso uses should be specified in the config file.
Original issue reported on code.google.com by [email protected]
on 21 Mar 2008 at 5:25
What steps will reproduce the problem?
1. Select text in Firefox, that has HTML markup in it
2. Run an Enso command that will try to get the selection
3. Crash
This is a leftover from the old logging module from Frozen Enso - debugMsg
It should be calling logging.debug or logging.info
The attached patch changes from calling debugMsg to calling logging.debug
Original issue reported on code.google.com by [email protected]
on 22 Mar 2008 at 7:26
Attachments:
A patch to make command matching case-insensitive, which makes it a lot
easier to type commands which have uppercase letters in them or in their
valid_args.
Original issue reported on code.google.com by [email protected]
on 6 Jul 2008 at 9:00
Attachments:
The README files were somewhat unclear and in some cases just plain wrong.
Attached is a set of diffs which I hope clarify them. I only worked on the
linux backend, the core, and the toplevel. I don't know if the other
backends are correct or not.
-- William McVey
Original issue reported on code.google.com by [email protected]
on 17 Mar 2008 at 11:32
Attachments:
What steps will reproduce the problem?
1. Build on Windows
2. See errors
3. Curse
This is mostly related to building with version of Visual Studio and
Platform SDK/Windows SDK that SCons doesn't support or doesn't detect
properly. But there are some other issues too.
Note that most of these fixes assume that Visual Studio has set the right
environment variables. Often, vcvarsall.bat needs to be run before hand.
And while these environment variables may exist, doesn't import any of them
unless you do it explicitly.
1. Linker sometimes needs a temp directory to write to
2. Compiler/linker paths not detected
3. Include/lib directories not always detected
Original issue reported on code.google.com by [email protected]
on 22 Mar 2008 at 7:00
Attachments:
What steps will reproduce the problem?
1. Install Swig into a directory with a space (eg, "c:\Program Files\Swig\")
2. Change Swig path in win32\SConstruct
3. Try compiling
4. Fail.
What is the expected output? What do you see instead?
Swig's .exe should be executed with the path enclosed in double quotes - at
the moment it isn't, so fails when the path contains any spaces.
What version of the product are you using? On what operating system?
Windows
Original issue reported on code.google.com by [email protected]
on 22 Mar 2008 at 5:46
Attachments:
What steps will reproduce the problem?
1. Compile win32 backend
2. Run with Python 2.5
3. Imports of compiled modules fail
Python v2.5 on Windows will no longer import modules with the .dll
extension - they need to have the .pyd extension instead.
Thankfully, SCons allows you to easily override the extension for the
output of SharedLibary, via SHLIBSUFFIX
At the moment, this is restricted to:
* the Swig helper script win32/SConsTools/SwigTool.py
* the Cairo build script win32/src/Graphics/cairo/src/SConscript
Quote from Python.org:
Windows: .dll is no longer supported as a filename extension for extension
modules. .pyd is now the only filename extension that will be searched for.
See: http://docs.python.org/whatsnew/ports.html#SECTION0001510000000000000000
Original issue reported on code.google.com by [email protected]
on 22 Mar 2008 at 5:19
Attachments:
What steps will reproduce the problem?
1. select an expression e.g. "2*3"
2. trigger "evaluate" command
What is the expected output?
The selected expression should be evaluated and overwritten. Example above: "6"
What do you see instead?
After triggering the evaluate command the selection is gone leaving the
expression unchanged. Example above: "2*3"
What version of the product are you using?
enso trunk revision 103
On what operating system?
Linux (Gentoo), Xfce
additional information:
The problem here is the set_text function of the pygtk clipboard object.
Nothing is in the clipboard after enso_linux/selection.py:121
clipboard.set_text (seldict["text"])
The xclipboard utility gives a hint (not for me, though!) what could be the
problem here. After the set_text call, xclipboard shows the following error:
CLIPBOARD selection conversion failed
Following lines produce the same xclipboard error directly
import gtk
clipboard=gtk.clipboard_get(selection="CLIPBOARD")
clipboard.set_text("6")
P.S.: Normal Copy&Paste operations work as expected on my system.
Original issue reported on code.google.com by [email protected]
on 21 Mar 2008 at 11:37
What steps will reproduce the problem?
1. Compile Enso on WindowsXP, using MS Windows Server 2008 SDK
2. Run Enso
What is the expected output? What do you see instead?
The colors of the main semi-transparent window are just wrong,
it seems it is not semitransparent but instead it just re-colors
the background, see the attached screenshots.
The background for the list of matches is missing, only white
text is visible.
What version of the product are you using? On what operating system?
Latest source from SVN
Windows XP SP2
Litestep shell
Please provide any additional information below.
I do not have that problem with frozen Enso version.
Original issue reported on code.google.com by [email protected]
on 26 Mar 2008 at 12:44
Attachments:
Running Enso (r. 160) on Kubuntu Hardy Heron. On a dual-monitor setup (set
up using urandr), Enso windows calculate position based on the entire
viewport. Thus, centered windows show up split with two halves on the
inside edge of the two monitors.
Here is my proposed patch, though I'm new to python so you'll have to
excuse anything I break. However, on my system, Enso windows show up on
the monitor that the mouse cursor is currently on. The patch covers
multiple files, but also includes Stuart Langridge's 3 patches (I'm also
new to svn, and my local setup uses his code, and I'm not sure how to
separate them all).
The patch will break Windows and OSX versions, as their
platform/graphics.py doesn't have my new getDesktopOffset() function.
Adding in a dummy function to return (0,0) should do the trick. Also,
instead of using the mouse cursor, it would probably be more 'humane' to
find the monitor where the cursor (or window) focus is on. I haven't
figured out how to do that yet.
Original issue reported on code.google.com by [email protected]
on 24 Jul 2008 at 9:10
Attachments:
What steps will reproduce the problem?
1. Using enso_linux, open the quasimode window (caps lock)
2. Hit the del key
3. enso crashes.
What is the expected output? What do you see instead?
No crash, maybe an output in the terminal I'm running enso from:
INFO:root:Deleting the quasimode window.
What version of the product are you using? On what operating system?
Latest trunk both for enso and enso_linux
Please provide any additional information below.
Traceback (most recent call last):
File "threading.py", line 460, in __bootstrap
self.run()
File "/home/matsubara/devel/enso/trunk/linux/enso_linux/input.py", line
149, in run
self.__callback (make_event ("quasimodeEnd"))
File "/home/matsubara/devel/enso/trunk/linux/enso_linux/input.py", line
265, in __keyCallback
KEYCODE_QUASIMODE_END)
File "/home/matsubara/devel/enso/trunk/core/enso/events.py", line 283, in
onKeypress
func( eventType, keyCode )
File "/home/matsubara/devel/enso/trunk/core/enso/quasimode/__init__.py",
line 199, in onKeyEvent
self.__quasimodeEnd()
File "/home/matsubara/devel/enso/trunk/core/enso/quasimode/__init__.py",
line 342, in __quasimodeEnd
self.__showBadCommandMsg( userText )
File "/home/matsubara/devel/enso/trunk/core/enso/quasimode/__init__.py",
line 386, in __showBadCommandMsg
messages.displayMessage( text )
File "/home/matsubara/devel/enso/trunk/core/enso/messages/__init__.py",
line 432, in displayMessage
MessageManager.get().newMessage( msg )
File "/home/matsubara/devel/enso/trunk/core/enso/messages/__init__.py",
line 330, in newMessage
self.__newPrimaryMessage( msg )
File "/home/matsubara/devel/enso/trunk/core/enso/messages/__init__.py",
line 406, in __newPrimaryMessage
self.__primaryMsgWind.setMessage( msg )
File
"/home/matsubara/devel/enso/trunk/core/enso/messages/primarywindow.py",
line 146, in setMessage
self.__drawMessage()
File
"/home/matsubara/devel/enso/trunk/core/enso/messages/primarywindow.py",
line 259, in __drawMessage
height )
File
"/home/matsubara/devel/enso/trunk/core/enso/messages/primarywindow.py",
line 330, in __layoutText
ellipsify = "true",
File
"/home/matsubara/devel/enso/trunk/core/enso/messages/primarywindow.py",
line 504, in layoutMessageXml
_tagAliases
File
"/home/matsubara/devel/enso/trunk/core/enso/graphics/xmltextlayout.py",
line 707, in xmlMarkupToDocument
xml.sax.parseString( text, xmlMarkupHandler )
File "/usr/lib/python2.5/site-packages/_xmlplus/sax/__init__.py", line
47, in parseString
parser.parse(inpsrc)
File "/usr/lib/python2.5/site-packages/_xmlplus/sax/expatreader.py", line
109, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/usr/lib/python2.5/site-packages/_xmlplus/sax/xmlreader.py", line
123, in parse
self.feed(buffer)
File "/usr/lib/python2.5/site-packages/_xmlplus/sax/expatreader.py", line
220, in feed
self._err_handler.fatalError(exc)
File "/usr/lib/python2.5/site-packages/_xmlplus/sax/handler.py", line 38,
in fatalError
raise exception
SAXParseException: <unknown>:1:53: reference to invalid character number
Original issue reported on code.google.com by [email protected]
on 13 Mar 2008 at 1:01
At the moment, Enso is using the HOME environment variable to get the
user's home/profile directory - unfortunately, this doesn't exist in
Windows. Therefore, it needs to be delegated to the platform-specific backends.
My recommendations are as follows:
* On Linux (and probably OSX?): $HOME/.enso/
* On Windows: $APPDATA\Enso\
I suggest a Enso-specific sub-directory so that Enso doesn't pollute the
user's home directory. Plugins should be able to write to this directory -
saving settings, saving data related to learning, etc.
The backends will therefore need to implement a new provider interface, as
the existing ones don't fit with this functionality.
Original issue reported on code.google.com by [email protected]
on 25 Mar 2008 at 10:32
Enso could really use a better calculate command which supports square
roots, sin, cos, etc... As a programmer, these additional features would
really come in handy.
Original issue reported on code.google.com by [email protected]
on 1 May 2008 at 11:06
What steps will reproduce the problem?
1. Go to http://ensowiki.com
- Expected to see wiki content but all content seems to be deleted (only blank
page presented)
- Contents were there late Jan 2011, early Feb 2011
Original issue reported on code.google.com by [email protected]
on 26 Feb 2011 at 6:32
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.