Re: GtkCanvas requirements?
Carlos Garnacho wrote: Hello!, On Fri, 2007-04-20 at 17:11 +0200, Sven Herzberg wrote: Marco Pesenti Gritti wrote: 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? This is a very important aspect, right. Especially with the upcoming *resolution independence* in MacOS X, people will start requesting this feature in GTK+ as well. So we should really add resolution independence to the feature list. This would at least satisfy the request for increasing widget spacing if the resolution increases (so we can have something like 1mm between widgets). Sadly, I see a some problems here: 1) We don't control the hardware our software is running on. So, where's this a problem? 2) Broken X servers reporting bad dpi values, relying just on modern/non-broken servers doesn't look very attractive either... There are also broken flatpanels that report broken sizes. But this is not a big deal if the user has got an easy way of specifying the correct resolution. 3) I bet there's still lots of people with 800x600 (or worse) screens So what? The resolution independence will improve the situation for them, because 1mm will be less pixels on the same display with 800x600 (compared to 1024x768). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Carl Worth cworth at cworth.org writes: I'm quite convinced that using floating-point at the interface, and fixed-point internally as needed provides the right combination of performance and ease-of-use for cairo. I'd highly recommend any new canvas interfaces being proposed follow the same approach. A huge advantage that a cairo-like API has over a canvas is that it has far less interaction using the interfaces. In cairo the interfacing goes like this: - create surface - draw In a canvas it goes like this: - add item - query size - answer size request - allocate size - send event - answer event ... So there's a lot more situations where you have to pass doubles. That being said, I'll trust doubles being slow when I see the numbers. There have been a lot of complaints about cairo's usage of doubles when it wasn't even an issue. [1] But the most important issue for a canvas is its API. If I have to know all sorts of internal things (like what sort of fixed point magic to apply) to get a canvas item coded, I'm not gonna code a canvas item. And without canvas items a canvas is pretty boring. Noone cares about text entries and rectangles. Benjamin [1] http://blogs.gnome.org/view/xan/2006/11/06/0 - compare the green and the blue bar ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On Tue, 2007-04-24 at 00:19 +0100, Damon Chaplin wrote: thinking 'in these days of 64-bit machines' would basically screw up all of the people working on getting GTK+ to work on small devices which - surprise! - have no FPU, hence perform like shit with doubles and floats. in Clutter, for instance, most of the operations are done using fixed point algebra and transforming doubles in the public API into 16.16 or 21.11 fixed point numbers internally; we also expose a fixed point API to avoid using doubles altogether. is this hard? yes. is it necessary? yes. should it be a part of the initial design and implementation? hell, yes. because history teach us that starting with well, we have 64-bit machines nowadays, what's a double going to do is the perfect way to hit the wall of performance regressions. cairo and pango developers and contributors went all the lengths to reduce the floating point usage in their libraries; we shouldn't screw the developers on embedded devices *again*. But the cairo API already uses doubles, for coordinates and transformations. I'm not saying that cairo API exposes fixed point values; neither I'm saying that a GtkCanvas should expose a fixed point API (albeit we went down this road in Clutter and we will see where that leads). all I'm saying is that people should not think that the canvas should be design or targeted for desktop boxes; instead, we avoid screwing up people in the embedded world. we've been there, we've seen what happens. that's the only point I was trying to make. really. :-) 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: GtkCanvas requirements?
Federico Mena Quintero federico at ximian.com writes: Now for the other use-case... in GNOME we don't have much experience with loading SVG-like things and then manipulating them (think Flash). Maybe we can find someone with Flash experience to comment on what API would be helpful to them? Model-View-Controller Flash is all about being able to separate creating the visual contents from writing the code to interact with them. And separating means being able to do both in completely different apps by completely different people. I'll give a little intro to this part of Flash now, since I think it is pure genius. Flash knows exactly one graphical object: a shape. You can think of it as a simple static SVG (no scripting) or better as a cairo_path_t with a cairo_pattern_t to fill it. That's it. All drawing is done that way. The most important container object is the Sprite. It's just a timeline that starts playing automatically. Inside that timeline are placement instructions (including animnations) how other objects are placed inside it. Example: draw a ball (the Shape), create a sprite and move the shape up and down in its timeline. Tell the timeline to loop and you have a bouncing ball. This is probably equivalent to a pretty advanced SVG, with animations etc. Another container object is a Button. A button has 3 states (roughly the Gtk button states normal, prelight and active) and you place objects for those states. So you can now put the bouncing ball into the button and only in the prelight state and boom, you have a nice animated indicator that your mouse is hovering over a button. Up to this point, we haven't left the Flash equivalent of Inkscape, we're still in the realm of the graphic artist. We haven't written a single line of code. But we have a ball bouncing in front of a button. To get a feel of how that looks, I recently linked to a tutorial [1] in my blog [2] that I think describes it quite well. As Havoc said in the other mail, a programmer interacts with these items using a pretty simple API [3]. So what does that mean for a GtkCanvas? The canvas should make it easy to load the full graphical description from a file created by a graphic artist. So you want a function like gtk_canvas_new_from_svg (char *filename). That would create the right amount of canvas items for the SVG and place them correctly. It would also give you access to the items by name like glade: gtk_canvas_get_item_by_name (canvas, name). You probably want an easy way to duplicate them, too. That way the developers could specify what items they need (asteroid, space-ship, rocket and ufo) and then code the functionality for these objects into their app and the graphic designers work on the agreed on SVG file. And then you end up with a very famous game with even greater graphics. [4] Cheers, Benjamin [1] http://www.kirupa.com/developer/flash8/simple_animation.htm [2] http://www.advogato.org/person/company/diary.html?start=39 [3] http://www.brajeshwar.com/reference/as2/MovieClip.html - note that children movie clips get their own variable, so if movie has a child named foo you can reference it as movie.foo in your script. [4] http://en.wikipedia.org/wiki/Image:Asteroi1.png ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On Tue, 2007-04-24 at 08:12 +, Benjamin Otte wrote: [...] So what does that mean for a GtkCanvas? The canvas should make it easy to load the full graphical description from a file created by a graphic artist. [...] I strongly agree and strongly disagree (which might or might not mean that we are in agreement ;-D ) IMO GtkCanvas should be very very low level and simple, have support for canvas items etc to be implemented at will in any programatical ways thinkable, GtkFlashCanvas on the other hand can feel free to implement vectorial animated objects as canvas items (or however the implementation would be, up to the GtkFlashCanvas maintainer) and load them from an swf stream... I think it is definitly important to keep in mind the possibility of a canvas being used to render html, flash or other graphic artist based material, but we should also be carefull and take baby steps: we should take this oportunity to focus on how powerfull and fine-tuned we can make the essential base canvas tools/objects and make that available as soon as possible, doubtlessly GtkHtmlCanvases and GtkFlashCanvases will organically evolve from that point and eventually one of those could be included in gtk+ as well... I think that discussion is for another day. I also have to support Carlos where he says: quote who=Carlos Garnocho But, even being the canvas a great excuse to begin this effort, I don't think it's going to offer enough improvements to the canvas itself to deserve such a long wait, I think leaving potential API users with the current canvas buffet for (say) these two years would harm us in the medium/long term. /quote Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On Sun, 2007-04-22 at 21:16 +0100, Damon Chaplin wrote: On Thu, 2007-04-19 at 16:19 -0400, Havoc Pennington wrote: Marco Pesenti Gritti wrote: 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? I agree that it would be really good to avoid floating point. Pixels are by far the most intuitive thing for people using or writing items, too (since as you say they avoid having to multiply everything). Pango does have the precedent though and for convenience we could just use the same units as Pango. I don't really think that pixels or fixed point integers are enough for a general purpose canvas. If people want to write complex layout apps like DTP/illustration packages they need more precise control over coordinates (and in different units like points/millimeters/inches). e.g. the SVG spec says high quality viewers should use doubles for calculations: http://www.w3.org/TR/SVG11/types.html#BasicDataTypes I want to point out here that while you can specify units in points or ems, or whatever, with a data type of fixed point numbers, or doubles, or whatever, you simply can't ignore the pixel grid and expect to get good looking results; it matters whether a line is 1.5 pixels wide (a black line next to a gray line), or 2 pixels wide (a black line.) It was a deliberate design decision for the HippoCanvas that layout happens in integer pixels; a get_width_request() call returns 29px or 30px, never 29.5px. If you say that a box has a spacing of 10pt you don't want to interpret that as 10 * (96 / 72.) = 13.33 pixels, you want to interpret that as 13 pixels. Don't forget the pixel! - Owen (This is, of course, different for a widgety use of a Canvas as compared to a WYSYWIG use of the canvas. I'm not sure what that implies for trying to use the same canvas for both. Maybe a global setting or the right layered design can give sufficient flexibility.) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On Sat, 2007-04-21 at 22:12 +0300, Kalle Vahlman wrote: 2007/4/21, Gustavo J. A. M. Carneiro [EMAIL PROTECTED]: I can tell you the reasons why I usually use a canvas: 1. Writing widgets is _very hard_ (when compared to e.g. canvas items). Depends on your language (and on your widget of course). In python, deriving a widget not a big deal. In C, well I guess you need to grasp some concepts but it's hardly rocket sience. Ahem, yes, writing widgets is very hard - not because of language orientation but because of the long history of gtk+ - interestingly I've been away for a week since my internet is down and I see there's been alot of discussion on the lists... interesting points I've seen: Havoc pointed out that - if we were to view the canvas as a completely alternative widget system core, we would have the oportunity of having something lightweight (A gtk+ 3.0 without gtk+ 3.0 I think he said); this idea is very attractive at first sight... but be warned - in my limited experience - I've found that (in this corporation where I work), they went and trashed all the work that we did for 4 years to start a new generation that; in the eyes of the salesmen would solve all of our problems, in the end it was a huge game of appearences and worked out well to gain investments for the company etc... but from a developer point of view it was a big waste of time - we were already on our way to a huge refactoring phase that would have allowed us to reposition ourselves for future needs without trashing everything that was already written and was already good (this was already going to be a huge cost, but not nearly as huge as the new generation route)... sorry for the long winded analogy but it just goes to say that a technically complex problem requires alot of thought and we shouldnt shy away from trying to understand the code that people have written 5 years ago and improve upon it/refactor it. Another (Clemens Eisserer) in a seperate thread[1] pointed out an interesting way that things could be improved in gtk+, optimizing backbuffering etc, hell from my point of view; GtkWidgets could probably be simplified if the resource management (GdkWindow allocations etc for every damn widget that must support GTK_NO_WINDOW cases or not etc etc) were just deffered out of the typical GtkWidget context. Thats why I'm replying to THIS mail in the thread, GtkWidget's are complex and difficult to write because of the requirements that they meet, this doesnt mean we must sadly lose all hope in them and write something new for the sake of something new just because nobody has the balls to go and refactor the core, Clemens has balls and for that I salute him :) Canvases... thats right this thread is about canvases... canvases historically have been something great for highly customized application environments, but there are so very many applications that need widgets, just basic building blocks, a button here, a slider there, a nicely resizing container - and there you have a simple GUI tool frontend for your typical unix CLI program that is essential to your system. I think its clear we need canvases, and we need all the themable goodness that works out of the box that is gtk+ as well, personally I dont think those two things go in the same boat. A good day to you all, -Tristan [1]http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00074.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Hi Havoc!, On Fri, 2007-04-20 at 10:13 -0400, Havoc Pennington wrote: In HippoCanvas we took this to the extreme of not including gdk.h or gtk.h in the canvas core. I happen to really like this approach, but in general I tend to like to keep code almost annoyingly layered/orthogonal, just a personal taste kind of thing that can create extra work. Then as you mention there's an item that can contain GtkWidget and a GtkWidget that can contain an item. It definitely has the downside that you'd have to replicate large parts of what's in gdk and gtk already. On the upside, if you're writing a new widget core, apps could avoid the old one entirely someday. It's a GTK 3.0 in parallel and interoperable with 2.x sort of thing. Probably at least a little bit insane. What are we missing in the current core? What benefits would bring a new one? would it be worth in the long term the pain of duplicating code paths? AFAIK, we're missing advanced layout properties like height-for-width, width-for-height and such, maybe they would be done differently if it all were done from scratch, but it seems doable for 2.x. Regards, Carlos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Hi Federico :), On Sat, 2007-04-21 at 10:30 -0500, Federico Mena Quintero wrote: El jue, 19-04-2007 a las 15:00 -0400, Havoc Pennington escribió: 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.: Havoc is on the right track here. You can pile an immense feature list on top of the canvas and still get a useless thing. We need use-cases. My use-cases for a canvas: - Interactive, pre-drawn graphical content which cannot be done with stock widgets. Think of using Inkscape instead of Glade; think of a poor man's Flash. People want to do this: canvas = new Canvas (); svg = canvas.load_svg (foo.svg); handle = svg.get_object_by_id (bouncing-ball); handle.animate (new BounceAnimation (1.5, 1.3, 2.0, 3.4)); I see this more as a higher level abstraction over the canvas rather than an intrinsic feature. - Interactive diagrams, generated programmatically. Think of the sexy call-graphs in kcachegrind. A static diagram is trivial, as you can just draw it with Cairo *once* and BitBlt() it when you need it. An interactive diagram is harder, since you need event handling, hit testing, painless redraw, etc. - Simple games are already covered by the points above. - I think we want to focus on simplicity and heavy use of SVG. Thousands of programmatically-generated items (music editor, flyweight items, etc.) are not very interesting and could complicate the design a lot. As I see it, with a higher abstraction on the latter you could get the former. - Whoever does a canvas really really really needs to look at Piccolo.NET (http://www.cs.umd.edu/hcil/piccolo/). The animation API is lovely, and the support for zoomable UIs is lovely as well. If we had Piccolo.NET on top of Cairo and GTK+, we'd have 99% of our needs covered. [Side note... at this point I think doing a canvas in C is a big mistake. Interesting canvases will inevitably get cycles in the pointer graph, and reference counting becomes just too painful then. [This is irrelevant to .net or whatever; it's a general We Should Stop Writing Nontrivial Shit In C thing. People would be really really happy with the Piccolo.NET API implemented with pygtk or gtk-sharp.]] There are already other pieces of complicate software in GTK+ (for example, GtkTreeView), which have proved to be quite beneficial, and one of the reasons is that they're implemented in C, and thus, they were bindable to other languages. IMHO programming a potentially widely used piece of software in a higher level language would cut down severely its user base. - when is a canvas item used vs. a widget? what current widgets would be replicated as canvas items? If you have a stock canvas item for editable text, you already have 95% of the cases covered --- you can compose editable mega-items out of that text item plus decoration. That's what we do in the Evolution calendar, for instance: the calendar's appointments are just a bunch of boxes and lines plus text items. Putting GtkWidgets inside a canvas is a nice gimmick, but I don't think you need to make them fully zoomable/transformable/etc. If you want GtkFixed-like layout with canvas drawings underneath, you don't need exotic transformations. (People often do diagrams which need pushable buttons, and so they want to stick a GtkButton inside a canvas. For that it may be simpler to just create a CanvasButton object which you can decorate to your heart's content with SVG.) The canvas also needs to have performance goals defined up front. We don't want the case where people avoid using the canvas because it is too slow (like what happened with the antialiased GnomeCanvas). hmm, right, what should be a reasonable/feasible goal? visualizing a bunch of thousand items with little/no noticeable delay? moving a few tenths/hundreds around? I guess that making performance studies on the current canvases could help here. Regards, Carlos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Hello!, On Fri, 2007-04-20 at 17:11 +0200, Sven Herzberg wrote: Marco Pesenti Gritti wrote: 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? This is a very important aspect, right. Especially with the upcoming *resolution independence* in MacOS X, people will start requesting this feature in GTK+ as well. So we should really add resolution independence to the feature list. This would at least satisfy the request for increasing widget spacing if the resolution increases (so we can have something like 1mm between widgets). Sadly, I see a some problems here: 1) We don't control the hardware our software is running on. 2) Broken X servers reporting bad dpi values, relying just on modern/non-broken servers doesn't look very attractive either... 3) I bet there's still lots of people with 800x600 (or worse) screens Regards, Carlos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: GtkCanvas requirements?
e.g. the SVG spec says high quality viewers should use doubles for calculations: http://www.w3.org/TR/SVG11/types.html#BasicDataTypes The problem with double is not the size it is the speed of them. Right now there are people like (me) who are trying to use GTK on cell phones. Working with doubles without hardware support means software emulation and that is SLOW to the point of unusable. I wonder if there is a way of using a 64 bit int to get the fidelity of a double without the overhead. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Hi, Federico Mena Quintero wrote: Now for the other use-case... in GNOME we don't have much experience with loading SVG-like things and then manipulating them (think Flash). Maybe we can find someone with Flash experience to comment on what API would be helpful to them? For most Flash usage, API really is not the issue... people do it like HTML, where they write the markup then add a little bit of scripting (for Flash, it isn't literally markup, but what I mean is 'data not code'). Unlike HTML, the data part is edited in a dedicated app rather than written by hand or using templates. When I used Flash, I created a blank rectangle in the editor app, then did everything programmatically from ActionScript - but this is _clearly_ the thing that 0.01% of programmer freaks do, not something that would be common among people who use Flash. No Flash books or docs would suggest doing it this way. One of the big reasons Flash is popular is that graphic designers can use it without knowing how to program. The Flash API looks similar to GnomeCanvas or the DOM in that it's a tree of display objects. It's much simpler than either one of those though, there's no layout, there are only a few kinds of item, etc. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Hi, Carlos Garnacho wrote: What are we missing in the current core? What benefits would bring a new one? I certainly have not sat down and exhaustively tried to figure this out. There is a fair bit of cruft in the core; if you were starting over, I'm sure you'd want to just kill GdkWindow for example, and many other Xlib leakages such as how some of the events work. You'd want to be Cairo-only, use interfaces instead of objects for the core APIs (widget, container), rethink GtkContainer and its common subclasses (as HippoCanvas does), fix the theme system, blah blah. The list could get pretty long. The question is which of these are cosmetic cleanups that aren't really worth it and which add new capabilities, and how long is the new capabilities list. Probably not nearly as long as the cosmetic list. Replacing the core with a more canvas-ish solution would not have to be done all in one shot, though; the WidgetCanvasItem and CanvasWidget provide a lot of interoperability. You could also have some of the existing widgets implement the CanvasItem interface directly, for example GtkEntry could be both a GtkWidget and a CanvasItem. There's no real disruption to the current core while building a new canvas-style core either, in fact I'd suggest evolving the canvas stuff outside of GTK+ for at least a couple of years. It is probably also true that certain heavy widgets such as TextView and TreeView never benefit from conversion to a canvas-like model. New capabilities I can quickly think of, all of which might be possible to retrofit into GtkWidget/GtkContainer themselves: - better layout - overlapping/alpha-blending - reduced overhead / more lightweight objects (speculative) - better containers replacing [HV]Box/Misc (see HippoCanvasBox and xalign, yalign, padding, border properties) - printing trees of items - general ability to draw an item to stuff other than the screen - support for nonrectangular items (e.g. a diagonal line) - nicer event system (e.g. easier enter/leave tracking, remove only-useful-for-toplevels stuff from main item interface) In the end I'm guessing this is just too much work. At the same time, for some apps already we see that even a simple answer like HippoCanvas has important advantages over GtkWidget. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On Sun, 2007-04-22 at 21:16 +0100, Damon Chaplin wrote: In these days of 64-bit machines I don't think sizeof (double) is a big deal, if its just for a few coordinates per item. Anyway if we're using interfaces for items then the items can use whatever they like internally. it's not a matter of space. thinking 'in these days of 64-bit machines' would basically screw up all of the people working on getting GTK+ to work on small devices which - surprise! - have no FPU, hence perform like shit with doubles and floats. in Clutter, for instance, most of the operations are done using fixed point algebra and transforming doubles in the public API into 16.16 or 21.11 fixed point numbers internally; we also expose a fixed point API to avoid using doubles altogether. is this hard? yes. is it necessary? yes. should it be a part of the initial design and implementation? hell, yes. because history teach us that starting with well, we have 64-bit machines nowadays, what's a double going to do is the perfect way to hit the wall of performance regressions. cairo and pango developers and contributors went all the lengths to reduce the floating point usage in their libraries; we shouldn't screw the developers on embedded devices *again*. 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: GtkCanvas requirements?
El lun, 23-04-2007 a las 13:44 -0400, Havoc Pennington escribió: For most Flash usage, API really is not the issue... people do it like HTML, where they write the markup then add a little bit of scripting (for Flash, it isn't literally markup, but what I mean is 'data not code'). Unlike HTML, the data part is edited in a dedicated app rather than written by hand or using templates. And a dedicated app to create the drawing content is exactly the killer feature of Flash. That's what I want to do with use Inkscape and slap the SVG into the canvas; then write some simple code to interact with it. People in the Real World need a very simple way to do interactive displays (be it with graphics or just text widgets). A few years ago in Brazil I had a gentleman ask me, why is GTK+ and Glade so complicated? I'm using a database that lets me write GUIs by typing Enter Name [] (write-your-GUI-though-ASCII-art), and it will then let me name the field, define its type, etc.. People *need* that level of simplicity. Draw something, BANG - it's there. You just write some glue code to the rest of your app. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On Mon, 2007-04-23 at 20:09 +0100, Emmanuele Bassi wrote: On Sun, 2007-04-22 at 21:16 +0100, Damon Chaplin wrote: In these days of 64-bit machines I don't think sizeof (double) is a big deal, if its just for a few coordinates per item. Anyway if we're using interfaces for items then the items can use whatever they like internally. it's not a matter of space. thinking 'in these days of 64-bit machines' would basically screw up all of the people working on getting GTK+ to work on small devices which - surprise! - have no FPU, hence perform like shit with doubles and floats. in Clutter, for instance, most of the operations are done using fixed point algebra and transforming doubles in the public API into 16.16 or 21.11 fixed point numbers internally; we also expose a fixed point API to avoid using doubles altogether. is this hard? yes. is it necessary? yes. should it be a part of the initial design and implementation? hell, yes. because history teach us that starting with well, we have 64-bit machines nowadays, what's a double going to do is the perfect way to hit the wall of performance regressions. cairo and pango developers and contributors went all the lengths to reduce the floating point usage in their libraries; we shouldn't screw the developers on embedded devices *again*. But the cairo API already uses doubles, for coordinates and transformations. So if the canvas used fixed point numbers you'd be converting to doubles and then back again. With 32-bit fixed point numbers you also cut down the maximum possible size of the canvas, plus you lose the precision of doubles (which may be important for some data visualization apps). If the canvas item API uses doubles, items can still use fixed point numbers internally if necessary. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On Mon, 2007-04-23 at 19:19 -0400, Damon Chaplin wrote: But the cairo API already uses doubles, for coordinates and transformations. So if the canvas used fixed point numbers you'd be converting to doubles and then back again. With 32-bit fixed point numbers you also cut down the maximum possible size of the canvas, plus you lose the precision of doubles (which may be important for some data visualization apps). I completely agree here with Damon. With fixed point api, bug reports will come in very soon that if I zoom in 1000x on a point and try to move it, it jumps around We've had similar reports when people tried to port Inkscape to cairo, because cairo uses a 16.16 fixed point internally. When you are locked with fixed point, it would be really hard to get out of it. On the other hand, since cairo has double api already and we don't see adding fixedpoint api any time soon, the canvas can do a good job at avoiding floating-point arithmetic completely and use cairo transformations for all the work. And we have been optimizing cairo as much as possible to make this usecase fast for example for non-scale non-rotation matrices. Doing affine transformations completely in fixedpoint is very hard, and probably even impossible to support extreme zoom factors with. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On Tue, 24 Apr 2007 00:19:08 +0100, Damon Chaplin wrote: On Mon, 2007-04-23 at 20:09 +0100, Emmanuele Bassi wrote: floats. in Clutter, for instance, most of the operations are done using fixed point algebra and transforming doubles in the public API into 16.16 or 21.11 fixed point numbers internally; That's a similar approach as has been used in cairo very successfully. we also expose a fixed point API to avoid using doubles altogether. is this hard? yes. As a datapoint, cairo does not do this. cairo and pango developers and contributors went all the lengths to reduce the floating point usage in their libraries; we shouldn't screw the developers on embedded devices *again*. But the cairo API already uses doubles, for coordinates and transformations. So if the canvas used fixed point numbers you'd be converting to doubles and then back again. Some people have misunderstood what kinds of optimizations happened in cairo. Cairo has always had a floating-point API, with an implementation that tries to get to fixed-point as quickly as possible. There were several performance problems that were fixed between the 1.2 and 1.4 releases of cairo that involved the following: * Using clever techniques to make the conversion of floating-point to fixed-point values as fast as possible. * Using similar techniques to make the rounding of floating-point values to integers as fast as possible. * Avoiding floating-point arithmetic where the result was unchanged, (multiplying by an identity matrix, for example). At this point, cairo seems plenty fast on embedded systems for the kinds of things that people are throwing at it. Now, some of that speed comes from simply not doing some of the scaling and transformation that might be desired, (see the identity transformation optimization mentioned above). But even if more scaling and rotation were desired, there would be plenty of ways to optimize this, (using fixed-point arithmetic when the scaling is small enough to avoid overflow, using fast integer techniques for computing things like square roots, etc.). And all of that could be done without ever adding any fixed-point API to cairo. I'm quite convinced that using floating-point at the interface, and fixed-point internally as needed provides the right combination of performance and ease-of-use for cairo. I'd highly recommend any new canvas interfaces being proposed follow the same approach. -Carl pgpzlnZ1k131g.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Hi!, On Mon, 2007-04-23 at 14:03 -0400, Havoc Pennington wrote: I certainly have not sat down and exhaustively tried to figure this out. Oh, nice list below, I was somehow thinking a shorter in scope, less tangential, set of changes. There is a fair bit of cruft in the core; if you were starting over, I'm sure you'd want to just kill GdkWindow for example, and many other Xlib leakages such as how some of the events work. You'd want to be Cairo-only, use interfaces instead of objects for the core APIs (widget, container), rethink GtkContainer and its common subclasses (as HippoCanvas does), fix the theme system, blah blah. The list could get pretty long. The question is which of these are cosmetic cleanups that aren't really worth it and which add new capabilities, and how long is the new capabilities list. Probably not nearly as long as the cosmetic list. Replacing the core with a more canvas-ish solution would not have to be done all in one shot, though; the WidgetCanvasItem and CanvasWidget provide a lot of interoperability. You could also have some of the existing widgets implement the CanvasItem interface directly, for example GtkEntry could be both a GtkWidget and a CanvasItem. There's no real disruption to the current core while building a new canvas-style core either, in fact I'd suggest evolving the canvas stuff outside of GTK+ for at least a couple of years. It is probably also true that certain heavy widgets such as TextView and TreeView never benefit from conversion to a canvas-like model. I agree this is a great idea for a testbed independent to GTK+, but even in this case you could only test a subset of the things mentioned here, other ones could prove to be hardly interoperable with the current GtkWidget/GdkEvent functional details (Events handling, GdkWindow revamp, ...). IMVHO, such testbed should become directly a gdk/gtkwidget proof of concept experiment, with two or three widget implementations to play with, and such codebase could be reused later when it proves to be a substantial improvement. But, even being the canvas a great excuse to begin this effort, I don't think it's going to offer enough improvements to the canvas itself to deserve such a long wait, I think leaving potential API users with the current canvas buffet for (say) these two years would harm us in the medium/long term. Regards, Carlos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On Sáb, 2007-04-21 at 17:09 -0400, Havoc Pennington wrote: [...] So another structure could be that there's a core which tries to encapsulate the minimum amount of structure for multiple objects to negotiate their usage of the screen area and keyboard, and then there are objects that layer in more widget-like and more svg/flash-like behaviors. Don't know exactly how that would work. I agree that a layered solution is the way to go. The layers I envision are along these lines: 1- An immediate mode drawing layer: we have this now, it is called Cairo; 2- A retained mode drawing layer: a bunch of objects that know how to paint themselves, and when pointer or keyboard events belong to them. GooCanvas is one example of such a layer (except that it also does stuff like animations which I don't think belong in this layer). 3- Then we can have a bunch of modules on top of layer-2: 3a- animations; 3b- object drag-and-drop; 3c- markup language, scripting, SVG, etc. Federico also brings up again the great point that the whole thing should perhaps be designed for primarily markup, plus some scripting, rather than primarily as a programming API. Maybe the as-lightweight-as-possible core has some ideas like: - the whole display is a DOM-like tree, loadable from markup - item painting - keyboard focus - ... Yes, I agree with this view, except that I hope you mean DOM-like tree is just a programmatic object tree, like gtk widgets, not XML. I think glade/libglade/gtk clearly have proved to us that you can perfectly layer XML on top of a core library. Then add a set of widget style items built on the core which have: - layout management - themes - keyboard accelerators/mnemonics - ... And have a set of SVG items (could just be SVG embedded in the overall markup), used for drawing and animations. Just brainstorming on how to break down the big picture enough to get a handle on it... This is all very nice except that I believe that for now we should focus on only layer-2 for inclusion in Gtk+, and only time will tell how many layer-3+ modules belong in Gtk+, or how much of that is application-specific. But even if it belongs in Gtk+, I believe a clear separation of the layers 2 and 3 is crucial. -- 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: GtkCanvas requirements?
On Thu, 2007-04-19 at 16:19 -0400, Havoc Pennington wrote: Marco Pesenti Gritti wrote: 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? I agree that it would be really good to avoid floating point. Pixels are by far the most intuitive thing for people using or writing items, too (since as you say they avoid having to multiply everything). Pango does have the precedent though and for convenience we could just use the same units as Pango. I don't really think that pixels or fixed point integers are enough for a general purpose canvas. If people want to write complex layout apps like DTP/illustration packages they need more precise control over coordinates (and in different units like points/millimeters/inches). e.g. the SVG spec says high quality viewers should use doubles for calculations: http://www.w3.org/TR/SVG11/types.html#BasicDataTypes Maybe there's some way to make this optional, for example items that feel they can do something useful with sub-pixel sizes could implement an interface that did the size negotiation in sub-pixels. The default implementation of the sub-pixel size negotiation methods would call the whole pixels one, and the default implementation of the whole-pixels methods would call the sub-pixels one and round off. If you didn't override either one it would break badly, but don't do that then ;-) all items would have to implement one or the other but not both. One downside of doubles is simply the extra memory usage when storing coordinates; I think keeping the abstract base class for items and most common concrete classes as small as possible is a nice win. I'd like to see items be lighter than GtkWidget, in almost any of the usage scenarios (widget core or drawing api or other). In these days of 64-bit machines I don't think sizeof (double) is a big deal, if its just for a few coordinates per item. Anyway if we're using interfaces for items then the items can use whatever they like internally. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On Sat, 2007-04-21 at 10:30 -0500, Federico Mena Quintero wrote: El jue, 19-04-2007 a las 15:00 -0400, Havoc Pennington escribió: 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.: Havoc is on the right track here. You can pile an immense feature list on top of the canvas and still get a useless thing. We need use-cases. My use-cases for a canvas: - Interactive, pre-drawn graphical content which cannot be done with stock widgets. Think of using Inkscape instead of Glade; think of a poor man's Flash. People want to do this: canvas = new Canvas (); svg = canvas.load_svg (foo.svg); handle = svg.get_object_by_id (bouncing-ball); handle.animate (new BounceAnimation (1.5, 1.3, 2.0, 3.4)); - Interactive diagrams, generated programmatically. Think of the sexy call-graphs in kcachegrind. A static diagram is trivial, as you can just draw it with Cairo *once* and BitBlt() it when you need it. An interactive diagram is harder, since you need event handling, hit testing, painless redraw, etc. - Simple games are already covered by the points above. Here's some use-cases mentioned on the GooCanvas list: - DTP app (that's what I originally wrote it for). - Multi-track audio editor (currently uses GnomeCanvas). - Genome viewer (currently uses FooCanvas). - Air traffic controller simulator. - Database relationship viewer. - PIM Synchronizer connection viewer. So basically it is all kinds of data visualization and manipulation, and the occasional animation. Plus some WYSIWYG stuff to be printed. - I think we want to focus on simplicity and heavy use of SVG. Thousands of programmatically-generated items (music editor, flyweight items, etc.) are not very interesting and could complicate the design a lot. - Whoever does a canvas really really really needs to look at Piccolo.NET (http://www.cs.umd.edu/hcil/piccolo/). The animation API is lovely, and the support for zoomable UIs is lovely as well. If we had Piccolo.NET on top of Cairo and GTK+, we'd have 99% of our needs covered. I spent quite a while reading through the Piccolo docs before writing GooCanvas, but I'm afraid I didn't like it that much. The API is horribly complicated: http://www.cs.umd.edu/hcil/piccolo/learn/piccolo/doc-1.2/api/ What was great about the animation API and zoomable UIs? As far as I could see zoomable UIs just meant using different painting code at different scales, which isn't that difficult: http://www.cs.umd.edu/hcil/piccolo/learn/patterns.shtml#Desing% 20Patterns%20for%20ZUI%20Interaces I basically copied what they did for their convenience animation functions, but it didn't work well for rotations so I had to rewrite it. I thought SVG was a much nicer model. [Side note... at this point I think doing a canvas in C is a big mistake. Interesting canvases will inevitably get cycles in the pointer graph, and reference counting becomes just too painful then. [This is irrelevant to .net or whatever; it's a general We Should Stop Writing Nontrivial Shit In C thing. People would be really really happy with the Piccolo.NET API implemented with pygtk or gtk-sharp.]] I don't really agree about the reference counting - noone has reported problems yet. I don't think C is that bad. GLib and GTK+ are a bit painful at times, but hard problems are hard in any language. The canvas also needs to have performance goals defined up front. We don't want the case where people avoid using the canvas because it is too slow (like what happened with the antialiased GnomeCanvas). GooCanvas has a demo that creates 100,000 items over a large canvas. The main problem is startup time of about 5 seconds (creating all the items and measuring text item widths probably). But it works fine after that. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
El jue, 19-04-2007 a las 15:00 -0400, Havoc Pennington escribió: 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.: Havoc is on the right track here. You can pile an immense feature list on top of the canvas and still get a useless thing. We need use-cases. My use-cases for a canvas: - Interactive, pre-drawn graphical content which cannot be done with stock widgets. Think of using Inkscape instead of Glade; think of a poor man's Flash. People want to do this: canvas = new Canvas (); svg = canvas.load_svg (foo.svg); handle = svg.get_object_by_id (bouncing-ball); handle.animate (new BounceAnimation (1.5, 1.3, 2.0, 3.4)); - Interactive diagrams, generated programmatically. Think of the sexy call-graphs in kcachegrind. A static diagram is trivial, as you can just draw it with Cairo *once* and BitBlt() it when you need it. An interactive diagram is harder, since you need event handling, hit testing, painless redraw, etc. - Simple games are already covered by the points above. - I think we want to focus on simplicity and heavy use of SVG. Thousands of programmatically-generated items (music editor, flyweight items, etc.) are not very interesting and could complicate the design a lot. - Whoever does a canvas really really really needs to look at Piccolo.NET (http://www.cs.umd.edu/hcil/piccolo/). The animation API is lovely, and the support for zoomable UIs is lovely as well. If we had Piccolo.NET on top of Cairo and GTK+, we'd have 99% of our needs covered. [Side note... at this point I think doing a canvas in C is a big mistake. Interesting canvases will inevitably get cycles in the pointer graph, and reference counting becomes just too painful then. [This is irrelevant to .net or whatever; it's a general We Should Stop Writing Nontrivial Shit In C thing. People would be really really happy with the Piccolo.NET API implemented with pygtk or gtk-sharp.]] - when is a canvas item used vs. a widget? what current widgets would be replicated as canvas items? If you have a stock canvas item for editable text, you already have 95% of the cases covered --- you can compose editable mega-items out of that text item plus decoration. That's what we do in the Evolution calendar, for instance: the calendar's appointments are just a bunch of boxes and lines plus text items. Putting GtkWidgets inside a canvas is a nice gimmick, but I don't think you need to make them fully zoomable/transformable/etc. If you want GtkFixed-like layout with canvas drawings underneath, you don't need exotic transformations. (People often do diagrams which need pushable buttons, and so they want to stick a GtkButton inside a canvas. For that it may be simpler to just create a CanvasButton object which you can decorate to your heart's content with SVG.) The canvas also needs to have performance goals defined up front. We don't want the case where people avoid using the canvas because it is too slow (like what happened with the antialiased GnomeCanvas). Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Hmm: Once again I too fast on pressing send and forgot the links: Vala: http://live.gnome.org/Vala EggDocument: http://taschenorakel.de/svn/repos/eggdocument/trunk/ Am Samstag, den 21.04.2007, 17:49 +0200 schrieb Mathias Hasselmann: Am Samstag, den 21.04.2007, 10:30 -0500 schrieb Federico Mena Quintero: [Side note... at this point I think doing a canvas in C is a big mistake. Interesting canvases will inevitably get cycles in the pointer graph, and reference counting becomes just too painful then. [This is irrelevant to .net or whatever; it's a general We Should Stop Writing Nontrivial Shit In C thing. People would be really really happy with the Piccolo.NET API implemented with pygtk or gtk-sharp.]] I'd rather consider using Vala in that case: It gives you a highlevel syntax for the GObject system, whilest generating native, binding friendly code. GNOME avoids using high-level languages for libraries for good reason: Bindings and politics. Used it for toying with some document model for printing [1] and expect for minor bugs in Vala's code generator, which where resolved quickly, vala worked pretty well for me in creating a native GObject library. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Am Samstag, den 21.04.2007, 10:30 -0500 schrieb Federico Mena Quintero: [Side note... at this point I think doing a canvas in C is a big mistake. Interesting canvases will inevitably get cycles in the pointer graph, and reference counting becomes just too painful then. [This is irrelevant to .net or whatever; it's a general We Should Stop Writing Nontrivial Shit In C thing. People would be really really happy with the Piccolo.NET API implemented with pygtk or gtk-sharp.]] I'd rather consider using Vala in that case: It gives you a highlevel syntax for the GObject system, whilest generating native, binding friendly code. GNOME avoids using high-level languages for libraries for good reason: Bindings and politics. Used it for toying with some document model for printing [1] and expect for minor bugs in Vala's code generator, which where resolved quickly, vala worked pretty well for me in creating a native GObject library. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Federico Mena Quintero wrote: [snip] [Side note... at this point I think doing a canvas in C is a big mistake. Interesting canvases will inevitably get cycles in the pointer graph, and reference counting becomes just too painful then. [This is irrelevant to .net or whatever; it's a general We Should Stop Writing Nontrivial Shit In C thing. People would be really really happy with the Piccolo.NET API implemented with pygtk or gtk-sharp.]] Only mono (python) people would be happy with whatever implemented in gtk-sharp (python). If it's not C, then everybody implements same thing in their favorite language. Unfortunately, it is just hard to implement so we use that one works only if that one is written in C. Even if you forget about problems of interoperability between different languages (some bindings do work two ways, e.g. pygtk; some don't, e.g. gtkmm). So while it's good to write something totally good in C# (and same thing about python, vala, C++, and lisp), it's totally useless as GTK canvas. Best regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On Qui, 2007-04-19 at 15:00 -0400, Havoc Pennington 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 can tell you the reasons why I usually use a canvas: 1. Writing widgets is _very hard_ (when compared to e.g. canvas items). 2. Dynamically creating tons of widgets is costly, or at least I get that impression, due to round-trips when creating gdk windows, or gdk contexts, or whatever; 3. The Gtk widget size negotiation protocol is not flexible enough; 4. Widgets cannot be printed to a PDF file or printer while preserving full vectorial information (and no, taking a pixmap of a window and printing that is certainly not good enough for quality publishing); 5. Overlaying widgets and making translucent widgets is difficult or impossible; 6. I want to make slightly interactive diagrams with a clearly distinctive style from regular gtk widgets, namely i want to draw math plots for later export into articles. For this kind of content, users don't want their selection of gtk theme to interfere with final content, and the content should have white background and simple colors, none of these gradients and 3d look that widgets have. These are my reasons. I will not comment on whether or not the gtk widget system could fulfill my needs. -- 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: GtkCanvas requirements?
2007/4/21, Gustavo J. A. M. Carneiro [EMAIL PROTECTED]: I can tell you the reasons why I usually use a canvas: 1. Writing widgets is _very hard_ (when compared to e.g. canvas items). Depends on your language (and on your widget of course). In python, deriving a widget not a big deal. In C, well I guess you need to grasp some concepts but it's hardly rocket sience. In general, I think people are easily intimitated by the notion of creating a new widget.They go ooh, new widget, HARD! and then go and implement pretty much the same functionality by connecting to signals and overriding them (which IMO results in uglier code, and is harder to reuse), perhaps using even more effort than what it would take to cp some boilerplate code for a widget and doing it properly. I guess that's the price to pay for non-oo-native language :/ 2. Dynamically creating tons of widgets is costly, or at least I get that impression, due to round-trips when creating gdk windows, or gdk contexts, or whatever; Most widgets don't have windows, so that shouldn't be a problem. Per-widget (private) structures might be, but I doubt it would show up significantly (unless we are literally talking about thousands of them). The last option you give seems to imply that this is again a case of it MUST be costly, right? rather than look, it's costly since foo!. 3. The Gtk widget size negotiation protocol is not flexible enough; That's true, although good things are under development currently (in SoC). 4. Widgets cannot be printed to a PDF file or printer while preserving full vectorial information (and no, taking a pixmap of a window and printing that is certainly not good enough for quality publishing); Shouldn't this be almost good with the printing API these days? 5. Overlaying widgets and making translucent widgets is difficult or impossible; I hope we can work this one out (since it seems to be quite popular demand, lord knows why ;), maybe GTK+ should have some support in widget API for the composite extension / similar implementations for other platforms? 6. I want to make slightly interactive diagrams with a clearly distinctive style from regular gtk widgets, namely i want to draw math plots for later export into articles. For this kind of content, users don't want their selection of gtk theme to interfere with final content, and the content should have white background and simple colors, none of these gradients and 3d look that widgets have. This is what I have thought as the main use of a canvas widget. This thread indicates that people seem to want a lot more than that though. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Am Samstag, den 21.04.2007, 11:57 -0500 schrieb Yevgen Muntyan: Federico Mena Quintero wrote: [snip] [Side note... at this point I think doing a canvas in C is a big mistake. Interesting canvases will inevitably get cycles in the pointer graph, and reference counting becomes just too painful then. [This is irrelevant to .net or whatever; it's a general We Should Stop Writing Nontrivial Shit In C thing. People would be really really happy with the Piccolo.NET API implemented with pygtk or gtk-sharp.]] Only mono (python) people would be happy with whatever implemented in gtk-sharp (python). If it's not C, then everybody implements same thing in their favorite language. Unfortunately, it is just hard to implement so we use that one works only if that one is written in C. Even if you forget about problems of interoperability between different languages (some bindings do work two ways, e.g. pygtk; some don't, e.g. gtkmm). So while it's good to write something totally good in C# (and same thing about python, vala, C++, and lisp), it's totally useless as GTK canvas. I agree for you, expect for Vala where you are wrong: Vala doesn't directly produce machine or byte code, it produces standard C code with standard C headers. So technically writing something in Vala is the same as writing something in C - expect that you save alot of typing. As the Vala parser itself is avaiable as GObject library, it even should by extremly easy to generate GAPI files for language bindings directly (without parsing the generated C code). Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Cody Russell wrote: I'd like the canvas system to be generalized enough that we can have multiple implementations of it, in the same way that GDK allows us to port to Win32 or MacOSX. In particular, I think we could have an implementation that is much like what most of the canvases are doing today where everything is software rendered.. Well, there are actually two generations of GTK+ related canvases out there. The GnomeCanvas family (with FooCanvas), which indeed does all the rendering in software. And then there's the cairo-based generation (libccc, goocanvas, hippocanvas, …). The cairo-based generation already isn't forced to being rendered in software. but I also think we could do an OpenGL backend, an OpenGL|ES backend, and possibly a Direct3d backend if there were a reason to do one. We already have this on the cairo level. You can render by using OpenGL using the Glitz backend. You can render hw-accelerated using the Xlib backend (which uses XRender). On windows, it uses a GDI backend. IMHO one of the biggest points of a canvas as a next gen widget system is that lots of window-system-dependent stuff isn't needed in canvas items anymore (in contrast to the GnomeCanvasItem::map stuff). I've been putting some thought into the idea of a GPU-based GTK, and when Havoc first mentioned going the route of having a canvas-based widget system I became instantly interested in that because I thought it was the perfect opportunity to go the GPU route. Well, isn't the right way to go the cairo path and make the communication of cairo and the GPU faster (that's improve Xrender, the drivers etc.)? As this needs to be improved for a GPU based GTK anyway you won't get any advantage by adding this new level of platform independence to GTK (which is already available in cairo). Unfortunately I'm not completely into the current state of hardware-accelerated cairo, but that information should be easy to collect. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Carlos Garnacho wrote: 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. Sounds pretty good until this point. Benjamin just mentioned in IRC that *theming* is also pretty important. We want to be able to render the same canvas item in different ways for different themes. - 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] I don't think the GtkWidget API and the GtkCanvas API shouldn't be tied together too much. I would like to see the canvas approch being the new API and the widget API to become some legacy API (to make app porting easier). As long as we can have these two things everything should be fine: 1. A CanvasWidget: a canvas item that can serve as a GtkContainer for GtkWidgets (so you can have widgets inside the canvas) 2. A WidgetCanvas: a GtkWidget that displays a GtkCanvas You can do everything you want with this structure, so I don't think there's a large need more (but maybe I'm alone with this opinion). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Sven Herzberg wrote: I don't think the GtkWidget API and the GtkCanvas API shouldn't be tied together too much. In HippoCanvas we took this to the extreme of not including gdk.h or gtk.h in the canvas core. I happen to really like this approach, but in general I tend to like to keep code almost annoyingly layered/orthogonal, just a personal taste kind of thing that can create extra work. Then as you mention there's an item that can contain GtkWidget and a GtkWidget that can contain an item. It definitely has the downside that you'd have to replicate large parts of what's in gdk and gtk already. On the upside, if you're writing a new widget core, apps could avoid the old one entirely someday. It's a GTK 3.0 in parallel and interoperable with 2.x sort of thing. Probably at least a little bit insane. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Sven Herzberg herzi at gnome-de.org writes: Sounds pretty good until this point. Benjamin just mentioned in IRC that *theming* is also pretty important. We want to be able to render the same canvas item in different ways for different themes. Let me elaborate on this a bit. I think right now everyone would just say make sure the gtk_paint_foo functions work on the canvas. I have no clue where Gtk wants to go with its support for themeing, but the current approach for themeing is lacking. Not only in that theme engine writers think it sucks, but in particular if you look at current possibilities and compare it to the newer display engines like the iPhone [1] or Compiz [2]. OTOH the amount of useful theme engines has been quite limited. I'm not aware of anything really new since Clearlooks (and even that wasn't radically new). So does Gtk want to reduce themeing and just have a simple file that specifies colors (like Metacity) or does it want to increase its features to allow stuff such as allowing theme engines to do animations, fades and what do I know? This seems like an important question to me since a canvas looks like the place where this approach would be tested first. Cheers, Benjamin [1] http://www.google.com/url?sa=tct=rescd=2url=http%3A%2F%2Fwww.apple.com%2Fiphone%2Fphone%2Fei=P8soRtSwJIfgnAP3l7WFAwusg=AFrqEzeH-MauqKxnTqdDfrV5uDjfBNFh_Qsig2=HBq0ZWprcLSiamgZotpdzg [2] Try to imagine Compiz were written using GtkCanvas and every application was a CanvasItem. How much code would the flames animation take? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
So does Gtk want to reduce themeing and just have a simple file that specifies colors (like Metacity) or does it want to increase its features to allow stuff such as allowing theme engines to do animations, fades and what do I know? If we care about looking native on Win32 and OSX, I'd say that rules out the simple file that specifies colors approach. Dom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Marco Pesenti Gritti wrote: 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? This is a very important aspect, right. Especially with the upcoming *resolution independence* in MacOS X, people will start requesting this feature in GTK+ as well. So we should really add resolution independence to the feature list. This would at least satisfy the request for increasing widget spacing if the resolution increases (so we can have something like 1mm between widgets). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On Fri, 2007-04-20 at 12:02 +0200, Sven Herzberg wrote: Well, isn't the right way to go the cairo path and make the communication of cairo and the GPU faster (that's improve Xrender, the drivers etc.)? As this needs to be improved for a GPU based GTK anyway you won't get any advantage by adding this new level of platform independence to GTK (which is already available in cairo). What I was envisioning is more along the lines of having the widget system drawn as texture-mapped vertices in the GL, with the textures being drawn by Cairo and such. Some textures are repeatable, which means once it is rendered one time then even upon configure events you never need to render it again (except maybe for widget state changes). Also, it could be theoretically possible to implement layout managers as vertex shader programs. These are just some ideas. I'm not sure how this compares to doing the current system + Glitz surfaces. When you use Glitz, how is it drawing the surfaces? If you have 20 different Glitz surfaces in your window, does each one get rendered with a separate GL pass? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkCanvas requirements?
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] Thoughts? Opinions? Regards, Carlos [1] http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00058.html [2] http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg1.html [3] http://mail.gnome.org/archives/gtk-devel-list/2006-August/msg00168.html ___ 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?
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. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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. * 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) Havoc ___ 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: GtkCanvas requirements?
On Thu, 2007-04-19 at 18:51 +0200, Carlos Garnacho wrote: 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. - 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] Thoughts? Opinions? This is awesome. I want to propose another thing, which I think is especially worth considering if we move in the direction of implementing widgets and layouts using the canvas: I'd like the canvas system to be generalized enough that we can have multiple implementations of it, in the same way that GDK allows us to port to Win32 or MacOSX. In particular, I think we could have an implementation that is much like what most of the canvases are doing today where everything is software rendered.. but I also think we could do an OpenGL backend, an OpenGL|ES backend, and possibly a Direct3d backend if there were a reason to do one. I've been putting some thought into the idea of a GPU-based GTK, and when Havoc first mentioned going the route of having a canvas-based widget system I became instantly interested in that because I thought it was the perfect opportunity to go the GPU route. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Marco Pesenti Gritti wrote: 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? I agree that it would be really good to avoid floating point. Pixels are by far the most intuitive thing for people using or writing items, too (since as you say they avoid having to multiply everything). Pango does have the precedent though and for convenience we could just use the same units as Pango. Maybe there's some way to make this optional, for example items that feel they can do something useful with sub-pixel sizes could implement an interface that did the size negotiation in sub-pixels. The default implementation of the sub-pixel size negotiation methods would call the whole pixels one, and the default implementation of the whole-pixels methods would call the sub-pixels one and round off. If you didn't override either one it would break badly, but don't do that then ;-) all items would have to implement one or the other but not both. One downside of doubles is simply the extra memory usage when storing coordinates; I think keeping the abstract base class for items and most common concrete classes as small as possible is a nice win. I'd like to see items be lighter than GtkWidget, in almost any of the usage scenarios (widget core or drawing api or other). Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
