Re: Question about installation from bzr-branch into a new user account ?
Hi Edward, On 30 Aug., 16:50, "Edward K. Ream" wrote: > On Sun, Aug 29, 2010 at 2:36 PM, VR wrote: > > File "D:\Branches\leo-editor\leo\core\leoApp.py", line 686, in > > setLeoID > > f.write() > > TypeError: function takes exactly 1 argument (0 given) > > Thanks for this report. > > This is a recent crasher introduced in trying to make more code work > with Python 3k. > > The fix is on the trunk at rev 3293. No new unit test added: it would > be difficult to do. The initial problem is gone, i.e. Leo starts up properly. - However a new problem showed up. - Even if specifying '--gui=tk' Leo is started with the Qt-Gui. With kind regards, Viktor PS: For the record: the test was done on rev. 3300 -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: HOWTO: implement drag drop for Qt
On Mon, Aug 30, 2010 at 10:07 PM, Terry Brown wrote: > I'd like to see shift-click and control-click have their normal multiple > selection behaviors (i.e. normal for most list widgets in most systems). And > to allow DnD of multiple selections... > The complexities of handling multiple selections have been discovered and I > think handled before. Creating @auto and @thin as appropriate have higher priority. I'll see about these other bells and whistles later. EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: HOWTO: implement drag drop for Qt
On Mon, Aug 30, 2010 at 9:07 PM, Edward K. Ream wrote: > Still to do: > 1) clone-drags. > 2) Creating @thin or @auto nodes instead of @edit nodes as appropriate. As of rev 3300, ctrl-dragging an outline will clone the moved tree. That is, gnx's are preserved. In intra-outline moves, the dragged node will always show up as a clone. For inter-outline moves, the dragged node will show up as a clone if and only if a node in the target outline already has that gnx. As I write this, it seems that some weirdness could happen if two nodes with the same gnx's have different descendants. I'm not sure why this has never been an issue before. 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-edi...@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: HOWTO: implement drag drop for Qt
On Aug 30, 9:07 pm, "Edward K. Ream" wrote: > All suggestions for improvement welcome here, but please do not file > wishlist bugs. As of rev 3298, Leo will create @url nodes for 'http' scheme urls. This means you can drag a url from Mozilla to Leo and get an @url node. You can then double-click the node (or do simulate- double-click to open the url back in the browser. This rev also contains a complete refactoring and several bug fixes. The to-do list remains as before. EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: HOWTO: implement drag drop for Qt
On Sun, Aug 29, 2010 at 7:05 AM, Ville M. Vainio wrote: > I pushed a branch that shows how to add drag & drop support for Qt: > > https://code.launchpad.net/~leo-editor-team/leo-editor/dragdrop Rev 3297 of the trunk contains a greatly expanded version of this branch. I plan to do all further work directly in the trunk. The dragdrop branch will soon be marked merged. Here is the checkin log: Q Leo now supports Drag n Drop with Qt gui: the dragdrop branch has been merged by hand. Added LeoQTreeWidget from dragdrop branch and greatly expanded it. Creates @edit nodes when dragging to Leo files from the file system. Supports both intra-outline and inter-outline moves. Still to do: 1) clone-drags. 2) Creating @thin or @auto nodes instead of @edit nodes as appropriate. All unit tests pass. Q This has been another great collaborative effort. Ville's work was the most important. I simply had no idea how to get started. After the first step, everything went smoothly. All suggestions for improvement welcome here, but please do not file wishlist bugs. 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-edi...@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: Problem importing flattened outline (MORE text format)
> I don't want to take time now to do this--it's not high enough priority. I must have misinterpreted "remove the file reference from the tree produced by @auto" -- I thought this meant I could manually remove it outside of Leo (like, using an editor), and all would be well. I just didn't know how to go about removing it. Since you quoted both of my questions in your reply, and I know #2 requires a program change, I guess this means #1 does as well. > If you want to change Leo you will have to start studying the code. Your suggestion is certainly reasonable, and I've been around open source projects long enough to know that sometimes the only way an enhancement would get done is if I do it myself. I get that. I've been studying the Leo code when I run into problems. It's way over my head. :D After looking at it for hours, reading some of the detail code discussions (fascinating, but also way over my head), and reading in other threads about how fragile some Leo code sections are, I'm too intimidated to try to make significant changes on my own. I'm reluctant to ask for feature enhancements. I know that some changes users request might be incredibly simple to implement, so I'd rather ask in case it is something easy, rather than suffer in silence. :D On Aug 30, 11:05 am, "Edward K. Ream" wrote: > On Sun, Aug 29, 2010 at 12:58 AM, taa, Leo Newbie > wrote: > > 1. Could you provide the specific steps to "remove the file reference > > from the tree produced by @auto"? > > > 2. Is there a way to have a File->Import... function open a file based > > on its extension and automatically create an @auto node? There doesn't > > seem to be an import-at-auto command I can tie to an @menu node, like > > the import-at-file command. > > I don't want to take time now to do this--it's not high enough priority. > > If you want to change Leo you will have to start studying the code. > Stepping through the code with g.pdb() is sometimes useful in this > study. > > 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-edi...@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: Import Flattened Outline log error: not a valid MORE file
'p var' and the link are exactly what I needed. Thanks! On Aug 30, 9:53 am, "Edward K. Ream" wrote: > On Mon, Aug 30, 2010 at 11:10 AM, taa, Leo Newbie > wrote: > > I didn't realize I needed to restart Leo to have it recognize the > > change I made to leoImport.py. Having done that and attempting the > > import again, I switch to the console and use 'n' to step through the > > code. I'm making progress. :D > > Indeed you are. The first steps are always the most fraught with > difficulty. It's good you are pushing on. Things will only get > easier from here on. > > How do I show the contents of variables? > > p var > > See also:http://docs.python.org/library/pdb.html#debugger-commands > > EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: HOWTO: implement drag drop for Qt
On Mon, Aug 30, 2010 at 6:59 PM, Sam Hartsfield wrote: > On Aug 30, 3:14 pm, "Edward K. Ream" wrote: >> I'll add this to the trunk after a bit more testing. Also, this >> should be undoable, and ctrl-drags should copy instead of move. > > How about cloning? Yes, this will happen. Be just a *little* patient. 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-edi...@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: HOWTO: implement drag drop for Qt
On Aug 30, 3:14 pm, "Edward K. Ream" wrote: > I'll add this to the trunk after a bit more testing. Also, this > should be undoable, and ctrl-drags should copy instead of move. How about cloning? Ctrl-Shift-Drag makes a link in Windows Explorer, and I think the same shortcut does symbolic links in Nautilus in GNOME; it seems to fit. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: More thoughts about slides
On Mon, Aug 30, 2010 at 4:03 PM, Terry Brown wrote: > At this rather late stage :-} is that the kind of think you're looking for? Absolutely. Good tools save so much time. Furthermore, good tools here are another selling point for Leo. I'll take a look after finishing DnD. 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-edi...@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: HOWTO: implement drag drop for Qt
> It should also support dropping files from file manager (perhaps creating > @path / @edit / @auto nodes?) https://bugs.launchpad.net/leo-editor/+bug/568646 :) -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: HOWTO: implement drag drop for Qt
It should also support dropping files from file manager (perhaps creating @path / @edit / @auto nodes?) -- Sent from my Nokia N900 - Original message - > > > On Aug 30, 2:14 pm, "Edward K. Ream" wrote: > > > On Sun, Aug 29, 2010 at 7:05 AM, Ville M. Vainio > > > wrote: > > > > I pushed a branch that shows how to add drag & drop support for Qt: > > > > Ville's big hint made everything easy. > > Oops. The code does only DnD within the same outline. But Qt > supports dragging from one .leo file to another. Actually, it > probably supports even more than that... > > The code must do the full mime-type thingee to record the content of > inter-Leo-file drags. > > Still, the initial code is a good starting point... > > 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-edi...@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. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: Question about installation from bzr-branch into a new user account ?
Hi Edward, On 30 Aug., 16:50, "Edward K. Ream" wrote: > On Sun, Aug 29, 2010 at 2:36 PM, VR wrote: > > File "D:\Branches\leo-editor\leo\core\leoApp.py", line 686, in > > setLeoID > > f.write() > > TypeError: function takes exactly 1 argument (0 given) > > Thanks for this report. > > This is a recent crasher introduced in trying to make more code work > with Python 3k. > > The fix is on the trunk at rev 3293. No new unit test added: it would > be difficult to do. Thanks for this quick fix/ reply. - I'll provide an update about my progress to this list tomorrow. With kind regards, Viktor -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: HOWTO: implement drag drop for Qt
On Aug 30, 2:14 pm, "Edward K. Ream" wrote: > > On Sun, Aug 29, 2010 at 7:05 AM, Ville M. Vainio wrote: > >> I pushed a branch that shows how to add drag & drop support for Qt: > > Ville's big hint made everything easy. Oops. The code does only DnD within the same outline. But Qt supports dragging from one .leo file to another. Actually, it probably supports even more than that... The code must do the full mime-type thingee to record the content of inter-Leo-file drags. Still, the initial code is a good starting point... 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-edi...@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: HOWTO: implement drag drop for Qt
> On Sun, Aug 29, 2010 at 7:05 AM, Ville M. Vainio wrote: >> I pushed a branch that shows how to add drag & drop support for Qt: Ville's big hint made everything easy. What I did: 1. Added c to the ctor of LeoQTreeWidget.__init__. self.c.p becomes the node to be dragged. 2. dropEvent is straightforward using tree.item2positionDict:: def dropEvent(self,ev): if not ev: return c = self.c ; tree = c.frame.tree ev.setDropAction(QtCore.Qt.IgnoreAction) ev.accept() item = self.itemAt(ev.pos()) if not item: return itemHash = tree.itemHash(item) p = tree.item2positionDict.get(itemHash) if not p or c.p == p: return c.p.moveAfter(p) c.redraw_now() I'll add this to the trunk after a bit more testing. Also, this should be undoable, and ctrl-drags should copy instead of move. 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-edi...@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: Problem importing flattened outline (MORE text format)
On Sun, Aug 29, 2010 at 12:58 AM, taa, Leo Newbie wrote: > 1. Could you provide the specific steps to "remove the file reference > from the tree produced by @auto"? > > 2. Is there a way to have a File->Import... function open a file based > on its extension and automatically create an @auto node? There doesn't > seem to be an import-at-auto command I can tie to an @menu node, like > the import-at-file command. I don't want to take time now to do this--it's not high enough priority. If you want to change Leo you will have to start studying the code. Stepping through the code with g.pdb() is sometimes useful in this study. 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-edi...@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: Is it time to retire tk?
Mon, Aug 30, 2010 at 6:52 PM, Edward K. Ream wrote: >> It is also possible that in the future somebody would need a new leo >> feature backported to tk for personal use. This is why I thought >> having a distinct branch in the first place. > > There will be no fork. Period. Having a stable maintence-only version (with occasional backports) is not the same thing as fork. Tk users might actually prefer a stable maintenance version, since the risk of Tk features breaking between releases is much bigger than with Qt. 4.8 probably won't be that stable maintenance version, but as for 4.9 / 4.10... time will tell. -- Ville M. Vainio @@ Forum Nokia -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: Help on simulating Leo <> in @rst branches
On Sat, Aug 28, 2010 at 7:54 PM, Offray Vladimir Luna Cárdenas wrote: > Could we use "combined directives" for example "@render @language html". Interesting idea. As you may know, the directives machinery is complicated. There are three versions of scanAllDirectives: c.scanAllDirectives, at.scanAllDirectives and the deprecated tangle.scanAllDirectives, which I'll ignore from here on. c/at.scanAllDirectives have been refactored so they call functions in: Code-->Core classes-->@thin leoGlobals.py-->Commands & Directives-->g.Directive utils... So it's conceivable that more flexibility could be built in. 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-edi...@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: seeking help with broken script node after upgrade to 4.7
On Mon, 30 Aug 2010 09:59:54 -0700 (PDT) Phil wrote: > So a final question: Other than looking at the code (which I assume is > in leoGuiPluginsRef.leo), is there any "official" documentation of the > gui-agnostic API? Not that I know of. Cheers -Terry -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: seeking help with broken script node after upgrade to 4.7
On Mon, Aug 30, 2010 at 11:59 AM, Phil wrote: > Other than looking at the code (which I assume is > in leoGuiPluginsRef.leo), is there any "official" documentation of the > gui-agnostic API? The good stuff is in leoPy.leo: Code-->Gui Base classes--><< about gui classes and gui plugins >> Code to the high-level api defined in children of: Code-->Gui Base classes-->@thin leoFrame.py--><< define text classes >>-->class baseTextWidget leoEditCommands.py has a gazillion examples. 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-edi...@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: seeking help with broken script node after upgrade to 4.7
On Aug 22, 10:03 am, Terry Brown wrote: > On Sun, 22 Aug 2010 10:00:56 -0500 > > Terry Brown wrote: > > To clarify, Leo has a gui agnostic API for these parts of the interface for > > Leo's core functions, but I'm not sure it covers everything plugins might > > need. > > Ahem, and to clarify the point of my posting :-) .configure() is a Tk > function, so it won't work with Qt. There may or may not be Leo wrapper > functions to get the same result in either gui. Terry, thanks for the tips. I found some spare time to look into this a bit more and found that the plugin "toolbar.py", which I had enabled, was the main culprit. Upon disabling it, my script worked ok on Windows (tk), but not on Ubuntu (qt). As you say, the .configure() function does not work in qt, so as a temporary workaround I simply removed DeleteButtonCallback(), at which point it worked alright with qt. Ultimately, I would like to have a script that works the same on both tk and qt. I'll continue to tinker with it until I get it the way I want it, but for now I have it working well enough on both platforms. So a final question: Other than looking at the code (which I assume is in leoGuiPluginsRef.leo), is there any "official" documentation of the gui-agnostic API? Thanks! Phil -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: Import Flattened Outline log error: not a valid MORE file
On Mon, Aug 30, 2010 at 11:10 AM, taa, Leo Newbie wrote: > I didn't realize I needed to restart Leo to have it recognize the > change I made to leoImport.py. Having done that and attempting the > import again, I switch to the console and use 'n' to step through the > code. I'm making progress. :D Indeed you are. The first steps are always the most fraught with difficulty. It's good you are pushing on. Things will only get easier from here on. How do I show the contents of variables? p var See also: http://docs.python.org/library/pdb.html#debugger-commands EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: Import Flattened Outline log error: not a valid MORE file
I didn't realize I needed to restart Leo to have it recognize the change I made to leoImport.py. Having done that and attempting the import again, I switch to the console and use 'n' to step through the code. I'm making progress. :D How do I show the contents of variables? I did 'help' at the (Pdb) prompt but don't see a command to show variable values. On Aug 30, 8:48 am, "Edward K. Ream" wrote: > On Mon, Aug 30, 2010 at 10:25 AM, taa, Leo Newbie > wrote: > > What do I do to see the the results of g.pdb()? > > Run Leo from a console. When g.pdb() starts it will print a message > to the console. > > Switch to the console (Alt-tab) and then do 'n' (pdb's next command) > to get out of the pdb() function itself. Now you are at the "real" > breakpoint. > > EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: Working around problems with "Save node as HTML" under Ubuntu
On Sun, Aug 29, 2010 at 1:55 PM, SegundoBob wrote: > Properies menu not supported for Qt gui > Note that "Properties" is misspelled. Fixed on the trunk. > This worked around my problems with "Save node as HTML". I hope this > narrative helps others with similar problems and someone who generates > a patch to improve "Save node as HTML". Please consider posting this to Leo's wiki. Thanks. 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-edi...@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: save uA on @ nodes?
On Mon, Aug 30, 2010 at 10:59 AM, Kent Tenney wrote: > I would be interested in testing. > > @auto represents the bridge between Leo and the big world outside Leo. > As such, I consider the uA of an @auto node crucial, a critical > element of leveraging Leo as a tool for managing the data of the world. Thanks for you offer. Unit tests will only take us so far, namely to the point at which there are no blunders in the tested code. 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-edi...@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: save uA on @ nodes?
On Mon, Aug 30, 2010 at 10:34 AM, Edward K. Ream wrote: > On Sun, Aug 29, 2010 at 8:21 PM, Terry Brown wrote: > >>> The code in putTnode writes uA's for *all* nodes, which is also >>> correct because Leo only writes elements for the top-level nodes >>> of @thin, @edit and @auto trees. >> >> Based on the snippet below, I suspect it only writes t nodes for the top >> level of @file, not @thin/edit/shadow/auto. It would be great if it wrote a >> t node for all of them. >> >> >> @edit 1.txt >> @file 2.txt >> @shadow 3.txt >> @auto 4.txt >> @thin 5.txt >> >> >> > annotate="7d710055087072696f7269747971014b02 >> >> > > Thanks for this. > > The relevant code is in putVnode, specifically the forceWrite var. We > can write elements simply by ignoring this var when writing > elements. That is, we would change > << Set gnx = vnode index >> from:: > > gnx = g.app.nodeIndices.toString(v.fileIndex) > if forceWrite or self.usingClipboard: > v.setWriteBit() # 4.2: Indicate we wrote the body text. > > to: > > gnx = g.app.nodeIndices.toString(v.fileIndex) > v.setWriteBit() # 4.2: Indicate we wrote the body text. > > (Actually, the entire section is wretched style. The code should be > placed inline :-) > > **Important**: the real question is, do we dare write elements for > @auto, etc? > > There are three files to consider: leoFileCommands.py, leoAtFile.py > and leoImport.py. > > 1. leoFileCommands.py: > > The addition of a new element *might* work as desired without side > effects: > > A: getSaxUa never alters the node structure, it merely adds uAs. > > B: createSaxVnode *does* set the body text from (in effect) the element. > Presumably the leoAtFile read code will override this effect, but > it's tricky. > > 2. leoAtFile.py: > > The crucial methods are at.createThinChild4, at.createNewThinNode and > at.terminateNode (at.findChild4 exists only to read *old-style* @file > nodes.) > > at.terminateNode (via its helper at.terminateBody) just jams the new > text into the node, with many complications arising from the desire to > report changed nodes. Happily, no warnings are ever given for the root > node (perhaps because no element existed for the root node??), so > we should be good to go. > > 3. leoImport.py: > > readOneAtAutoNode and its helper, createOutline, are the methods in question. > > Again happily, createOutline jams the empty string into the body > string initially, so body text arising from a element will > probably be totally ignored. > > The conclusion seems to be that we can ignore forceWrite in putVnode > when deciding whether to write elements. This *might* be a > legitimate change. However, it is way too dangerous to do in the > trunk. > > If you are interested, please create a new branch, and test for > several days after all unit tests pass. I would be interested in testing. @auto represents the bridge between Leo and the big world outside Leo. As such, I consider the uA of an @auto node crucial, a critical element of leveraging Leo as a tool for managing the data of the world. As always, I wish it wasn't a pickle by default, but that's another story. :-] Thanks, Kent > > 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-edi...@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. > > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: save uA on @ nodes?
On Mon, Aug 30, 2010 at 10:47 AM, Terry Brown wrote: > I guess I'm not sure how you'd write *new* unit tests to show that everything > that worked before still works. > Isn't that what the existing unit tests do? They don't have to be new tests. You might add an assert that says, in effect, that the tnode was written to the .leo file. Not quite sure how to do that :-) > It almost seems as if you'd need to change the setup on all the @ > related unit tests to include uAs and some place holder body text in > nodes, and then, if writing nodes for everything plus including that > dummy content breaks no existing unit tests, conclude either (a) there's no > negative impact, or (b) current unit test coverage is incomplete ;-) Sure, unit tests that say that uA's on top-level @ nodes work would be good. But uA's are not what worry me. I'm much more concerned that writing elements in the .leo file will screw up the read logic in some way. Perhaps this is a nameless fear. The only way to know for sure is to make sure that all kinds of @ nodes continue to work. We *should* have existing unit tests that prove this. I don't know for a fact that we do. 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-edi...@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: More thoughts about slides
On Mon, Aug 30, 2010 at 10:07 AM, Terry Brown wrote: >> Thanks for this suggestion. It is timely. Is make_svg something that >> already exists? > > Um, no, but I'll try and throw something together today, it's just a > variation on a technique I've used multiple times before. Thanks! That would be both helpful and timely. 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-edi...@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: save uA on @ nodes?
On Mon, 30 Aug 2010 10:37:44 -0500 "Edward K. Ream" wrote: > My bad. This is the old (thoroughly hopeless) approach. Time simply > doesn't matter in such situations. The only valid approach is to > create unit tests that demonstrate conclusively that the new way > works. I liked the old way :-) I guess I'm not sure how you'd write *new* unit tests to show that everything that worked before still works. Isn't that what the existing unit tests do? It almost seems as if you'd need to change the setup on all the @ related unit tests to include uAs and some place holder body text in nodes, and then, if writing nodes for everything plus including that dummy content breaks no existing unit tests, conclude either (a) there's no negative impact, or (b) current unit test coverage is incomplete ;-) I guess you could also add a unit test to check that the uAs are actually written/read. I'll put this in the hopper after I've written a failing then fixed unit test for the driver relative "absolute" path thing, seeing then I should understand Leo's unit tests better. Cheers -Terry -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: Is it time to retire tk?
On Mon, Aug 30, 2010 at 10:23 AM, zpcspm wrote: > It is also possible that in the future somebody would need a new leo > feature backported to tk for personal use. This is why I thought > having a distinct branch in the first place. There will be no fork. Period. There may come a time when Tk is no longer supported at all. But I expect Tk to stick around for at least a year or two. 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-edi...@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: Is it time to retire tk?
On Mon, Aug 30, 2010 at 10:05 AM, Terry Brown wrote: > I think the issue is, do you expect the functionality of Tk to stay at its > present level or to decline over time? It's not going to decline if I have anything to say about it :-) Why should it? I'm not going to make unnecessary changes to Leo's core to make it Qt-specific. 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-edi...@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: Import Flattened Outline log error: not a valid MORE file
On Mon, Aug 30, 2010 at 10:25 AM, taa, Leo Newbie wrote: > What do I do to see the the results of g.pdb()? Run Leo from a console. When g.pdb() starts it will print a message to the console. Switch to the console (Alt-tab) and then do 'n' (pdb's next command) to get out of the pdb() function itself. Now you are at the "real" breakpoint. EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: save uA on @ nodes?
On Mon, Aug 30, 2010 at 10:34 AM, Edward K. Ream wrote: > There are three files to consider: leoFileCommands.py, leoAtFile.py > and leoImport.py. I forgot @shadow. @shadow writes @thin-style files as the private files, so presumably this will work provided that @thin itself works. EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: save uA on @ nodes?
On Mon, Aug 30, 2010 at 10:34 AM, Edward K. Ream wrote: > If you are interested, please create a new branch, and test for > several days after all unit tests pass. My bad. This is the old (thoroughly hopeless) approach. Time simply doesn't matter in such situations. The only valid approach is to create unit tests that demonstrate conclusively that the new way works. EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: save uA on @ nodes?
On Sun, Aug 29, 2010 at 8:21 PM, Terry Brown wrote: >> The code in putTnode writes uA's for *all* nodes, which is also >> correct because Leo only writes elements for the top-level nodes >> of @thin, @edit and @auto trees. > > Based on the snippet below, I suspect it only writes t nodes for the top > level of @file, not @thin/edit/shadow/auto. It would be great if it wrote a > t node for all of them. > > > @edit 1.txt > @file 2.txt > @shadow 3.txt > @auto 4.txt > @thin 5.txt > > > annotate="7d710055087072696f7269747971014b02 > > Thanks for this. The relevant code is in putVnode, specifically the forceWrite var. We can write elements simply by ignoring this var when writing elements. That is, we would change << Set gnx = vnode index >> from:: gnx = g.app.nodeIndices.toString(v.fileIndex) if forceWrite or self.usingClipboard: v.setWriteBit() # 4.2: Indicate we wrote the body text. to: gnx = g.app.nodeIndices.toString(v.fileIndex) v.setWriteBit() # 4.2: Indicate we wrote the body text. (Actually, the entire section is wretched style. The code should be placed inline :-) **Important**: the real question is, do we dare write elements for @auto, etc? There are three files to consider: leoFileCommands.py, leoAtFile.py and leoImport.py. 1. leoFileCommands.py: The addition of a new element *might* work as desired without side effects: A: getSaxUa never alters the node structure, it merely adds uAs. B: createSaxVnode *does* set the body text from (in effect) the element. Presumably the leoAtFile read code will override this effect, but it's tricky. 2. leoAtFile.py: The crucial methods are at.createThinChild4, at.createNewThinNode and at.terminateNode (at.findChild4 exists only to read *old-style* @file nodes.) at.terminateNode (via its helper at.terminateBody) just jams the new text into the node, with many complications arising from the desire to report changed nodes. Happily, no warnings are ever given for the root node (perhaps because no element existed for the root node??), so we should be good to go. 3. leoImport.py: readOneAtAutoNode and its helper, createOutline, are the methods in question. Again happily, createOutline jams the empty string into the body string initially, so body text arising from a element will probably be totally ignored. The conclusion seems to be that we can ignore forceWrite in putVnode when deciding whether to write elements. This *might* be a legitimate change. However, it is way too dangerous to do in the trunk. If you are interested, please create a new branch, and test for several days after all unit tests pass. 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-edi...@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: Import Flattened Outline log error: not a valid MORE file
>Put a call to g.pdb() in stringsAreValidMoreFile. > >The 'i' variable will be the line number you want, +- 1 perhaps. I don't know Python but I tried changing leoImport.py as follows: def stringsAreValidMoreFile (self,strings): g.pdb() if len(strings) < 1: return False ... I saved the change, tried the import again, got the error (as expected). What do I do to see the the results of g.pdb()? Only the error appears in the log tab. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: Is it time to retire tk?
On Aug 30, 6:05 pm, Terry Brown wrote: > I think the issue is, do you expect the functionality of Tk to stay > at its present level or to decline over time? It is also possible that in the future somebody would need a new leo feature backported to tk for personal use. This is why I thought having a distinct branch in the first place. After the fork happens, current trunk will always contain a tk functionality that is declining over time, because ideally nothing tk related will be done there. The other branch could get more commits over time, if a tk related bug will be fixed or a feature from the trunk will be backported. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: More thoughts about slides
On Mon, 30 Aug 2010 09:11:44 -0500
"Edward K. Ream" wrote:
> > make_svg("gnx.2309525.blah.png", callouts, numbers=[1,2])
> >
> > to make an SVG with a screen shot, three filled-in text style callouts and
> > two white number on black circle style markers. make_svg() or another
> > function could then load the SVG in Inkscape for the pointers from the
> > callouts etc. to be positioned as needed.
>
> Thanks for this suggestion. It is timely. Is make_svg something that
> already exists?
Um, no, but I'll try and throw something together today, it's just a variation
on a technique I've used multiple times before.
Cheers -Terry
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to leo-edi...@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: Is it time to retire tk?
On Mon, 30 Aug 2010 09:15:04 -0500 "Edward K. Ream" wrote: > > I'm not sure if zpcspm meant a branch or a tag, or perhaps they're the same > > thing in bzr..., no, they're not, so perhaps a tag make as much sense as a > > branch. But I think zpcspm's point was that you can then point people who > > must use Tk to the branch/tag/revision at which Tk support was best, > > because it's only going to go down hill from here. > > I'm not going to do this. And there is no need to do so. As Ville > says, Qt is already the default, or is the default *almost* > everywhere. > > I'll have to track down several special cases. In particular the code > that tells how to put up "emergency" dialogs and prompts for the > contents of .leoID.txt. But such special cases will not affect > existing Tk users, so in effect we can deprecate Tk simply by changing > the docs. I think the issue is, do you expect the functionality of Tk to stay at its present level or to decline over time? I would assume the latter, in which case some marker for the current revision would be useful when someone must use Tk and wants the best Tk leo there ever was. Cheers -Terry -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: Question about installation from bzr-branch into a new user account ?
On Sun, Aug 29, 2010 at 2:36 PM, VR wrote: > File "D:\Branches\leo-editor\leo\core\leoApp.py", line 686, in > setLeoID > f.write() > TypeError: function takes exactly 1 argument (0 given) Thanks for this report. This is a recent crasher introduced in trying to make more code work with Python 3k. The fix is on the trunk at rev 3293. No new unit test added: it would be difficult to do. 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-edi...@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: Is it time to retire tk?
On Sun, Aug 29, 2010 at 8:39 PM, Terry Brown wrote: >> A branch will not be needed. Indeed, the code could stay the same, >> except for two or three places. Rather, it is the docs that would >> change: newbies would think that only Qt exists. Existing users would >> be free to use Tk and Tk plugins. > > I'm not sure if zpcspm meant a branch or a tag, or perhaps they're the same > thing in bzr..., no, they're not, so perhaps a tag make as much sense as a > branch. But I think zpcspm's point was that you can then point people who > must use Tk to the branch/tag/revision at which Tk support was best, because > it's only going to go down hill from here. I'm not going to do this. And there is no need to do so. As Ville says, Qt is already the default, or is the default *almost* everywhere. I'll have to track down several special cases. In particular the code that tells how to put up "emergency" dialogs and prompts for the contents of .leoID.txt. But such special cases will not affect existing Tk users, so in effect we can deprecate Tk simply by changing the docs. 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-edi...@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: More thoughts about slides
On Sun, Aug 29, 2010 at 8:56 PM, Terry Brown wrote:
> Using Inkscape, i.e. SVG, to add callouts would be more FLOSSy than using
> Flash, and a reasonably high level of automation should be possible:
>
> callouts = [
> "This goes here",
> "These are those",
> "Then you pull this",
> ]
>
> make_svg("gnx.2309525.blah.png", callouts, numbers=[1,2])
>
> to make an SVG with a screen shot, three filled-in text style callouts and
> two white number on black circle style markers. make_svg() or another
> function could then load the SVG in Inkscape for the pointers from the
> callouts etc. to be positioned as needed.
Thanks for this suggestion. It is timely. Is make_svg something that
already exists?
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-edi...@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: Import Flattened Outline log error: not a valid MORE file
On Sun, Aug 29, 2010 at 9:54 PM, taa, Leo Newbie wrote: > What would help me most right now is if leoImport.py could tell me the > line# of the import file that it stopped at. Can anyone help with this? Put a call to g.pdb() in stringsAreValidMoreFile. The 'i' variable will be the line number you want, +- 1 perhaps. 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-edi...@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: Chapter 7 of docs seems to contain some wrong statements
I solved my variable highlight issue by using a workaround: I open the body in an external editor (gvim) and just use highlight there. Regarding the reported bug - I filled a bug report: https://bugs.launchpad.net/leo-editor/+bug/626835 -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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: Plans for Leo 4.8 a1
> I would like to release Leo 4.8 a1 a week from now on Sept. 3. The > essentials: > > - A workable .exe installer for windows. Hurrah! That would be awesome Edward, if you can manage it. Still a Leo novice, but using it heavily in my work nonetheless... And loving it! Cheers, Alec -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-edi...@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.
