Re: GdkSubwindowMode bug in Win32
On Tue, 2007-07-31 at 13:09 +0300, Tor Lillqvist wrote: Roberto writes: I would know: does this old bug http://bugzilla.gnome.org/show_bug.cgi?id=141721 has ever been fixed? Doesn't look so. GDK_INCLUDE_INFERIORS seems like still not working in windows, as you can test with this really simple program: Thanks for the test program. I attached it to the bug report. (Minimal test programs are essential for fixing bugs like this. I don't think it's unreasonable to ask bug reporters, assuming they can't provide patches, to at least bother writing minimal test programs. I asked the original bug reporter to provide a such already three years ago, but nope. Kinda gives the impression it can't be such a serious problem then, doesn't it? Thanks again!) I think you're being pretty arrogant there. I have helped fix loads of GTK+ bugs over the years. To complain just because I didn't write a test case for this one is a bit much. Maybe I shouldn't bother helping out at all in future. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]
On Sat, 2007-06-16 at 01:59 +0200, Tim Janik wrote: On Sat, 16 Jun 2007, Damon Chaplin wrote: On Fri, 2007-06-15 at 11:25 +0200, Tim Janik wrote: please read Kris' description again. if you set ::tooltip-markup, ::has-tooltip is set automatically, and you don't need to worry about it. this is *not* the case if you connect to ::query-tooltip and possibly return TRUE. there is no way for gtk to tell this kind of setup and querying every widget would be excessively expensive, so we need the user to set ::has-tooltip here. We discussed it before. I said that query-tooltip should really only be emitted just before a tooltip is shown, and you agreed. If that is done the efficiency problem disappears, doesn't it? i'm not sure it does (on every machine). worst case, there would be widget_tree_height signal emissions for each pixel the mouse pointer moves or at least 20 times a second if we reduce querying to 50ms intervalls. I guess you're talking about the time after the initial tooltip has appeared, when other tooltips appear immediately as the user moves the mouse around. (By they way, the docs for query-tooltip don't mention this case, so need updating a bit.) Efficiency-wise it seems comparable to how mouse motion events are propagated up the hierarchy. It shouldn't really be a problem. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]
On Fri, 2007-06-15 at 11:25 +0200, Tim Janik wrote: On Thu, 14 Jun 2007, Damon Chaplin wrote: On Tue, 2007-06-12 at 13:59 +0200, Kristian Rietveld wrote: 2. When you need a tooltip with a little more fancy contents, like adding an image, or you want the tooltip to have different contents per GtkTreeView row or cell, you will have to do a little more work: - Set the has-tooltip property on GtkWidget to TRUE, this will make GTK+ monitor the widget for motion and related events which are needed to determine when and where to show a tooltip. I still think this is unnecessary and clutters the API - it can be determined automatically from the other settings. Can't we get rid of it? please read Kris' description again. if you set ::tooltip-markup, ::has-tooltip is set automatically, and you don't need to worry about it. this is *not* the case if you connect to ::query-tooltip and possibly return TRUE. there is no way for gtk to tell this kind of setup and querying every widget would be excessively expensive, so we need the user to set ::has-tooltip here. We discussed it before. I said that query-tooltip should really only be emitted just before a tooltip is shown, and you agreed. If that is done the efficiency problem disappears, doesn't it? Is has-tooltip needed for anything besides the efficiency issue? (e.g. a11y or something?) Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
On Thu, 2007-06-14 at 11:55 -0300, Johan Dahlin wrote: Damon Chaplin wrote: On Wed, 2007-06-13 at 11:49 -0400, Tristan Van Berkom wrote: Anyway, my point here is not wrt code that exists already in Gtk+, I am of the opinion that GContainer iface is missing, and that objects in general use other objects in general, and in that process of ownership, packing properties are an essential thing. Yes, generic support for packing properties will be needed for any future GtkCanvas widget as well (for packing items inside each other). Not really, GtkCanvas can just define it's own custom tags where it controls the relation between the canvas and its items. Though if we added a generic GContainer interface, we wouldn't need to mess around with custom tags. For GooCanvas I've already had to cut paste a bunch of GtkContainer code to get packing properties working for canvas items. I've also had to add a hack to gtk-doc to document the packing properties. With a GContainer interface things would be a lot simpler. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
I think its quite important here to not repeat one of the the most obvious mistakes of glade/libglade, swapping the signal based on the fact that an object was specified is confusing - it also rules out the use case of specifying a signal that is not swapped has an object user_data. Back in the GTK+ 1.x days I think gtk_signal_connect_object() used to automatically swap the callback arguments. There wasn't any swap option. So calling it one of the most obvious mistakes is a bit harsh! Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
On Thu, 2007-06-14 at 12:42 +0300, [EMAIL PROTECTED] wrote: So, I'm asking: Why not include something like set widget name option into glade and xml-file, or separate property for the name to be set?? Those widgets that have this flag set will have gtk_widget_set_name called, other do not (name is just a internal reference, like a variable name in C). By default this would be off (since most widgets are certainly not special ones, you are not calling gtk_widget_set_name for each widget if you write the UI by hand, do you...) In Glade-2 for code generation it was a project-wide option, Set Widget Names, and the default was FALSE (since few people use them). If it was up to me I'd probably make it an optional GtkBuilder setting, and default to FALSE again. Though it's not a big deal. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
On Wed, 2007-06-13 at 11:49 -0400, Tristan Van Berkom wrote: Anyway, my point here is not wrt code that exists already in Gtk+, I am of the opinion that GContainer iface is missing, and that objects in general use other objects in general, and in that process of ownership, packing properties are an essential thing. Yes, generic support for packing properties will be needed for any future GtkCanvas widget as well (for packing items inside each other). Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: goocanvas notes
On Mon, 2007-04-30 at 12:52 -0400, Havoc Pennington wrote: Something like: - get a few reviews and comments on candidate codebases - iterate codebases accordingly - try to get a couple real-world apps to try them out - iterate accordingly - get review and feedback from gtk maintainers - iterate accordingly - submit resulting mature and well-reviewed codebase to gtk bugzilla If that makes sense, I'd suggest that others review and write up their thinking on GooCanvas, perhaps reading some of the old threads, Piccolo, HippoCanvas, etc. as background material. And also if there are other canvas maintainers who want to put their hat in the ring, they should probably speak up. I've already spent a lot of time on GooCanvas though, so I don't really want to spend a lot more time implementing features the GTK+ maintainers want, and then have them choose another canvas instead. I'd rather they chose one canvas and said do A, B C and it goes in. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject introspection
On Wed, 2007-05-02 at 01:12 +0100, Rob Taylor wrote: Michael Lawrence wrote: I made some suggestions along those lines a while ago on the GtkDocFuture page: http://live.gnome.org/DocumentationProject/GtkDocFuture. It's at the bottom of the page. I'm not sure I like the idea of the gtk-doc comments containing extra tags for return values and arguments. It could get pretty messy. Yeah, hmm, my take is that the introspection data should live in the code, and gtk-doc should pick these up for the docs (just like signals and object hierarchy). I'll be able to tell more after hashing out my prototype. One point I'm interested in from that POV: are there any plans for gtk-doc to document signals/properties on interfaces? (e.g. by instantiating objects pretending to implement them?) gtk-doc documents signals/properties on interfaces already. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
*_type_register_static() and g_intern_static_string()
Why do the *_type_register_static() functions use g_intern_static_string() for the type name? Should apps be using g_intern_static_string() as well? If so, the docs should mention it. There is some inconsistency as well. Some calls don't seem to use it: GtkPaperSize GtkTextIter GtkRecentInfo GtkIconSource GtkWidget GtkIconViewAccessible GtkIconViewAccessibleFactory GtkAssistantAccessible GtkAssistantAccessibleFactory 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 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 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
GooCanvas 0.8 available
Hi, I've put GooCanvas 0.8 up on sourceforge: http://sourceforge.net/project/showfiles.php?group_id=173653 GooCanvas is a cairo-based canvas widget for GTK+. I want to freeze the API soon, so now is the time to discuss any problems with it. GooCanvas Features: o Optional 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 Table item for layout of other items (similar to the GtkTable widget). (This also supports items whose requested height changes according to their allocated width, such as text items.) o Embedded GTK+ widgets. o Layers/stacking order with raise/lower functions. o Cascading styles - line width/style/dashes, colors, fill patterns. o Affine transformations for all items - rotations/scales/skews. o Clip paths to support clipping items. o Event handling - button/motion events, pointer-events property like SVG. o Grabs - support for pointer keyboard grabs. o Keyboard focus traversal. o Accessibility (item 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. GooCanvas 0.8 (Apr 3 2007) = o Added support for width-for-height layout - items whose requested height changes according to their allocated width (typically text items). o Added background-color and background-color-rgb properties to GooCanvas. o Added ellipsize property to GooCanvasText. o Added goo_canvas_item_remove() and goo_canvas_item_model_remove() convenience functions to remove an item or model from the canvas. o Fixed bug removing widget items. o Fixed bug which meant that the fill pattern couldn't be reset to NULL. o Fixed the item event signals, so that returning TRUE from a handler stops the signal emission. o Added a few things that will be needed to support tooltips, when GTK+ 2.12 is available. (Though I don't want to depend on GTK+ 2.12 yet.) o Added const to arguments, where appropriate. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Tooltips patch [take 1]
On Sun, 2007-03-18 at 01:22 +0100, Tim Janik wrote: the main reason for ::has-tooltip is efficiency, because the new tooltips potentially do many tip checks currently (ca. on every mouse motion, however we might implement some coalescing to limit the number of tip checks to 16-25 per second), and for each such tooltip check, multiple widgets maybe queried (the innermost child widget and all its parents worst case). has-tooltip is a bit kludgy though. It would be better if it wasn't needed. (It will probably confuse people using GUI builders. Or GUI builders will have to add special code to avoid showing it.) Do we need to emit tooltip-query in the motion event? Why can't we just setup/update the timeout handler in the motion event and only emit tooltip-query when the timeout fires? That sounds more efficient anyway. If we do that, and tell people who use tooltip-query that they must set the event mask to get motion events, then we may not need has-tooltip. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Tooltips patch [take 1]
Is there any real need for the has-tooltip property? From a quick look at the API it doesn't seem that useful to me. The developer either wants to set a simple tooltip with tooltip-markup or connect to the signal-query signal to set context-sensitive tooltips. Have I missed something? Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: However, the first method you describe: ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt sounds perfect. It's rich (we can get back the mount info later), extensible (we don't have to figure out the entire set of potential mount options in advance) and fairly simple (the root nodes are all direct children of ~/.mounts). You're probably always going to need type, server and share though, so maybe you can make it a bit more readable: ~/.mounts/smb:$server:$share/dir/file.txt Extra options can go on the end. Also I'd probably avoid ';' just in case bash goes anywhere near it. Just a thought, Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pluggable widget types and implementations
On Fri, 2006-12-08 at 13:13 +0100, Tim Janik wrote: On Fri, 1 Dec 2006, Damon Chaplin wrote: On Tue, 2006-11-28 at 14:53 +0100, Tim Janik wrote: Hey all, this is a proposal for allowing pluggable widget types and implementations, assorted bug report: http://bugzilla.gnome.org/show_bug.cgi?id=356864 How about a sort of widget/object factory? So you'd set the default implementation for a type: gtk_object_factory_set_default_implementation (factory, GTK_TYPE_LABEL, MY_CUSTOM_LABEL_TYPE); And then in the widget/object xxx_new() functions instead of calling g_object_new() they call: gtk_object_factory_create (factory, GTK_TYPE_LABEL, ...); that sounds much like the alternative GFactory i suggested in another reply: http://mail.gnome.org/archives/gtk-devel-list/2006-November/msg00133.html Yes, I missed half of the discussion somehow. Applications could then use different sets of widgets for different parts of the interface, just by switching the default factory: gtk_set_default_object_factory (factory); the only differences i see are that you didn't introduce the factory at GLib level, and that you seem to advocate multiple factories. i'm not quite sure why though, can you give more concrete examples on why i would want to switch factories at all? I don't have any specific examples. I just thought using a factory was a more flexible approach - better than adding XXX_appoint_type() functions for each widget. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pluggable widget types and implementations
On Tue, 2006-11-28 at 14:53 +0100, Tim Janik wrote: Hey all, this is a proposal for allowing pluggable widget types and implementations, assorted bug report: http://bugzilla.gnome.org/show_bug.cgi?id=356864 How about a sort of widget/object factory? So you'd set the default implementation for a type: gtk_object_factory_set_default_implementation (factory, GTK_TYPE_LABEL, MY_CUSTOM_LABEL_TYPE); And then in the widget/object xxx_new() functions instead of calling g_object_new() they call: gtk_object_factory_create (factory, GTK_TYPE_LABEL, ...); Does that work? Applications could then use different sets of widgets for different parts of the interface, just by switching the default factory: gtk_set_default_object_factory (factory); Damon ___ 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 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 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: GtkBuilder status
On Wed, 2006-05-10 at 11:51 -0300, Johan Dahlin wrote: We've made a couple of important decisions: * GMarkup based parser which parses and creates the object tree in one step go instead of saprving a whole tree in memory. * breaking xml format compatibility with libglade * not supporting any deprecated or broken widgets * only supporting menubar and toolbar construction through GtkUIManager * custom/fake properties are not intended to be supported. Instead functionality relying on them needs to be rewritten. I don't really see the necessity of breaking the current xml format, or not supporting the older widgets. I wouldn't mind if it supported alternatives to some of the special-cased stuff we have in the current xml, if they were obviously much better. But tweaking it slightly will just cause unnecessary hassle. (The switch to the glade-2 format was a pain in the neck.) Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GooCanvas 0.3
On Wed, 2006-04-26 at 11:16 +0200, Murray Cumming wrote: On Tue, 2006-04-25 at 21:02 +0100, Damon Chaplin wrote: I've put GooCanvas 0.3 (a GTK+ cairo canvas widget) up at: http://www.dachaplin.dsl.pipex.com/goocanvas/ This release adds pretty much all of my list of essential features: o New GooCanvasPath item (similar to SVG path element). o Accessibility support. o Keyboard focus navigation. o API documentation. o Convenience functions for coordinate conversions. o Smooth scrolling zooming. o Zoom-independent text layout. o Render part or all of canvas to a cairo_t, for ps/pdf output. o New visibility and visibility-threshold properties for items. o New pointer-events property specifying which parts of items get events (like SVG). It should be usable now. Though there will probably be a few bugs to iron out. The main thing I want to add now is an editable text item, like GtkTextView. Other than that it depends on what features people need. Do you plan to put this in cvs or similar? It's in fdo cvs: http://webcvs.freedesktop.org/cairo/goocanvas/ Though I wouldn't mind moving it to GNOME cvs at some point. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
canvas + widgets
Hi, One of the main missing pieces of my GooCanvas widget is support for embedded widgets (especially a GtkTextView). I know Alex worked on offscreen rendering of widgets a while back. Is there any code available for that? To be honest, that sounds pretty difficult to me (especially trying to add support for things like event-handling, drag-and-drop etc.). Another option is to write new canvas items like buttons combos instead (like we have various renderers for GtkTreeView). (Obviously porting GtkTextView won't be much fun though!) So I'm not sure which way to go. Thoughts? Damon (PS. I'll release GooCanvas 0.3 as soon as my ISP sorts out its ftp.) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GooCanvas 0.3
I've put GooCanvas 0.3 (a GTK+ cairo canvas widget) up at: http://www.dachaplin.dsl.pipex.com/goocanvas/ This release adds pretty much all of my list of essential features: o New GooCanvasPath item (similar to SVG path element). o Accessibility support. o Keyboard focus navigation. o API documentation. o Convenience functions for coordinate conversions. o Smooth scrolling zooming. o Zoom-independent text layout. o Render part or all of canvas to a cairo_t, for ps/pdf output. o New visibility and visibility-threshold properties for items. o New pointer-events property specifying which parts of items get events (like SVG). It should be usable now. Though there will probably be a few bugs to iron out. The main thing I want to add now is an editable text item, like GtkTextView. Other than that it depends on what features people need. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: goocanvas 0.2
On Tue, 2005-12-06 at 10:27 +0100, Alexander Larsson wrote: On Mon, 2005-12-05 at 22:44 +, Damon Chaplin wrote: I've put goocanvas 0.2 (my cairo canvas widget) up at: http://www.dachaplin.dsl.pipex.com/goocanvas/ New features: o affine transformations for all items. o event handling, including support for pointer grabs. o support for simple animation. o finished port of FooCanvas demo, and added test for pointer grabs. See the TODO file for things left to finish. I still see no way to output the canvas model (or part of it) to a different cairo media (say a cairo postscript target for printing), and this is not in the TODO file. Are you not interested in this? Yes, it is essential, of course. I just forgot it. (I'm writing the canvas to use in a DTP app, so I am interested in printing!) Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
goocanvas 0.2
I've put goocanvas 0.2 (my cairo canvas widget) up at: http://www.dachaplin.dsl.pipex.com/goocanvas/ New features: o affine transformations for all items. o event handling, including support for pointer grabs. o support for simple animation. o finished port of FooCanvas demo, and added test for pointer grabs. See the TODO file for things left to finish. I've also read the SVG spec (http://www.w3.org/TR/SVG11/), which is very interesting. I wonder if we'll want an SVG widget in GTK+ at some point, and if so, will we want a separate canvas as well? I guess it makes sense to try to use the same code for both, if possible. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The state of the canvas
On Fri, 2005-11-18 at 14:28 +0100, Alexander Larsson wrote: Why don't you split the group only methods from GooCanvasItemIface into, say GooCavnasCompositeItemIface. Right now you can call goo_canvas_item_add_child() on any item, but it will crash since iface-add_child is NULL. I could split the interface, but I'd have to split the view interface as well. I'm not sure it would help that much though. Maybe just outputting a warning would be enough. For the text object it would be very nice to have a mode where the text is zoomlevel independent. As a very easy way to do this, use CAIRO_HINT_METRICS_OFF for the text layout. Ideally you'd do the full thing described at: http://people.redhat.com/otaylor/grid-fitting/ Yes, zoom-level-independent layout is essential, and is one of my main worries. I hadn't spotted CAIRO_HINT_METRICS_OFF, so thanks for that. Unfortunately it doesn't seem to work for me. Maybe since it is only a hint it isn't guaranteed to work. I'll have to check with the cairo people. There is no support for applying generic affine transformations to the items. Maybe this is a design decision though? Adding affines to gnome-canvas was certainly when it started going downhill, which is why I backed up to before that when I did foocanvas. However, with cairo instead of libart for the rendering and all rendering being done with cairo this might be doable in a sane way these days. I wasn't sure I was going to add them to the basic items. But I think I'll add them to everything, like Piccolo. Its a shame that GooCanvasView is not an interface. Its used by GooCanvasItem in create_view, so the items are tightly tied to it. If it was an interface then you could implement a different view for e.g. drawing to a pdf surface (i.e. support printing). I thought it was more appropriate to subclass GooCanvasView rather than use interfaces, since it is mainly concerned with widget-related stuff - handling scrollbars events. I think I'm going to change the create_view() functions, and use something like a 'GooCanvasViewFactory' since the application may want to use a custom view, and will need to hook up signals for the events. I'll probably add a render_to_cairo (cairo_t*) function to render to an arbitrary cairo object. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The state of the canvas
On Thu, 2005-11-17 at 12:47 +0100, Jean Bréfort wrote: Hi, It seems that things do not advance a lot by now. AFAIK, no much work have been done except Alexander Larsson's patch available at: http://bugzilla.gnome.org/show_bug.cgi?id=318807 I've almost got a canvas widget working. It's similar to foocanvas, but renders with cairo, has a model/view split, and uses interfaces for canvas items and views. Here's a demo (basically a port of the foocanvas demo): http://www.dachaplin.dsl.pipex.com/goocanvas I should have all the basics sorted out in the next week. I'd be interested to hear what essential features people think are missing in it. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 10 Questions about Printing
On Fri, 2005-10-07 at 23:22 -0400, Owen Taylor wrote: Some fodder for discussion this weekend: 1. Is there a cross-platform printing user interface? Actually, what we are interested in is not the printing user interface per-se, but the points of interaction between the application user interface and the printing user - what are the menu items? What are the places where the application can extend the printing user interface? In terms of menu-items, Windows typically has: Page Setup Print And sometimes Print Preview. OS X has Page Setup and Print; Preview is a button on the Print dialog. GNOME has Page Setup integrated into Print, though many (most?) apps also have a separate Page Setup which may or may not duplicate stuff from the print dialog. I think Page Setup, Print Preview Print are best. Though Print Preview could be optional. For complex layout apps, you need to do Page Setup before editing the document (to set paper size/orientation/margins etc.), so putting it in the Print dialog seems a bit silly. Also, people tend to preview documents multiple times before printing, so it does seem to warrant its own menu item, at least for document- centric apps. Though for some applications you may need to configure the print options before printing (e.g. select a date range in a calendar to print), so a Preview button in the Print dialog makes sense in that case instead. 5. Can we not use the native UI? If we write our own dialog, then we have to be able go beyond enumerating printers, show printer specific options, possibly with driver-provided UI, etc. It doesn't seem that either windows or OS X has a API for writing print dialogs I think trying to avoid the native UI is going to be a lot harder for the print dialog than for the file chooser. For the file chooser, we may be idiosynchratic, but there is a lot of variability anyways (on Windows). For the print dialog, we'll just be non-functional. If we use native UI, can we still customize the dialog? I guess it becomes harder to do. Ideally if we are using the same printer from Linux/Windows/OS X, we should be showing the same options from all of them. So I'd be tempted to use a GTK+ UI. Of course native Windows/OS X driver-provided UI may be better at the moment, but printer manufacturers could provide plugin GTK+ UI in future. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: idea on gobject-introspection / gtk-doc metadata
On Wed, 2005-09-21 at 11:18 -0400, Dan Winship wrote: So, what if we made it so that the extra annotations needed to generate correct gobject-introspection metadata go into the gtk-doc comments (thus encouraging people to write API docs, because it's essentially necessary to get working introspection data), and further made it so that the metadata was written in such a way that you can tell that certain parts of the documentation are directly related to certain pieces of metadata, which might therefore make them irrelevant in other language bindings. Eg: /** * gtk_tree_selection_get_selected_rows: * @selection: A #GtkTreeSelection. * @model:[[direction=out]] A pointer to set to the #GtkTreeModel, or * %NULL. * * Creates a list of path of all selected rows. Additionally, if you are * planning on modifying the model after calling this function, you may * want to convert the returned list into a list of * #GtkTreeRowReference!-- --s. To do this, you can use * gtk_tree_row_reference_new(). * * Return value: A #GListGtkTreePath containing a #GtkTreePath for * each selected row. [[transfer=full] You must free each element of * the list with gtk_tree_path_free() and then free the list itself with * g_list_free().] * * Since: 2.2 **/ From this, the scanner learns that the model parameter is direction=out and null-ok=1 (because the description contains or %NULL), and the returned GList contains GtkTreePaths and is transfer=full. Personally I'm not too sure this would be a good idea. I think it is asking a bit too much from developers to add all this stuff. So you'd probably have to rely on bindings people checking over all the comments. I also worry that the C documentation may contain references to things that aren't applicable to language bindings, so you'd have to mark these as C-only. Then there may be pieces of documentation that should be added for a specific language binding, so you'd have to add them and mark them. It might get messier and messier. Though if lots of language binding maintainers said it would be really useful I might change my mind. Maybe a better idea would be for bindings to grab all the gtk-doc documentation, and then just override the docs for particular functions if they need to. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: suggestion of documentation for new releases
On Tue, 2005-09-20 at 20:26 +0200, Guillaume Cottenceau wrote: Hi, I'm currently scanning the nice Index of new symbols in 2.8 documents, and while they are immensely useful, I have noticed that they don't list new properties and new signals. For example, GdkEventGrabBroken is a new symbol of gdk, and grab-broken-event is a new signal of GtkWidget but the latter is not listed in new symbols in 2.8, which makes it easy to remain unnoticed. Maybe there are practical reasons to let properties and signals out, in such a case accept my apologies. It looks like the grab-broken-event signal has been documented incorrectly: /** * GtkWidget::grab-broken: That should probably be GtkWidget::grab-broken-event:. I've updated the bug about gtk-doc indices, to mention that signals and properties aren't included: http://bugzilla.gnome.org/show_bug.cgi?id=115531 Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some introspection on GtkContainer children.
On Sat, 2005-09-17 at 11:34 +0100, Damon Chaplin wrote: I've had a look at all the composite children that Glade uses for GTK+ widgets. I think all of these could have been avoided if the widgets had been written slightly differently: GladeChildOKButton; GladeChildCancelButton; GladeChildApplyButton; GladeChildHelpButton; GladeChildSaveButton; GladeChildCloseButton; These are the buttons used on many of the dialogs in GTK+. As I said before, if the dialogs had a response signal, these would be unnecessary. Actually I think all of the dialogs except GtkInputDialog use gtk_dialog_add_button() now and do emit response signals, so these aren't needed any more anyway. (And GtkInputDialog could be updated easily as well.) Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some introspection on GtkContainer children.
I've had a look at all the composite children that Glade uses for GTK+ widgets. I think all of these could have been avoided if the widgets had been written slightly differently: GladeChildOKButton; GladeChildCancelButton; GladeChildApplyButton; GladeChildHelpButton; GladeChildSaveButton; GladeChildCloseButton; These are the buttons used on many of the dialogs in GTK+. As I said before, if the dialogs had a response signal, these would be unnecessary. GladeChildMenuItemImage; (the image in a GtkImageMenuItem) GladeChildComboEntry; (the GtkEntry inside the old GtkCombo) GladeChildComboList; (the GtkList inside the old GtkCombo) GladeChildFontSelection; (inside the font selection dialog) GladeChildColorSelection; (inside the color selection dialog) These could be avoided if the parent widget provided the necessary properties itself, and just passed the values on to the children. (Similar to how many of the GtkFileChooser-related properties work.) GladeChildDialogVBox; (used for GtkDialog and GtkFileChooser) GladeChildDialogActionArea; (ditto) For GtkDialog we could have just got rid of these completely, and used regular child widgets for everything (with helpers to set up standard dialogs for you). Buttons would have response_id properties, and when clicked the button would find its toplevel dialog/window widget and emit a response signal on it. Another option is for these widgets to act like a standard container, so you can pack widgets into them. So basically if widgets are designed with GUI builders in mind, I think you can avoid composite children issues 99% of the time. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some introspection on GtkContainer children.
On Thu, 2005-09-15 at 15:46 -0400, Tristan Van Berkom wrote: as specially noted that there are in effect three types of child widgets; normal, added as a result of a property value; added as a composite child which is constantly present. I think that if we're going to talk of ideal scenarios, GtkContainer should probably be a GInterface and allow for any object to have child objects; which also could be composite or not; children also tend to have different relationships to parents; for example a GtkMenuItem parented by a GtkMenu isnt exactly a GtkContainer -- GtkWidget relationship, its also concievable that a parent object can have multiple children of multiple relationship types. I think you guys should probably give up on the idea of handling standard GTK+ widgets generically. There are so many special cases that it is almost impossible. But what you should aim for is to be able to handle external widget libraries generically (e.g. there is very little special-case code to handle the GnomeDB widgets in glade-2). You can then write up a guide for widget developers who want to be compatable with GUI builders - e.g. use widget properties to configure everything, don't use construct-only properties, avoid composite children unless absolutely necessary (and even then only use simple ones). You can probably cover over 95% of all external widgets that way. (You could also add hints to the widget description catalog files to support things like Dan's gtk_container_get_max_children() idea. It doesn't all have to be introspection if its just for GUI builders.) Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some introspection on GtkContainer children.
On Fri, 2005-09-16 at 12:14 +0100, Gustavo J. A. M. Carneiro wrote: On Fri, 2005-09-16 at 11:02 +0100, Damon Chaplin wrote: avoid composite children unless absolutely necessary (and even then only use simple ones). I don't agree it's fair to limit developers' options on code reuse just for the sake of GUI builders. I'd rather pack an hbox into my widget than duplicate its layout algorithm, for example. Sorry, I wasn't being very clear. When I said avoid composite children I meant avoid forcing the GUI builder to support setting the properties of composite children. For example, for many of the dialogs (GtkFontSelection etc.) Glade has to let the user select the OK button (a composite child) and add a signal handler. But it would be better if the dialog had something like a response signal instead, so there was no need to select the OK button at all. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some introspection on GtkContainer children.
On Wed, 2005-09-14 at 23:27 -0400, Tristan Van Berkom wrote: On a more practicle note; I was thinking that internal children of composite widgets should be more introspectable; for the purpose of GUI builders and loaders, if every child widget implicitly created by its parent at least had a name, we could avoid alot of special case code and maintanence. Composite children can be marked when created by the container calling gtk_widget_push_composite_child()/gtk_widget_pop_composite_child(). They can also be named with gtk_widget_set_composite_name(), though this hasn't been used much in GTK+ itself. Ideally a GUI builder shouldn't have to touch composite children - the properties of the widget should be enough to configure it completely. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: annoying glib licencing stuff
On Thu, 2005-06-16 at 10:00 +0200, Mathieu Lacage wrote: I understand that this might not be high on the todo list of the gtk+ developers but I would appreciate an answer to that email. Most of the initial glib 1.x documentation was written by me, plus Sebastian Wilhelmi wrote the Threads section and Havoc Pennington wrote the Date Time section. I don't know much about the documentation for 2.x but I would think that only a handful of people wrote significant amounts (i.e. whole sections). (For a list of people who submitted docs for the Reference Documentation Project do 'cvs co -D 2005-01-01 gtk-web/rdp/status.html') Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Future of GtkTooltips
On Wed, 2005-02-09 at 12:23, Christian Neumair wrote: Problems - in short - with the current tooltip system: - Not flexible enough (only plain text can be set) - Unable to set popup location - Exposes too many internals (GtkTooltipsData, tip_text, tip_private) without getters/setters Proposed resultions: Flexibility: - Use either GtkTextBuffer for powerful tooltips, might be overhead - Or use at least PangoMarkup or PangoLayout Location: - Model an optional function similar to GtkMenuPositionFunc I think you should track mouse movement in the core GTK+ event handling code, and setup the idle handler function there. Then when the idle handler fires you can find out which widget the mouse is in and call a new function like gtk_widget_show_tooltip() on it. (This hopefully means it can be used for NO_WINDOW widgets as well as widgets with windows, unlike the present code.) The default gtk_widget_show_tooltip() class function would do basically the same as now, but subclasses could override it so they could change the position or text of the tooltip as appropriate. (But you'd provide helper functions for doing the basic tooltip stuff.) I'd use the code event handling code to check when to hide tips as well, as that could be tricky. I don't think the GtkTooltips thing is much use. Though I don't know the code too well. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
