On Fri, Feb 27, 2009 at 14:30, Wang Kunshan <wks1...@gmail.com> wrote: > > I add gaphas, the canvas system of gaphor UML modelling program.
Gaphas is a good fit in my experience. Regards, Tomeu > The code looks well-commented. And the README shows its structure > which addressed some problems (like the responsibility of geometric > objects, canvas, tools) that I am also considering recently. > > But the size of gaphas is almost as big as the entire labyrinth. > Isn't is a bit overkilling? > > > > 2009/2/27 Matthias Vogelgesang <matthias.vogelges...@gmail.com>: >> >> Hello Wang and Readers, >> >> On Fri, Feb 27, 2009 at 05:05, Wang Kunshan <wks1...@gmail.com> wrote: >>> Currently self.translation is referenced all around the code. It >>> should be taken seriously whether to introduce >>> self.central_point_of_view and remove self.translation. >> >> The code is quite a mess, indeed. Oh, and nice analysis of the zoom >> problem. I had a hard time doing it correctly and it never worked they >> way I wanted it to do. >> >>> Summary: >>> >>> 1. The current implementation of scroll() is obviously incorrect. >>> 2. The self.translation is strange. It is difficult to understand and >>> difficult to use. >>> 3. Introducing self.central_point_of_view will simplify coordinate >>> handling, but will result in many code-changes. >> >> The way labyrinth is working with all those nifty details of a canvas >> is rather awkward, that's right. In the last week I needed something >> similar to represent a directed graph in a python application. >> However, the "canvas" (or MMapArea) of Labyrinth is too tied to the >> rest of the code, to be useful for any other application. >> >> I checked out other gtk canvas widgets which might be useful for >> Labyrinth [1]. The pros and cons of adopting an existing canvas widget >> are obvious: >> >> + well tested >> + we can spend time on Labyrinth's real problems >> + with a proper widget a11y is already done >> - might not be that flexible >> >> A must-have for our purpose seems to be Cairo rendering. GnomeCanvas >> seems to be a no-go, whereas (py)goocanvas and ccc are already adopted >> by some projects. Clutter on the other hand is a bit overkill for our >> purposes, I think. >> >> So we have several options: >> >> * GooCanvas: has a11y support, very low-level (zooming and dnd must >> be done by us) >> * ccc: according to the wiki page it seems ok, but it looks like it >> is abandoned >> * CrCanvas [2]: this is my all-time favor, it has builtin panning, >> zooming and infinite scrolling and is made with performance in mind >> (this is where Labyrinth really sucks) >> * make our own generic canvas from scratch >> >> And I have a question regarding the vcs. I would like to use git or >> some other kind of dvcs, however the git-to-svn-bridge I used sucked a >> little bit. Has anyone objections of moving to a distributed vcs? >> >> So I would suggest to release the next version of Labyrinth asap and >> then make a hard break. >> >> >> [1] http://live.gnome.org/ProjectRidley/CanvasOverview >> [2] http://geocanvas.sourceforge.net/crcanvas/index.html >> >> -- >> Matthias Vogelgesang >> Public-Key: http://tinyurl.com/2qcydl >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Labyrinth Discussion" group. To post to this group, send email to labyrinth-devel@googlegroups.com To unsubscribe from this group, send email to labyrinth-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/labyrinth-devel?hl=en -~----------~----~----~----~------~----~------~--~---
