Re: Units and resolution independence for gtk+
David Zeuthen wrote: PROPOSAL My proposal is to merge something like this for gtk 2.x in the near future and make it mandatory in gtk 3.0. Flames, praises, thoughts? Awesome!!! We could really use something like this in Sugar... Marco ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: goocanvas notes
On 4/28/07, Havoc Pennington [EMAIL PROTECTED] wrote: Hi, I read over the GooCanvas code and wrote down everything I thought of, some of it is half-baked or quarter-baked, but hopefully helpful in some way. Looks like a pretty good list. I would add that, at least for widget-y uses, layout should happen in integer pixels, not in double. Marco ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On 4/19/07, Carlos Garnacho [EMAIL PROTECTED] wrote: Hi all!, After reading Tim's mail about volunteer tasks [1], I've bitten the bullet and will try to help out fostering the GtkCanvas discussion, so here it goes! There have been several discussions about getting a canvas into GTK+, being the last one in the GTK+ meeting at Fosdem [2], where one of the conclusions was that we needed to gather the candidates on one side and the desired feature set for a GtkCanvas on another. First of all we need to specify the feature requirements for the canvas. The following is a list of features I think we should consider, hope it's a good start, please add to it if there are others: - GTK+ suitable API. - a11y support. - Model/View split. - Size negociation, height for width, width for height and natural size. - object shapes, collision detection. - animation framework (perhaps should be more tied to GTK+, GtkTimeLine maybe?). - get the offscreen rendering patch in. - GtkPrint* integration. - grouping/ungrouping. - extensibility, being able to create new canvas elements with little effort. - DnD support. - Integrate tightly GTK+ and the canvas, even making GtkWidgets specialized canvas elements drawn with a certain layout in a canvas, see Havoc's proposal [3] A couple of features which we are really missing in hippo-canvas: * Key navigation (which is obviously also a prerequisite for a11y) * Ability to set a global scaling factor for the canvas and support for units. Marco ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On 4/19/07, Havoc Pennington [EMAIL PROTECTED] wrote: Hi, Carlos Garnacho wrote: First of all we need to specify the feature requirements for the canvas. I'd step back first and do use-cases instead, and also talk about at a high level what the canvas is for and when it would be used, i.e.: - when is a canvas item used vs. a widget? what current widgets would be replicated as canvas items? - when is a canvas used vs. just drawing to a drawable with Cairo and Pango? - is the canvas essentially a fixed-up replacement for GtkWidget/GtkContainer (the GTK widget core) or does it have some other purpose? If it has another purpose, what is it? - can a list of use cases be spelled out? - how are existing canvases being used? which apps seem to be using canvases and why and for what? I bet everyone would think more clearly if we put a bullet in the word canvas and instead thought about next-gen widget system core or simplified drawing API or something of that nature. If you start thinking this way, perhaps there's even more than one new API that's needed, i.e. maybe there's a next-gen widget core, but *also* a simplified drawing API used to *write* complex widgets/canvas-items. I don't know. The word canvas is especially misleading because GnomeCanvas is such a bad model; the big problems GnomeCanvas used to solve no longer exist, so the GnomeCanvas design really has little or nothing to do with anything. GnomeCanvas was based on TkCanvas, which has even less to offer as a model I'd say. I can think about 3 main uses cases: 1 Free form views(html like). 2 Make it easier to implement complex controls (more powerful drawing API) 3 Next generation controls framework (gtk replacement) In Sugar we are going to use hippo for 1 and probably for 2 (the concern there being the lack of accessibility support). We considered using it for 3 but dropped the idea because it would require resources we don't have and break compatibility with gtk. Marco ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On 4/19/07, Havoc Pennington [EMAIL PROTECTED] wrote: Marco Pesenti Gritti wrote: * Key navigation (which is obviously also a prerequisite for a11y) I'd add to this bullet anything GtkWidget has that HippoCanvasItem does not - basically HippoCanvas is the GtkWidget/GtkContainer replacement school of canvas thought. Yeah. * Ability to set a global scaling factor for the canvas and support for units. Would this require modifying individual canvas items, or can the HippoCanvas widget just transform the cairo_t it passes to the root item (and also transform event coords of course) I don't think it would require modifying items (embedded widgets being the exception, in their current incarnation at least). cairo_t and events coords transformations should do it. There is something which bothers me though. Support for some units, points for example, would require floating points measures. And I suspect we don't want to do layout in floating point (instability issues). Mozilla converts css units in twips (an arbitrary integer unit, 1/20 of a point). That's a way to go about it I guess, though it requires conversions it in the canvas items. Better ideas? Marco ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
On 9/19/06, Damon Chaplin [EMAIL PROTECTED] wrote: So how are we going to decide on a list of requirements for a canvas?I think there seem to be two main use cases: A) DTP/Graphics apps that want a canvas for the main document.(A model/view split, device-independent layout, zooming printing are important here.) B) Flashy user interfaces.(Support for embedded widgets is useful here.)Can we even agree on 2 fundamental requirements: 1) Should the canvas items have a model/view split? - It is very useful for (A) above but makes (B) awkward.I agree with the analysis. I have no good ideas on how to avoid the problem other then designing two different API though. 2) Should it support embedded widgets?- Useful for (B) but will probably always have limitations (either you can't stack items like in GnomeCanvas, or you can'tzoom or transform widgets, or you can't print widgets).It is also difficult to fit into a model/view architecture. I'm not sure (2) is an absolute requirement for (B). Widgets are going to look somewhat ugly and I'm not sure they are flexible enough to be used in a canvas based UI. I think having an editable text canvas item would cover most of the use cases. Also I think some sort of layout support is a requirement for (B).Thanks,Marco ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
On 8/31/06, Havoc Pennington [EMAIL PROTECTED] wrote: Gustavo J. A. M. Carneiro wrote: It seems this HippoCanvas has no model-view split, yet I remember you designed GtkTextBuffer/View with model/view.Do you consider model-view unimportant, or simply just got prioritized away? I'm not sure, I'd have to look at GooCanvas or experiment myself. It'scertainly not required for Mugshot so I didn't think about it too much.I can definitely imagine it complicates things. On the other hand, conceptually for e.g. HippoCanvas it just means passing theHippoCanvasContext to the size and paint methods, instead of havingset_context(), and probably moving the allocation to becontext_get_allocation() instead of storing it in the item. For textview the reason we did it is to support e.g. split buffers in aprogramming editor (like emacs C-x 2 or whatever)A possible use-case for it with a canvas is something like a magnifieritem that is a view of another part of the canvas. But, how often do you really need stuff like that.Goocanvas has a view/model split at item level too. There is an ItemModel and and ItemView, and the Item interface has a create_view method. IHMO this introduce needless complexity, especially in the event handling. Mouse events are signals on the ItemView, so you have two options to listen for item events:1 Subclass Item and ItemView and handle signals in ItemView2 Handle events from the CanvasView (which therefore needs to know about his Model internals) None of these is really acceptable.I can see the usefullness of model/view split at item level in a widget system (Swing for example) where logic and presentation are clearly separated. But in goocanvas Model is totally about presentation (stroke-color, fill-color, line-width to cite some of the SimpleItem properties). Marco ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
On 8/30/06, Havoc Pennington [EMAIL PROTECTED] wrote: Hi,I posted some sort of blue-sky canvas ideas a year ago: http://mail.gnome.org/archives/gtk-devel-list/2005-August/msg00067.html Since then I've learned HTML/CSS much more thoroughly and also usedFlash a bit. And in the last week needed to write a canvas in 2-3 daysto use for Mugshot. Which is maybe interesting as a case study - if you had to strongly prioritize features since you only have 2-3 days, whatwould be really important for a real-world applicationThe code is here: http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-canvas-item.c http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-canvas.c http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-canvas-box.c http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-canvas-text.cRemember, written in a few days for a single app; not intended to becomea maintained library API. The HippoCanvasBox is the base class for all the items, i.e. all items are containers.This seem to imply a box based layout for the canvas, similar to the gtk one. In one of your previous canvas posts you was talking of more powerful layout managers (to be able to layout widgets around a shape for example). Something turned down that idea? I think the biggest question about a canvas in gtk in my mind really isthis thing about how far to go - how do you define the thing, both in absolute terms, and relative to the core gtkwidget/gtkcontainer stuff. +1Marco ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
- typing in C is definitely worse than HTML, so having a markup languageas an integral part of a canvas design is of interest. The other option is a GUI editor a la Flash/glade. Obviously the editor could use a markup language. But designing a toolkit from the beginning to be used programmaticaly, with some kind of markup language or with a GUI editor (or with a combination of these) can make a big difference , most notably on the layout model... Marco ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
