Re: Cleo icons won't work on linux
Running leo under python 2.4 solves the problem. On Apr 13, 7:16 pm, marko [EMAIL PROTECTED] wrote: Hello, I've got Leo running on debian linux, but the cleo icons won't load. Leo Log Window... Leo 4.4.8 final, build 1.244 , April 6, 2008 python 2.5.0, Tk 8.4.12, Pmw 1.3 linux2 reading: /home/marko/marko.leo can not import Image module from PIL can not import ImageTk module can not load image: /usr/local/lib/leo/leo/Icons/cleo/pri5.png PIL and ImageTk have been installed and the icon files are in the correct location. Any ideas how to make it work? TIA, Marko --~--~-~--~~~---~--~~ 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: Eureka!!! Unified nodes
On Apr 13, 7:20 am, Edward K. Ream [EMAIL PROTECTED] wrote: It appears that Leo will, relatively soon, move to the unified-node world. Compatibility with existing code and scripts should be no big deal. Indeed, unified nodes will contain .v and .t ivars, inited in the ctor as follows: self.v = self self.t = self That is for any node n, n.v == n, n.t == n, n.v.t == n. In other words, if there is only one kind of node, the problem of distinguishing between vnodes and tnodes becomes pretty easy :-) Similarly for positions. p.v == p.n == p.v.t. I'll probably write scripts to eliminate references to v and t from Leo's core (and plugins) but it is my intention that old scripts works as before. There will be instances where this could produce weird, inefficient or even incorrect code. We shall see... Edward P.S. I just finished talking to my brother Speed. He points out that several interesting projects use DAG's, and that work is happening in devising a DAG-based file format for holograms. DAG's are used in 3-D cad formats. Apparently representing holograms as DAG's improves compression. Anyway, a simplified, more flexible format for .leo files could make Leo relevant for such projects. This will encourage me to make the format of .leo files as straightforward, honest, (optionally) compressible and user-customizable as possible. 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-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: Cleo icons won't work on linux
On Sun, 13 Apr 2008 03:21:12 -0700 (PDT) marko [EMAIL PROTECTED] wrote: Running leo under python 2.4 solves the problem. Probably Python Imaging Library (PIL) and the ImageTk module aren't installed from 2.5's point of view, but are available to 2.4. 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-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: Eureka!!! Unified nodes
On Sun, 13 Apr 2008 05:20:54 -0700 (PDT) Edward K. Ream [EMAIL PROTECTED] wrote: - Unified nodes are *precisely* the nodes contemplated in the graph world. /me grins Recall that a key part in my rejection of the graph world was a realization that iterators in any graph world are much more complex than Leo's iterators. True, but now you're on the slippery slope :-) It seems to me that hard part with the new node system will be not implementing general graph world accidentally. I.e. it's up to the interface to stop the user linking a node in a way that creates a cycle, and the interface has to do that to avoid the more complicated iterators (for now, at least :-) P.S. As a matter of symmetry, a unified node could contain a list of the node's parents. This is not necessary: it is analogous to double- linking a linked list. Unnecessary, but a big speed boost (at the cost of memory) if you wanted to access the list of a nodes parents. Seems to me that the concept of parent only exists as a side effect of the position. What if a node simply had a list L of all nodes to which it connects, and functions that return a list of children or iterate children simply omit any members of L that point to p.parent? So for DAG world, iterating children requires a position? Nah, I guess it's not quite that simple, it doesn't account for loops back to the parent through an intermediate node. But of course that's not a concern if you know the interface doesn't allow creation of such loops. I think this is a great path your heading down - get all the current DAG machinery working on top of the new structure, which sounds doable, then there'll be some solid ground from which to explore the possibilities for cyclic graphs. Bearing in mind that this is all future stuff not to be played with before the DAG stuff is done, a node could have two lists; a list of parents and a list of children, or a single list of tuples (o, d) where o is anOther node to which the current node connects and d is the direction of the connection. These two approaches are equivalent and the two list option might be more convenient, anyway they're equivalent so it doesn't matter much. Then iterators could have three flags, 'unique' as you discussed, 'directed' meaning pay attention to direction (don't follow links to parents), and 'cyclic' meaning don't shield me from cycles in the data (the default being to shield the caller from cycles by maintaining a list of visited nodes). Not sure how unique and cyclic interact, unique makes sense is a DAG+clones context, where cyclic doesn't apply. Again, none of that matters until the DAG stuff is done. Anyway, exciting news. 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-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: Selecting from multiple Leo versions - Best practice exist?
The CMD command with the /C directive runs Leo as a subprocess and allows me to close the dos window while Leo remains running. It would be nice if it closed automatically once it has finished openning Leo. TL --~--~-~--~~~---~--~~ 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_button bug and hook problems
On Sun, Apr 13, 2008 at 4:57 PM, Edward K. Ream [EMAIL PROTECTED] wrote: I never heard of pyDispatcher. Time to google... It looks like pyDispatcher is highly rated. It's definitely worth looking at. It could have even more important uses within Leo: there are many places where a listener/broadcaster framework might simplify event handling. Something I've considered before, and then got distracted :-) 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-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 -~--~~~~--~~--~--~---
