Re: New canvas??
James Henstridge wrote: So do you think this is a good idea? I think such a project could be useful for a lot programs (there is a lot of code in the GNOME CVS tree handling multiple views of a canvas based display). Is there anyone who would be interested in helping out on a project like this? I know our project would have a lot of use for something like that. I'm not sure how much time I could dedicate to helping out, but I'd do what I could. -- Rick L. Vinyard, Jr.
Re: New canvas??
James Henstridge wrote: With such a canvas, all dia objects would probably be subclassed from some special dia canvas item type, rather than the base canvas item. I agree here. In our project, we are currently using the CanvasWidget in several different ways, providing the functionality in our child classes. The hierarchy you propose would also allow current code to remain mostly compatible with the base CanvasWidget class. Additional functionality can come through inherited classes and could allow for several divergent child inheritance paths. In fact, a child class could be developed that would include all the features of the current CanvasWidget. I have gotten rid of the idea of layers, as they are really just groups that are children of the root canvas item (I am not saying that dia should get rid of its layers concept -- just that they don't need to be in the base canvas implementation). Very good point. That allows for child branches with and without layers. There are other features, such as the grapples/handles that could be included/excluded in derived children. The main point is that the base class doesn't impose either upon the programmer. -- Rick L. Vinyard, Jr.
Re: New canvas??
"Gilles J. Seguin" wrote: Somes taughts, conceptually, I would have liked the grapples/handles/knobs to be used like the GTK_CONTAINER(frame). Be able to do grapplesIn/grapplesOut, draw the frame, modify the frame, like the color, the size, the way it is hatched, shadowed. The drawing objects can be group, resize/move has a group. A hook to treat the inside hit in a special way. What about addressing that as a CanvasGroup with draw methods, as opposed to a completely different canvas? As a user, I prefer James idea of a very thin base class that provides a core functionalitu, with more complete and possibly divergent derivatives. I haven't looked indepth at DiaCanvas, perhaps it's already done this way. I should probably familiarize myself more with Arjan's work before I make many more comments. -- Rick L. Vinyard, Jr.
Re: Should we drop the imlib dependency alltogether?
James Henstridge wrote: I was wondering what people think of the idea of dropping imlib support in dia altogether in favour of gdk-pixbuf. The next version of gdk-pixbuf drops the libart dependency, so the only libraries required to build gdk-pixbuf are glib, gtk+ and the image libraries, so it is no more of a problem to compile than imlib. The current way we use imlib doesn't exploit any of its caching functionality, and fits what gdk-pixbuf provides quite nicely. What do you think? FWIW I work with a research project that is migrating our visual interface for the same reasons. By projecting ahead, we're ready to run with gdk-pixbuf when it and the gnome canvas widget are fully integrated. Since gnome will rely so heavily upon gdk-pixbuf I wouldn't be too concerned about the user base not having the library, or having it readily accessible very soon. On another issue, I haven't looked at your code, but I assume you're still using the DiaCanvas as your main widget. On Arjan Molenaar's web site the latest version is 0.40.0 of November 6 1999. Do you have an updated version of the widget in CVS? -- Rick L. Vinyard, Jr.
Re: Should we drop the imlib dependency alltogether?
James Henstridge wrote: The DiaCanvas is actually a modification of what Dia uses. I haven't actually looked at DiaCanvas though. Gotcha. I was under the impression that it was a separate component developed by the Dia developers and was broken out separately. As for gdk-pixbuf support, dia currently uses it if it is available in preference to imlib (this support is a bit broken after Federico's big gdk-pixbuf changes (which removed the libart dependency and made GdkPixbuf an opaque structure)). I see, I didn't read the question carefully enough. I interpreted it as when should migration begin as opposed to what was actually asked. It broke some of our code too, but wasn't too bad to fix. Ahhh, life on the CVS bleeding edge. -- Rick L. Vinyard, Jr.
Re: UML
Pardon my ignorance... where do I find out... "what is UML?" UML is the Unified Modeling Language. It is a diagramming tool for designing object oriented software. There are several books on the subject, and a link collection exists here: http://www.cetus-links.org/oo_uml.html My hope is that the UML portions of dia can be broken off into a CORBA component, and used in a collection of services like code generation to be used by gIDE. Ambitious I suppose, but we really do need good OO modeling tools. Commercial products are prohibitively expensive, and not availiable for linux. Very nice. I've been using gIDE for about a year now, and Dia for about two months. Combine the two with Glade and it will be a killer app. I wonder what the difficulty of parsing the Glade XML and mapping it to Dia XML would be? -- Rick L. Vinyard, Jr.
