[OT] Nokia N9
Following my usual tradition of shamelessly plugging what I've been working around in my professinal capacity, here's the N9: http://swipe.nokia.com/ (built with Linux and Qt). -- 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 leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
OT: Nokia N9
Following my usual tradition of shamelessly plugging what I've been working around in my professinal capacity, here's the N9: http://swipe.nokia.com/ (built with Linux and Qt). -- 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 leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Can we change the screen layout?
On Apr 29, 8:17 pm, Terry Brown terry_n_br...@yahoo.com wrote: If you have the viewrendered / free_layout plugins enabled you right-click on the panel dividers and swap things around. Currently it doesn't persist, but hopefully it will in future. Cheers -Terry Hi, I am new to leo. Is there any way to make the layout persistent? -m -- 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 leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Leo 4.9 final is here
Leo 4.9 final is now available at: http://sourceforge.net/projects/leo/files/ Many thanks to all those who have helped on this project. Leo 4.9 promises to be the most capable and solid release in Leo's history. This will likely be the last packaged release this year. Enjoy. As always, development will continue on Leo's bzr trunk. Edward -- 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 leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Visions of Leo 5.0
On Jun 18, 8:20 am, Edward K. Ream edream...@gmail.com wrote: 8. Super-slim .leo files At present, .leo files contain v elements for all nodes that are *not* descendants of @file nodes. In the new world, no (computed) descendants of @view nodes would be written to .leo files. Already, this would slim down .leo files considerably. Upon further review, this seems like a very bad idea. It is inflexible (it would give users less choice, not more), and it would drastically alter existing .leo files. There is no way we can allow this. It's all pain and no gain. Edward -- 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 leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Sourceforge description
On the main page for Leo at Sourceforge ( http://sourceforge.net/projects/leo/ ) is the following: Leo is 100% pure Python, but requires either Qt or Tk. Not really a big deal but thought you might want to change that considering recent developments. Rob -- 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 leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Sourceforge description
On Tue, Jun 21, 2011 at 7:26 AM, Largo84 larg...@gmail.com wrote: On the main page for Leo at Sourceforge ( http://sourceforge.net/projects/leo/ ) is the following: Leo is 100% pure Python, but requires either Qt or Tk. Not really a big deal but thought you might want to change that considering recent developments. Thanks. It's updated now. Edward -- 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 leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Visions of Leo 5.0
On Jun 21, 6:54 am, Edward K. Ream edream...@gmail.com wrote: 5.0 is completely speculative. It may turn out that @view nodes aren't worth doing. But if they do turn out to be interesting, 5.0 a1 might be released sometime in July. To clarify, the release will simply be a merge of a to-be-created 5.0 branch into the trunk. The next scheduled official/packaged release will be in January or February of next year. Edward -- 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 leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Keybindings: Some do not get through, some just print characters
I recently discovered some problems with key bindings. Can you tell me which of them are features and which bugs? Are they platform-specific? 1. Character insertion If I use a key combination that is not bind to a command in the body editor, Leo just writes down there what I pressed, e.g. pressing Ctrl- Down just writes Down at the position of my cursor. This is highly annoying, as it inserts text into my code when I do not expect it, and often yields syntax errors in compilation. 2. Some bindings only work on some machines On my Laptop, Ubuntu 10.10 32-bit, binding Alt-Ctrl-UpArrow to move- lines-up works fine. Having done the same on my Desktop, Ubuntu 10.04 64-bit, pressing this binding does not do anything (although it is listed in the autocompletion tab as move-lines-down all: Alt+Ctrl +Down). EDIT: I just realised why this happens, see further down. I keep this if people want to Google this. 3. Some bindings do not work at all Is it impossible to bind something to Ctrl-Shift-Insert (on Linux)? The xev output for hold ctrl, hold alt, tap insert, release alt, release ctrl is: KeyPress event, serial 36, synthetic NO, window 0x481, root 0x15a, subw 0x0, time 312321606, (64,77), root:(1051,1070), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 36, synthetic NO, window 0x481, root 0x15a, subw 0x0, time 312321902, (64,77), root:(1051,1070), state 0x4, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 36, synthetic NO, window 0x481, root 0x15a, subw 0x0, time 312322318, (64,77), root:(1051,1070), state 0xc, keycode 118 (keysym 0xff63, Insert), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 36, synthetic NO, window 0x481, root 0x15a, subw 0x0, time 312322366, (64,77), root:(1051,1070), state 0xc, keycode 118 (keysym 0xff63, Insert), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 36, synthetic NO, window 0x481, root 0x15a, subw 0x0, time 312322662, (64,77), root:(1051,1070), state 0xc, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 36, synthetic NO, window 0x481, root 0x15a, subw 0x0, time 312322838, (64,77), root:(1051,1070), state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False For question 2: Apparently the two systems recognize different input in xev. I type: hold ctrl, hold alt, tap down, release alt, release ctrl On the working laptop: KeyPress event, serial 27, synthetic NO, window 0x181, root 0xa8, subw 0x0, time 589317, (433,148), root437,455), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 27, synthetic NO, window 0x181, root 0xa8, subw 0x0, time 589491, (433,148), root437,455), state 0x4, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 27, synthetic NO, window 0x181, root 0xa8, subw 0x0, time 589851, (433,148), root437,455), state 0xc, keycode 116 (keysym 0xff54, Down), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0x181, root 0xa8, subw 0x0, time 589931, (433,148), root437,455), state 0xc, keycode 116 (keysym 0xff54, Down), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0x181, root 0xa8, subw 0x0, time 590090, (433,148), root437,455), state 0xc, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0x181, root 0xa8, subw 0x0, time 590110, (433,148), root437,455), state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False On the broken Desktop: KeyPress event, serial 36, synthetic NO, window 0x481, root 0x15a, subw 0x0, time 312170294, (84,110), root:(945,659), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 36, synthetic NO, window 0x481, root 0x15a, subw 0x0, time 312170502, (84,110), root:(945,659), state 0x4, keycode 64 (keysym
Leo's target audience? (was Visions of Leo 5.0)
I've been following with interest the v5.0 thread and thought I'd hijack the discussion about Leo's target audience. It seems that one's opinion of the ideal target user for Leo depends on how one uses Leo for one's self. For me, I came to Leo from ECCO Pro looking for an effective outlining program. I followed the countless other frustrated OpenOffice users at OO's inability to provide an outlining view in OO Writer (still curious why that is still unresolved). I don't write write code much anymore (unless you consider html, css or tex writing code). I find Leo invaluable for almost all of my writing and outlining tasks. The following non-exhaustive list includes ways that I use Leo: * Build and maintain web sites* * Write articles, books and training manuals (using mostly LaTex tools) * Write tests and exams using LaTex Exam class * Outline presentations that end up in OO Impress or PowerPoint (ugh!) * Manage daily tasks and to-do lists * Various text editing tasks, including writing email drafts Considering at least how I use Leo, there may be a much larger target audience for Leo than the hard core 'code bangers'. Unfortunately, for many of them (me included) the learning curve is still a little steep and there's little interest in 'the man behind the curtain'. It just needs to work. I agree with much of what aeromorrison says about Leo as well. Keep up the good work and sorry I can't be any help on the dev side. Rob. *This entire site was built and is maintained using Leo: http://northgeorgiamodurail.org/ -- 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 leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Readability and formatting of Plugins information
Edward, Firstly, congratulations on Leo 4.9 final. I noticed that when the renderpane is active it is not affected by the WindowEqual Sized Panes command. Only the Outline and Body Panes are affected - just as described in http://webpages.charter.net/edreamleo/outlines.html#resizing-panes. However from the user perspective the current behaviour appears as though the command is only partially successful. Since there are specific commands to contract/expand the log pane, shouldn't the log and render panes also be affected by the WindowEqual Sized Panes command? Regards Lewis On Jun 21, 10:02 am, lewis lewisn...@operamail.com wrote: Thanks - Leo users will benefit from the 'polish' Lewis -- 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 leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Keybindings: Some do not get through, some just print characters
2011/6/21 Niklas Hambüchen n...@deditus.de: I recently discovered some problems with key bindings. Can you tell me which of them are features and which bugs? Are they platform-specific? First of all, I need to know, for each problem, what version of Leo you are using, and what platform. 1. Character insertion If I use a key combination that is not bind to a command in the body editor, Leo just writes down there what I pressed, e.g. pressing Ctrl- Down just writes Down at the position of my cursor. I don't see this. Have you tried binding the offending keys to do-nothing or self-insert-command? This may be a way of handling platform and keyboard-specific idiosyncrasies. Edward -- 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 leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Readability and formatting of Plugins information
On Tue, Jun 21, 2011 at 8:47 AM, lewis lewisn...@operamail.com wrote: Shouldn't the log and render panes also be affected by the WindowEqual Sized Panes command? I suppose so. I would prefer to wait for Terry to finish his pane-generalization code before dealing with this. I've made a note of this request and put it on the 4.10 to-do list. Edward -- 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 leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Leo's target audience? (was Visions of Leo 5.0)
When you have questions or difficulties with any aspect of Leo, please ask here. That way I can either explain (making a note to myself that the docs are lacking) or I can fix a problem. Edward That's one of the great things about Leo is the timely and courteous responses to user questions on this list. Rob -- 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 leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Leo's target audience? (was Visions of Leo 5.0)
On Tue, Jun 21, 2011 at 9:31 AM, Largo84 larg...@gmail.com wrote: When you have questions or difficulties with any aspect of Leo, please ask here. That way I can either explain (making a note to myself that the docs are lacking) or I can fix a problem. Edward That's one of the great things about Leo is the timely and courteous responses to user questions on this list. :-) You're welcome. Edward -- 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 leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Keybindings: Some do not get through, some just print characters
On Tuesday, 21 June 2011 14:53:47 UTC+1, Edward K. Ream wrote:
2011/6/21 Niklas Hambüchen n...@deditus.de:
I recently discovered some problems with key bindings.
Can you tell me which of them are features and which bugs? Are they
platform-specific?
First of all, I need to know, for each problem, what version of Leo
you are using, and what platform.
2. was the Compiz issue, the other ones appear for me on both Ubuntu 10.04
64bit and Ubuntu 10.10 32bit. Both Leo versions are the one from yesterday's
bzr head.
1. Character insertion
If I use a key combination that is not bind to a command in the body
editor, Leo just writes down there what I pressed, e.g. pressing Ctrl-
Down just writes Down at the position of my cursor.
I don't see this. Have you tried binding the offending keys to
do-nothing or self-insert-command? This may be a way of handling
platform and keyboard-specific idiosyncrasies.
It looks like self-insert-command is executed to all unbound key
combinations. The attached patch fixes my problem. Can you check if it
breaks anything?
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To view this discussion on the web visit
https://groups.google.com/d/msg/leo-editor/-/EbzXaLR9788J.
To post to this group, send email to leo-editor@googlegroups.com.
To unsubscribe from this group, send email to
leo-editor+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
From cc6188ae3cc42742fe1b3606470bc5af5107628e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Niklas=20Hamb=C3=BCchen?= n...@deditus.de
Date: Tue, 21 Jun 2011 16:57:18 +0100
Subject: [PATCH] Do nothing on unbound key combination
Fixes e.g. Down being printed in the body editor on Ctrl-Down
---
leo/core/leoKeys.py |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/leo/core/leoKeys.py b/leo/core/leoKeys.py
index 48a6092..e388272 100644
--- a/leo/core/leoKeys.py
+++ b/leo/core/leoKeys.py
@@ -3203,7 +3203,8 @@ class keyHandlerClass:
else:
if trace: g.trace('no func',repr(char),repr(stroke))
-return k.masterCommand(event,func=None,stroke=stroke,commandName=None)
+# Do nothing to not print e.g. Down on Ctrl-Down in the body editor
+return
#@+node:ekr.20061031131434.155: *4* masterMenuHandler
def masterMenuHandler (self,stroke,func,commandName):
--
1.7.0.4
Undoing is terribly slow and sluggish
Just keep move-lines-down pressed until a line has moved down 20 lines and then keep undo pressed until it is back again to see what I mean. It makes undoing a 5-minutes-work to see what was there before pretty impossible. Is it known why undoing is that slow? (Actually, move-lines-down is too slow as well, but that might be a different issue.) I think it should be at least as fast as gedit. What I noticed is that if one comments out c.redraw() and c.recolor() in the undo and redo functions (patch attached), undo gets a lot faster and also uses the glitch that the whole code goes black for a short amount of time after undo. The code seems to stay highlighted correctly in all cases I've tried though. I have the strong feeling that Leo repaints its UI a lot more than necessary, but delving into the undo code has not yielded better results than simply commenting out these two lines yet. -- You received this message because you are subscribed to the Google Groups leo-editor group. To view this discussion on the web visit https://groups.google.com/d/msg/leo-editor/-/aGATsxt1cmoJ. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en. From ececbe3182ef3c018be8ed9b05803ea2292ac5f8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Niklas=20Hamb=C3=BCchen?= n...@deditus.de Date: Sun, 19 Jun 2011 20:03:51 +0100 Subject: [PATCH 3/5] Prevent redraw and recolor for undo and redo --- leo/core/leoUndo.py | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/leo/core/leoUndo.py b/leo/core/leoUndo.py index 3cdc6c1..21152aa 100644 --- a/leo/core/leoUndo.py +++ b/leo/core/leoUndo.py @@ -1389,8 +1389,9 @@ class undoer: # Redrawing *must* be done here before setting u.undoing to False. i,j = w.getSelectionRange() ins = w.getInsertPoint() -c.redraw() -c.recolor() +# TODO check if these are really not needed (maybe needed for non-Qt GUIs?) +#c.redraw() +#c.recolor() c.bodyWantsFocus() w.setSelectionRange(i,j,insert=ins) w.seeInsertPoint() @@ -1721,8 +1722,9 @@ class undoer: # Redrawing *must* be done here before setting u.undoing to False. i,j = w.getSelectionRange() ins = w.getInsertPoint() -c.redraw() -c.recolor() +# TODO check if these are really not needed (maybe needed for non-Qt GUIs?) +#c.redraw() +#c.recolor() c.bodyWantsFocus() w.setSelectionRange(i,j,insert=ins) w.seeInsertPoint() -- 1.7.0.4
