Re: Failed unit tests on Linux
On Thu, Mar 6, 2008 at 7:13 PM, Edward K. Ream [EMAIL PROTECTED] wrote: In short, all OS's are, or can be made to be, pretty much the same. That being so, Linux does indeed have real advantages for programmers. It's so cool to be able to enable thousands of packages from the package manager. Linux has real advantages for normal users as well; the most prominent probably being the unix file system approach. You can remove/rename an open file without problems. On windows, you can't even rename a *directory* when one file under it is open somewhere. Quite often one has to log off windows to accomplish something simple such as renaming that directory. Not to mention the flexibily of symlinks that can cross file systems (as opposed to NTFS junctions), the fragility of drive letter based file system (with various SUBST hacks) etc. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Embedding Leo to IPython
On Sun, Mar 30, 2008 at 3:57 PM, Ville M. Vainio [EMAIL PROTECTED] wrote: It seems embedding leo to ipython is a trivial task - you just %run leo.py. Then, in leo ipython plugin, you can get the handle by Well, it seems it was not as trivial as I figured, from users point of view. You currently need to do the following to embed leo in existing ipython session: import IPython.Shell IPython.Shell.hijack_tk() %run leo.py (in leo/leo/src) When leo is installable as a package, this will be much simpler (because we don't need to know where leo.py is). We can just do magic command %leo that hijacks tk, launches leo, and possibly also does launch-ipython inside the leo session (that should be possible, right?). The implementation of the support for this was trivial: http://bazaar.launchpad.net/~leo-editor-team/leo-editor/trunk/revision/240 -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Making Leo a package
On Tue, Apr 1, 2008 at 7:04 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Now, after stepping through the code a few times, I have a much better feel for what the code is intending to do. I can return to the sources to look for clues. My first guess is that the atrociously- documented options are the place to start looking for relief. Rather than read the worse-than-useless docs, I plan to read the actual code. I don't think you should spend so much time with distutils - it kind of expects that it's used as it's supposed to, and fooling around too much can cause problems later on (e.g. in different platforms). I think that setuptools is a much better bet: http://peak.telecommunity.com/DevCenter/setuptools Also, if you want to debug it, there's a much better chance of getting your code/feature requests in. Duh! leo.__init__.py is not sufficient to start Leo! You have to do: import leo.src.leo leo.src.leo.start() (or something, can't check right now). And indeed, you don't even have to copy the files to site-packages; you can try creating a launchleo.py script in leo root folder, and see what you have to do there to get going. Kind of like the ipython.py in the IPython source distribution root directory. setuptools also supports python setup.py develop, which acts like the package is in site-packages, even if it isn't. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Making Leo a package
On Tue, Apr 1, 2008 at 8:46 PM, Edward K. Ream [EMAIL PROTECTED] wrote: I think that setuptools is a much better bet: http://peak.telecommunity.com/DevCenter/setuptools Thanks for this reminder. I've looked at it in the past and it looked good. But then, don't users have to install setuptools first? Yes; however, requiring setuptools is quite normal in python world these days (and ez_setup.py bootstrap script makes it trivial). It should be ok to require setuptools for installation-as-package; people who don't want to do that can run the source distribution created by bzr export directly. leo.src.leo.start() # EKR: should be leo.src.leo.run() leo.src.leo.run() fails: g.app isn't defined in the plugins. No doubt this is a subtle import problem. At least I'm debugging my own code :-) Yeah, that's usually the right place to start ;-) I think your suggestion to change leo/src to leo/core is a good one. I suspect, though, that making Leo into a proper package, with 'core' and 'plugins' (etc.) subpackages, probably should wait until 4.4.8 final. Would that be a hardship for you, Ville? Not at all. The IPython embedding use case is easily solved by doing an ipython macro (as I described in the docs), so this can take the time it needs. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Making Leo a package
On Tue, Apr 1, 2008 at 9:04 PM, Kayvan A. Sylvan [EMAIL PROTECTED] wrote: Although I can't figure out where ipython stored the macro in my Windows box. :-) Ville, can you point me to the right file? They are stored in a pickleshare database that IPython uses for all persistent stuff. Explore the ~/_ipython/db directory. Observant reader may guess that it contains pickles ;-). If you want the contents of the database in a more readable format, you can do: import ipy_exportdb ipy_exportdb.export() -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Making Leo a package
On Wed, Apr 2, 2008 at 2:38 AM, Edward K. Ream [EMAIL PROTECTED] wrote: I'm not sure what the solution is. Possibly all Leo imports will have to be changed from: import leoX to import leo.core.x. Yes. Fully qualified imports will be made mandatory in the future anyway, IIRC. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Leo 4.4.8 final is on the trunk. Pls test
On Sun, Apr 6, 2008 at 11:12 AM, Ville M. Vainio [EMAIL PROTECTED] wrote: On Sun, Apr 6, 2008 at 12:16 AM, Edward K. Ream [EMAIL PROTECTED] wrote: On second thought, let's leave the trunk branch as it is--for development. I'll create a 'stable' branch that corresponds to the latest official release, plus any bug fixes. The advantage of leaving the trunk branch alone is that nobody's work flow will have to change. Yeah, and it's more in line with traditional concept of trunk. BTW, there seems to be a problem; ipython.py plugin does not work. I get: @enabled-plugins found in myLeoSettings.leo ipython plugin: can not import IPython.ipapi ipython plugin: can not import IPython.Shell.IPShellEmbed I'm investigating the issue. Seems that sys.path is broken when leo is starting up: ['C:\\p\\leo\\leo\\src', 'C:\\opt\\PyGTK\\Python\\python25.zip', 'C:\\opt\\PyGTK\\Python\\DLLs', 'C:\\opt\\PyGTK\\Python\\lib', 'C:\\opt\\PyGTK\\Python\\lib\\plat-win', 'C:\\opt\\PyGTK\\Python\\lib\\lib-tk', 'C:\\opt\\PyGTK\\Python', 'C:\\opt\\PyGTK\\Python\\lib\\site-packages', u'C:\\p\\leo\\leo', u'C:\\p\\leo\\leo\\config', u'C:\\p\\leo\\leo\\doc', u'C:\\p\\leo\\leo\\extensions', u'C:\\p\\leo\\leo\\modes', u'C:\\p\\leo\\leo\\plugins', u'C:\\p\\leo\\leo\\test'] It's missing all the fundamental stuff, normal sys.path is: ['', 'c:\\python25\\lib\\site-packages\\docutils-0.4-py2.5.egg', 'c:\\python25\\lib\\site-packages\\matplotlib-0.91.2-py2.5-win32.egg', 'c:\\python25\\lib\\site-packages\\numpy-1.0.4-py2.5-win32.egg', 'c:\\ipython', 'c:\\python25\\lib\\site-packages\\sphinx-0.1.61611-py2.5.egg', 'c:\\python25\\lib\\site-packages\\pygments-0.9-py2.5.egg', 'c:\\python25\\lib\\site-packages\\zc.buildout-1.0.1-py2.5.egg', 'C:\\Windows\\system32\\python25.zip', 'c:\\python25\\DLLs', 'c:\\python25\\lib', 'c:\\python25\\lib\\plat-win', 'c:\\python25\\lib\\lib-tk', 'c:\\python25', 'c:\\python25\\lib\\site-packages', 'c:\\python25\\lib\\site-packages\\PIL', 'c:\\python25\\lib\\site-packages\\gtk-2.0', 'c:\\python25\\lib\\site-packages\\wx-2.8-msw-unicode'] I wonder whether pygtk installation broke this... -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Leo 4.4.8 final is on the trunk. Pls test
On Sun, Apr 6, 2008 at 4:08 PM, Edward K. Ream [EMAIL PROTECTED] wrote: I wonder whether pygtk installation broke this... Should I hold 4.4.8 final until you resolve this? No. It was PyGtk installation that broke it (it installed a new version of python, no less!). -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Leo 4.4.8 final is on the trunk. Pls test
On Sun, Apr 6, 2008 at 6:54 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Thanks for these replies. Leo 4.4.8 will go out the door today. To complement Leo 4.4.8, there is also compatible IPython (rc1 of python 0.8.3 - I don't foresee anything new going in) available at: https://launchpad.net/ipython/stable/0.8.3pre -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Bzr guide in leodocs
I added a short bzr guide to LeoDocs, but didn't push it yet (because the trunk was reverted). Here is the guide (with some hard-earned information ;-), it will be on trunk later. - Many users will want to track the development version of Leo, in order to stay on top of the latest features and bugfixes. Running the development version is quite safe and easy, and it's also a requirement if you want to contribute to Leo. 1. First, you need to get Bazaar (bzr) from http://bazaar-vcs.org. For windows users we recommend the standalone installer - the python installer may have problems pushing to Launchpad. Plain bzr installer only contains the command line version, so you might want to augment that with a friendly GUI - qbzr is recommended as it's the easiest one to install. It provides command like ``bzr qlog``, ``bzr qannotate`` etc. 2. Get Leo from launchpad by doing:: bzr branch lp:leo-editor And that's it! You can run leo/src/leo.py directly. When you want to refresh the code with latest modifications from Launchpad, run ``bzr pull``. If you make modifications to Leo (with the interest in sharing them with the Leo community), you can check them in to your local branch by doing ``bzr checkin``. Now, to actually request your changes to be merged to Leo trunk, you need a Launchpad account with RSA keys in place. There is showmedo video about how to accomplish this on Windows using puttygen and pageant at ``http://showmedo.com/videos/video?name=1510070fromSeriesID=151``. After your Launchpad account is set up, go to ``https://launchpad.net/leo-editor``, choose Code tab - Register Branch, select Branch type Hosted and fill in descriptive details about the branch. After that, go to the branch home page from Code tab again, and copy-paste the push command line to terminal. For example, for branch:: https://code.launchpad.net/~leo-editor-team/leo-editor/mod_rclick The push command is:: bzr push bzr+ssh://[EMAIL PROTECTED]/~leo-editor-team/leo-editor/mod_rclick You may wish to add --remember command line option to bzr push, to direct all future pushes to that location. Then, you only need to execute ``bzr push``. After your branch is pushed, you can email the Leo mailing list and request it to be reviewed and merged to trunk. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Implementing half-assed collaboration support
Here's a stopgap measure to survive 2 people editing the same .leo file, with very little coding - Suppose 2 people (A and B) have foo.leo open - A edits node with gnx 1 and saves the document. A also adds a new node with gnx 3. - B edits node with gnx 2, but is alarmed that document has been saved after he opened it, and leo suggests doing File - Merge changes - B does 'merge changes', which results in the xml of foo.leo being parsed (but the document is NOT opened). - We note that there is a new node (with gnx 3). We also know the headline. We just add the new node as a child under of a top level AUTOMERGE node - We note that node with gnx 2 has been medified. If it's not dirty, just update B's document. If it's dirty, add a new node or conflict markers And we are done! Of course the merge can be generalized to merging from any file. This should be easy to code, and can be done from a plugin. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Implementing half-assed collaboration support
On Thu, Apr 10, 2008 at 5:05 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Here's a stopgap measure to survive 2 people editing the same .leo file, with very little coding I'm not sure I understand the problem you are trying to solve. Two people editing the same .leo file in network share. There is no version control system involved. bzr will warn about conflicts in .leo files. In a collaborative environment, all data should be in thin derived files. The reference .leo That's too much overhead for an outline/mindmap/whatever. This is not really about programming tasks. files hardly ever change, the corresponding local .leo files can have whatever people want. Yeah, but here the reference leo file is all there is. Perhaps more importantly, Leo's compare-leo-outlines command was designed to handle cvs conflicts. It compares the present outline with another, and creates clones of all inserted, deleted and changed nodes. Might this be a good starting point for you? Yes, sounds like it. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: A more philosophical question
On Thu, Apr 10, 2008 at 7:16 PM, Kayvan A. Sylvan [EMAIL PROTECTED] wrote: with my python code (import a file, play with its classes, test out my ideas), then update the code in Leo and back in ILeo, just reload the module and continue playing, ad infinitum. I get all the power of IPython (tab You'll probably want to check out the new ipy_autoreload extension, do this to get help: [C:opt/Console2]|3 import ipy_autoreload [C:opt/Console2]|4 %autoreload? I want to publicly thank Edward and Ville for their work on integrating Leo and IPython. ILeo makes programming in python very fun! Thank you - this is indeed a great enabler and removes a crucial can't get there from here :-) -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Intrepid testers of the sax-graph branch wanted
On Mon, May 5, 2008 at 5:50 PM, Edward K. Ream [EMAIL PROTECTED] wrote: The sax-graph branch is ready for testing by those who don't mind the risk of the occasional crash :-) I am now using the code in the sax- Here's one way to choke it: - Launch ipython plugin with alt + I - On ipython prompt, enter command wb.foo.v = 1 The IPython command returns, but leo event loop is dead (window is not responding) -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Printing a .leo file / export to html
On Mon, May 5, 2008 at 11:53 PM, Kayvan A. Sylvan [EMAIL PROTECTED] wrote: Hmmm... So you must have a bad @enabled-plugins in your myLeoSettings Compare against the one in LeoSettings and set it up accordingly. Yeah, that worked. I always forget that @enabled-plugins are not loaded incrementally. Btw, anyone else have the problem in sax branch where the menu items don't draw before you use the mouse over them, immediately after launching Leo? The menu bar itself is correctly displayed, but not the menu pane. This is on Vista. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Lite-leo with Qt4 using leoBridge
Now shoot this down if it's a nonworkable idea: What if someone (say, me ;-) decided to port leo to pyqt4, but not really port the source code - rather, implement a new GUI on top of leoBridge? This would not need to be a full-blown leo; just something simple that displayed the outline in a tree widget, and the body area using a code editor. This could be useful because: - It will help exploration of a full-blown qt port - Qt is much faster than Tk - It would run on mobile phones (my mobilileo miniproject is read-only view of the .leo file) - It should be easier than a full port (judging by the fact that gtk / wx ports have been attempted but not completed) - Qt rocks, and these days (Qt4) it's GPL on all platforms. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Lite-leo with Qt4 using leoBridge
On Thu, May 15, 2008 at 4:23 PM, Edward K. Ream [EMAIL PROTECTED] wrote: This is an initialization problem. Plugins must be careful to load first so they can set the gui. You can't be using the nullGui, because nullGui.get_focus is: def get_focus(self,frame): return self.focusWidget or (hasattr(frame,'body') and frame.body.bodyCtrl) or None Actually, it isn't. It's (in leo trunk): def get_focus(self,frame): return self.focusWidget or frame.body.bodyCtrl (leoGui.py, line 546) And this causes the crash. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Lite-leo with Qt4 using leoBridge
On Thu, May 15, 2008 at 7:48 PM, Edward K. Ream [EMAIL PROTECTED] wrote: I see. Apparently I made a recent change to nullGui.getFocus in the key-handling branch. The code I suggested should work. Feel free to modify the trunk. Done. I get another crash, though (every line is twice): QQQ wrote recent file: /home/ville/.leoRecentFiles.txt saved: Komodo.leo exception writing derived files Traceback (most recent call last): Traceback (most recent call last): File /home/ville/leo-editor/leo/src/leoFileCommands.py, line 2112, in write_Leo_file changedFiles,atOk = c.atFileCommands.writeAll() File /home/ville/leo-editor/leo/src/leoFileCommands.py, line 2112, in write_Leo_file changedFiles,atOk = c.atFileCommands.writeAll() File /home/ville/leo-editor/leo/src/leoAtFile.py, line 2190, in writeAll if p.isAnyAtFileNode() or p.isAtIgnoreNode(): File /home/ville/leo-editor/leo/src/leoAtFile.py, line 2190, in writeAll if p.isAnyAtFileNode() or p.isAtIgnoreNode(): File /home/ville/leo-editor/leo/src/leoNodes.py, line 1164, in isAtIgnoreNode def isAtIgnoreNode (self): return self.v.isAtIgnoreNode() File /home/ville/leo-editor/leo/src/leoNodes.py, line 1164, in isAtIgnoreNode def isAtIgnoreNode (self): return self.v.isAtIgnoreNode() File /home/ville/leo-editor/leo/src/leoNodes.py, line 461, in isAtIgnoreNode flag, i = g.is_special(self.t._bodyString, 0, @ignore) File /home/ville/leo-editor/leo/src/leoNodes.py, line 461, in isAtIgnoreNode flag, i = g.is_special(self.t._bodyString, 0, @ignore) File /home/ville/leo-editor/leo/src/leoGlobals.py, line 3504, in is_special if g.match_word(s,i,directive): File /home/ville/leo-editor/leo/src/leoGlobals.py, line 3504, in is_special if g.match_word(s,i,directive): File /home/ville/leo-editor/leo/src/leoGlobals.py, line 3548, in match_word if s.find(pattern,i,i+j) != i: File /home/ville/leo-editor/leo/src/leoGlobals.py, line 3548, in match_word if s.find(pattern,i,i+j) != i: AttributeError: find AttributeError: find saved: Komodo.leo QQQ I need to explore it a bit more later. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: leo-as-a-package issues possible solutions
On Sun, May 18, 2008 at 11:02 PM, Edward K. Ream [EMAIL PROTECTED] wrote: 2. We will change all imports from import leoX to import leo.core.leoX. Or, perhaps less intrusively (sourcecodewise), from leo.core import leoX, as you mention later on. Requirement 2. We have got to be able to override the Leo package defined in site-packages. That is, even if Leo is truly installed as a package, we must be able to run Leo from a bzr branch. Python This works if you have a small leo launch script in bzr root. In ipython we have ipython.py at root of the source distribution, and it just does the import and launch. Also, you can benefit from setuptools here. See e.g. eggsetup.py in ipython. If you do 'python eggsetup.py develop, a small wrapper will be installed in site-packages and all places that import the leo package will see the bzr checkout. In short: A: We must rename leo.py. Very true. B: We can simulate Leo being a package by having sitecustomize.py place leo.repo\leo-as-a-package in sys.path. Or just having the script that does the import in source root folder. C: All imports in Leo, wherever they may be, will use fully-qualified imports such as import leo.core.leoGlobals as g. This should ensure sanity and consistency. I think you meant from leo.core import leoGlobals as g. These imports are all different because they put three different entries in sys.modules. The keys in sys.modules are respectively leoGlobals, core.leoGlobals and leo.core.leoGlobals. I have no idea whether this could be called a bug (I kinda doubt it), but it means that all imports in Leo must use exactly the same scheme. This is a misfeature in python, but the plan is to require fully qualified import for package modules anyway (but of course that will break lots of stuff). See http://www.python.org/dev/peps/pep-0328/ esp. the part about from __future__ import absolute_import -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: does leo support large project
On Tue, May 27, 2008 at 4:12 PM, Edward K. Ream [EMAIL PROTECTED] wrote: There are various possible ways to speed up loading a large number of files. The most effective ways might take a *lot* of work: - Rewrite the read code in pyrex to get C-like speed. - Represent the Leo outline as a zodb database. Considerable support for this already exists. - Use pickle to preserve a large project: reading would be replaced by unpickling. Since it's most probably an I/O bound operation, I think the biggest win would still be lazy nodes (which, as said before, is not easy). Conceivably, if you sacrifice DOM that always has globally correct information, you could have the browsing usability of today's leo long before the whole document has been parsed, by swallowing only the node info that is needed at the particular tree level. I wonder if mxTextTools tagging engine could be used to speed up post-xml phase (parsing @auto nodes)... http://www.egenix.com/products/python/mxBase/mxTextTools/ -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: does leo support large project
On 5/28/08, Edward K. Ream [EMAIL PROTECTED] wrote: - Reading files in the background is tricky. In particular, iterators must be aware that parts of the tree haven't been fully read. Perhaps it might be feasible to read in and parse the files in multiple processes using the processing module + mxTextTools. That way, the file I/O could be performed while the parsing is taking place. There are some pretty fascinating benchmarks at the PEP for processing: http://www.python.org/dev/peps/pep-0371/ The interaction would not be enabled before the file processing is done, so the DOM would be complete when interactive mode is entered. Important: zodb is appealing because it has *already* solved the problem of converting a cache (the zodb) to Leo's dom. That is, when ZODB is essantially a pickle on steroids, so I don't see it solving the performance problem... Anyone ran a large leo file reading in profiler? -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
setuptools setup.py for leo-as-package
Attached is a setup.py that almost works.
The problem is that extensions like pmw are not installed by it.
You can try it by installing setuptools and running python setup.py install.
On windows it should create leo.exe, but you will see the errors
better if you run python c:\python25\scripts\leo-script.py
--
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---
from setuptools import setup,find_packages
setup(
name = 'leo-editor',
version = 0.1,
author = Edward Ream,
author_email = '[EMAIL PROTECTED]',
url = 'http://foo.com',
packages =find_packages(),
description = 'Literate editor with outlines',
long_description = blah blah
,
entry_points = {
'console_scripts': [
],
'gui_scripts' : [
'leo = leo.core.runLeo:run'
]
}
)
Re: setuptools setup.py for leo-as-package
On Thu, May 29, 2008 at 2:53 PM, Ville M. Vainio [EMAIL PROTECTED] wrote: Attached is a setup.py that almost works. Note that setup.py develop does work. I.e. if you run that and launch python c:\python25\scripts\leo-script.pyw, leo is launched properly. develop means use the leo in the source code location as the global leo package, which means it uses the package directly from bzr branch - which is probably what the developers will want, as opposed to running setup.py install every time you want to try it out. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
headline editing home and end keys
It seems it would be very handy / intuitive if home and end keys acted in typical fashion (beginning of line / end of line), instead of terminating the headline editing mode. Also, now that the code in the area has been tweaked a bit, would it be possible to make esc cancel the headline edit? -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Read stats
On Fri, May 30, 2008 at 5:26 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Actually, I am in the midst of a small detour. I am busy subclassing Python's bdb.Bdb debugger so that it keeps track of the tree of calls. This would be useful, say, if I decided to rewrite all of leoAtFile.py using pyrex. We want to know all the methods called by at.readAll, for example, including calls to functions in leoGlobals.py. To avoid boundary overhead we would want to rewrite just about everything in the call tree. I still think you should try mxTextTools first. Pyrex would suck in the sense of making part of leo code not be pure python. Additionally, I think the performance of pyrex would be worse than the mxtexttools approach. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Read stats
On Fri, May 30, 2008 at 5:46 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Additionally, I think the performance of pyrex would be worse than the mxtexttools approach. I find this statement hard to believe. How can mxTextTools do the code generation part? What do you mean by code generation? As I understand it, mxtexttools is just a set of rules that would be executed completely inside C extension without popping back to python in between. It's optimized for this kind of task, and probably has a streamlined implementation. Of course the only way to know for sure is to try it out... -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: $200 reward for gui plugins
On Fri, Jun 6, 2008 at 5:36 PM, Edward K. Ream [EMAIL PROTECTED] wrote: P.S. It is my present opinion that wxWidgets is not capable of supporting a proper gui plugin for Leo I won't reject such a plugin-- in fact I would love to have such a critter, but you should be aware that I have failed more than once in the attempt. So this would be a *high* risk project. OTOH I would reward it highly. If it can't do that, could it be that something may be a bit off in Leo's UI asbtraction. Of course the problem is non-trivial as well. I am asking this because I'm wondering about the feasibility of pyqt plugin... and I thought lots of stuff could be simpler. The tree view for example, there is lots of manual drawing code when you'd get around with stock qt treeview stuff (non-readonly). -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: $200 reward for gui plugins
On Tue, Jun 10, 2008 at 12:13 AM, Ville M. Vainio [EMAIL PROTECTED] wrote: I am asking this because I'm wondering about the feasibility of pyqt plugin... and I thought lots of stuff could be simpler. The tree view for example, there is lots of manual drawing code when you'd get around with stock qt treeview stuff (non-readonly). I guess what I'm saying is - we should probably should not implement all of leo, but let the features of stock controls do most of our work. QScintilla would do all the code coloration, tree view would be connectected to QAbstractTreeModel that exposes the leo outline in editable form, etc. We just treat Leo itself as a model and create some kind of UI on top of that. E.g. key bindings would not be immediately set like they should, but it could lead to cleanups and removal of assumptions on many fronts. What I'm talking about is much more loosely coupled GUI + model, with some loss of functionality, and in the meantime increased performance when more stuff happens on native C++ widget code side. Note that I'm not after the $200 reward, but interested in the idea of the Qt GUI. I'm too busy to plunge into this right now, but just some food for thought for others... Here's an example of editable tree with c++ code - pyqt code is pretty much the same: http://doc.trolltech.com/4.4/itemviews-editabletreemodel.html -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: $200 reward for gui plugins
On 6/10/08, Pieter [EMAIL PROTECTED] wrote: I once thought about a PyQt frontend also. However, when I looked into the Leo PyGTK code a few months ago, it seemed that the current GUI code does not follow a Publisher - Subscriber pattern, or something remotely related. It seemed that to build a PyQt GUI lots of PyQt Yeah, it (the gtk plugin) didn't seem to use publish-subscribe and MVC structure (for outline tree view), which kind of raised some concerns for me about how easy / fun it would be. It should be easy to get SOME kind of gui going, so you can start dogfooding immediately. Perhaps we could try adding a publish / subscribe (via pydispatcher?) and mvc functionality, which could be used to develop the new frontends... and then add features to those as need arises (we want to implement more features). Note that adding those would not disrupt the current tk leo. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: $200 reward for gui plugins
On Tue, Jun 10, 2008 at 5:13 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Again, I have lots of experience in this area. I think you may as well accept the fact the present framework is about the simplest and best that we are likely ever to see. I can easily trust your experience with this, but I don't believe what we have is the simplest thing that could possibly work. I have to admit that I haven't dwelled on the code in-depth, but when I saw words like drawline and canvas in tree widget, I basically gave up - I just don't want to get this close to the metal as far as drawing goes, and it makes me doubt how portable or fast it's ever going to be (without writing too much custom drawing code). I can't help thinking that since the whole outline structure could be represented in standard tree widget with strings and icons, there has to be simpler way around. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: $200 reward for gui plugins
On Tue, Jun 10, 2008 at 5:36 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Ville, you are completely misunderstanding the task at hand. The task is not to duplicate the Tk code, which is *extremely* complex. The task is to implement c.frame.tree.redraw_now. How you do that is up to you. If the gui supports a capable tree widget, the obvious first choice is to let the tree widget do as much of the work as possible. Ah, *now* we are talking. I don't think there is any code that needs to be written to implement tree redraw because most tree widgets should handle that automatically. This should be almost trivial. Here's how I did it in qleolite (http://bazaar.launchpad.net/~villemvainio/leo-editor/qleolite/files): 55 def populate_tree(self, parent=None): 56 Render vnodes in tree 57 58 for p in c.allNodes_iter(): 59 parent = self.items.get(p.parent().v, self.treeWidget) 60 it = QTreeWidgetItem(parent) 61 self.items[p.v] = it 62 self.treeitems[it] = p.t 63 it.setText(0, p.headString()) Of course we would need to add icons as well, but that is trivial as well. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: $200 reward for gui plugins
On Tue, Jun 10, 2008 at 6:14 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Exactly this kind of code failed with wx, iirc because there were allocation problems related to the wx items, 'it' in this code. I kept taking segfaults when accessing items that should have existed. No matter how I tried to baby the widget it always messed up. In general I *would* expect this kind of code to work. Indeed, the job of any tree widget is to manage it's own internal data properly! In particular, it should be able to handle large changes gracefully. But that is hardly a foregone conclusion... For large data sets, this should be implemented with Qt's mvc structure that only creates items when they are needed. This would probably be *the* optimal (memory consumption / performance) appoach. One of these days I will rewrite QLeoLite to use QTreeView and QAbstractItemModel. It should map quite directly to leo's data model. I'm not sure what I should do with rest of full leo (as opposed to leobridge) though - i.e. how keybindings will map, etc. This is why I'm thinking of lite approach, we should be able to make some compromises where necessary, regarding how all of it works. QTreeView will handle the tree, QScintilla will handle the text editor, but much of the stuff that relates to user interaction would not work. The important stuff (buttons, menus, scripts) should still be pretty easy to implement, but may require some decoupling from the UI. OTOH I'm quite ready to wait for another GUI plugin to emerge, to make all of this easier. Somehow I feel this may be an intimidating chore, whereas qleolite (that used leobridge) was 100 lines + the stuff autogenerated by Qt ui designer... -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Read stats
On Fri, May 30, 2008 at 4:45 AM, Edward K. Ream [EMAIL PROTECTED] wrote: 58590.0840.0000.1650.000 leoAtFile.py: 1079(readEndNode) 430.5310.0126.5640.153 leoAtFile.py: 744(scanText4) Judging by the cumulative time taken by scanText4, it does seem rewriting this to use mxTextTools might help. Some easier optimizations you may also want to do to this func: while at.errors == 0 and not at.done: s = at.readLine(theFile) self.lineNumber += 1 if len(s) == 0: break kind = at.sentinelKind4(s) # g.trace(at.sentinelName(kind),s.strip()) if kind == at.noSentinel: i = 0 else: i = at.skipSentinelStart4(s,0) func = at.dispatch_dict[kind] func(s,i) Store all the attributes to local variables skind = at.sentinelKind noSent = at.noSentinel skips = at.skipSentinelStart4 ddict = at.dispatch_dict I suppose the same could be done for lineNumber. I suppose the repeated toUnicode stuff in readLine slows it down too. Perhaps there should be short circuit for files that are plain ascii. It may also be significantly faster to convert the whole file in one swoop, as opposed to doing it line-by-line. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
Re: problems using leo-4-5-b1 install script on linux
On Wed, Aug 20, 2008 at 5:05 PM, Edward K. Ream [EMAIL PROTECTED] wrote: We have gone around and around with the linux install script. I'd rather not change it at all unless absolutely required. I don't see a need for that install script at all, really. There are currently 2 alternative linux installation routes, both of which are simpler than what is done in the install script: 1) Install leo as library (currently only used by %lleo in ILeo, but other uses may surface in the future): - Have setuptools installed (in ubuntu this means sudo apt-get install python-setuptools) - Run python setup.py develop Now, you'll have /usr/bin/leo that launches leo. 2) Do not install leo: - Just run launchLeo.py from the root directory where you extracted the tarball. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: setup.py develop: leo-as-package works as it should
On Wed, Aug 20, 2008 at 7:39 PM, Edward K. Ream [EMAIL PROTECTED] wrote: On Aug 16, 1:16 am, Ville M. Vainio [EMAIL PROTECTED] wrote: Hmm. It looks like I'm going to have to come to speed on ileo. This one is very easy to reproduce: I hope to fix this today. Is this issue going to affect IPython 0.9? I don't think so - it's the exact same lines as in launchLeo, so the launching in ipython should be exactly like that. It's just a leo bug/issue... -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: setup.py develop: leo-as-package works as it should
On Wed, Aug 20, 2008 at 9:07 PM, Edward K. Ream [EMAIL PROTECTED] wrote: On my machine I must start ipython from c:\leo.repo\trunk, the top-level directory for the bzr trunk branch. I presume that this is because I don't put any bzr branches on sys.path. It's probably because you didn't run setup.py develop in leo root folder to install the leo package properly. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: problems using leo-4-5-b1 install script on linux
On Thu, Aug 21, 2008 at 5:17 PM, rogererens [EMAIL PROTECTED] wrote: - Just run launchLeo.py from the root directory where you extracted the tarball. If a /usr/bin/leo or /usr/local/bin/leo executable script is created that contains python root of extracted leo-directory/launchLeo.py $@ Ok, perhaps this is what the install script should do, then: - copy the extracted tarball to /opt - Create the launcher command /usr/local/bin/leo And optionally run setup.py develop in /opt/leo (if import setuptools does not raise ImportError, i.e. setuptools is installed). -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Leo now requires Python 2.4 or higher
On Mon, Aug 25, 2008 at 3:08 AM, Edward K. Ream [EMAIL PROTECTED] wrote: for very much longer. Python 2.4 is probably the earliest version that can be make compatible with Python 3k, so pretty soon Python 2.4 will have to be the minimum. Python 2.6 will probably be the earliest version that can be made compatible with py3k (that's the explicit design choice of python developers), so 2.4 as an interim requirement may not be worth it... -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Installation of Leo on Linux
On Mon, Aug 25, 2008 at 4:02 PM, Edward K. Ream [EMAIL PROTECTED] wrote: The 'install' script (not setup.py install) could be called the recommended way to install Leo, but there is presently debate about whether to get rid of that script. Your question convinces me that the b4 version will be distributed without the not-too-helpful scripts. I took the liberty of showing an error message for 'setup.py install'. [C:p/leo-editor]|10 python setup.py install WARNING: 'setup.py install' is known to not work. Either use 'setup.py develop', or run launchLeo.py directly (just pushed to trunk) These should help avoid the most typical mistake. But really, there should be README.txt directly in the root folder (as opposed to docs/), and it should be updated since it doesn't seem to be quite valid anymore (i.e. installation is more complicated than it needs to be). -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: problems using leo-4-5-b1 install script on linux
On Mon, Aug 25, 2008 at 4:07 PM, Edward K. Ream [EMAIL PROTECTED] wrote: It seems to me that 2) is the simplest thing that could possibly work. Both the 'install' script and the 'setup.py' script seem to cause confusion. For b4 I'm going to remove 'install', 'uninstall' and 'setup.py' from the distribution. I'll change the installation notes accordingly. Let's see whether that is any improvement. Please don't remove setup.py. My recent change should prevent the confusion. What you need is a readme.txt in the root folder. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: .leo directory - Issues
On Mon, Aug 25, 2008 at 6:31 PM, TL [EMAIL PROTECTED] wrote: 1. The File Explorer application in Windows XP does not allow users to manually create a .leo directory. The message You must type a file name is given when trying to rename the directory from New Folder to .leo. No problem for HOME/.leo. It is created the first time Leo is run. However, there doesn't appear to be a way for a user to put a .Leo directory anywhere else. You need to use command prompt (mkdir) for that. With ipython, we use _ipython instead of .ipython as the rc directory on windows, for this and other reasons (some win32 programs don't really like files/dirs starting with .). -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Pysmell (auto completion)
Bumped on this on planet python: http://orestis.gr/en/blog/2008/08/31/announcing-pysmell/ It may be something that could be usefull for Leo... -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Pysmell (auto completion)
On Mon, Sep 1, 2008 at 7:42 PM, Edward K. Ream [EMAIL PROTECTED] wrote: I wonder if that can be done fast enough for auto-completion? Perhaps by caching the text from preceding nodes part of the answer? Speed is the heart of the matter. In general, stupid scanning is too slow. There are two (compatible) choices: scan in separate threads, or cache the scans. pysmell seems to operate in tags like manner, and that should be good enough for most purposes. I.e. generate the completion database every now and then, and just use it (without updating it) in the interim. Of course you can always use a background process to update the database when the derived files have been written. This will not slow down leo in any away, nor would it have to be in the same process... -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Pysmell (auto completion)
On Tue, Sep 2, 2008 at 6:39 PM, Terry Brown [EMAIL PROTECTED] wrote: Right - but I think, if I'm reading the vim code for pysmell correctly, pysmell will do that part for you, whereas, if I read the ctags API correctly, ctags won't... unless perhaps you update the tag file with the contents of the current file before looking for completions. ModuleName.ClassName. [file in the method names] is easyish, but x = Foo() a = x. [now what are my choices] is triciker. This article explains it pretty well: http://orestis.gr/en/blog/2008/08/25/on-python-static-typing/ It seems to be quite simple, really. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Launching leo directly against a .py file
I'm wondering, would it make sense for leo to do something when launched directly against a .py file, i.e. leo test.py. Of course that's a perfectly sensible thing to do, considering that leo is, among other things, a python editor ;-) Perhaps it might create create a (unsaved) leo document where the .py file is present as @shadow node, or something. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Some (subjective) usability glitches
Now that the leo is more modeless (I'm speaking of switching between outline navigation and body editing modes), which btw is a clear improvement to how leo used to behave, here are some things that still feel a bit un-intuitive: - ctrl+H (edit-headline) locks the user into the mode way too much. * The headline editing mode should be cancelled when the user does: - cursor up/down - ESC * Even better alternative: I find myself constantly thinking that ok, now I need to edit a headline (typically not the current headline), so now I'll press ctrl+H. I think perhaps pressing up/down should cancel the current headline editing, and select the next/previous headline for editing. That is, I wouldn't need to navigate to the headline I want to edit before I start editing it. - cut-node (ctrl+shift+x) selects the wrong node after the cut. The intuitive assumption is that cut will select the node that took the place of the current node, instead of starting to travel upwards the set of nodes. * Typical use case is the way you usually start deleting a set of items. You move to the first item and start cutting repeatedly. This wont work with the current behaviour. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Merging of read-at-foo-nodes
Currently, there are many commands to read in current node: read-at-auto-nodes read-at-file-nodes read-at-shadow-nodes Why not have one command to combine all of these, which would select the right command based on the headline of the current node (@shadow, @auto...) More importantly, this command should be available as keyboard shortcut by default. read-at-shadow-nodes is way too painful to invoke currently, and for large projects invoking it at root @path nodes is not practical. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Merging of read-at-foo-nodes
On Fri, Sep 5, 2008 at 10:38 PM, Ville M. Vainio [EMAIL PROTECTED] wrote: Why not have one command to combine all of these, which would select the right command based on the headline of the current node (@shadow, @auto...) More importantly, this command should be available as keyboard shortcut by default. read-at-shadow-nodes is way too painful to invoke currently, and for large projects invoking it at root @path nodes is not practical. Ok, the previous statement betrays my absolute ignorance of how @shadow works (I just started playing with it). My planned usage pattern, and the resulting problem is this: - I go no a root directory of some kind, and do %lshadow there (thus creating a potentially huge @path tree of @shadow nodes). - I really don't want them all to be imported when I reopen the .leo file! I only want the nodes I've explicitly requested to be read in to be opened. I suppose there are a few ways to do this, but this seems simple: - have %lshadow not create @shadow nodes, but something like @@shadow that you rename manually - Implement uncomment-headline command (with keyboard shortcut) that changes @@ to @ I can easily do this in ileo (so that doing push-to-ipython (alt+I) on @@shadow renames it to @shadow and does read-at-shadow-nodes), but this problem / usage pattern might be of more general interest as well (and clearly has nothing to do with ipython - I just like to think of alt+I as activate command of sorts, that does the most sensible thing on the current item - and I don't need to configure anything on the leo side to use it ;-). -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
ILeo example: getting gmail to leo
Here's an example ileo snippet to get your gmail threads with todo label into leo outline (under heading MyTodo): QQQ import ipy_gmail gml todo ipy_gmail.to_leo(_, wb.MyTodo) QQQ Just posting this as an example of an interesting productivity feature to emphasize how ileo reduces the amount of typing and thinking that needs to be done. gml is a magic function introduced in ipy_gmail that searches gmails with the specified label. You still need to find this node and press alt+I, but once we get @button working with ileo we can forget about that as well ;-) -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Some (subjective) usability glitches
On Sat, Sep 6, 2008 at 2:53 PM, Edward K. Ream [EMAIL PROTECTED] wrote: I understand the temptation to think in terms of keys--it's how I sometimes muse about alternatives. However, eventually everything must boil down either to Leo's commands or other aspects of Leo's internal behavior. Of course - I'm just playing the part of clueless user / interaction designer here ;-). - cut-node (ctrl+shift+x) selects the wrong node after the cut. The intuitive assumption is that cut will select the node that took the place of the current node, instead of starting to travel upwards the set of nodes. Interesting. This must be an option then so that we don't argue about preferences. Actually, if the wrong way ends up being the default, having it configurable is worse than having it set to wrong at all times. So if you do change it, make the right way the default ;-) As an analogy. you can think of delete key, for example. It deletes the current character and moves the next character to the current position, so pressing delete again deletes the next character. The current ctrl+shift+x behaviour, otoh, is the same as delete erasing the current character, then moving one char to the left (which, when you think about it, is quite wacky...). It's just not the way an average user thinks. -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Run @button's in ileo, and tab completion
On Sat, Sep 6, 2008 at 4:23 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Tab completion is complex. See leoPy.leo, the class: Code--Gui Base classes--@thin leoKeys.py--class autoCompleterClass In particular, see the helper methods, doTabCompletion, doBackspace and computeCompletionList. These are wildly complicated, and depend on lots of arcane ivars. I guessed as much. Would it make sense to expose some kind of simple api for stuff like this? In ipython, we abstracted various things to ipapi that can be used to extend ipython. I think this would be a boon to leo as well (and especially ileo, since completion there does not require analysis of any kind). As I said, all I need would be is for leo to call callback/hook with signature like def complete(line-up-to-cursor, current_node) = list of strings This should make writing leo's own completers easier as well (it doesn't need to be hard wired to leo core). -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio' --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Run @button's in ileo, and tab completion
On Sat, Sep 6, 2008 at 4:18 PM, Edward K. Ream [EMAIL PROTECTED] wrote:
Can I create buttons directly without relying on @button nodes, e.g. with
something like:
c.new_button('hello', my_callback)
Of course. You don't think the @button code does all the work itself, do you?
Ok, it was indeed as simple as doing:
def mkbutton(text, node_to_push):
ib = c.frame.getIconBarObject()
ib.add(text = text, command = node_to_push.ipush)
Some notes:
- Perhaps stuff like this could be abstracted away from gui classes to leo API
- callback would be more descriptive keyword arg name for arg() than
'command' (since passing a normal callable to it seems to be ok).
--
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---
Re: Feature request, Vim the entire file
On Mon, Sep 15, 2008 at 4:54 PM, Edward K. Ream [EMAIL PROTECTED] wrote: I'm not inclined to do that. It's too specialized. You would bind a key to read-at-shadow-nodes. The point is that this kind of specialized feature can easily be done with @button or @command nodes. I would prefer to spend my time on more fundamental problems, like autocompletion, @path integration, etc. You are right that it's a specialized feature. That, however, does not mean that it couldn't be implemented in the open-with plugin. Certainly a normal user should not be required to implement an own button node... In general, this kind of feature should come out-of-the-box *somehow*. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Leo notebook - finally a reality (in literal sense ;-)
On Sat, Sep 6, 2008 at 5:29 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Now it's easier than ever to add *quick* notes with leo. ILeo knows of special leo file ~/.ipython/ipython_notebook.leo, which is opened automatically when you...launch leo without specifying a .leo file to open. This is a clever idea. Iirc, it would actually be possible to make the default .leo file be a user option. That is, opening the first file happens after Leo reads configuration options. Actually, even if I say so myself, opening a default leo file is a very good idea. Tk file select dialogs suck (for save as), and many users can get by with just a single leo document to 'hold their notes'. Now we even have a good place for it (~/.leo/default.leo or something). In the beginning, it could contain a node with simple instructions (like the emacs *scratch* buffer). Again, defaults matter here - most users will never find the feature if it's an option, and the whole idea is to deliver the goods right now. It doesn't make much sense to make it configurable - it's just as easy to create a shortcut that opens leo with an arbitrary file in the file system. Or it may be that I'm just lazier than most leo users ;-) -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Sqlite, leo's future file format?
On Sat, Sep 6, 2008 at 5:03 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Are you aware of Leo's support for zodb data stores? Afaik, nobody has done anything at all with it. Perhaps there is a big untapped potential in this area. Zodb is a big dependency, while sqlite is bundled with python (like tkinter). Also, it's not clear to me whether representing .leo files as a db will really help. In particular, most of the time loading leoPy.leo is spent in the code that reads thin derived files: in contrast, loading the .leo file itself happens almost instantaneously. Perhaps sqlite would be an ideal node cache for thin derived nodes. It would contain the actual data, and the time stamp of the file it was derived from. A background process could then be launched to update the sqlite database with the real data, while the user is already browsing the outline! Most users would probably trade the startup time to ~ double the disk space use quite willingly. In that case, feel free to experiment with a sqlite plugin :-) Or simply prototype the plugin with @button's. This feels like too much like core stuff to be implemented as a plugin. Notably, it would need to hook into the system where leo reads files and opens nodes (i.e. it's way over my head). -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Preliminary merge of trunk into at-path
On Thu, Sep 18, 2008 at 8:51 PM, Edward K. Ream [EMAIL PROTECTED] wrote: P.P.S. The leo-30 branch compiles with both Python 2k and Python 3k. However, if you run the code with Python 3k you will get dropped into the curses gui(!) That's intentional: the regular gui code doesn't Leo has a curses gui?? How can I enable it? Are there screenshots anywhere? -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Leo's to-do list
On Sat, Sep 20, 2008 at 1:52 PM, Edward K. Ream [EMAIL PROTECTED] wrote:
On Fri, Sep 19, 2008 at 4:18 PM, Ville M. Vainio [EMAIL PROTECTED] wrote:
Sqlite format usage can be started wih by a very simple scheme:
implement a tnode, vnode and uA dictionaries.
In that case, a prototype should be possible using one or two script buttons.
If I were writing the prototype, I would do the following:
1. Create these data structures **from the present outline**. This
eliminates all the read code.
2. I would create a new outline (as in c.new) and populate it with the
new data structures.
Or something like that. In other words, it shouldn't take much work
to prototype the main ideas, ignoring all the hard stuff.
I'm not sure it even needs this level of a prototype, since it's
obvious that it will work (there is nothing revolutionary in the
simplest implementation, streaming of key (index) and value (body)
items from the database as is done currently with the xml file).
Especially if you store the outline structure as xml (exactly as it is
now) to a text field in the database.
Obviously this should not be rushed, so take your time with leo3k -
I'm just throwing ideas around as they come :-). This concept is a
fertile source of ideas since it frees you from thinking about what
is sensible to store in a file, and you can put as much crap and
metadata to an sql file as you want, without compromising read time /
memory use.
- Want to mirror that website completely?
- Want to store your mp3 collection or high-res photos in Leo document?
- Want to store a binary for that phone device ROM image that exhibited a bug?
- Want to store a source code snapshot in leo?
- Want to access Leo document with light FUSE file system server?
You get the idea.
One thing that could accelerate the development of this is pluggable
persistence framework - i.e. being able to easily to plug in your own
reader/writer that you could register with a specific filename
pattern. E.g:
{ '*.leo' : LeoXmlStorage, '*.leodb' : LeoSqliteStorage }
The storage classes would then take the place of current reader/writer
code, i.e. provide streaming/random access of nodes and outline
information (listTnodes(), putTnode('1231241', 'some text body'),
getTnode('1211')...)
--
Ville M. Vainio
http://tinyurl.com/vainio
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---
Guide: sensible fonts for linux
Since the default fonts look a bit crappy and too big on Linux systems, here is a suggestion of sensible (smaller and more readable) fonts. This is for the normal, non-antialiased fonts (pre-python-2.6). Just copy the xml data starting below to your clipboard and ctrl+shift+v to your myLeoSettings, under @settings: ?xml version=1.0 encoding=utf-8? ?xml-stylesheet ekr_test? leo_file leo_header file_format=2/ vnodes v t=ville.20080920145943.3 a=E annotate=7d71002evhFonts/vh v t=ville.20080920145943.4vh@font body text font/vh/v v t=ville.20080920145943.5vh@font button font/vh/v v t=ville.20080920145943.6vh@font log font/vh/v v t=ville.20080920145943.7vh@font menu text font/vh/v v t=ville.20080920145943.8vh@font outline font/vh/v /v /vnodes tnodes t tx=ville.20080920145943.3@nocolor @ Valid values: weight: bold, normal, None slant: roman, italic, None Use the show-fonts command to pick fonts, then copy the values shown by the show-fonts command to the values here. @c import sys ; print sys.platform /t t tx=ville.20080920145943.4body_text_font_family = fixed body_text_font_size = 11 body_text_font_slant = None body_text_font_weight = None /t t tx=ville.20080920145943.5button_text_font_family = fixed button_text_font_size = 8 button_text_font_slant = roman button_text_font_weight = normal /t t tx=ville.20080920145943.6# The font for the log pane. Default is default font for Tk.Text widgets. # Tk translates invalid font names to another font in a system-dependent way. # # Default size is 12 for Linux, 9 otherwise. log_text_font_family = Courier log_text_font_size = 9 log_text_font_slant = roman log_text_font_weight = normal /t t tx=ville.20080920145943.7menu_text_font_family = None menu_text_font_size = None menu_text_font_slant = None menu_text_font_weight = None/t t tx=ville.20080920145943.8headline_text_font_family = fixed headline_text_font_size = 11 headline_text_font_slant = roman headline_text_font_weight = normal /t /tnodes /leo_file --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: autocompleter.getExternalCompletions now on the trunk
On Wed, Sep 24, 2008 at 8:29 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Rev 1157 now contains a new autoCompleter.getExternalCompletions method. It's signature is: Did you push it yet? I only got rev 1154. getExternalCompletions(self,s,p=None,language='python') s should be a single line, containing the text you want to complete. I don't quite understand how I should use this (and it doesn't work, because I didn't get the version on pull). How can I hook my own completer into this? What I need is that leo will call my own hook function when the user tries to autocomplete, and my own function will tell leo what completions are suggested (and thus what leo should show for the user). -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: ubuntu python tk fragility
On Wed, Sep 24, 2008 at 7:24 PM, Terry Brown [EMAIL PROTECTED] wrote: On one of the systems installing matplotlib had no adverse impact, on the other the whole python / tk / blah / blah stack is broken. python 2.4 as well as 2.5. Very irritating. It will be nice when the gtk gui is ready ;-) Actually, I'm more surprised that meddling with python 2.5 didn't screw up both of your systems (which is what I recall speculating earlier). I think that if you build your own python, you should not set it up as system default python... this is why it's safer to run leo + new tk with freshly compiled python 2.6, and not set python2.6 up to be run with 'python' command. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Tk, Qt, Gtk
On Wed, Sep 24, 2008 at 11:43 PM, Terry Brown [EMAIL PROTECTED] wrote: be allowed to rest in peace. There's really no point in investing all the effort it would take to have it become comparable to gtk / Qt, but it's more portable and lighter weight than either of them, so it just sort of lingers. Of course that's not entirely fair, 8.5 does look better, the problem is tkinter dragging its heels. I'm not so sure about tkinter being more portable, or lighter weight than, say, Qt. They are even porting Qt to Nokia S60 these days. It's pretty clear that Tk is a dying toolkit, but I have to say I'd rather see Leo ported to Qt than Gtk. I think it's widely agreed that Qt is better (== faster, more features, ...) of the two (esp. after Qt4), and Gtk is playing catchup. Gtk has just a more liberal license, which makes it more attractive to some (commercial) development, but Leo doesn't have to care about that. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Mon, Sep 29, 2008 at 1:17 PM, Edward K. Ream [EMAIL PROTECTED] wrote: I think it's widely agreed that Qt is better (== faster, more features, ...) of the two (esp. after Qt4), and Gtk is playing catchup. Gtk has just a more liberal license, which makes it more attractive to some (commercial) development, but Leo doesn't have to care about that. I'm willing to consider Qt. How sure are you that Qt is better that Gtk? Can you give references? It's just a bunch of references I bump into on the web, every now and then. Google for qt gtk comparison. The only downside qt has over gtk (gpl license, as opposed to lgpl) is a non-issue for leo. Technically (according to my own observations), Qt core is infinitely more solid than Gtk one. There is a reason Nokia bought trolltech, instead of settling with Gtk (that they could use freely in commercial applications). Gtk is held down by the various bad design decisions they made back in the day (one of those being choosing C + GObject instead of C++). -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Mon, Sep 29, 2008 at 3:18 PM, Ville M. Vainio [EMAIL PROTECTED] wrote: Yes, there is. Try downloading pyqt. http://www.riverbankcomputing.co.uk/software/pyqt/download One point for Qt again: it's a much simpler download than Gtk (on windows). -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Mon, Sep 29, 2008 at 6:29 PM, zpcspm [EMAIL PROTECTED] wrote: I would guess every linux distribution has Qt4 available by now...If not, change the distribution ;-) Not quite every distribution, but it seems to be a minor problem. A bit of googling revealed that it is possible to install Qt4 to an alternate location so it can co-exist with Qt3. I guess I should be Yeah, typically Qt3 and Qt4 will coexist on a linux system. BTW, what distribution does not ship Qt4? It's quite likely that the next iteration will.. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Mon, Sep 29, 2008 at 4:14 PM, zpcspm [EMAIL PROTECTED] wrote: On Sep 29, 2:36 pm, Ville M. Vainio [EMAIL PROTECTED] wrote: Apart from all this, Qt look-and-feel (and performance) is what the kids want. Reading this made me smile since leo doesn't look like a toy for kids to me :-) It is a very complex tool that I use for what it can do, not for how it looks. At least theory, Leo could be a very non-complex tool (i.e. a basic outliner). That's what I think leo should aim for to get maximum initial appeal. After that, the users can blow their mind with all the other (complex) stuff leo can do. My only concern is if Qt3 and Qt4 are compatible enough so leo having a Qt interface wouldn't enforce having Qt4 installed (the Linux distribution that I'm using is a late adopter of new stuff). I would guess every linux distribution has Qt4 available by now...If not, change the distribution ;-) -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Mon, Sep 29, 2008 at 7:21 PM, Edward K. Ream [EMAIL PROTECTED] wrote: http://www.riverbankcomputing.co.uk/software/pyqt/download Excellent. Thanks for the link. And a good place to get started might be reading the source code of qleolite (all 94 lines of it, if you leave out the autogenerated UI code): http://bazaar.launchpad.net/~villemvainio/leo-editor/qleolite/files ;-) -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Tue, Sep 30, 2008 at 11:07 AM, Alex Polite [EMAIL PROTECTED] wrote: Apart from all this, Qt look-and-feel (and performance) is what the kids want. Tk lacks the snappiness and glitz people expect from their apps. On Linux, Tk looks like it came from the early 90's ;-) I have to admit to being one of those superficial persons. When I It's not merely superficial. Everyone will appreciate the fact that text editor will run fast, have well-rendered antialiased fonts etc. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Tue, Sep 30, 2008 at 3:46 PM, Edward K. Ream [EMAIL PROTECTED] wrote: A qt gui plugin is rising in the priority list. As you know, any gui plugin is a big job. If somebody would like to try I'll be happy to provide assistance. It may be several months before I can start on that project myself. I looked at this back in the day, but it just felt too big a chore for me to get started (and currently I'm way too busy). The reason for this is that the gui code feels a bit too tangled with the rest of the leo, and especially the fact that leo likes to work on the low level of the gui code (there is tree drawing stuff, etc.). This is the mvc stuff that I mentioned back then. As I see it, the core leo should be the model that the leo gui accesses to fetch the data. I could achieve this trivially by using leoBridge, so perhaps the Qt gui could start groving from this direction? leoBridge could start providing callbacks like childNodesCreated (which would make the gui refresh that part of the tree), etc.The Qt gui could initially ignore all the text manipulation stuff of Leo, relying on the functionality built in to QTextEdit (or scintilla). -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Tue, Sep 30, 2008 at 7:06 PM, Edward K. Ream [EMAIL PROTECTED] wrote: I know *for sure* that this architecture minimize the work that must be done. I've created 3 or 4 guis for Leo, and this organization is clean. All you have to do is reimplement the gui subclasses. Now that I took a look at it, it doesn't seem too terrible. I guess what freaked me out was the low level stuff in leoTkInterTree.py. 1. Creating the frame and its sub-frames so they work smoothly. Why is this hard? Can't I just slap a tree, text body and and log window on GUI and then connect it to my own forwarder classes (that inherit from Leo's base classes)? 2. Handling clones and events in the tree widget. Why does the tree widget know about the clones in the first place? Isn't clone just a position with different icon? 3. Handling key events. That can be ignored in the beginning, I think. The idea is to get bootstrapped quickly, so there is something you can click around (in usable fashion). -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Tue, Sep 30, 2008 at 8:57 PM, Edward K. Ream [EMAIL PROTECTED] wrote: No tree widgets understand clones directly, so expanding and contracting trees typically means allocating and destroying headlines as they come into view and go out of view. I've implemented at least six tree widgets, and none of them were trivial. In particular, you must be careful not to crush the gc: managing headline widgets by hand is probably required. The leoTkinterTree code shows what is needed in order not to choke the Tk.Canvas. I'd definitely want to avoid maintaining headline widgets by hand. They are just an icon + headline text, and with qt tree widget you get it for free. The widget allocation / deallocation is handled entirely by Qt if you use QTreeView (and use QAbstractItemModel to implement the mapping of leo document to a tree, which should be direct enough). This brings up an interesting issue - in Qt mvc approach, the view (QTreeView) queries the model (QAbstractItemModel - eventually the LeoTreeModel) for data to draw. I.e. it asks the model for something like give me the icon for child #4 of node #121 when it needs to draw it. How does this map to leo? -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Tue, Sep 30, 2008 at 10:13 PM, Ville M. Vainio [EMAIL PROTECTED] wrote: This brings up an interesting issue - in Qt mvc approach, the view (QTreeView) queries the model (QAbstractItemModel - eventually the LeoTreeModel) for data to draw. I.e. it asks the model for something like give me the icon for child #4 of node #121 when it needs to draw it. How does this map to leo? My guess for this would be - there is very little to be implemented for the tree view. In writing the LeoTreeViewModel, you can pretty much map it directly to leo controller, but have to know when to call beginInsertRows / endInsertRows etc (answer - when vnodes are being added). Is it easy to get callbacks from leo model, along the lines of vnode v1 child #3 was added? The API to implement to get full model functionality is not too big: http://www.potu.com/man/doc.trolltech.com/4.0/qabstractitemmodel.html Of course we might be lazy and just use QTreeWidget (as I did in qleolite), especially if we forego lazy loading of tree structure for now... which may not be a good idea, considering the eventual possibilty of doing it someday... -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Wed, Oct 1, 2008 at 1:37 AM, Edward K. Ream [EMAIL PROTECTED] wrote: http://www.potu.com/man/doc.trolltech.com/4.0/qabstractitemmodel.html Sure. The question is, how will the widget react to massive changes provoked by c.frame.redraw? I'm sure it will be a breeze. That's what trolltech people are paid to do, and it happens entirely on the C++ side. Since we are constructing the whole tree from the scratch, in should be easy to implement. Here's the code that does the trick in qleolite: 55 def populate_tree(self, parent=None): 56 Render vnodes in tree 57 58 for p in c.allNodes_iter(): 59 parent = self.items.get(p.parent().v, self.treeWidget) 60 it = QTreeWidgetItem(parent) 61 self.items[p.v] = it 62 self.treeitems[it] = p.t 63 it.setText(0, p.headString()) 64 -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Wed, Oct 1, 2008 at 1:36 AM, Edward K. Ream [EMAIL PROTECTED] wrote: whole tree, or at least the visible part of the tree. Consider: because clones can contain clones, any change to a tree can cause *arbitrarily many* changes throughout the tree. In the face of this fact, it becomes extremely difficult to understand how to create meaningful hints about the relationship between the present tree (the tree to be drawn) and the previous tree (the tree that exists in the tree widget and is about to be replaced). In fact, Leo's core provides no such hints. In my qleolite solution, I just have a dict that maps vnodes to GUI widgets. If leo can give the gui callbacks like: vnode_deleted(v) child_created(v, idx) It's easy to find the corresponding treewidgetitem and remove it from tree. The same goes for adding items. It might be better (and faster!) to silently ignore redraw_now, the tree is being kept up to date at all times. I think this will produce a generally snappier experience as well. Of course a full_redraw feature is needed occasionally (though I'm not sure when - it might be faster to use it at startup at least). -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Wed, Oct 1, 2008 at 2:50 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Yes, this sets up the tree. How does it handle expansion/contraction status of nodes? That's trivial - just use: setItemExpanded ( const QTreeWidgetItem * item, bool expand ) of QTreeWidgetItem. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Wed, Oct 1, 2008 at 3:05 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Hmm. My *guess*, and you might call it more like a hunch, is that the only place that this could be done are in the low-level *position* methods: Great - having an only place is always good. @thin leoNodes.py--class position--p.Moving, Inserting, Deleting, Cloning, Sorting @thin leoNodes.py--class position--p.moveToX @thin leoNodes.py--class position--p.Low level methods I know this seems very strange. Let me give you some background. It doesn't seem strange at all. Now, if we add code that emits signals whenever a vnode is created, deleted or moved (to child number N of vnode v), we can pretty much hack qleolite to modify the tree in real time, as instructed by the engine (leoBridge). Note that I still think using leoBridge is the best way to reach a state where we have a prototype *you can use* as quickly as possible (i.e. without having to support everything from get-go). After that, we can focus on stuff like turning keyboard events to leo commands, adding a minibuffer, ... (or perhaps the minibuffer should be one of the first things to add, for testing purposes) -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Wed, Oct 1, 2008 at 6:56 PM, Ville M. Vainio [EMAIL PROTECTED] wrote: (or perhaps the minibuffer should be one of the first things to add, for testing purposes) Just changed my mind about that. ILeo is the best way to execute commands in the initial phase. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tk, Qt, Gtk
On Wed, Oct 1, 2008 at 6:56 PM, Ville M. Vainio [EMAIL PROTECTED] wrote: It doesn't seem strange at all. Now, if we add code that emits signals whenever a vnode is created, deleted or moved (to child number N of vnode v), we can pretty much hack qleolite to modify the tree in real time, as instructed by the engine (leoBridge). Maybe we could use pydispatcher to distribute the events: http://pydispatcher.sourceforge.net/ This would allow any interested party (plugin, whatever) to connect to the node creation loop. Or maybe we'd just use the activestate recipe pydispatcher is derived from: http://code.activestate.com/recipes/87056/ -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: nav_buttons plugin seems broken
On Thu, Oct 2, 2008 at 3:37 PM, Edward K. Ream [EMAIL PROTECTED] wrote: BTW, launchpad is *much* worse in showing diffs from previous versions than was cvs/tigris. This does not help my present mood :-) Why not diff in local bzr repo with bzr qlog or equivalent? -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Qt tree widget performance (qleolite)
Playing with Qt4 tree control in qleolite, it seems that: - Creating a whole LeoPyRef.leo (i.e. adding all the nodes as QTreeWidgetItems to the tree - 5942 nodes) takes 0.5 seconds on my machine. I repeated the process 2000 times before getting bored. It didn't seem to leak memory, or choke in other ways. Creation time fluctuated around 0.5 all the time - Note that it created the whole tree, i.e. it didn't optimize away invisible / unexpanded nodes (at least explicitly - Qt probably of course does it in the background). - expandAll and collapseAll are instantaneous (this is very cool - a good use case is to use expandAll, then add search box that filters the tree by headline to quickly find relevant nodes in a modern way - with all nodes expanded, collapsing was fast but re-expanding took a while. - You can do this to play with it (adjust paths accordingly): bzr branch lp:~villemvainio/leo-editor/qleolite cd qleolite python qleolite.py /home/ville/leo-editor/leo/core/LeoPyRef.leo (this also creates ileo console for the loaded document in current term) w.treeWidget.expandAll() This, of course, needs ipython. You also need to do easy_install ipython-extensions If you don't have ipy_leo.py available already. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Qt tree widget performance (qleolite)
On Sat, Oct 4, 2008 at 4:13 PM, Edward K. Ream [EMAIL PROTECTED] wrote: The initial load of LeoPyRef takes a long time, presumably because it is going through the entire startup process and loading derived files. You must have measured the actual creation of the tree in some other way. Yes, I removed tree creation separately. - with all nodes expanded, collapsing was fast but re-expanding took a while. I'm not sure what you mean by this. Expanding and collapsing nodes by hand looks instantaneous to me also. If you expandall, then close a node with large subtree, then expand it again, you'll see this. What are your plans for further work? I did key event capturing. Needless to say, it works like a charm. Do bzr pull and try entering some chars on text editor or tree, and observe the console. You'll see stuff like: Keypress: [ Alt+Ctrl+Shift+I ] PyQt4.Qsci.QsciScintilla object at 0x8b2a02c 73 PyQt4.QtCore.KeyboardModifiers object at 0x9fab62c Keypress: [ Alt+unknown ] PyQt4.QtGui.QTreeWidget object at 0x8afbeec 16777251 PyQt4.QtCore.KeyboardModifiers object at 0x9fab62c Keypress: [ Alt+unknown ] PyQt4.QtGui.QTreeWidget object at 0x8afbeec 16777252 PyQt4.QtCore.KeyboardModifiers object at 0x9fab62c Keypress: [ Alt+Ctrl+G ] PyQt4.QtGui.QTreeWidget object at 0x8afbeec 71 PyQt4.QtCore.KeyboardModifiers object at 0x9fab62c That is, you can get all the info from characters and the place it came from. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qleolite with scintilla - screenshot of future leo? ;-)
On Sat, Oct 4, 2008 at 4:34 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Using scintilla has always been my dream. It promises greatly increased performance for editing and syntax coloring. Also, it seems that komodo is based on scintilla. This might make it simpler to steal their autocompletion code ;-) -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qleolite with scintilla - screenshot of future leo? ;-)
On Sat, Oct 4, 2008 at 4:34 PM, Edward K. Ream [EMAIL PROTECTED] wrote: Iirc, scintilla has a way of extending syntax coloring for 'unknown' language. If this could be done in pure python it would be possible to adapt the info in the leo/Modes folder to extend the scintilla syntax coloring. Are you sure we need new lexers: scintilla already has: QsciLexerBash, QsciLexerBatch, QsciLexerCMake, QsciLexerCPP, QsciLexerCSS, QsciLexerD, QsciLexerDiff, QsciLexerFortran77, QsciLexerHTML, QsciLexerLua, QsciLexerMakefile, QsciLexerPascal, QsciLexerPerl, QsciLexerPostScript, QsciLexerPOV, QsciLexerProperties, QsciLexerPython, QsciLexerRuby, QsciLexerSQL, QsciLexerTCL, QsciLexerTeX, QsciLexerVHDL, and QsciLexerYAML. Also, unless I'm mistaken those are written in C++ so they are fast as well, for large amounts of text. I'm convinced. Leo needs a qui to replace Pmw/Tkinter, and qt looks up to the task. I'm glad about that, and pretty sure this will make leo more attractive to newcomers as well. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qleolite with scintilla - screenshot of future leo? ;-)
On Sat, Oct 4, 2008 at 6:19 PM, Peter Bienstman [EMAIL PROTECTED] wrote: What about Eric4? It's an IDE which also uses PyQt4, is purely written in Python, and has support for plugins. A leo plugin for Eric would be nice. Very good idea. And if it proved to be unfeasible (eric relying too much to existence of files / whatever), eric would still be a good source of usable code (autocompletion for QScintilla, etc). -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qleolite with scintilla - screenshot of future leo? ;-)
ctrl+H now activates edit headline. It does it with Qt:s persistent editor, because normal editItem failed for some reason. It's not necessarily worse than what leo has now, just different. Many could even think it's better. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qleolite with scintilla - screenshot of future leo? ;-)
On Sat, Oct 4, 2008 at 7:53 PM, Randy Kramer [EMAIL PROTECTED] wrote: On Saturday 04 October 2008 10:05 am, Edward K. Ream wrote: A good start, but I think people use languages not on the list. Yes. In fact, I use something that almost certainly no one else does (TWiki markup with my own extensions) so I will be trying to pay attention to be able to write my own lexer for that. This might be a place to start: http://www.riverbankcomputing.co.uk/static/Docs/QScintilla2/classQsciLexer.html -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qtGui plugin: first light
On Sun, Oct 5, 2008 at 5:59 AM, Edward K. Ream [EMAIL PROTECTED] wrote: recent qleolite code. I tested this with test.leo. To enable the plugin, uncomment the line # qtGui.py in the @enabled-plugins node in test.leo. Does not work for me: I get @enabled-plugins found in leoSettings.leo can not load enabled plugin: qtGui c.frame.tree.redraw_now calls c.frame.top.populate_tree, i.e., Window.populate_tree and all pretty much works as before. The Window class must eventually migrate to the other gui classes. This will be pretty slow (though it's probably too early to optimize it). It may be worthwhile to really provide methods to set node / subtree dirty, so only that part of the tree would need to be regenerated. Moreover, if clones are detected, the subtrees of all the clones would need to be recreated as well. I actually have not looked closely at class Ui_MainWindow. Apparently it comes from the gui designer. Eventually I will probably have to shuffle the code to other classes, or at the very least assign official ivars like c.frame, c.frame.tree, c.frame.body to entities created in the Ui_MainWindow class. Actually, it would best be left alone, and in its own file so it can be re-created by the GUI designer (this will probably need a rename). -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qtGui plugin: first light
On Sun, Oct 5, 2008 at 7:43 AM, Ville M. Vainio [EMAIL PROTECTED] wrote: Does not work for me: I get @enabled-plugins found in leoSettings.leo can not load enabled plugin: qtGui Nevermind that. I didn't realize that it has to be the first plugin specified (load order). Note that runLeo.py still imports tkinter... -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qtGui plugin: first light
On Sun, Oct 5, 2008 at 3:09 PM, Edward K. Ream [EMAIL PROTECTED] wrote: It may be worthwhile to really provide methods to set node / subtree dirty, so only that part of the tree would need to be regenerated. Moreover, if clones are detected, the subtrees of all the clones would need to be recreated as well. This seems like an heroic solution if done in Leo's core. Another possibility would be to try to compute the diffs within leoQtTree.redraw_now. For now, I'll leave possible optimizations to you. Ok, here's a simple plan that should work: subtree_changed_tnodes = set() - When a tree-changing operation happens, we add the tnode of the parent (subtree of which needs to be created) to the set - Then, it's just a matter of maintaining a dict that maps tnode to list of positions (all clones), iterating though subtree_changed_tnodes and using the dict to re-create the dirty subtrees, skipping invalid positions. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qtGui plugin: first light
On Sun, Oct 5, 2008 at 6:04 PM, Edward K. Ream [EMAIL PROTECTED] wrote: I've made the changes I discussed. I plan not to touch the qtGui plugin until you have made the changes necessary to use qllmain.ui. In other words, we shouldn't have to worry about merge conflicts for now. It's done, so you can proceed. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qtGui plugin: first light
On Sun, Oct 5, 2008 at 5:08 PM, Edward K. Ream [EMAIL PROTECTED] wrote: BTW, please remove the menu stuff from gllmain.ui: menus must be created programmatically in the leoQtMenu class. I guess we should leave them in for a while, until we really start getting the data from leo. It's easy to change anyway, and you can add stuff to the menu even if it was created in the ui designer. Note that I added a tab widget (for log stuff) and minibuffer to trunk. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Scintilla auto completion
It seems Scintilla relies on externally generated api description files to provide autocompletion. Links that may be of interest: http://www.riverbankcomputing.co.uk/static/Docs/QScintilla2/classQsciAPIs.html#b0f824492bb0f3ca54edb4d46945a3de http://www.burgaud.com/scite-java-api/ http://scintilla.sourceforge.net/tags2api.py http://www.koders.com/python/fid7000B9C96CF2C6FB5BCE9DF700365C5B2A1F36A7.aspx?s=gtk#L53 -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qtGui plugin: first light
On Sun, Oct 5, 2008 at 11:18 PM, Edward K. Ream [EMAIL PROTECTED] wrote: http://www.saltycrane.com/blog/2008/01/python-pyqt-tab-completion-example/ I think it will be even easier if we use the already existing event filter for this, though. This is useful, but it doesn't solve the real problem, namely discovering the list of completions. Everything except that problem Finding completions for minibuffer is trivial. As far as completions for body pane go, it is probably best done by scintilla (do not reinvent the wheel..). -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qtGui plugin: first light
On Mon, Oct 6, 2008 at 1:28 PM, Edward K. Ream [EMAIL PROTECTED] wrote: update information in the background in a separate thread. Moreover, it would be good for autocompletion to do the following: 1. Resolve the meaning of 'self'. For this the autocompleter code must know in what class the present node appears, which requires a scan of ancestor nodes, apparently. 2. Work in the presence of incomplete or syntactically incorrect functions or classes. This is true - however, it's a problem that all scintilla users share. Therefore, fixing it would best be done in scintilla (possibly integrating PySmell to it somehow). It's something that Leo should not worry about at this point, because there is so much other stuff to do. Providing the level of autocompletion that e.g. eric4 provides should be enough in the meantime. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qtGui plugin: first light
On Mon, Oct 6, 2008 at 4:41 PM, Edward K. Ream [EMAIL PROTECTED] wrote: As I understand the links you gave recently, the strategy will be to provide scintilla-compatible files to drive auto-completion. This can be done off line for standard Python modules, and can be done in the background for files that Leo is editing. Presumably Leo would work on previously saved files to maximize the chance that the files contain valid info. Yes. We could use/steal eric4-api.py to do this (http://osdir.com/ml/ide.eric/2007-11/msg9.html) (I have attached the script). This still leaves the question of determining the type of variables and ivars. Some kind of duck typing my help. I don't have a clear sense of what is possible or of what rope or pysmell presently do, nor do I have any idea of the kind of info resides in scintilla auto-completion files, or how scintilla uses this info. Scintilla auto-completion files have ctags-like information (functions arguments). I guess my point is - this issue is not worth thinking too much about at the moment. Scintilla should provide good enough autocompletion, and it's better to let others (scintilla people, eric4...) work on this and rather concentrate to more crucial things of getting the Qt plugin working properly in the first place (tree updates, key handling, menus, icons...). Also, I'm personally more interested in reading source trees in Leo (and C / C++, not python) than writing source code, though now that scintilla can be used (well, soon at least ;-) I could be swayed to start doing actual code authoring inside leo as well... autocompletion and type os.path.jtab. Furthermore, Leo already does what is, imo, a better job than most editors in showing possible completions and inserting text directly into the body area. In other words, there is likely to be some competition between the scintilla way of showing completions and the already-existing Leo way. Yeah, we'll see what works best. However, I wouldn't start shoehorning the leo completion system to scintilla until it is evident that it's actually needed. Again, it's better to let other people write code for us and enjoy the flow ;-) -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qt plugin: status
On Mon, Oct 6, 2008 at 5:41 PM, Edward K. Ream [EMAIL PROTECTED] wrote: The @auto nodes are a nice touch. If you, Ville, change the qt_main files, please remove the File menu and its actions. That way I won't have to disable it by hand again. Done. Now it is time for me to read, read, read the Qt docs. If you want something to print, you can download C++ GUI Programming with Qt 3 at: http://www.informit.com/content/images/0131240722/downloads/blanchette_book.pdf It's largely valid for Qt4 as well. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qt plugin: status
It seems much of the code currently in qtGui.py is redundant or outright harmful low-level tk-isms (and I don't mean just the current tk implementation, but the fact that such functions would exist at all): - All the creation destruction stuff - Splitter and scrollbar stuff - All the low level stuff leoQtTree - etc etc I suppose they will be removed or replaced with no-ops? -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qt plugin: status
One thing I noticed - the qt-plugin performance has degenerated quite a bit (I'm talking about the responsiveness). You can see this when you compare it agains qleolite, using the same leo document (e.g. test.leo) and moving around the tree with cursor keys. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qt plugin: status
On Mon, Oct 6, 2008 at 10:02 PM, Edward K. Ream [EMAIL PROTECTED] wrote: It would be convenient if you would allow me to revert your changes to qt_main. My code wants to have a menu bar already allocated, and there is no longer any reason to have by hand menu items. When my code is pushed you can insert whatever menu items you like in leoSettings.leo! It this ok with you? It's ok. Once I pull, I can re-generate the ui stuff so that I just allocate the menu, but don't leave any menu items. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Startup speed improvement
2 ideas on how to speed up startup (just wanted to get them off my chest - I definitely don't want to distract from qt plugin development though): - Implement the lazy loading. It's not a problem that you create the nodes after the outline is loaded. It's the users responsibility to avoid editing thin nodes while the loading is taking place. Yeah, I know it's an old idea, but the more I think about it, the more it makes sense. I'm not even thinking of totally lazy loading here, the loading would happen completely, it would just happen while the user can already navigate the tree. The load order would be remembered, so that recently edited nodes would be loaded first. - Implement a helper app in C that would take a bunch of file names and dump parsed data to stdout. The binary could be shipped with leo. This would be much simpler from deployment perspective than python extension / pyrex / whatever. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: qt plugin: status
I just added QTextBrowser to log panel. It will allow users to put all kinds of cool stuff to log as html (images, rich formatting, hyperlinks etc): http://doc.trolltech.com/4.4/qtextbrowser.html --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
