jparris / enso Goto Github PK

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.

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.

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.

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.

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

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.

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

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.

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.

setup.py is currently only supported on Linux; we need to get it working on
OS X and Windows.

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

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.

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.

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.

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".

The following patch implements a very basic define command using dict as
its backend.

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.

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.

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

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

<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.

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

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

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.

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).

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

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).

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