Re: GTK+ canvas?
On Tue, 2006-09-19 at 11:20 -0400, Havoc Pennington wrote: Hi, Damon Chaplin 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.) My basic feeling is that a) should be a separate lib and b) should be in gtk, but both are potentially useful. a) might or could be a little different api as Soeren was talking about, I don't know. b) is the one I have the most experience with. 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. For b) I don't think it's very important. I think it may actually be possible to make the model optional. (For a simple canvas you would add items groups yourself, but if you set a model the canvas connects to the model's item-added/moved/removed signals and creates/updates the canvas items automatically.) The only downside is that canvas items would have to be either simple items or model/view items. (I'd turn the basic items into simple canvas items, since they probably aren't that useful for large model/view apps anyway.) Is it worth trying that? missing (from your list anyway), some important, some nice: o Widget embedding o Layout I'd be willing to try to support these as well (though someone else can sort out the widget embedding limitations if they want to). Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
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. 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't zoom or transform widgets, or you can't print widgets). It is also difficult to fit into a model/view architecture. If there was a definitive list of required features for a GTK+ canvas I'd try to support them in GooCanvas if possible. But it still all seems a bit hazy to me. Damon PS. Here's a list of the current GooCanvas features: o Model/view split. o Uses interfaces for items views. o Basic items - rect/ellipse/polyline/text/image/group. o Path item, using SVG path specification strings. o Layers/stacking order with raise/lower functions. o Styles - line width/cap style/join style/dashes/colors/fill patterns. o Affine transformations for items ( views) - rotations/scales/skews. o Event handling - button/motion events, pointer-events like SVG. o Grabs - support for pointer keyboard grabs. o Keyboard focus traversal. o Accessibility (title description properties and hierarchy stuff). o Printing (output to a given cairo_t). o Scrolling. o Zooming. o Item visibility setting - on/off/above zoom threshold. o Simple animation. o Scalable - support for thousands of items over a large canvas area. o Support for different units - pixels/points/inches/millimeters. o API docs. ___ 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?
Hi,
Damon Chaplin 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.)
My basic feeling is that a) should be a separate lib and b) should be in
gtk, but both are potentially useful. a) might or could be a little
different api as Soeren was talking about, I don't know. b) is the one I
have the most experience with.
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.
For b) I don't think it's very important.
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't
zoom or transform widgets, or you can't print widgets).
It is also difficult to fit into a model/view architecture.
I think it's essential for b). The limitations there are pretty possible
to overcome; there are patches like Alex's to allow redirecting the
drawing of legacy widgets, which is already enough to transform and
print them (essentially, as bitmaps).
But also if the CanvasItem is an interface, widgets can implement it.
For widgets that do, you don't have to use a CanvasWidget adapter item,
you can just dump the widget itself into the canvas.
If there was a definitive list of required features for a GTK+ canvas
I'd try to support them in GooCanvas if possible. But it still all seems
a bit hazy to me.
You know how open source is ;-) what are the chances of getting anything
definitive! At best someone can keep summarizing the conversation and
try to clarify the options as you did here with a) and b).
PS. Here's a list of the current GooCanvas features:
My .02 on the important, nice, could-live-without, and missing here,
assuming canvas type b).
important:
o Uses interfaces for items views.
o Layers/stacking order with raise/lower functions.
o Affine transformations for items ( views)
o Event handling - button/motion events, pointer-events like SVG.
o Grabs - support for pointer keyboard grabs.
o Keyboard focus traversal.
o Accessibility (title description properties and hierarchy stuff).
o Printing (output to a given cairo_t).
o Basic items - text/image/group.
o Scrolling.
o Item visibility setting - on/off/above zoom threshold.
o Simple animation.
o Scalable - support for thousands of items over a large canvas area.
o API docs.
nice:
o Path item, using SVG path specification strings.
o Styles - line width/cap style/join style/dashes/colors/fill
o Zooming.
o Support for different units - pixels/points/inches/millimeters.
could live without:
o Model/view split.
o Basic items - rect/ellipse/polyline
missing (from your list anyway), some important, some nice:
o Widget embedding
o Layout
o Does not include gtkwidget.h in the canvas item interface, only in
canvas widget and canvas widget item, i.e. canvas item tree can go
'alongside' gtk conceptually and be used to paint to a non-gtkwidget
o Fix gtk's container-itis with the layout (e.g. HippoCanvas now has
padding-{left,right,top-bottom}, border-{left,right,top-bottom}, xalign,
yalign, border-color, background-color for all items)
o Inheritance of certain properties from parent items (e.g. font), i.e.
cascading styles
o Behaviors (draggable, raisable)
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
On Tue, 2006-09-19 at 13:07 +0100, Damon Chaplin wrote: 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. 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't zoom or transform widgets, or you can't print widgets). It is also difficult to fit into a model/view architecture. My biggest requirement is that it's designed with a creation tool in mind. GTK+ would be very different (and probably better) if it had been developed with glade in mind. Thanks, -Jonathan signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
From: Havoc Pennington [EMAIL PROTECTED] I can't think of more than a short list of layout managers that would be widely used. Application-specific layouts could be useful though, e.g. put these items in a circle or flow items around this item or something like that. Constraints libraries such as Qoca or Cassowary could be used. Because I'm up to OpenGL-only GUI, I have also thought of if game physics/collision libraries such as ODE or Bullet could be used for layout and other constraints. There is already a Physics Processing Unit (PSU) in hardware which could manage fairly large GUIs. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Havoc Pennington wrote: Soeren Sandmann wrote: Yevgen Muntyan [EMAIL PROTECTED] writes: Much more people would make use of simple things like draw a rectangle and drag it around if it wasn't so hard. The draw a rectangle and drag it around use-case is somewhat misleading; it applies most to something like a game, maybe 15-game or Solitaire. plenty of HTML or Flash apps aren't really doing this. I think html pages and flash app _are_ in fact drawing lines and points, maybe some vectorial drawing routines - text rendering etc. etc. dont get me wrong - I think it would be great if we could have flash-like functionality available in gtk+, but I think it would be 100 times superior if all that great stuff were implemented on top of the simple hypothetical GtkCanvas - that does just that: simple things like drawing vectorial shapes with anti-aliasing, allowing widget embedding and even the embedding of movies... how about something a little more far-fetched - how about swapping your toplevel canvas for a gstreamer video output canvas derivative and dishing out all that html/flash magic on top of that instead of a bland white background ? (insert endless possibilities here) Whether any of this is in reach or not is irrelevent, my point is more that when you need a canvas, you want some really really simple building block that you will use to do something very custom for your application - when you want to implement a vectorial scene with embedded buttons and rocket-ships, you might not even be aware that your GtkRocketShip object used the GtkCanvas at all. I just dont think we should dive right into writing up a GtkRocketShip or a GtkFlashScene without having paved the way with a simple GtkCanvas that is usefull to everybody first - rocket ships and geckos might also be considered as unneeded bloat to gtk+, and could probably better be included a little higher up in the stack. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Tristan Van Berkom wrote: I just dont think we should dive right into writing up a GtkRocketShip or a GtkFlashScene without having paved the way with a simple GtkCanvas that is usefull to everybody first - rocket ships and geckos might also be considered as unneeded bloat to gtk+, and could probably better be included a little higher up in the stack. You may be overestimating the futuristicness of something more useful than GnomeCanvas ;-) e.g. the HippoCanvas I wrote in 3 days lacks some stuff (i.e. I didn't bother to support events other than button press), but it's already more useful than GnomeCanvas because it supports layout (width-for-height layout even). I'm sure the other more serious existing implementations have also surpassed GnomeCanvas already. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
On Sat, 2006-09-09 at 21:43 -0500, Yevgen Muntyan wrote: Soeren Sandmann wrote: Yevgen Muntyan [EMAIL PROTECTED] writes: Much more people would make use of simple things like draw a rectangle and drag it around if it wasn't so hard. But applications generally need to do much more than draw a rectangle and drag it around. If dragging rectangles around was really all there was to it, then yes, fixing GnomeCanvas and putting it GTK+ would be mostly fine. Well, draw a rectangle was a bit simplistic, indeed. Right now I can think of games like chess (if it's not as static as chess, you want some special lib anyway), or some custom tooltip-like things, where you want to be able to add some nifty pictures onto the layout without extra pain, or for stuff like widgets in system monitor - two rectangles where you draw some stuff independently, or diagrams which do not require great deal of interactivity (the system monitor thing belongs to this category). And don't forget the Eclipse GEF API [http://www.eclipse.org/gef/], which is pretty widly used for various graphical editors in Eclipse. Its basic feature is that it lets you draw boxes and drag them around. Best regards, Yevgen -- Michael R. Head [EMAIL PROTECTED] suppressingfire.org ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Havoc Pennington wrote: e.g. the HippoCanvas I wrote in 3 days lacks some stuff (i.e. I didn't bother to support events other than button press), but it's already more useful than GnomeCanvas because it supports layout (width-for-height layout even). I'm sure the other more serious existing implementations have also surpassed GnomeCanvas already. Basing a canvas on cairo requires very little to surpass GnomeCanvas. For example, I put down some rough thoughts here: http://libpapyrus.sourceforge.net/gnomecanvasmm.php I think perhaps my goals and the design of papyrus are a little different from the general discussion I've seen in this thread. In particular, my interest lies in diagrammatic reasoning, visual languages, and in particular rule-based visual languages. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Havoc Pennington [EMAIL PROTECTED] writes: I think retained mode is interesting when the objects have two properties: - Does the object contain state that the application doesn't *care* about. - Is the object generic enough that many applications would need it That amounts to saying does the object do more than just draw? doesn't it? I mean, if a canvas item adds any value or prebuilt functionality, then it will be an abstraction (hide state or at least code that the app doesn't care about) and it will be of general enough interest to be worth having in a library. I don't think a Tetris or an Inkscape or an Abiword widget is generally useful. Things like that always end up being specific to the application. On the other hand a button or a label is clearly generic enough to be useful in almost all applications. So I'd be careful about only having a retained mode 'canvas'; you risk ending up having to write tons and tons of special purpose 'canvas items', not matter how flexible you make the canvas. Since I'm claiming a canvas is just an extra-nifty GUI toolkit, this isn't surprising ;-) I'd expect a canvas to have essentially all useful widgets found in GTK. The simplest way to accomplish that is to allow embedding a GtkWidget as a canvas item. What I am claiming is that GnomeCanvas failed on at least two counts: (1) it didn't really have the required features to do interesting UI's, and (2) its retained mode requirement is a huge impedance mismatch for applications that need to keep a complex and dynamic display in sync with an application data structure. Note that GTK+ itself is _also_ a failure wrt. to (2). Interesting applications invariably draw their main display themselves; they don't build it out of GTK+ widgets. This means there is hard and boring code, such as scrolling and mouse input and drag and drop, that gets reimplemented in every application. So what I am saying is that any new extra-nifty GUI toolkit should at least consider whether insisting on retained mode for all elements is necessarily the right model. And also whether the traditional model/view split where the model is forced to implement a special interface, is really a good match for applications. A premise of all this is that building flash/html-like custom UI is a reasonable thing to do; I happen to think it is in lots of cases: - games - sufficiently consumer-ish applications where fun trumps consistency (think about Konfabulator/Dashboard for example) - non-desktop platforms (set-top box, handheld device, kiosk, OLPC) My point is that flash/html-like custom UI is simply not convenient to do in _any_ toolkit, extra-nifty or not, and that adding more and more niftyness is really just a workaround for the fact that the application can't just draw - it is constrained to set properties on widgets. Note that I am not against implementing an extra-nifty toolkit inside a GTK+, and also not against looking at a canvas as a parallel layer to GDK. There is tons of stuff in GDK that is basically obsolete by now. I just don't think niftier widgets is the answer to how do we make more dynamic and interesting UI easier to create. But it may well be the answer to GTK+ is getting long in the tooth. Again I think it's sort of interesting to think about the canvas as alongside GDK in the dependency graph instead of above it; that is, think of the canvas as a way to abstractly define a scene graph and interactions with it, and think of GdkWindow as one input/output device - so GDK is responsible for the idea of multiple windows and a desktop environment or window system surrounding said multiple windows, the canvas is responsible for defining the scene graph that goes in a window, and GTK is responsible for a collection of items (aka widgets) typical of standard desktop applications Another thing that is worth considering is whether composite is really all that great. A lot of the features of composite could be implemented on the client side without any (or much simpler) X server changes. Instead of creating a toplevel window, application could simply create a pixmap, then notify the window manager whenever that pixmap was ready to be published. The benefits here are - no X extension with unclear semantics needed - applications are explicitly aware that they are drawing to an offscreen area which means they can do things like scrolling without worrying about intermediate steps. To do tear-free compositing, the X server may need to provide a copy-on-write copy mechanism for pixmaps, but that is both simpler and semantically much more well-defined than Composite/Damage. I should say that the idea of simply drawing to pixmaps on the client side was Adam Jackson's, not mine. Soren ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Soeren Sandmann wrote: What I am claiming is that GnomeCanvas failed on at least two counts: (1) it didn't really have the required features to do interesting UI's, and (2) its retained mode requirement is a huge impedance mismatch for applications that need to keep a complex and dynamic display in sync with an application data structure. GnomeCanvas failed because it's buggy, undocumented, called gnome, is separate from GTK, not maintained, doesn't have win32 binaries, etc., etc. Much more people would make use of simple things like draw a rectangle and drag it around if it wasn't so hard. Best regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
On Sat, 2006-09-09 at 23:15 +0200, Soeren Sandmann wrote: H Another thing that is worth considering is whether composite is really all that great. A lot of the features of composite could be implemented on the client side without any (or much simpler) X server changes. Instead of creating a toplevel window, application could simply create a pixmap, then notify the window manager whenever that pixmap was ready to be published. The benefits here are - no X extension with unclear semantics needed - applications are explicitly aware that they are drawing to an offscreen area which means they can do things like scrolling without worrying about intermediate steps. To do tear-free compositing, the X server may need to provide a copy-on-write copy mechanism for pixmaps, but that is both simpler and semantically much more well-defined than Composite/Damage. This is slightly similar to the offscreen windows work I did for gtk+. It uses a single pixmap and manually handles event subsetting and clipping. This uses a toplevel window to get the events of course, and the pixmap solution must have something similar so that X sends events. Maybe an input-only window? There are some problems with this though. By not using real windows you loose a lot of X functionallity. For things like Xv, OpenGL, XIM, XEmbed, etc you really need a real window, and it has to be put in a normal window hierarchy. Also, the Composite/Damage way lets any existing X application be smooth, not only new apps. But its a very interesting idea. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a witless devious sorceror who hangs with the wrong crowd. She's a high-kicking snooty bounty hunter from beyond the grave. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Hi, Soeren Sandmann wrote: My point is that flash/html-like custom UI is simply not convenient to do in _any_ toolkit, extra-nifty or not While I don't doubt something even more convenient is possible, I would say Flash and HTML are well ahead of both GtkWidget (retained-mode) or GtkDrawingArea/custom-widget (not retained) for doing free form custom UI. Matching them would already be a big step up for GTK+. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Yevgen Muntyan [EMAIL PROTECTED] writes: Much more people would make use of simple things like draw a rectangle and drag it around if it wasn't so hard. But applications generally need to do much more than draw a rectangle and drag it around. If dragging rectangles around was really all there was to it, then yes, fixing GnomeCanvas and putting it GTK+ would be mostly fine. But real applications do (or should do) more complicated things like drawing formatted text and handling text selection and editing, and have the text flow around a rectangle which is connected to other rectangles with arrows. And the rectangles have handles that can be dragged around changing the layout of both rectangles and arrows and text, etc. etc. The amount of code needed to do things like that with the GnomeCanvas API (and similar) is excessive because you end up having to keep zillions of little canvas items in sync. Soren ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Soeren Sandmann wrote: Yevgen Muntyan [EMAIL PROTECTED] writes: Much more people would make use of simple things like draw a rectangle and drag it around if it wasn't so hard. The draw a rectangle and drag it around use-case is somewhat misleading; it applies most to something like a game, maybe 15-game or Solitaire. plenty of HTML or Flash apps aren't really doing this. What's often desired is more web-page-like; text and images, in a layout, with some decorations, and maybe a few interactive controls. Or even think about something like the GMail UI, for something more application and less document. The GMail view of a conversation is a nice example of something that could easily be a canvas. Some Windows Vista screenshots show a similar idea. Or think about the iTunes user interface; it has a standard list widget and an entry box or so mixed in there, but then there's a custom-drawn background and a custom burn CD widget. That kind of thing is a big headache in GTK. It's nice to be able to mix in custom drawn elements, either decorative, or things like displaying a selection rectangle or help balloon. But the bulk of the UI/page is often images, text, and normal widgets like lists. Obviously for the use case Soeren mentions (word-processor/spreadsheet/illustrator main document editor), this isn't true. Those things will need to be largely custom. If dragging rectangles around was really all there was to it, then yes, fixing GnomeCanvas and putting it GTK+ would be mostly fine. I think it's a mistake to take GnomeCanvas as prototypical example when discussing a canvas. GnomeCanvasItem was only just barely different from GtkWidget. HTML and Flash are in some ways pretty lame, but do have really useful stuff GnomeCanvas did not offer. FooScrollArea could also be much more useful than GnomeCanvas. GnomeCanvas was also fundamentally crippled since embedding widgets did not work, which severely restricted where it could be used and where people imagined using it. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Soeren Sandmann wrote: Yevgen Muntyan [EMAIL PROTECTED] writes: Much more people would make use of simple things like draw a rectangle and drag it around if it wasn't so hard. But applications generally need to do much more than draw a rectangle and drag it around. If dragging rectangles around was really all there was to it, then yes, fixing GnomeCanvas and putting it GTK+ would be mostly fine. Well, draw a rectangle was a bit simplistic, indeed. Right now I can think of games like chess (if it's not as static as chess, you want some special lib anyway), or some custom tooltip-like things, where you want to be able to add some nifty pictures onto the layout without extra pain, or for stuff like widgets in system monitor - two rectangles where you draw some stuff independently, or diagrams which do not require great deal of interactivity (the system monitor thing belongs to this category). There are many possible uses for a simple dumb canvas which is just less buggy, is in GTK, and is as well documented as the rest of GTK. I am sure having GnomeCanvas (fixed) in GTK would not be enough (the more you have the more you need), but it would be real real good. If there was a choice, GnomeCanvas (tested in applications, people know the most annoying bugs and inconveniences) fixed and renamed to GtkCanvas OR hypothetical super-flexible super-powerful canvas (where the author wants the thing opposite to what I (you, he, she) want), I'd choose GnomeCanvas. Best regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Havoc Pennington wrote: To me an HTML widget basically _is_ a canvas, and canvas heavily overlaps HTML/Flash, except that the canvas works well in a desktop app and HTML/Flash work well inside a browser. I've seen many comments re HTML as a model. Is there a reason why SVG hasn't entered the conversation; in particular the aspects of SVG that refer to interactivity (with many events that are almost a 1-1 mapping with Gdk), scripting and animation. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
One of the big challenges for a gtk+ canvas has to do with accessibility. If we build a gtkcanvas that is nice to use (and therefore gets widely adopted), it also has to expose all the appropriate ATK information. Otherwise, we'll be eroding gtk+ accessibility, and creating obstacles to deployment of gtk+ and gnome apps. (There are already statutory accessibility requirements for deployment in some environments, notably US education and government, and those requirements are expected to become more widespread in the future. They also tend to be of the all or nothing variety, so even one or two inaccessible applications in a desktop environment can become an issue). Thoughts since last canvas notes === - I think an important thing to keep in mind is that a canvas is just an alternate widget system. Yeah, kind of agree. To the extent that this is true, the accessibility requirements are fairly clear - widget-like things inside the canvas must follow the ATK accessibility principles, exposing fairly rich queryable interfaces. Textual content must expose AtkText/AtkEditableText, and onscreen objects must expose AtkComponent (bounds, z-order, position, focus). Also the objects must somehow have a keyboard navigation model so that the canvas can be used without the mouse. If we anticipate using a canvas for something other than plain vector or graphics primitive drawing, then a good deal of thought needs to go in to how the canvas' object model hooks in to ATK. Even in a simple graphics primitive canvas, we need an object model so that the parts of the resulting drawing can be organized in a hierarchical model and queried for bounds and attributes such as color, names/labels/descriptions, etc.The need to make a canvas-based application accessible also means that some facility for making the content accessible to blind users needs to be available in the main canvas API (in the manner of web page alt text, at minimum) so that the application developer can provide the appropriate info when building the app. The danger in canvases is that an attractively simple API, with only low-level primitives, will in the long run work against application consistency and accessibility. Any canvas needs an object model and I think ours needs one that incorporates accessibility from the outset. For historical reasons the ATK support for GTK+ widgets has been provided by the (external) gail library. This causes some headaches because it means everything required by ATK must be available via public widget API. In the case of gtkcanvas I think the ATK support would be more effectively written into the gtk+ codebase itself, so that private/internal structs and APIs are available, and so that changes to implementation details are more easily kept in sync with the ATK implementation. best regards, Bill ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
On Qui, 2006-08-31 at 11:02 +0100, Bill Haneman wrote: [...] To the extent that this is true, the accessibility requirements are fairly clear - widget-like things inside the canvas must follow the ATK accessibility principles, exposing fairly rich queryable interfaces. Textual content must expose AtkText/AtkEditableText, and onscreen objects must expose AtkComponent (bounds, z-order, position, focus). Also the objects must somehow have a keyboard navigation model so that the canvas can be used without the mouse. GooCanvas has some sort of object focus and keyboard navigation. I think we need to programmatically activate it somehow, but it's there, I've seen a demo too. If we anticipate using a canvas for something other than plain vector or graphics primitive drawing, then a good deal of thought needs to go in to how the canvas' object model hooks in to ATK. Even in a simple graphics primitive canvas, we need an object model so that the parts of the resulting drawing can be organized in a hierarchical model and queried for bounds and attributes such as color, names/labels/descriptions, etc.The need to make a canvas-based application accessible also means that some facility for making the content accessible to blind users needs to be available in the main canvas API (in the manner of web page alt text, at minimum) so that the application developer can provide the appropriate info when building the app. The GooCanvas standard items implement Atk interfaces already. It contains a standard 'title' property that I guess fills the role of alt text. And it also contains a hierarchical model and queried for bounds and attributes such as color, names/labels/descriptions, etc. So I think GooCanvas is well ahead of the competition in terms of gtk+ accessibility support. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ 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
Re: GTK+ canvas?
On Thu, 2006-08-31 at 13:03 +0200, Marco Pesenti Gritti wrote: 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 ItemView 2 Handle events from the CanvasView (which therefore needs to know about his Model internals) None of these is really acceptable. I don't see the problem with (1) for large applications. That is standard model/view stuff. For simple apps you can connect signal handlers to the item views. This isn't that hard (it is easier in the latest release). 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). The simple items are all basic shapes, but for real-world use applications would use their document objects as the model. I agree that the model/view split does complicate it a bit. But it can also help a lot for larger apps. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Marco Pesenti Gritti wrote: 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? If HippoCanvas were real then it should maybe have layout managers separate from items, and ability to specify different layout managers. But it would be important to implement these in such a way that they didn't make doing basic stuff way more annoying. e.g. if I'm creating a big tree of items with boxes as the containers, I don't want the code to have a zillion canvas_item_set_layout_manager() calls in it. Maybe an object property like this would not be too bad: g_object_new(TYPE_CANVAS_CONTAINER, layout, TYPE_CANVAS_LAYOUT_BOX, NULL); but I think this would be bad: container = g_object_new(TYPE_CANVAS_CONTAINER, NULL); layout = box_layout_new(); container_set_layout_manager(container, layout); that would get old quickly. A short list of layouts covers almost all needs though, so pluggable layout managers are a little overrated. If you have boxes, esp. with the improvements of 4-side padding, alignment, avoiding the gtk H-separate-from-V glitch, then that covers the common case. You might occasionally need fixed-positioning, or a table. I guess you could do a layout manager that was like css float also. I can't think of more than a short list of layout managers that would be widely used. Application-specific layouts could be useful though, e.g. put these items in a circle or flow items around this item or something like that. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Someone posted a link to the minutes of the gtk+ meeting at GUADEC
which reminded me that I promised to write up some of the ideas I had
for a canvas-type widget.
The reason model/view is a useful model is that it allows applications
to keep a data structure (the model) containing all the business logic
(what the application *does*) in one place and then have separate
modules displaying views of this data structure. Whenever something
changes about the model the view is signalled to change itself as
appropriate.
In an application based on GnomeCanvas or similar there will often be
a correspondence between objects in the data model and canvas items
and changes to the model will cause changes to the canvas
items. Essentially the application is forced to keep two distinct
copies of the model up to date. Not only does this use lots of memory,
it also requires lots of code to be written.
A much simpler approach is often to simply walk the model and draw on
a drawing area on every expose event. This gets hard for two reasons:
- you need to handle input on distinct areas corresponding to objects
in the model.
- you need to handle scrolling
Both of these are solved by a canvas widget which I'd argue is its
main attraction. For the old GnomeCanvas you also had the attraction
of antialiasing/translucency and bezier curves, but not cairo provides
this.
So FooScrollArea is an attempt at implementing input and scrolling
without retaining a hierarchy of canvas items, ie, and immeddiate
mode canvas. Demo code here:
http://www.daimi.au.dk/~sandmann/canvas-demo.tar.gz
The main thing to note is the small amount of code in testarea2
actually needed to implement the features demonstrated.
How applications would use it:
Applications keep a datastructure containing the application
model. Whenever something changes in this datastructure the
corresponding area is invalidated. The scroll area will then emit an
expose signal and the application will repaint the invalid area. Ie
basically like the gtk+ drawing model.
The difference is in how input is handled. During the expose handling,
the application is not only drawing stuff, it is also setting input
regions. These input regions are remembered by the canvas, but *get
invalidated along with the pixels*. Ie., you are required to repaint
all the input regions on every expose. If you paint two input regions
on top of each other, the top one will get the event first (and can
optionally pass it along to lower layers).
This way, all information about stacking and overlapping input regions
is *implicit* in the application model rather than explicit in the
canvas hierarchy. So even input handling is immediate mode rather than
retained mode.
Example of why this is useful:
Suppose you are writing an illustration program like Inkscape. Your
data model might be a tree of groups containing shapes and curves. One
of these shapes might be selected which means it has little handles
you can use to change the shape.
In the FooScrollArea model all you need to write is expose code for
the shape:
expose_shape (Shape *shape, ScrollArea *area, Region *region)
{
draw_shape (area);
draw_input_region (area, shape);
if (shape-selected)
{
for (points in shape)
{
draw_drag_handle();
set_drag_handle_input (handle_shape_input);
}
}
}
When a shape is clicked, the old selected shape gets its selected
bit cleared and the new one gets it set in the application model. Then
both areas are invalidad. When a drag handle is dragged, the
corresponding point needs to be moved and the item invalidated. So
there is only one copy of the state pertaining to the shape.
In the retained model, this will need to happen:
When a shape is clicked, the old selected shape needs to be unslected,
which means deleting a canvas item for each point on the shape. Then
new canvas items must be created for each of the handle points in the
new shape. When a drag handle is clicked, three different objects must
be updated: the application model object, the canvas item for the
shape, and the drag handle for the clicked point.
And this is just for editing a simple shape.
I believe this 'immediate' mode canvas is a simpler and more efficient
model than retained mode canvases, at least for most non-trivial
applications.
Soren
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Soeren Sandmann wrote: A much simpler approach is often to simply walk the model and draw on a drawing area on every expose event. This gets hard for two reasons: - you need to handle input on distinct areas corresponding to objects in the model. - you need to handle scrolling Both of these are solved by a canvas widget which I'd argue is its main attraction. For the old GnomeCanvas you also had the attraction of antialiasing/translucency and bezier curves, but not cairo provides this. Do keep in mind though that GnomeCanvas is a very, very low bar. As I mentioned in my year-old canvas notes mail, based on GnomeCanvas I thought a canvas widget was useless - it was mostly useful as a workaround for GTK 1.2 deficiencies, and most of GNOME stopped using it after GTK 2.0. A canvas widget _can_ do a lot more, much of it useful. The difference is in how input is handled. During the expose handling, the application is not only drawing stuff, it is also setting input regions. Very clever! I believe this 'immediate' mode canvas is a simpler and more efficient model than retained mode canvases, at least for most non-trivial applications. It depends on the goals of a canvas right - you're thinking of it as drawing area plus hit testing while it can be thought of as solving a wider set of problems. In particular I think of it as a more flexible sort of widget system more like HTML or Flash or XAML, in which the existing more rigid gtkwidget/gtkcontainer framework could be embedded. I wonder if this immediate mode model is interesting as either a layer below a more complex retained-mode canvas, or as a particular kind of item (widget?) inside a more complex canvas. But also worth considering is essentially adding hit testing to GtkDrawingArea and leaving that as the canvas in gtk, that would be one way to avoid unlimited scope creep... Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Havoc Pennington [EMAIL PROTECTED] writes: It depends on the goals of a canvas right - you're thinking of it as drawing area plus hit testing while it can be thought of as solving a wider set of problems. In particular I think of it as a more flexible sort of widget system more like HTML or Flash or XAML, in which the existing more rigid gtkwidget/gtkcontainer framework could be embedded. I think retained mode is interesting when the objects have two properties: - Does the object contain state that the application doesn't *care* about. - Is the object generic enough that many applications would need it This is generally true for gtk+ widgets. For example GtkButton contains the state is the mouse cursor inside me? which is entirely uninteresting to applications. If gtk+ was completely immediate mode in the sense I described, applications would need to maintain this piece of information for every button it used, which is clearly undesirable. Also GtkButton is clearly generic enough to be useful in basically all applications. Other pieces of state are more interesting: whether a checkbox is checked or not is interesting to the application (I'll bet tons of applications maintain a separate copy of the 'checked' bit for many of their checkboxes). Information such as 'what text does the GtkTextView contain' is very clearly interesting to the application. GTK+ recognizes this by having GtkTextBuffer separate from GtkTextView. But GtkTextView is less generic; for example it is not useful as the main widget of a word processor. In the Inkscape example, all of the state pertaining to the shape is interesting to the application. And a shape item would almost certainly not be useful across applications. So I'd be careful about only having a retained mode 'canvas'; you risk ending up having to write tons and tons of special purpose 'canvas items', not matter how flexible you make the canvas. On the other hand, if all you have is immediate mode you might end up having to write the same recursive layout code over and over. Soren ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Qui, 2006-08-31 às 20:22 +0200, Soeren Sandmann escreveu:
Someone posted a link to the minutes of the gtk+ meeting at GUADEC
which reminded me that I promised to write up some of the ideas I had
for a canvas-type widget.
The reason model/view is a useful model is that it allows applications
to keep a data structure (the model) containing all the business logic
(what the application *does*) in one place and then have separate
modules displaying views of this data structure. Whenever something
changes about the model the view is signalled to change itself as
appropriate.
That theory breaks when you need to access the view in order to layout
the items in the model. For instance (real life example!) suppose you
want to draw a rectangle around a unconstrained text item. Obviously
the size and position of the rectangle are properties of the rectangle
item model. Also obviously, you don't know beforehand how much size a
pango layout will take without access to the text item view, since the
text item model only contains a text string and pango font description;
from this information to the actual size on screen is a long long way.
Applications keep a datastructure containing the application
model. Whenever something changes in this datastructure the
corresponding area is invalidated. The scroll area will then emit an
expose signal and the application will repaint the invalid area. Ie
basically like the gtk+ drawing model.
Basically, the gtk+ drawing model sucks for drawing large and complex
content. Programmers avoid this problem by using lots of small widgets
instead of a single large and complex widget. The biggest pain when
using GtkDrawinArea, for instance, is handling of expose events. You
know you want to draw a set of objects in the drawing area; now, for
each expose event, which objects are affected by the exposed region, so
that I draw only them? Of course no programmer ever worries about this
detail, and everyone ends up just blindly drawing everything, which is
much slower. This is one of the key areas where a canvas should help.
And for a canvas to be able to help, it needs to be retained mode, i.e.
keep state of objects to be drawn.
The difference is in how input is handled. During the expose handling,
the application is not only drawing stuff, it is also setting input
regions. These input regions are remembered by the canvas, but *get
invalidated along with the pixels*. Ie., you are required to repaint
all the input regions on every expose. If you paint two input regions
on top of each other, the top one will get the event first (and can
optionally pass it along to lower layers).
This way, all information about stacking and overlapping input regions
is *implicit* in the application model rather than explicit in the
canvas hierarchy. So even input handling is immediate mode rather than
retained mode.
Yeah, right, goocanvas already does this too.
Example of why this is useful:
Suppose you are writing an illustration program like Inkscape. Your
data model might be a tree of groups containing shapes and curves. One
of these shapes might be selected which means it has little handles
you can use to change the shape.
In the FooScrollArea model all you need to write is expose code for
the shape:
expose_shape (Shape *shape, ScrollArea *area, Region *region)
^^^
Is this supposed to be immediate mode? This is retained mode IMHO;
the canvas is keeping state about shapes here...
{
draw_shape (area);
draw_input_region (area, shape);
if (shape-selected)
{
for (points in shape)
{
draw_drag_handle();
set_drag_handle_input (handle_shape_input);
}
}
}
When a shape is clicked, the old selected shape gets its selected
bit cleared and the new one gets it set in the application model. Then
both areas are invalidad. When a drag handle is dragged, the
corresponding point needs to be moved and the item invalidated. So
there is only one copy of the state pertaining to the shape.
In the retained model, this will need to happen:
When a shape is clicked, the old selected shape needs to be unslected,
which means deleting a canvas item for each point on the shape. Then
new canvas items must be created for each of the handle points in the
new shape. When a drag handle is clicked, three different objects must
be updated: the application model object, the canvas item for the
shape, and the drag handle for the clicked point.
And this is just for editing a simple shape.
I believe this 'immediate' mode canvas is a simpler and more efficient
model than retained mode canvases, at least for most non-trivial
applications.
Immediate mode is more memory efficient, but less CPU efficient. I
guess this is a tradeoff; which to pick depends largely on the
Re: GTK+ canvas?
Soeren Sandmann wrote: I think retained mode is interesting when the objects have two properties: - Does the object contain state that the application doesn't *care* about. - Is the object generic enough that many applications would need it That amounts to saying does the object do more than just draw? doesn't it? I mean, if a canvas item adds any value or prebuilt functionality, then it will be an abstraction (hide state or at least code that the app doesn't care about) and it will be of general enough interest to be worth having in a library. So I'd be careful about only having a retained mode 'canvas'; you risk ending up having to write tons and tons of special purpose 'canvas items', not matter how flexible you make the canvas. Since I'm claiming a canvas is just an extra-nifty GUI toolkit, this isn't surprising ;-) I'd expect a canvas to have essentially all useful widgets found in GTK. The simplest way to accomplish that is to allow embedding a GtkWidget as a canvas item. If someone were starting a toolkit from scratch, of course they wouldn't want this canvas items vs. widgets distinction, but in the real world it may be very practical to evolve GTK by building a canvas around it and thus avoid having to rewrite entire apps and avoid getting bogged down writing the difficult widgets such as window, entry, treeview, textview, file selector, etc. The canvas could have native versions of the simplest building blocks of a custom display (text, images) instead of using GtkLabel, GtkImage; but doesn't need to replicate the interactive widgets as long as it can just use the existing ones. Widget embedding could be done in two ways, probably moving from one to the other over time: 1) a CanvasWidget canvas item, that can embed any widget, possibly with certain limitations or quirks 2) implementing the CanvasItem interface in the widget itself, allowing the widget to be fully canvas enabled if it wants 2) can be done widget-by-widget as it's useful, I would think. Going over the list of widgets, I'd say Label, Image, and the layout widgets are just about the only ones worth having as native canvas items. A premise of all this is that building flash/html-like custom UI is a reasonable thing to do; I happen to think it is in lots of cases: - games - sufficiently consumer-ish applications where fun trumps consistency (think about Konfabulator/Dashboard for example) - non-desktop platforms (set-top box, handheld device, kiosk, OLPC) Again I think it's sort of interesting to think about the canvas as alongside GDK in the dependency graph instead of above it; that is, think of the canvas as a way to abstractly define a scene graph and interactions with it, and think of GdkWindow as one input/output device - so GDK is responsible for the idea of multiple windows and a desktop environment or window system surrounding said multiple windows, the canvas is responsible for defining the scene graph that goes in a window, and GTK is responsible for a collection of items (aka widgets) typical of standard desktop applications There are definitely some practical annoyances here (e.g. the list of keysyms lives in GDK while in this model it's needed by the canvas also), but it could be the right way to think about things, even if it isn't quite a good idea in practice. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
On Wed, 2006-08-30 at 15:52 +0200, W. Borgert wrote: Hi, sorry, if this is an FAQ, my checks didn't reveal anything: AFAIK, GTK+ does not have a standard canvas widget. GNOME does have a canvas widget, but it seems to be not very popular. And having it in the GNOME libraries is not useful for programs that should run on multiple platforms (win32). Despite its name, GnomeCanvas does not require GNOME libraries; in fact, it has been successfully used (directly, or through bindings) on other platforms, like win32. There has been an effort (as part of Project Ridley) on creating a new canvas widget using Cairo; at least two canvases have been written that I recall: Goocanvas (which has had Python bindings recently added) and CCC - probably I am forgetting some other project. Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
On Wed, Aug 30, 2006 at 04:55:12PM +0100, Emmanuele Bassi wrote: There has been an effort (as part of Project Ridley) on creating a new canvas widget using Cairo; at least two canvases have been written that I recall: Goocanvas (which has had Python bindings recently added) and CCC - probably I am forgetting some other project. OK, as both GooCanvas and CCC come with a demo application, I just tried out both. At first glance I can only say, that the GooCanvas demo is more impressive than the CCC one. Maybe GooCanvas is more feature-rich, but the library is also a little bit bigger. Thanks for pointing me to these nice libs. Cheers, WB ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
2006/8/30, W. Borgert [EMAIL PROTECTED]: OK, as both GooCanvas and CCC come with a demo application, I just tried out both. At first glance I can only say, that the GooCanvas demo is more impressive than the CCC one. Maybe GooCanvas is more feature-rich, but the library is also a little bit bigger. Thanks for pointing me to these nice libs. As Emmanuele already said we have just released python bindings for GooCanvas, maybe you want to try them out: http://developer.berlios.de/projects/pygoocanvas ciao -- Gian Mario Tagliaretti http://www.parafernalia.org/pygtk/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Gian Mario Tagliaretti wrote: 2006/8/30, W. Borgert [EMAIL PROTECTED]: OK, as both GooCanvas and CCC come with a demo application, I just tried out both. At first glance I can only say, that the GooCanvas demo is more impressive than the CCC one. Maybe GooCanvas is more feature-rich, but the library is also a little bit bigger. Thanks for pointing me to these nice libs. As Emmanuele already said we have just released python bindings for GooCanvas, maybe you want to try them out: http://developer.berlios.de/projects/pygoocanvas There are at least two applications developed using the python bindings for goocanvas: The gst-editor rewrite and applications for the OLPC. It seems like goocanvas is gaining momentum. Which are the next steps towards including them in Gtk+ under the name GtkCanvas? Johan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
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 used Flash a bit. And in the last week needed to write a canvas in 2-3 days to 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, what would be really important for a real-world application The 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.c Remember, written in a few days for a single app; not intended to become a maintained library API. The HippoCanvasBox is the base class for all the items, i.e. all items are containers. Thoughts since last canvas notes === - I think an important thing to keep in mind is that a canvas is just an alternate widget system. You can think of it as a GUI toolkit with different tradeoffs from GtkWidget, or a GUI toolkit with some of the misfeatures/limitations of GtkWidget corrected. But in any case it is basically defining the same thing as gtkwidget.c, gtkcontainer.c and other core GTK classes. - Along the same lines you can also think of a canvas as an alternative to Flash or HTML/CSS, two systems many programmers will be familiar with. - This poses a huge question for a canvas in GTK, namely, how much does it overlap widgets; if I'm writing an app, when do I use the canvas vs. widgets; exactly what is the scope of a canvas project; etc. - My opinion is that the canvas should replace the GTK core in a way, i.e. GtkWidget becomes a specialized thing you can embed in a canvas. This obviously makes the canvas into a pretty big project. - In fact a useful bit of discipline might be that gtkwidget.h does not get #include'd by the canvas item implementations. (except the canvas item that embeds a widget) Notes on how the Mugshot canvas worked out so far === - note that we're using it cross-platform but not using gtk cross-platform, so the canvas widget uses gtk, but none of the items do; the items don't have a concept of being on a canvas or even in a tree of items, they are all just standalone objects that can be sized and painted. Cairo and Pango are used cross-platform though. - canvas items always see only their own coordinates (what gnomecanvas called item coordinates), this removes a _lot_ of confusion that GnomeCanvas had - unlike GtkAllocation, this means the canvas item only needs to store its allocated size, not its allocated origin. Cairo makes this possible since drawing doesn't require converting to drawable coords (the cairo_t can have its translation matrix already set up) - we had previously coded the Mugshot custom display separately for Linux and Windows. On Linux, we used an atrocious custom widget from hell: http://svn.mugshot.org/dumbhippo/trunk/client/linux/src/hippo-bubble.c and on Windows we used an embedded IE control, i.e. HTML/CSS. - GnomeCanvas wouldn't have helped much if at all with cleaning up hippo-bubble.c, because the disaster is all the custom layout code. So, the canvas should support layout. - in the canvas layout code, we fixed several suboptimal aspects of GtkWidget: - it's width-for-height so text items work right - you can set padding on all 4 sides separately (and in the base class) - GtkMisc functionality is built in to all the items (but changed to enum FILL,START,CENTER,END instead of xscale/yscale/xfill/yfill) - I think making CanvasItem an interface worked very well, I haven't looked at GooCanvas but I see its website says it does the same. - the image item is able to tile, which is a common way to draw e.g. the edge of a box in html - the text item has a nice size-mode setting for whether you want it to be its natural full width, wrapped, or ellipsized which are the three cases I consider common - a link item, or somehow adding link support to Pango markup, is very useful; many custom displays are made to look html-like or web-page-like - I wanted a canvas shape item but Cairo supports no good way to store a shape, so instead we made the paint method a signal so you can hook in and draw something custom. But this is painful, as you also have to override hit detection and size request/allocation. - a deficiency vs. HTML is the lack of cascading or class-based styles. So e.g. if you set the font size for a box, it should become the default font size for all items that are children of the box, similar to how nested GtkTextTag get their attributes composited. Alternatively or in addition, it might be interesting to be able to define named styles that are then applied to multiple items, as in CSS classes. Lack of these
Re: GTK+ canvas?
In-Reply-To: [EMAIL PROTECTED] On Wed, Aug 30, 2006 at 08:38:22PM +0200, Gian Mario Tagliaretti wrote: As Emmanuele already said we have just released python bindings for GooCanvas, maybe you want to try them out: Hm, my PyGObject is too old, so I cannot try it now. Anyway, Python bindings are a very good reason to go for GooCanvas! Mille grazie! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Qua, 2006-08-30 às 16:17 -0400, Havoc Pennington escreveu: 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 used Flash a bit. And in the last week needed to write a canvas in 2-3 days to 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, what would be really important for a real-world application The 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.c Remember, written in a few days for a single app; not intended to become a maintained library API. The HippoCanvasBox is the base class for all the items, i.e. all items are containers. 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? IMHO, and from experience with coding in GooCanvas, dealing with model-view split adds much complexity with very little gain. How often do you see or use e.g. the model-view split of GtkTextBuffer being used by an application? And doing layout with MVC is cumbersome; e.g. in case of GooCanvas, doing layout with text items is hard and weird: you store the position in the model, but you need the view in order to get the size that item; but from the moment you need the view for anything, which view do you choose? Effectively you lose the model-view separation... but you just have to get the job done, so you eventually stop caring about model-view. In any case, it's still possible to do multiple views on top of a single-view canvas, even if it wastes more memory. However, I would argue that to display a very large document in a canvas creating a canvas item for each document item is not the best solution; I'd rather have a pool, or cache, of visible canvas items, and just reconfigure them on the fly to show the portion of the document currently visible. Thoughts since last canvas notes === - I think an important thing to keep in mind is that a canvas is just an alternate widget system. Yeah, kind of agree. - Along the same lines you can also think of a canvas as an alternative to Flash or HTML/CSS, two systems many programmers will be familiar with. Don't agree so much. I would say that an HTML widget could be built on top of a canvas, but a canvas IMHO should be something lower level than HTML (can't comment about Flash). - This poses a huge question for a canvas in GTK, namely, how much does it overlap widgets; if I'm writing an app, when do I use the canvas vs. widgets; exactly what is the scope of a canvas project; etc. There is some overlap. A canvas system, if done right, could lay the foundation for a next-generation widget system. - My opinion is that the canvas should replace the GTK core in a way, i.e. GtkWidget becomes a specialized thing you can embed in a canvas. This obviously makes the canvas into a pretty big project. Sounds an interesting idea... - In fact a useful bit of discipline might be that gtkwidget.h does not get #include'd by the canvas item implementations. (except the canvas item that embeds a widget) Notes on how the Mugshot canvas worked out so far === [...] - canvas items always see only their own coordinates (what gnomecanvas called item coordinates), this removes a _lot_ of confusion that GnomeCanvas had - unlike GtkAllocation, this means the canvas item only needs to store its allocated size, not its allocated origin. Cairo makes this possible since drawing doesn't require converting to drawable coords (the cairo_t can have its translation matrix already set up) It works this way in GooCanvas. - GnomeCanvas wouldn't have helped much if at all with cleaning up hippo-bubble.c, because the disaster is all the custom layout code. So, the canvas should support layout. GooCanvas doesn't have layout yet, but Damon mentioned some plans about this. - I think making CanvasItem an interface worked very well, I haven't looked at GooCanvas but I see its website says it does the same. It's true. Item and ItemView are two interfaces. - the image item is able to tile, which is a common way to draw e.g. the edge of a box in html So true. - typing in C is definitely worse than HTML Try Python! ;-) , so having a markup language as an integral part of a canvas design is of interest. Markup in the text item sounds fine. Anything else sounds like reinventing HTML. I think the biggest question about a canvas in gtk in my mind really is this thing
Re: GTK+ canvas?
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's certainly 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 the HippoCanvasContext to the size and paint methods, instead of having set_context(), and probably moving the allocation to be context_get_allocation() instead of storing it in the item. For textview the reason we did it is to support e.g. split buffers in a programming editor (like emacs C-x 2 or whatever) A possible use-case for it with a canvas is something like a magnifier item that is a view of another part of the canvas. But, how often do you really need stuff like that. - Along the same lines you can also think of a canvas as an alternative to Flash or HTML/CSS, two systems many programmers will be familiar with. Don't agree so much. I would say that an HTML widget could be built on top of a canvas, but a canvas IMHO should be something lower level than HTML (can't comment about Flash). A full HTML implementation certainly shouldn't be in a base canvas, but there's large overlap in when you might use a canvas or an HTML widget I would say. (Well, I know it's true for us - we were using an embedded IE on Windows and will now use a canvas thingy.) HTML also has some of the same advantages over gtkwidget/gtkcontainer that a canvas would have, it's easier for doing custom displays. If nothing else, a baseline metric of canvas quality is would it be easier to do the same apps in HTML - if yes, then the canvas would seem kind of lame to me. It's not like CSS is all that good. , so having a markup language as an integral part of a canvas design is of interest. Markup in the text item sounds fine. Anything else sounds like reinventing HTML. Is Glade reinventing HTML? ;-) I don't think there's a problem with being HTML-like because there is no reasonable way to use HTML in many of the contexts where you want to use the canvas. In fact, if using HTML was practical for Mugshot we would have used it, but unfortunately there is no plausible way to use it that's cross-platform and lightweight enough to use in something like a tray icon. To me an HTML widget basically _is_ a canvas, and canvas heavily overlaps HTML/Flash, except that the canvas works well in a desktop app and HTML/Flash work well inside a browser. GtkHTML was used for lots of custom display / canvas like purposes back in the day IIRC. IMHO a canvas in gtk+ should not go too far. I'm not saying an HTML widget would not be good to have in gtk+, but HTML/CSS and canvas are two separate things; HTML/CSS can be built on top of a canvas, in principle. There's a lot of stuff in HTML that a canvas doesn't need, but the basic tree of graphical nodes and layout model and styles aspects of HTML are shared with any useful canvas... Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
As many others have, I needed a canvas and adapted an existing OpenGL canvas library I had sitting around. It's written in C++ and based on cairo (well, cairomm): http://libpapyrus.sf.net Havoc Pennington wrote: - we need to be able to do animations, which may involve adding some kind of absolute positioning and/or other stuff; don't really know yet. But I think it is a big open question. This is one of the things I needed recently and put in a simple frame-based animator concept based loosely on OpenSceneGraph's frame-based animations, but are perhaps more akin to Smalltalk's controller concept. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Havoc Pennington wrote: Gustavo J. A. M. Carneiro wrote: [...] Thanks Havoc for sharing that wealth of notes with us ! I didnt really look deeply into any of these implementations and I'm not commenting on them per se, but will happily share my thoughts with you :-) Havoc I think an important thing to keep in mind is that a canvas is just an alternate widget system. You can think of it as a GUI toolkit with different tradeoffs from GtkWidget, or a GUI toolkit with some of the misfeatures/limitations of GtkWidget corrected. But in any case it is basically defining the same thing as gtkwidget.c, gtkcontainer.c and other core GTK classes. Yes, I think having it all mixable is also a big priority, a notable advantage of GnomeCanvas is the fact that it can easily blend with normal widgets, it derives from GtkContainer - allowing you to add widgets and canvas items. Havoc My opinion is that the canvas should replace the GTK core in a way, i.e. GtkWidget becomes a specialized thing you can embed in a canvas. This obviously makes the canvas into a pretty big project. Kindof disagree here - I think that in most cases a canvas is needed when one leaves the boundries of a simple UI. Core GTK widgets offer standard tools for standard proceedures, stock icons, hig complient dialogs and everything is supposed to be theme friendly. On the other hand, when you want to plot out an accel sheet or draw a map with clickable city items, or anything at all visually specialized - then you are looking at canvas work. Havoc so having a markup language as an integral part of a canvas design is of interest. Gustavo Markup in the text item sounds fine. Anything else sounds like reinventing HTML. Havoc Is Glade reinventing HTML? ;-) Luckily; since markup language is already an integral part of gtk+ design, it wouldnt have to be part of the canvas design at all - canvases and canvas items should simply be buildable from thier properties and the GtkBuilder should take care of it natively. /me actively discourages yet another seperate builder mechanism in gtk+ Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Tristan Van Berkom wrote: Havoc My opinion is that the canvas should replace the GTK core in a way, i.e. GtkWidget becomes a specialized thing you can embed in a canvas. This obviously makes the canvas into a pretty big project. Kindof disagree here - I think that in most cases a canvas is needed when one leaves the boundries of a simple UI. Core GTK widgets offer standard tools for standard proceedures, stock icons, hig complient dialogs and everything is supposed to be theme friendly. On the other hand, when you want to plot out an accel sheet or draw a map with clickable city items, or anything at all visually specialized - then you are looking at canvas work. What I mean is that the canvas tends to be more flexible / less specialized while gtk focuses on displaying something specific (widgets) - so the natural thing is that the canvas is the base or the superset and gtkwidget is the specialization Just like you can have buttons, etc. in an HTML page, but HTML as a whole is much more free-form. Luckily; since markup language is already an integral part of gtk+ design, it wouldnt have to be part of the canvas design at all - canvases and canvas items should simply be buildable from thier properties and the GtkBuilder should take care of it natively. Quite possibly. Something to keep in mind though is that a builder UI can be programmer-oriented (Glade) or designer-oriented (Flash), and you get a really different flavor to apps depending on what this app encourages. Sort of social engineering through software design or something. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Gustavo J. A. M. Carneiro wrote: However, I would argue that to display a very large document in a canvas creating a canvas item for each document item is not the best solution; I'd rather have a pool, or cache, of visible canvas items, and just reconfigure them on the fly to show the portion of the document currently visible. I definitely agree that a model based on per-item objects is inefficient when dealing with a large number of items. In this case, one is usually employing the canvas from a data-oriented perspective rather than one that is serving in a GUI role. Approaching the problem of a canvas from a data-oriented perspective suggests that a different type of model is required. One example would be a tabular model, like GtkTreeModel. In this case the rows would be the items and each column would contain variables describing the items. These items would then be mapped to their appearance using something analogous to the GtkCellRenderer. There would be one or more renderers per column that would serve to take the values for each row (item) and use them to decorate the item view. The renderers could also map user interaction with a item view back to the row in the table. Given that GTK+ is centered around the GUI, the goocanvas model makes sense to me. Granted, it would be much more useful if the canvas model could be mapped to other view types. For example, the GtkTreeView could show the hierarchy of items. , so having a markup language as an integral part of a canvas design is of interest. Markup in the text item sounds fine. Anything else sounds like reinventing HTML. I think Havoc's idea of integrating HTML and the canvas is very interesting. HTML would serve nicely for serialization of the canvas and the canvas would provide a interface for integrating widgets within an HTML document. They (HTML rendering and a canvas) are also two things that GTK+ sorely needs, in my opinion. Michael Lawrence ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK-Canvas
On Tue, 2006-02-28 at 16:33 +, Gustavo J. A. M. Carneiro wrote: That sounds complicated to get right in one go. Personally, I'd just be happy to have a canvas that lets you create items, with virtualized draw method, even at position/size statically controlled by the programmer, stacking/layering and events. Basically like GnomeCanvas. If we get that right, and optimise the redrawing properly using micro tile arrays like in GnomeCanvas, then we can put that in gtk+ 2.10 right away. It seems to me like everything else is either not so important that can't wait a bit more (like embedding widgets) or can be done on top of the existing framework (animations, layout, object graph file persistency). Maybe so. I feel like we kind of stopped using GnomeCanvas though, because it just wasn't that much more useful than a drawing area, and had its own kind of complexity and limitations ... retained mode in particular adds the problem of keeping the retained graphics state in sync with the state of the app, while with non-retained mode when the app state changes you just queue_draw() and that's it. The two exciting features of GnomeCanvas really were antialiasing and lack of flicker, and a drawing area has both of those now. The only other thing the canvas really does for you is event handling on objects, but GnomeCanvas wasn't that convenient for that because the hard part really is coding the grab handling and such (behaviors). Also, I'm not sure all the cool features can be done on top, at least not while keeping a nice simple API. Or put differently, maybe the API can be better if it's a bit higher level than put a line here and a circle there - think about making the XML format the primary usage pattern, with subsequent manipulation from code, sort of like a web page. It's not like all my wishlist items are star trek hard - behaviors and animations in particular seem pretty manageable, and for widget embedding Alex already sorted out the hard bits. Just trying to cheerlead some ambitious goals ;-) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK-Canvas
On Ter, 2006-02-28 at 12:42 -0500, Havoc Pennington wrote: On Tue, 2006-02-28 at 16:33 +, Gustavo J. A. M. Carneiro wrote: That sounds complicated to get right in one go. Personally, I'd just be happy to have a canvas that lets you create items, with virtualized draw method, even at position/size statically controlled by the programmer, stacking/layering and events. Basically like GnomeCanvas. If we get that right, and optimise the redrawing properly using micro tile arrays like in GnomeCanvas, then we can put that in gtk+ 2.10 right away. It seems to me like everything else is either not so important that can't wait a bit more (like embedding widgets) or can be done on top of the existing framework (animations, layout, object graph file persistency). Maybe so. I feel like we kind of stopped using GnomeCanvas though, because it just wasn't that much more useful than a drawing area, and had its own kind of complexity and limitations ... retained mode in particular adds the problem of keeping the retained graphics state in sync with the state of the app, while with non-retained mode when the app state changes you just queue_draw() and that's it. I think this is why GnomeCanvas failed too, but the precise reason seems to ellude everyone. You seem to think in terms of reimplementing the GnomeCanvas model of having many Canvas Items, one for each shape--circle, polygon, text, etc. -- and let canvas item composition be used to accomplish more complex shapes. Of course this model is tedious, you have to keep adding and removing canvas items in order to modify how objects look. My proposal would be rather different. Have a single CanvasItem object, which would emit a draw signal with a cairo_context_t as argument. Also define a queue_draw method, like in gtk+ widgets. Then let programmers simply connect a handler to that signal--or even override the class virtual--and draw _whatever they want_ based on application document model. This has several advantages: 1- The programmer can direclty map document objects to canvas objects; 2- The programmer can use the full cairo API, instead of being restricted by the available shapes; 3- No need to keep adding/removing items to change appearance of objects; 4- It is rather intuitive for people used to program gtk widgets or with GtkDrawingArea. The two exciting features of GnomeCanvas really were antialiasing and lack of flicker, and a drawing area has both of those now. The only other thing the canvas really does for you is event handling on objects, but GnomeCanvas wasn't that convenient for that because the hard part really is coding the grab handling and such (behaviors). True. I think behaviours are important but, if I had to choose to leave behaviours out in order to have a basic canvas in gtk+ 2.10, I wouldn't hesitate. Keep in mind that having interactable objects in a canvas is just one part of what the canvas can do. For me, the canvas is more important because it allows you to have complex graphics in gtk+ that are both fast (no need to redraw everything all the time) and don't necessarily take lots of X server memory (no need to draw everything once to an offscreen pixmap in order to avoid redrawing complex graphics while something is being dragged over your widget). And of course that you can selectively redraw an object inside the canvas, instead of calling queue_draw and then forcing all the objects to redraw themselves. Also, I'm not sure all the cool features can be done on top, at least not while keeping a nice simple API. Or put differently, maybe the API can be better if it's a bit higher level than put a line here and a circle there - think about making the XML format the primary usage pattern, with subsequent manipulation from code, sort of like a web page. Hhm.. cool, but not nearly as useful as having a way to draw complex graphics in gtk+ and be able to print them without losing vectorial quality. It's not like all my wishlist items are star trek hard - behaviors and animations in particular seem pretty manageable, and for widget embedding Alex already sorted out the hard bits. Just trying to cheerlead some ambitious goals ;-) All those features are nice, but I'm afraid that we might end up not getting anything into gtk+ 2.10 if we aim for too much, and I'd really really love to have a canvas in gtk+. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK-Canvas
Nice work Sven, The obvious question, any plan to merge efforts with GooCanvas? behdad On Mon, 27 Feb 2006, Sven Herzberg wrote: Hi there, I spend the last weeks to develop a cairo based canvas for GTK+. When developing that canvas I was inspired by the GNOME canvas API. For people who have been using the GNOME canvas, it's very easy to use, there's just one bis change: Model/View split. The dependency list of that canvas is quite short: GTK+ 2.8 with cairo and all the libraries below these two. If you want to play around with it, grab it with: svn co http://www.blaubeermuffin.de/svn/repos/libccc [I needed subversion for development and I plan to move the code to the GNOME servers once they're using subversion too] If you have questions, bug reports, recommendations, feel free to send them either per email (I read the lists I sent this email to) or take the newly created Wiki Page [1] and edit it. Regards, Sven [1] http://live.gnome.org/Criawips/CriaCanvas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
