DrX, an object inspector
in [Ruby]
|
Prev: [BUG] Segmentation fault
Next: ya config file parser
From: Rick DeNatale on 22 Apr 2010 08:50 On Thu, Apr 22, 2010 at 12:20 AM, Charles Oliver Nutter <headius(a)headius.com> wrote: > For GUIs, there's a lot of cool options that have come up on this list: > > * Raw Swing (not for the uninitiated) > * Rubeus (a Swing DSL) http://talklikeaduck.denhaven2.com/2009/02/14/erich-gamma-on-eclipse-lessons-agility-and-open-source > * LimeLight (a Flash/JavaFX-like environment for building lickable interfaces) I shudder to think about what a lickable interface would be like, except for something like a lollipop. <G> -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale
From: Mooffie n/a on 22 Apr 2010 23:38 Caleb Clausen wrote: > > The size and style drop-down boxes don't work for me if I > close and then re-open drx a second time from within irb. Thanks for reminding me of this Ruby/Tk bug. I think I'll have a workaround soon. It only happens for Tk 8.4, not for Tk 8.5. Tip for Ubuntu users: Here's how to compile Ruby/Tk against the new Tk 8.5: http://drx.rubyforge.org/ubuntu-new-tk.html > > Is there any chance you'll extend this to show an object's > contents instead of or in addition to it's class/type? Yes, there's a chance. I haven't yet an idea how this feature will look/behave. > > You ought to provide a drx command so I can launch it directly > instead of invoking it via irb. Yes, that's a good idea. > > You should consider using the EDITOR or VISUAL environment > variables instead of DRX_EDITOR_COMMAND. There are several reasons for not doing this. Jakub has explained. I certainly don't want to use my EDITOR: mine works only in the console, and gedit starts up faster. (Besides, I don't recommend people to use this environment variable anyway. They should put all their configuration in ~/.drxrc: it's much better because they can backup it, copy to other systems, etc. This DRX_EDITOR_COMMAND exists only because DrX didn't have ~/.drxrc when I wrote that section in the user manual.) Brian Candler wrote: > Only suggestion: a "back" button would be nice. I had to go to > the docs to find out that right-click = back. Thanks, I've added this to my Issue Tracker. -- Posted via http://www.ruby-forum.com/.
From: Mooffie n/a on 23 Apr 2010 00:38 Arndt Roger Schneider wrote: > Mooffie wrote: > > (You believe the object graph DrX produces can be generated by existing > > documentation tools? I'm not aware of similar tool(s). > > doxygen generates a similar [...] No, it doesn't. Doxygen, and similar tools, generate diagrams that are *not* suitable for Ruby: * Ruby's object model is diagrammed best by using a grid where the various lines of inheritance are shown orthogonal (in parallel/perpendicular). That's what DrX does. Doxygen is good for languages like C++ and PHP, whose class inheritance is mostly a tree. Ruby's object model isn't a tree, it's a graph (and a circular one!). And unless this is taken into careful consideration when generating the DOT source, a very hard-to-read (and thus useless) diagram will come out. The only reason people _might_ feel good with Doxygen diagrams is because it blissfully ignores more than half of Ruby's object model (the singletons hierarchy, and the run-time part). * In Ruby, much of the object model is generated at run-time. Static diagramming tools are blind to this. For example, look at the DataMapper diagram. Static tools like 'rdoc' can't tell us in which classes the gazillion modules end up 'include'd. As for GraphViz's SVG problem: I think I vaguely remember that the font names it puts in the SVG file aren't standard ones. Perhaps fixing this will alleviate the problem. I'll need to investigate this. I certainly want SVG support. Let me know if you have more ideas on this and similar subjects. Note that I'm not using Tk's canvas to draw the graph. I show the bitmap GraphViz produces. -- Posted via http://www.ruby-forum.com/.
From: Mooffie n/a on 23 Apr 2010 00:48 Mooffie wrote: > Note that I'm not using Tk's canvas to draw the graph. I show the bitmap > GraphViz produces. I also ask GraphViz to produce a "hot spot" map, which I use to give visual cues to the user when he hovers the mouse on the various shapes in the bitmap. -- Posted via http://www.ruby-forum.com/.
From: Arndt Roger Schneider on 23 Apr 2010 04:09
Mooffie n/a schrieb: >Arndt Roger Schneider wrote: > > >>Mooffie wrote: >> >> >>>(You believe the object graph DrX produces can be generated by existing >>>documentation tools? I'm not aware of similar tool(s). >>> >>> >>doxygen generates a similar [...] >> >> > >No, it doesn't. > >Doxygen, and similar tools, generate diagrams that are *not* suitable >for Ruby: > >* Ruby's object model is diagrammed best by using a grid where the >various lines of inheritance are shown orthogonal (in >parallel/perpendicular). That's what DrX does. Doxygen is good for >languages like C++ and PHP, whose class inheritance is mostly a tree. >Ruby's object model isn't a tree, it's a graph (and a circular one!). >And unless this is taken into careful consideration when generating the >DOT source, a very hard-to-read (and thus useless) diagram will come >out. The only reason people _might_ feel good with Doxygen diagrams is >because it blissfully ignores more than half of Ruby's object model (the >singletons hierarchy, and the run-time part). > >* In Ruby, much of the object model is generated at run-time. Static >diagramming tools are blind to this. For example, look at the DataMapper >diagram. Static tools like 'rdoc' can't tell us in which classes the >gazillion modules end up 'include'd. > > > > >As for GraphViz's SVG problem: > >I think I vaguely remember that the font names it puts in the SVG file >aren't standard ones. Perhaps fixing this will alleviate the problem. >I'll need to investigate this. I certainly want SVG support. Let me know >if you have more ideas on this and similar subjects. > >Note that I'm not using Tk's canvas to draw the graph. I show the bitmap >GraphViz produces. > > Send a medium to large compressed svg via email to me, then I take a look at it. I suspect the graphviz/svg issue can be solved inside the DOM-tree after graphviz generated the svg. -roger |