I am aware that people have, in the past, asked for a Tk-style canvas object that manages shapes (etc) within it. I''m currently doing some work with 2D vector graphics as part of my final year University project (so far you can draw/select/drag polygons/images and export as SVG). Would it make sense to put the extra effort in and make my own work more generically useful? I''ve been looking for an open-source project to get into for a while and this seems like one that would be useful for myself and probably for others. The problem is that I really am not a professional programmer (...yet) - I am sure I could get something that *worked* well enough, but whether it would be well designed (in terms of API or architecture) is another question. I feel in a lot of ways that I would be better joining an existing project (and learning at the feet of those in the know) rather than starting my own (and blazing my own trail!). Any advice would be well received. Thanks, bil
On Jul 22, 2004, at 7:31 AM, Bil wrote:> I am aware that people have, in the past, asked for a Tk-style canvas > object that manages shapes (etc) within it. I''m currently doing some > work with 2D vector graphics as part of my final year University > project (so far you can draw/select/drag polygons/images and export as > SVG). Would it make sense to put the extra effort in and make my own > work more generically useful? > > I''ve been looking for an open-source project to get into for a while > and this seems like one that would be useful for myself and probably > for others. The problem is that I really am not a professional > programmer (...yet) - I am sure I could get something that *worked* > well enough, but whether it would be well designed (in terms of API or > architecture) is another question. I feel in a lot of ways that I > would be better joining an existing project (and learning at the feet > of those in the know) rather than starting my own (and blazing my own > trail!).Well, the bottom line (for me) is that (1) a lot of people would be interested in having this, and (2) no one''s working on it. So yes, I think people would be interested in it, whatever shape it''s in. One reality of most software projects is that the first cut ultimately gets thrown away. So I wouldn''t lose much sleep if your software architecture and API aren''t what you''d like for them to be; just consider this one a prototype for the improved "version 2." And as you are probably already aware, an advantage of the open source approach is that you''ll have (potentially) a lot of eyes looking at the code and offering suggestions on how to improve it.
On Thu, 22 Jul 2004, Bil wrote:> I am aware that people have, in the past, asked for a Tk-style > canvas object that manages shapes (etc) within it. I''m currently[...]> polygons/images and export as SVG). Would it make sense to put the > extra effort in and make my own work more generically useful?Certainly worth doing. It would be a valuable thing to have. As you point out, you''d learn from the experience, and you''d be contributing (not least time and energy). I expect you''ll need to discuss it on the FOX list, more so than the FXRuby list, though>Hugh
*********** REPLY SEPARATOR *********** On 22/07/2004 at 14:18 Hugh Sasse Staff Elec Eng wrote:>On Thu, 22 Jul 2004, Bil wrote: > >> I am aware that people have, in the past, asked for a Tk-style >> canvas object that manages shapes (etc) within it. I''m currently > [...] >> polygons/images and export as SVG). Would it make sense to put the >> extra effort in and make my own work more generically useful? > >Certainly worth doing. It would be a valuable thing to have. >As you point out, you''d learn from the experience, and you''d be >contributing (not least time and energy). I expect you''ll need to >discuss it on the FOX list, more so than the FXRuby list, thoughIn truth, I wasn''t planning to use C++/FOX to implement it. Obviously, though, it would make some sense to write it at a lower level to run a bit faster and allow it to be used by a lot more people. I didn''t really want that extra effort which would be unnecessary for my purposes...I''ll think again about that. Lyle said somewhere that he was not going to put it in FXRuby since it could be implemented in pure Ruby. Based on my unoptimised prototype, FXRuby seems to be reasonably fast with graphics, even when double-buffering. I imagine it would not be fast enough to act as a basis for Macromedia Flash-type animations though *8-)* bil
On Thu, 22 Jul 2004, Bil wrote:> *********** REPLY SEPARATOR *********** > > On 22/07/2004 at 14:18 Hugh Sasse Staff Elec Eng wrote: > >> Certainly worth doing. It would be a valuable thing to have. >> As you point out, you''d learn from the experience, and you''d be >> contributing (not least time and energy). I expect you''ll need to >> discuss it on the FOX list, more so than the FXRuby list, though > > In truth, I wasn''t planning to use C++/FOX to implement it. > Obviously, though, it would make some sense to write it at a lower > level to run a bit faster and allow it to be used by a lot moreThis latter point is the strongest: a wider readership for your code.> people. I didn''t really want that extra effort which would be > unnecessary for my purposes...I''ll think again about that.Consider it as you write the Ruby: there may be decisions you make about the design which could make a move to C++ later easier. I''ve not done enough to suggest any examples.> > Lyle said somewhere that he was not going to put it in FXRuby > since it could be implemented in pure Ruby. Based on myIf it were in FOX he almost certainly would include it, but that''s his decision, not mine of course!> unoptimised prototype, FXRuby seems to be reasonably fast with > graphics, even when double-buffering. I imagine it would not be > fast enough to act as a basis for Macromedia Flash-type animations > though *8-)*So your second project will be the silicon compiler for Ruby :-)> > bil >Hugh>
On Thu, 22 Jul 2004 16:15:26 +0100, "Bil" <bil.bas@virgin.net> wrote :> Lyle said somewhere that he was not going to put it in FXRuby since itcould be implemented in pure Ruby. I think I''ve lost track of this conversation. ;) Lyle said he wasn''t going to put *what* in FXRuby?
On Thu, 22 Jul 2004, lyle@knology.net wrote:> > On Thu, 22 Jul 2004 16:15:26 +0100, "Bil" <bil.bas@virgin.net> wrote : > >> Lyle said somewhere that he was not going to put it in FXRuby since it > could be implemented in pure Ruby. > > I think I''ve lost track of this conversation. ;)The context was the discussion of a canvas with memory like that of Tk. Bil was talking about his Ruby implementation, not designed to be part of FOX itself> > Lyle said he wasn''t going to put *what* in FXRuby? >Hugh
On Jul 22, 2004, at 6:19 PM, Bil wrote:>> Lyle said he wasn''t going to put *what* in FXRuby? > > Sorry, a vague reference there (with some inference by me). I read > something in the FXRuby docs. This is what made me think of starting > this whole thread: > > Chapter 7. To-do list > Many people have expressed interest in a framework similar > to Tk''s Canvas widget that allows you to draw and drag 2-D > shapes around, etc. Should be able to implement this kind > of thing directly in Ruby code (i.e. no need to write it in C++ > first and then "wrap" it).Oh, OK. I think what I was getting at was my opinion that it shouldn''t be necessary to first write a C++ widget and then wrap it, as is the case for most of FXRuby. I was guessing that this kind of widget could be written "directly" in Ruby by subclassing one of the existing FXRuby classes (probably FXWindow or FXCanvas) and adding the magic. Of course, if you (or someone else) went ahead and wrote said widget in C++ anyways, and it was a good one, I''d go to the effort of "wrapping" it for FXRuby, as has been previously done for FXScintilla. Now, based on some of the other e-mails in this thread, I think I jumped the gun and assumed that you were talking about some kind of FOX-based widget, and I now understand that might not be the case. That''s cool, too, it still sounds like an interesting project. I wonder if you''ve seen rasterman''s Evas widget (part of the Enlightenment project)? http://enlightenment.org/pages/evas.html It''s one I looked at about a year ago, and did some preliminary work on wrapping it for FOX. I need to see if I can find that again. ;) Lyle
*********** REPLY SEPARATOR *********** On 23/07/2004 at 13:39 Joel VanderWerf wrote:>Bil wrote: >> I am aware that people have, in the past, asked for a Tk-style canvas >> object that manages shapes (etc) within it. >> [snip] > >FWIW, I''ll add my encouragement. It''d be great to have a Tk canvas >workalike in FXRuby, for doing simple animations and diagrams that >aren''t worth the effort to do in OpenGL.Thanks everyone for the encouragement *8-)*. Just proposed at RubyForge (comments welcome!). I''ll CVS where I''m up to when I get a reply. The reason I haven''t gone with a C++ implementation is that, really _I_ don''t need it enough (at least to justify the much greater effort to get anywhere - C++ is OK, but I''ve not used ''real'' FOX and even after that it would have to be wrapped...). Most importantly I would like an FXRuby implementation sort of soon. If you are optimistic, see this as a prototype...> (Maybe I should just get better at OpenGL ;)Maybe I should just get better at C++ *8-P* <proposal> Working title ------------- FXSvgCanvas Purpose ------- FXRuby lacks a managed canvas like the Tk canvas widget. The intention is to create a subclass of FXCanvas that manages internal "pseudo-widgets" in an SVG-like hierarcy. Note: it is *possible* that this Ruby implementation will be a prototype for a later C++/FOX implementation (which would then be wrapped for FXRuby). Spec ---- Allow creation of pseudo-widgets: * Geometric shapes [circle, polygon, etc] * Images and icons. * Text. * Containers for grouping objects (SVG <g>). Allow manipulation of these objects: * move, resize, raise, lower, etc. * _possibly_ scripted animation. Canvas handles all re-drawing of items in correct order. Perform hit-testing (e.g. ob = canvas.hit(10, 30)). Allow tag-recognition (e.g. canvas["frog"].move! 10, 3). _Possibly_ XPath syntax as well as that of Tk (e.g. canvas["/fish/head/eye"] == canvas["eye"] assuming there is only one "eye" in diagram)? Allow event-binding (e.g. onMouseOver, onMouseClick) to these pseudo-widgets. Structure is based on w3''s SVG (Scaleable Vector Graphics) format. Thus can easily import from/export to SVG (though import of externally produced SVG will probably be limited). This relies on REXML for parsing. </proposal> bil
*********** REPLY SEPARATOR *********** On 24/07/2004 at 13:04 Bil wrote:>*********** REPLY SEPARATOR *********** > >On 23/07/2004 at 13:39 Joel VanderWerf wrote: > >>Bil wrote: >>> I am aware that people have, in the past, asked for a Tk-style canvas >>> object that manages shapes (etc) within it. >>> [snip] >> >>FWIW, I''ll add my encouragement. It''d be great to have a Tk canvas >>workalike in FXRuby, for doing simple animations and diagrams that >>aren''t worth the effort to do in OpenGL. > >Thanks everyone for the encouragement *8-)*. Just proposed at RubyForge >(comments welcome!). I''ll CVS where I''m up to when I get a reply. > > [snip specs...] >That was quick. Yay for RubyForge! I commited. Yay for me! I''ll take this discussion away now (since it is no longer a strictly FXRuby one *8-)* ). http://rubyforge.org/projects/fxsvgcanvas/ http://fxsvgcanvas.rubyforge.org/ bil