Re: porting gdk - cairo
On Wed, 18 Aug 2010, Dov Grobgeld wrote: I don't know if you noticed it in another thread, but I created a working example of the approach that I described in my earlier email. See: http://github.com/dov/dovtk-lasso See the program test-dovtk-lasso.c for an example of how to use it. Thanks. Yes, I did notice the discussion and I'll take a look at the code. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Performance issues of GDK deprecation in favour of Cairo
hi, On 17.08.2010 12:01, James Morris wrote: Hi, I see that some GDK drawing functions and graphics contexts have been deprecated in favour of using Cairo. Yesterday I spent a few hours *removing* Cairo code from my fledgling GTK application and replacing it with gdk_draw_rectangle, gdk_gc_set_rgb_fg_color, and gdk_gc_set_function. I did this for performance reasons[1] I am wondering if my approach to drawing is wrong however and if a better approach might yield less CPU usage? It begins with a 33ms timeout. The timeout callback calls gtk_widget_queue_draw on the window and the drawing area. Would it be possible to isolate this into a standalone demo. Or could you point us to the actual code? Stefan (Imagine rectangles appearing each time a note is played in a piece of music and disappearing when that note ends.) In the expose event callback a linked-list of rectangles is maintained. Rectangles are added to the list and removed from the list as notes start and end (The application is an experimental MIDI sequencer/arpeggiator operating in real time). Each and every time the expose event callback is called (every 33ms) the background and the entire list of rectangles is drawn as well as various maintenance functions performed on the list. The documentation of gdk_cairo_create seems to suggest this is the only way of doing it when it says: Note that due to double-buffering, Cairo contexts created in a GTK+ expose event handler cannot be cached and reused between different expose events. Is it possible to do this any other way? Cheers, James. [1]My machine is a 64bit 3.0ghz dual core desktop. Using GDK for drawing, the CPU usage is at worst 5% on both cores. Using Cairo on the other hand, the CPU usage can reach as much as 20% on both cores. The project is here:http://github.com/jwm-art-net/BoxySeq Cairo routines is here: http://github.com/jwm-art-net/BoxySeq/tree/97f6d674a2a182a143ef82b03bde11689fedcf18 GDK routines is here: http://github.com/jwm-art-net/BoxySeq/tree/29f412b41b2371ec136aa86da50d858f5892bfa0 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ 2.21.6
On Wed, 2010-08-18 at 11:52 -0400, Paul Davis wrote:
On Mon, Aug 16, 2010 at 8:48 PM, Matthias Clasen mcla...@redhat.com wrote:
GTK+ 2.21.6 is now available for download at:
is this really a correct description of 2.21:
Overview of Changes from GTK+ 2.21.5 to 2.21.6
==
* Most drawing done by GTK+ itself has been ported from
GDK drawing APIs to cairo
[ ]
* Deprecations:
- GtkNotebookPage
- The GtkRecenManager::limit property
- All GDK drawing functions, ie gdk_draw_*. Use cairo instead
- All GdkGC functions. Use cairo instead
- All of GdkImage. Use cairo instead
- All of GdkRGB. Use cairo instead
- gdk_{bit,pix}map_create_from_data
[ ... ]
* New cairo-related APIs:
- gdk_window_create_similar_surface
- gdk_window_get_background_pattern
I though that this work was mostly in the 2.9/3.0 branch ?
The old methods still need to be marked as deprecated and replacements
available in 2.x to ease GTK+ 3.x porting, otherwise you're left having
to port everything before you can test it out.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ 2.21.6
On Wed, 2010-08-18 at 12:14 -0400, Paul Davis wrote: On Wed, Aug 18, 2010 at 12:04 PM, Bastien Nocera had...@hadess.net wrote: On Wed, 2010-08-18 at 11:52 -0400, Paul Davis wrote: On Mon, Aug 16, 2010 at 8:48 PM, Matthias Clasen mcla...@redhat.com wrote: GTK+ 2.21.6 is now available for download at: is this really a correct description of 2.21: Overview of Changes from GTK+ 2.21.5 to 2.21.6 == * Most drawing done by GTK+ itself has been ported from GDK drawing APIs to cairo [ ] I though that this work was mostly in the 2.9/3.0 branch ? The old methods still need to be marked as deprecated and replacements available in 2.x to ease GTK+ 3.x porting, otherwise you're left having to port everything before you can test it out. i wasn't aware that the drawing switch was planned for 2.22. this now makes this branch barely 2.X at all, from our perspective. it fundamentally makes it a completely new implementation of GDK, within a supposedly stable branch of GTK. this is quite problematic, i think. i was under the impression that 2.22 was going to be the last release of 2.X, not a preview of what 3.0 would contain. New functionality is available in both when it makes sense to do so, and deprecated functionality is marked as much. You shouldn't see any difference in usage if you don't use the new functionality. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ 2.21.6
On Wed, Aug 18, 2010 at 12:27 PM, Paul Davis p...@linuxaudiosystems.com wrote: On Wed, Aug 18, 2010 at 12:21 PM, Bastien Nocera had...@hadess.net wrote: New functionality is available in both when it makes sense to do so, and deprecated functionality is marked as much. You shouldn't see any difference in usage if you don't use the new functionality. We distribute a version of GTK as part of our product for OS X. We had selected 2.22 as the branch to follow for this, on an apparently faulty understanding that 2.22 was a relatively stable branch at this point. Replacing every gdk_draw_* method doesn't qualify for relatively stable in my opinion. We now have to drop our tracking of 2.22 entirely and simply sit at the current (arbitrary) revision that we currently use for the build. Frustrating. I don't see how that follows. All that is happening in 2.22 is that some things are getting deprecated. You can still use them. We are not going to take them away from you during 2.x ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ 2.21.6
On 08/18/10 12:50, Paul Davis wrote: On Wed, Aug 18, 2010 at 12:44 PM, Matthias Clasen matthias.cla...@gmail.com wrote: I don't see how that follows. All that is happening in 2.22 is that some things are getting deprecated. You can still use them. We are not going to take them away from you during 2.x i wasn't really worried about the deprecations. replacing the implementation of all internal drawing methods is OK to do in a stable branch? From what I understand reading the thread, that's your wrong impression. The rendering-cleanup branch is NOT being merged into 2.22. Just that some new functions where added, and some old ones marked deprecated. You are imagining things that are simply not true. behdad ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
ms-windows engine on Windows 7
A user of my GTK app recently remarked on this: when he uses the ms-windows theme engine on Windows 7, the highlight on the currently selected menu item misbehaves: the text of the highlighted item goes white, while the background for that item goes almost-white, making the item unreadable. On MS Vista I don't see this problem (with the same gtkrc and libwimp.dll): the background goes light-colored but the menu text remains black. (FWIW the way highlighting works on my Windows 7 user's desktop for non-GTK apps is that the active item is surrounded by a barely perceptible box, with no change of text color.) Any ideas on how the text-disappearing problem could be fixed? Could some magic in gtkrc do the job? -- Allin Cottrell Department of Economics Wake Forest University ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Performance issues of GDK deprecation in favour of Cairo
On 18 August 2010 15:57, Stefan Kost enso...@hora-obscura.de wrote: hi, On 17.08.2010 12:01, James Morris wrote: Hi, I see that some GDK drawing functions and graphics contexts have been deprecated in favour of using Cairo. Yesterday I spent a few hours *removing* Cairo code from my fledgling GTK application and replacing it with gdk_draw_rectangle, gdk_gc_set_rgb_fg_color, and gdk_gc_set_function. I did this for performance reasons[1] I am wondering if my approach to drawing is wrong however and if a better approach might yield less CPU usage? It begins with a 33ms timeout. The timeout callback calls gtk_widget_queue_draw on the window and the drawing area. Would it be possible to isolate this into a standalone demo. Or could you point us to the actual code? Hi Stefan, The actual code is here: http://github.com/jwm-art-net/BoxySeq/blob/97f6d674a2a182a143ef82b03bde11689fedcf18/gui_grid.c I'm probably not going to work on it for a while. Probably going to make the back-end into a library first and then investigate the possibility of using FLTK. Cheers, James. Stefan (Imagine rectangles appearing each time a note is played in a piece of music and disappearing when that note ends.) In the expose event callback a linked-list of rectangles is maintained. Rectangles are added to the list and removed from the list as notes start and end (The application is an experimental MIDI sequencer/arpeggiator operating in real time). Each and every time the expose event callback is called (every 33ms) the background and the entire list of rectangles is drawn as well as various maintenance functions performed on the list. The documentation of gdk_cairo_create seems to suggest this is the only way of doing it when it says: Note that due to double-buffering, Cairo contexts created in a GTK+ expose event handler cannot be cached and reused between different expose events. Is it possible to do this any other way? Cheers, James. [1]My machine is a 64bit 3.0ghz dual core desktop. Using GDK for drawing, the CPU usage is at worst 5% on both cores. Using Cairo on the other hand, the CPU usage can reach as much as 20% on both cores. The project is here: http://github.com/jwm-art-net/BoxySeq Cairo routines is here: http://github.com/jwm-art-net/BoxySeq/tree/97f6d674a2a182a143ef82b03bde11689fedcf18 GDK routines is here: http://github.com/jwm-art-net/BoxySeq/tree/29f412b41b2371ec136aa86da50d858f5892bfa0 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Minutes of the GTK+ Team Meeting - 2010-08-17
Hi, - GAction, allows named actions + parameters (local+remote invocation) + only name, no visual/UI-related attributes + :enabled + (optional) state - GActionGroup, allows grouping of actions - GApplication, handles groups of actions - parametrized actions will be available on D-Bus - GtkAction is the presentation layer for GAction - other backends are still a question mark + probably unable to implement parametrized actions, but UI elements should be easy to write Can you undo an action? Any relation to a generic undo/redo framework? Regards, J-P Iivonen __ Saunalahdelta mullistava uutuus Nokia N97 ja kaiken kattava TotaaliMAX nyt ennakkomyynnissä uskomattoman edullisesti! Paketissa puhelut ja viestit (3000 min/kpl/kk), huippunopea mobiililaajakaista sekä Nokia N97 yhdellä kk-maksulla vain 59,95 e/kk (24 kk sopimus). Katso http://saunalahti.fi/totaalimax ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Tue, 2010-08-17 at 16:04 -0500, Federico Mena Quintero wrote: On Tue, 2010-08-17 at 21:10 +0200, Alexander Larsson wrote: Additionally I was thinking one could specify a border on the window such that for clipping purposes and calculation of what has to be repainted we grow the window by the border width, while for events and the rest we use the normal size. This makes it easy to implement themes that have a more organic look, for instance having a glow on an active button that extends outside the button without affecting events, etc. Do you need that? Can't you create a separate window overlaid on your button, and paint the glow on *that* one? (The window would extend past the normal window's edge; it would probably need the toplevel to be its parent so the glow can go over everything, etc. - but it sounds doable like that...) There are all sorts of ways you can hack it into GtkButton or any specific widget, I'm sure. However, its hard to do in a more generic way for a theme. I was thinking the theme could just set a style property to have the widget enlarge its border, and then the theme just draws a bit outside in its normal rendering operation. No hacks, no special code, works for all widgets. Who uses reparenting, anyway? Dnd of toolbars items, detachable docks, putting plugs in sockets, etc. I don't think reparenting is needed for toolbar items and detachable docks - unless X forces you to do it to get really smooth painting. Plug/socket is special anyway, as you need to cross into the actual window system. Yeah, but the way you do this is via gdk. It is the bridge to the native windowing system. Just ignoring that is not gonna help us. Event masks affect more than performance though. They are combined to decide which window gets each event. For instance, if you have a window somewhere with a bunch of child hierarchies, and the window has the event mask for mouse motion, then it will get mouse motion even over the child windows, unless the child window sets mask for mouse motion too. So, just sending everything everywhere is not a solution. Ah, OK :) I guess this is due to X not having event callbacks and the boolean means whether the callback handled the event thing... Such callbacks would be very costly in an client-server over-network model, since there will be many roundtrips per event. So, apart from the general pending cleanup, are we just lacking the don't clip flag discussed above for transparent windows? To fully take advantage of it we would also like to remove no-window widgets in Gtk and make getting a standard window easy via some default realize handler setup. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a bookish moralistic stage actor on the hunt for the last specimen of a great and near-mythical creature. She's a strong-willed French-Canadian barmaid trying to make a difference in a man's world. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.90.6
Overview of Changes from GTK+ 2.90.5 to 2.90.6 == ... * Allow windows to be dragged by clicking on empty areas in menubars and toolbars Can this be disabled, please? P.T. -- Petr Tomasek http://www.etf.cuni.cz/~tomasek Jabber: but...@jabbim.cz EA 355:001 DU DU DU DU EA 355:002 TU TU TU TU EA 355:003 NU NU NU NU NU NU NU EA 355:004 NA NA NA NA NA ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: cairo drawing commands to gdk_invalidate_region
On Tue, Aug 17, 2010 at 4:22 PM, Dov Grobgeld dov.grobg...@gmail.com wrote: The solution won't work if the default expose-event handler returns TRUE. I would still like to resolve the issues that Paul has with my description of the code. Paul, why don't you like the fact that I call draw() twice? that's overstating it a little bit. what i was taking issue with is that *unless* draw() has some way to be able to tell that it is being called from an expose event handler (and that would presumably have to be some global variable, since nothing is passed to it as an argument), it is by definition doing the wrong thing *if* it is responsible for all the rendering that occurs in the expose handler. why? because that would imply that it actually renders in both the pre-expose call and the expose-event call, but you should only be rendering (to the window at list) in the expose event call. you asked: How is update() supposed to know what region to invalidate? in your original description, you showed the flow as: # motion event calls update() # update() calls draw() in order to get regions to expose. # update() calls gdk_invalidate_region() based on output from draw # exposure-event callback calls draw() to carry out the drawing for each region so you have logic that knows what regions are affected by the motion event (the above description makes it sound as if that logic is inside draw()). update should have that logic so that it can call gdk_invalidate_region(), and then the expose-event call to draw() should use the event region list to redraw. if your code works, that's fine. i'm just trying to describe to you what i *think* is the right way to do this so that its portable to all backends of GTK and is following the overall drawing model embedded in GTK. --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Tue, Aug 17, 2010 at 5:04 PM, Federico Mena Quintero feder...@ximian.com wrote: [ ... ] its quite amusing to me how what is being described is slowly converging on something extremely close to a canvas model in many of its most fundamental aspects. am i the only one seeing this? does it matter? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Wed, Aug 18, 2010 at 3:37 AM, Alexander Larsson al...@redhat.com wrote: There are all sorts of ways you can hack it into GtkButton or any specific widget, I'm sure. However, its hard to do in a more generic way for a theme. I was thinking the theme could just set a style property to have the widget enlarge its border, and then the theme just draws a bit outside in its normal rendering operation. No hacks, no special code, works for all widgets. a solution. We are just about to remove that style property, called GtkWidget::draw-border, since it has some overhead, and nobody ever used it. See bug http://bugzilla.gnome.org/show_bug.cgi?id=426924 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.90.6
* Allow windows to be dragged by clicking on empty areas in menubars and toolbars Can this be disabled, please? Yes, it can (per theme) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: GLib 2.25.14
On Wed, 2010-08-18 at 10:36 +0800, Zhang, Qiang Z wrote: Thanks for your quick reply. As glib is the low level library, so I think it would be released ahead of time. Right? Can glib 2.26 be released end of August? Then we feel better about including it in MeeGo 1.1, and we have enough time to test. Not much, this time around. There is still changes expected to land in the new GApplication apis, and there is a bunch of outstanding network-related functionality that people want to include. GDBus and GSettings should be pretty much done as of 2.25.14, though. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Wed, 2010-08-18 at 07:56 -0400, Paul Davis wrote: its quite amusing to me how what is being described is slowly converging on something extremely close to a canvas model in many of its most fundamental aspects. am i the only one seeing this? does it matter? In my mind a canvas does two things: 1. Retained drawing. You draw something and you get a handle back to it so that you can modify it (move it, recolor it, etc.). GDK doesn't do retained drawing; it does direct drawing where you draw something but you have no way to modify it afterwards. 2. Hit detection. You get events relative to the objects that you drew. This is a lot more sophisticated than something happened inside this rectangular window :) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.21.6
On Mon, Aug 16, 2010 at 8:48 PM, Matthias Clasen mcla...@redhat.com wrote:
GTK+ 2.21.6 is now available for download at:
is this really a correct description of 2.21:
Overview of Changes from GTK+ 2.21.5 to 2.21.6
==
* Most drawing done by GTK+ itself has been ported from
GDK drawing APIs to cairo
[ ]
* Deprecations:
- GtkNotebookPage
- The GtkRecenManager::limit property
- All GDK drawing functions, ie gdk_draw_*. Use cairo instead
- All GdkGC functions. Use cairo instead
- All of GdkImage. Use cairo instead
- All of GdkRGB. Use cairo instead
- gdk_{bit,pix}map_create_from_data
[ ... ]
* New cairo-related APIs:
- gdk_window_create_similar_surface
- gdk_window_get_background_pattern
I though that this work was mostly in the 2.9/3.0 branch ?
--p
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.21.6
On Wed, 2010-08-18 at 11:52 -0400, Paul Davis wrote:
On Mon, Aug 16, 2010 at 8:48 PM, Matthias Clasen mcla...@redhat.com wrote:
GTK+ 2.21.6 is now available for download at:
is this really a correct description of 2.21:
Overview of Changes from GTK+ 2.21.5 to 2.21.6
==
* Most drawing done by GTK+ itself has been ported from
GDK drawing APIs to cairo
[ ]
* Deprecations:
- GtkNotebookPage
- The GtkRecenManager::limit property
- All GDK drawing functions, ie gdk_draw_*. Use cairo instead
- All GdkGC functions. Use cairo instead
- All of GdkImage. Use cairo instead
- All of GdkRGB. Use cairo instead
- gdk_{bit,pix}map_create_from_data
[ ... ]
* New cairo-related APIs:
- gdk_window_create_similar_surface
- gdk_window_get_background_pattern
I though that this work was mostly in the 2.9/3.0 branch ?
The old methods still need to be marked as deprecated and replacements
available in 2.x to ease GTK+ 3.x porting, otherwise you're left having
to port everything before you can test it out.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Wed, Aug 18, 2010 at 11:49 AM, Federico Mena Quintero feder...@ximian.com wrote: On Wed, 2010-08-18 at 07:56 -0400, Paul Davis wrote: its quite amusing to me how what is being described is slowly converging on something extremely close to a canvas model in many of its most fundamental aspects. am i the only one seeing this? does it matter? In my mind a canvas does two things: 1. Retained drawing. You draw something and you get a handle back to it so that you can modify it (move it, recolor it, etc.). GDK doesn't do retained drawing; it does direct drawing where you draw something but you have no way to modify it afterwards. 2. Hit detection. You get events relative to the objects that you drew. This is a lot more sophisticated than something happened inside this rectangular window :) in my mind, a canvas does two things: 1) composites together the result of a variety of different objects drawing themselves, most likely with z-axis ordering. it does 2) event distribution ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Wed, Aug 18, 2010 at 12:06 PM, Paul Davis p...@linuxaudiosystems.com wrote: sometimes i hate gmail keybindings ... so, to finish what i was saying ... in my mind, a canvas does two things: 1) composites together the result of a variety of different objects drawing themselves/ it does this paying attention to the area of a window that needs to be redrawn according to external information (e.g. expose events) and the internal state of the canvas (e.g. invalidated state in something that is displayed within the window). the primary information required to do this is the extent of each object. most canvases would also take z-order stacking into account when ordering the redrawing, but this isn't actual critical to this basic model of what is happening. 2) event distribution i.e. finding the correct object to deliver an event to in the first instance, and then propagating that to other objects until the event is handled according to some kind of logical rule or rules. it seems to me that GTK (like some other toolkits) is increasingly converging on this model, without any specific awareness that this is likely where it all ends up. --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.21.6
On Wed, Aug 18, 2010 at 12:04 PM, Bastien Nocera had...@hadess.net wrote: On Wed, 2010-08-18 at 11:52 -0400, Paul Davis wrote: On Mon, Aug 16, 2010 at 8:48 PM, Matthias Clasen mcla...@redhat.com wrote: GTK+ 2.21.6 is now available for download at: is this really a correct description of 2.21: Overview of Changes from GTK+ 2.21.5 to 2.21.6 == * Most drawing done by GTK+ itself has been ported from GDK drawing APIs to cairo [ ] I though that this work was mostly in the 2.9/3.0 branch ? The old methods still need to be marked as deprecated and replacements available in 2.x to ease GTK+ 3.x porting, otherwise you're left having to port everything before you can test it out. i wasn't aware that the drawing switch was planned for 2.22. this now makes this branch barely 2.X at all, from our perspective. it fundamentally makes it a completely new implementation of GDK, within a supposedly stable branch of GTK. this is quite problematic, i think. i was under the impression that 2.22 was going to be the last release of 2.X, not a preview of what 3.0 would contain. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Wed, 2010-08-18 at 09:37 +0200, Alexander Larsson wrote: [Border around windows so you can glow around a widget] There are all sorts of ways you can hack it into GtkButton or any specific widget, I'm sure. However, its hard to do in a more generic way for a theme. I was thinking the theme could just set a style property to have the widget enlarge its border, and then the theme just draws a bit outside in its normal rendering operation. No hacks, no special code, works for all widgets. Hmm. I just think it's overkill to complicate the GdkWindow abstraction just for themes' sake. Correct me if I'm wrong, but I think you imagine the glow-around-a-button to actually have allocated space around the button * +--+ * +--+ * |button| * |button| * +--+ * +--+ while I'm imagining that the glow actually overlaps anything around the widget ** * +--+ +*-+ * |button| |*utton| * +--+ +*-+ ** The latter is doable if the theme creates a temporary window as a child of the toplevel, on top of all the other subwindows. [Do we just lack the don't clip flag on windows] To fully take advantage of it we would also like to remove no-window widgets in Gtk and make getting a standard window easy via some default realize handler setup. I guess InputOnly windows are trivial when we get the transparent windows we've been talking about - you just never draw to them. Old apps could still use them to get events. Getting rid of no-window widgets would be trivial in GTK+, but it would break a lot of code that already uses that trick and does all the coordinate-munging on its own... maybe we should make no-window mean you won't know it, but you really get a cairo_t with a transformation relative to your parent widget? That way you still have to make the changes to take a cairo_t instead of a GdkWindow (for the draw() method), but you don't have to change your delicate code that deals with coordinates. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.21.6
On Wed, 2010-08-18 at 12:14 -0400, Paul Davis wrote: On Wed, Aug 18, 2010 at 12:04 PM, Bastien Nocera had...@hadess.net wrote: On Wed, 2010-08-18 at 11:52 -0400, Paul Davis wrote: On Mon, Aug 16, 2010 at 8:48 PM, Matthias Clasen mcla...@redhat.com wrote: GTK+ 2.21.6 is now available for download at: is this really a correct description of 2.21: Overview of Changes from GTK+ 2.21.5 to 2.21.6 == * Most drawing done by GTK+ itself has been ported from GDK drawing APIs to cairo [ ] I though that this work was mostly in the 2.9/3.0 branch ? The old methods still need to be marked as deprecated and replacements available in 2.x to ease GTK+ 3.x porting, otherwise you're left having to port everything before you can test it out. i wasn't aware that the drawing switch was planned for 2.22. this now makes this branch barely 2.X at all, from our perspective. it fundamentally makes it a completely new implementation of GDK, within a supposedly stable branch of GTK. this is quite problematic, i think. i was under the impression that 2.22 was going to be the last release of 2.X, not a preview of what 3.0 would contain. New functionality is available in both when it makes sense to do so, and deprecated functionality is marked as much. You shouldn't see any difference in usage if you don't use the new functionality. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.21.6
On Wed, Aug 18, 2010 at 12:21 PM, Bastien Nocera had...@hadess.net wrote: New functionality is available in both when it makes sense to do so, and deprecated functionality is marked as much. You shouldn't see any difference in usage if you don't use the new functionality. We distribute a version of GTK as part of our product for OS X. We had selected 2.22 as the branch to follow for this, on an apparently faulty understanding that 2.22 was a relatively stable branch at this point. Replacing every gdk_draw_* method doesn't qualify for relatively stable in my opinion. We now have to drop our tracking of 2.22 entirely and simply sit at the current (arbitrary) revision that we currently use for the build. Frustrating. We went through this earlier (at about 2.14), when we had to stop tracking releases because of the breakage being caused to non-X11 backends by changes to various parts fo the system. I guess we just do the same again. It only affects a handful of developers but it also pretty much blocks anyone from ever being able to easily build our GPL'ed app on OS X for themselves because there will never be a release version of GTK that corresponds to what is required. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
Hi, On Wed, Aug 18, 2010 at 7:56 AM, Paul Davis p...@linuxaudiosystems.com wrote: On Tue, Aug 17, 2010 at 5:04 PM, Federico Mena Quintero feder...@ximian.com wrote: [ ... ] its quite amusing to me how what is being described is slowly converging on something extremely close to a canvas model in many of its most fundamental aspects. am i the only one seeing this? does it matter? See http://log.ometer.com/2008-03.html#7 perhaps. Another way to think of canvas (different than in the above slide deck), is what I call just a canvas vs. toolkit stuff - toolkit stuff is all the global singletons, the GApplication, the main loop, the window system abstraction layer. A really nice thing about HippoCanvas was that the canvas items didn't really see above themselves to parent items, or most of all they didn't poke at toplevel windows or a stage or a global backend thingy such as a display. Instead HippoCanvas is totally recursive - events get to leaf items by being sent to parent items that then forward to the leaf items, to draw the whole screen you just draw the root item, etc. This then makes it very easy to be in that gtk_widget_draw() type of world where you can draw items to other contexts such as to print them. I think both GTK 2.x and Clutter have fairly suboptimal code where there's a good bit of leakage of the global window system goo into the actors/widgets, and part of this thread is about mopping that up. A nice thing about having actors and widgets separate from all the toolkit stuff is that it makes it a good bit simpler to mix two different kits together. Anyway that's one aspect of this, and the other I think is more in the slides I linked to, which is that canvas items are generally more flexible than widgets (have transforms, don't have to be a rectangle, etc.) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.21.6
On Wed, Aug 18, 2010 at 12:27 PM, Paul Davis p...@linuxaudiosystems.com wrote: On Wed, Aug 18, 2010 at 12:21 PM, Bastien Nocera had...@hadess.net wrote: New functionality is available in both when it makes sense to do so, and deprecated functionality is marked as much. You shouldn't see any difference in usage if you don't use the new functionality. We distribute a version of GTK as part of our product for OS X. We had selected 2.22 as the branch to follow for this, on an apparently faulty understanding that 2.22 was a relatively stable branch at this point. Replacing every gdk_draw_* method doesn't qualify for relatively stable in my opinion. We now have to drop our tracking of 2.22 entirely and simply sit at the current (arbitrary) revision that we currently use for the build. Frustrating. I don't see how that follows. All that is happening in 2.22 is that some things are getting deprecated. You can still use them. We are not going to take them away from you during 2.x ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Wed, Aug 18, 2010 at 12:27 PM, Havoc Pennington h...@pobox.com wrote: Hi, On Wed, Aug 18, 2010 at 7:56 AM, Paul Davis p...@linuxaudiosystems.com wrote: On Tue, Aug 17, 2010 at 5:04 PM, Federico Mena Quintero feder...@ximian.com wrote: [ ... ] its quite amusing to me how what is being described is slowly converging on something extremely close to a canvas model in many of its most fundamental aspects. am i the only one seeing this? does it matter? See http://log.ometer.com/2008-03.html#7 perhaps. Yes, absolutely. I've seen this before and I think it probably helped get me thinking along these lines. I think it doesn't quite go far enough, but something that combines these ideas with what has already happened regarding CSW and drawing methods moves things a good bit of the way. I also find it interesting that in some sense, Wayland is just another scene graph, but at a different level (able to eat X Window in a single bite-kind-of-level). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.21.6
On Wed, Aug 18, 2010 at 12:44 PM, Matthias Clasen matthias.cla...@gmail.com wrote: I don't see how that follows. All that is happening in 2.22 is that some things are getting deprecated. You can still use them. We are not going to take them away from you during 2.x i wasn't really worried about the deprecations. replacing the implementation of all internal drawing methods is OK to do in a stable branch? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.21.6
On 08/18/10 12:50, Paul Davis wrote: On Wed, Aug 18, 2010 at 12:44 PM, Matthias Clasen matthias.cla...@gmail.com wrote: I don't see how that follows. All that is happening in 2.22 is that some things are getting deprecated. You can still use them. We are not going to take them away from you during 2.x i wasn't really worried about the deprecations. replacing the implementation of all internal drawing methods is OK to do in a stable branch? From what I understand reading the thread, that's your wrong impression. The rendering-cleanup branch is NOT being merged into 2.22. Just that some new functions where added, and some old ones marked deprecated. You are imagining things that are simply not true. behdad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.21.6
Hi, On Wed, Aug 18, 2010 at 1:12 PM, Paul Davis p...@linuxaudiosystems.com wrote: On Wed, Aug 18, 2010 at 12:57 PM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: On 08/18/10 12:50, Paul Davis wrote: On Wed, Aug 18, 2010 at 12:44 PM, Matthias Clasen matthias.cla...@gmail.com wrote: I don't see how that follows. All that is happening in 2.22 is that some things are getting deprecated. You can still use them. We are not going to take them away from you during 2.x i wasn't really worried about the deprecations. replacing the implementation of all internal drawing methods is OK to do in a stable branch? From what I understand reading the thread, that's your wrong impression. The rendering-cleanup branch is NOT being merged into 2.22. Just that some new functions where added, and some old ones marked deprecated. You are imagining things that are simply not true. the announcement declared: Overview of Changes from GTK+ 2.21.5 to 2.21.6 == * Most drawing done by GTK+ itself has been ported from GDK drawing APIs to cairo did I interpret that incorrectly? After looking at the git log, you interpret correctly, but I fail to see why do you perceive this as being bad. So, some GDK API is marked as deprecated, it seems fair to me that Gtk+ maintainers ensure the deprecated API is not used in gtk+ itself anymore. It is also a good test that you are not deprecating something that can't be deprecated (i.e. there is no equivalent functionality in cairo). Please observe that many of the deprecated API (maybe all?) were already using cairo internally, so, as it has been already pointed out, you probably don't need to worry that much. Of course if gtk-2.22 DOES eventually broke something for you, then you should raise your voice high and complain ;) Greets José ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Gobject Introspection] GIRepository.gir seems incorrect
On 08/18/2010 07:32 PM, Mildred Ki'Lya wrote: Hi, I'm trying to use the GIRepository library in order to access GI information and create a compile time binding for the Lisaac language. I don't like C very much, and I'm going to use Vala. But the vala compiler complains that it can't find the type filename. GObject introspection use a filename string type to mark strings that represent file names, because those are not utf8 strings, rather bytestrings with exceptions. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.21.6
On Wed, Aug 18, 2010 at 2:01 PM, Jose Aliste jose.ali...@gmail.com wrote: After looking at the git log, you interpret correctly, but I fail to see why do you perceive this as being bad. So, some GDK API is marked as deprecated, it seems fair to me that Gtk+ maintainers ensure the deprecated API is not used in gtk+ itself anymore. It is also a good test that you are not deprecating something that can't be deprecated (i.e. there is no equivalent functionality in cairo). i think you missed my point. this is not about the deprecations. its about the fact that 2.22 will contain a complete reimplemenation of the GDK draw routines. this is happening in a branch this is supposedly stable. i don't understand how this can reconciled. no API is changed in order for this to happen, but the implementations are all new. existing programs will compile and run, but if linked against 2.22 they will be testing an implementation that was (i thought) aimed at the 3.0 release line. surely this stuff that should be in 2.90 ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: cairo drawing commands to gdk_invalidate_region
The problem of deciding what areas to expose are imho opinion too hard for the motion handler to deal with. E.g. if the rubberband is e.g. of an ellipse outline then you need quite a bit of mathematics to figure out what areas to expose. You can of course expose the entire bounding box, but that is very expensive for a large areas if it needs to be done several times a second. The idea of painting a low res mask takes care of it. Regarding the draw() routine, as you can see in the actual code, I do pass a boolean flag that indicates whether it is the low res mask that should be drawn or the actual drawing. This can be used to avoid drawing gradients and other expensive drawing operations during mask creation. In any case, thanks for your input. Dov On Wed, Aug 18, 2010 at 14:47, Paul Davis p...@linuxaudiosystems.comwrote: On Tue, Aug 17, 2010 at 4:22 PM, Dov Grobgeld dov.grobg...@gmail.com wrote: The solution won't work if the default expose-event handler returns TRUE. I would still like to resolve the issues that Paul has with my description of the code. Paul, why don't you like the fact that I call draw() twice? that's overstating it a little bit. what i was taking issue with is that *unless* draw() has some way to be able to tell that it is being called from an expose event handler (and that would presumably have to be some global variable, since nothing is passed to it as an argument), it is by definition doing the wrong thing *if* it is responsible for all the rendering that occurs in the expose handler. why? because that would imply that it actually renders in both the pre-expose call and the expose-event call, but you should only be rendering (to the window at list) in the expose event call. you asked: How is update() supposed to know what region to invalidate? in your original description, you showed the flow as: # motion event calls update() # update() calls draw() in order to get regions to expose. # update() calls gdk_invalidate_region() based on output from draw # exposure-event callback calls draw() to carry out the drawing for each region so you have logic that knows what regions are affected by the motion event (the above description makes it sound as if that logic is inside draw()). update should have that logic so that it can call gdk_invalidate_region(), and then the expose-event call to draw() should use the event region list to redraw. if your code works, that's fine. i'm just trying to describe to you what i *think* is the right way to do this so that its portable to all backends of GTK and is following the overall drawing model embedded in GTK. --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.21.6
On Wed, Aug 18, 2010 at 4:15 PM, Paul Davis p...@linuxaudiosystems.com wrote: On Wed, Aug 18, 2010 at 2:01 PM, Jose Aliste jose.ali...@gmail.com wrote: After looking at the git log, you interpret correctly, but I fail to see why do you perceive this as being bad. So, some GDK API is marked as deprecated, it seems fair to me that Gtk+ maintainers ensure the deprecated API is not used in gtk+ itself anymore. It is also a good test that you are not deprecating something that can't be deprecated (i.e. there is no equivalent functionality in cairo). i think you missed my point. this is not about the deprecations. its about the fact that 2.22 will contain a complete reimplemenation of the GDK draw routines. this is happening in a branch this is supposedly stable. i don't understand how this can reconciled. no API is changed in order for this to happen, but the implementations are all new. existing programs will compile and run, but if linked against 2.22 they will be testing an implementation that was (i thought) aimed at the 3.0 release line. surely this stuff that should be in 2.90 ? aha, now I understand and I believe you are missing something here. AFAIK, the Gdk draw functions are NOT being reimplemented. The only thing that has happened (if I understand correctly after reading some of the commits in git) is that the Gtk+ methods that before used the deprecated GDK API now use the cairo API instead. Greetings José ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Memory fonts in pangocairo
Hello! I was wandering if there is a way to use fonts placed in memory with the pangocairo API in Linux. I've tried to implement my own PangoCairoFontMap but it seems that the API was not written with extension in mind (for example I need the structures defined in pangocairo-private.h). I'm very new to the GObject/Pango system so maybe there is another option to force pangocairo to use fonts loaded in memory. I want to use FT_New_Memory_Face to load the fonts and then create a fontset that contains the FT_Face objects. Saving the font on the disk and then using FcConfigAppFontAddFile is not an option. Thanks, Andrei. ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Makefile for GTK2 programs?
What CFLAGS and LIBS I should use in Makefiles? I installed GTK2 to home directory, and thus I won't use lddconfig. My programs should take all from ~/gtk2/, and nothing from /usr/include/gtk-1.2/ and nothing gtk-related from /usr/lib/. GTK2 does not have gtk-config program. It made things easier in gtk1.2: CC=gcc -O2 -Wall CFLAGS = `gtk-config --cflags` LIBS= `gtk-config --libs` -lm -ljpeg -lpng Is there away to get all CFLAGS and LIBS by checking the pkgconfig file? ~/gtk2/lib/pkgconfig/gtk+-2.0.pc I have now the following in Makefile. Very messy. It does not work; I get errors: undefined reference to `gtk_text_view_new' and the like. CC=gcc -O2 -Wall CFLAGS= -I/home/juhana/gtk2/include/glib-2.0 -I/home/juhana/gtk2/include/gtk-2.0 -I/home/juhana/gtk2/lib/glib-2.0/include -I/home/juhana/gtk2/include/cairo -I/home/juhana/gtk2/include/pango-1.0 -I/home/juhana/gtk2/lib/gtk-2.0/include -I/home/juhana/gtk2/include/atk-1.0 LIBS= -L/home/juhana/gtk2/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -ljpeg -lpng O_ESPBROWSER=mylib/filesdirs.o mylib/buffer.o mylib/image.o mylib/gsl_taus.o mylib/clock.o mylib/mmapfile.o mylib/sprint.o mylib/arrays.o espbrowser.o all:: espbrowser espbrowser: $(O_ESPBROWSER) $(CC) $(CFLAGS) -o espbrowser $(O_ESPBROWSER) $(LIBS) I use this include command in the C code: #include /home/juhana/gtk2/include/gtk-2.0/gtk/gtk.h I'm afraid it won't help because gtk.h uses #include gdk/gdk.h which may be /usr/include/gtk-1.2/gdk/gdk.h. How the linked ld works? My programs are simple. Perhaps I could write a script to compile and link everything explicitly. But this include file business worries me still. This is so frustating. I will return to GTK 1.2 soon. First Ubuntu failed to install GTK2, and now this! I could start writing my programs under demos/gtk-demo/ and compile the demo. But then I don't understand how to add my mylib/mmapfile.o etc. files to the configure system. :-( Help needed. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Makefile for GTK2 programs?
Le mercredi 18 août 2010 à 10:26 +0300, Juhana Sadeharju a écrit : What CFLAGS and LIBS I should use in Makefiles? I installed GTK2 to home directory, and thus I won't use lddconfig. My programs should take all from ~/gtk2/, and nothing from /usr/include/gtk-1.2/ and nothing gtk-related from /usr/lib/. GTK2 does not have gtk-config program. It made things easier in gtk1.2: CC=gcc -O2 -Wall CFLAGS = `gtk-config --cflags` LIBS= `gtk-config --libs` -lm -ljpeg -lpng Is there away to get all CFLAGS and LIBS by checking the pkgconfig file? ~/gtk2/lib/pkgconfig/gtk+-2.0.pc CFLAGS=`PKG_CONFIG_PATH=~/gtk2/lib/pkgconfig:$PKG_CONFIG_PATH pkg-config --cflags gtk+-2.0` LIBS=`PKG_CONFIG_PATH=~/gtk2/lib/pkgconfig:$PKG_CONFIG_PATH pkg-config --libs gtk+-2.0` (you might have to replace ~ by the real path) hope this helps, regards, Jean I have now the following in Makefile. Very messy. It does not work; I get errors: undefined reference to `gtk_text_view_new' and the like. CC=gcc -O2 -Wall CFLAGS= -I/home/juhana/gtk2/include/glib-2.0 -I/home/juhana/gtk2/include/gtk-2.0 -I/home/juhana/gtk2/lib/glib-2.0/include -I/home/juhana/gtk2/include/cairo -I/home/juhana/gtk2/include/pango-1.0 -I/home/juhana/gtk2/lib/gtk-2.0/include -I/home/juhana/gtk2/include/atk-1.0 LIBS= -L/home/juhana/gtk2/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -ljpeg -lpng O_ESPBROWSER=mylib/filesdirs.o mylib/buffer.o mylib/image.o mylib/gsl_taus.o mylib/clock.o mylib/mmapfile.o mylib/sprint.o mylib/arrays.o espbrowser.o all:: espbrowser espbrowser: $(O_ESPBROWSER) $(CC) $(CFLAGS) -o espbrowser $(O_ESPBROWSER) $(LIBS) I use this include command in the C code: #include /home/juhana/gtk2/include/gtk-2.0/gtk/gtk.h I'm afraid it won't help because gtk.h uses #include gdk/gdk.h which may be /usr/include/gtk-1.2/gdk/gdk.h. How the linked ld works? My programs are simple. Perhaps I could write a script to compile and link everything explicitly. But this include file business worries me still. This is so frustating. I will return to GTK 1.2 soon. First Ubuntu failed to install GTK2, and now this! I could start writing my programs under demos/gtk-demo/ and compile the demo. But then I don't understand how to add my mylib/mmapfile.o etc. files to the configure system. :-( Help needed. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Makefile for GTK2 programs?
On Wed, 18 Aug 2010 10:26:45 +0300 Juhana Sadeharju kou...@nic.funet.fi wrote: This is so frustating. I will return to GTK 1.2 soon. First Ubuntu failed to install GTK2, and now this! If you are using ubuntu it will already have gtk2 installed, as it depends on it. No distribution has used gtk+-1.2 as the basis of its desktop environment for about 8 to 10 years. You probably just need to install the ubuntu development package containing the gtk2 headers. Chris ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Makefile for GTK2 programs?
On Wed, Aug 18, 2010 at 10:26:45AM +0300, Juhana Sadeharju wrote: I have now the following in Makefile. Very messy. It does not work; I get errors: undefined reference to `gtk_text_view_new' and the like. When does the error happen? If it is at run time, you may want to add -Wl,-R/home/juhana/gtk2/lib to LIBS... Cheers, Patrick ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Re: Makefile for GTK2 programs?
On Aug 18, 2010 1:57am, Chris Vine ch...@cvine.freeserve.co.uk wrote: You probably just need to install the ubuntu development package containing the gtk2 headers. apt-get install libgtk2.0-dev? And maybe libglib2.0-dev? ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ 2.21.6
On Mon, Aug 16, 2010 at 8:48 PM, Matthias Clasen mcla...@redhat.com wrote:
GTK+ 2.21.6 is now available for download at:
is this really a correct description of 2.21:
Overview of Changes from GTK+ 2.21.5 to 2.21.6
==
* Most drawing done by GTK+ itself has been ported from
GDK drawing APIs to cairo
[ ]
* Deprecations:
- GtkNotebookPage
- The GtkRecenManager::limit property
- All GDK drawing functions, ie gdk_draw_*. Use cairo instead
- All GdkGC functions. Use cairo instead
- All of GdkImage. Use cairo instead
- All of GdkRGB. Use cairo instead
- gdk_{bit,pix}map_create_from_data
[ ... ]
* New cairo-related APIs:
- gdk_window_create_similar_surface
- gdk_window_get_background_pattern
I though that this work was mostly in the 2.9/3.0 branch ?
--p
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ 2.21.6
On Wed, 2010-08-18 at 11:52 -0400, Paul Davis wrote:
On Mon, Aug 16, 2010 at 8:48 PM, Matthias Clasen mcla...@redhat.com wrote:
GTK+ 2.21.6 is now available for download at:
is this really a correct description of 2.21:
Overview of Changes from GTK+ 2.21.5 to 2.21.6
==
* Most drawing done by GTK+ itself has been ported from
GDK drawing APIs to cairo
[ ]
* Deprecations:
- GtkNotebookPage
- The GtkRecenManager::limit property
- All GDK drawing functions, ie gdk_draw_*. Use cairo instead
- All GdkGC functions. Use cairo instead
- All of GdkImage. Use cairo instead
- All of GdkRGB. Use cairo instead
- gdk_{bit,pix}map_create_from_data
[ ... ]
* New cairo-related APIs:
- gdk_window_create_similar_surface
- gdk_window_get_background_pattern
I though that this work was mostly in the 2.9/3.0 branch ?
The old methods still need to be marked as deprecated and replacements
available in 2.x to ease GTK+ 3.x porting, otherwise you're left having
to port everything before you can test it out.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ 2.21.6
On Wed, Aug 18, 2010 at 12:04 PM, Bastien Nocera had...@hadess.net wrote: On Wed, 2010-08-18 at 11:52 -0400, Paul Davis wrote: On Mon, Aug 16, 2010 at 8:48 PM, Matthias Clasen mcla...@redhat.com wrote: GTK+ 2.21.6 is now available for download at: is this really a correct description of 2.21: Overview of Changes from GTK+ 2.21.5 to 2.21.6 == * Most drawing done by GTK+ itself has been ported from GDK drawing APIs to cairo [ ] I though that this work was mostly in the 2.9/3.0 branch ? The old methods still need to be marked as deprecated and replacements available in 2.x to ease GTK+ 3.x porting, otherwise you're left having to port everything before you can test it out. i wasn't aware that the drawing switch was planned for 2.22. this now makes this branch barely 2.X at all, from our perspective. it fundamentally makes it a completely new implementation of GDK, within a supposedly stable branch of GTK. this is quite problematic, i think. i was under the impression that 2.22 was going to be the last release of 2.X, not a preview of what 3.0 would contain. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ 2.21.6
On Wed, 2010-08-18 at 12:14 -0400, Paul Davis wrote: On Wed, Aug 18, 2010 at 12:04 PM, Bastien Nocera had...@hadess.net wrote: On Wed, 2010-08-18 at 11:52 -0400, Paul Davis wrote: On Mon, Aug 16, 2010 at 8:48 PM, Matthias Clasen mcla...@redhat.com wrote: GTK+ 2.21.6 is now available for download at: is this really a correct description of 2.21: Overview of Changes from GTK+ 2.21.5 to 2.21.6 == * Most drawing done by GTK+ itself has been ported from GDK drawing APIs to cairo [ ] I though that this work was mostly in the 2.9/3.0 branch ? The old methods still need to be marked as deprecated and replacements available in 2.x to ease GTK+ 3.x porting, otherwise you're left having to port everything before you can test it out. i wasn't aware that the drawing switch was planned for 2.22. this now makes this branch barely 2.X at all, from our perspective. it fundamentally makes it a completely new implementation of GDK, within a supposedly stable branch of GTK. this is quite problematic, i think. i was under the impression that 2.22 was going to be the last release of 2.X, not a preview of what 3.0 would contain. New functionality is available in both when it makes sense to do so, and deprecated functionality is marked as much. You shouldn't see any difference in usage if you don't use the new functionality. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ 2.21.6
On Wed, Aug 18, 2010 at 12:21 PM, Bastien Nocera had...@hadess.net wrote: New functionality is available in both when it makes sense to do so, and deprecated functionality is marked as much. You shouldn't see any difference in usage if you don't use the new functionality. We distribute a version of GTK as part of our product for OS X. We had selected 2.22 as the branch to follow for this, on an apparently faulty understanding that 2.22 was a relatively stable branch at this point. Replacing every gdk_draw_* method doesn't qualify for relatively stable in my opinion. We now have to drop our tracking of 2.22 entirely and simply sit at the current (arbitrary) revision that we currently use for the build. Frustrating. We went through this earlier (at about 2.14), when we had to stop tracking releases because of the breakage being caused to non-X11 backends by changes to various parts fo the system. I guess we just do the same again. It only affects a handful of developers but it also pretty much blocks anyone from ever being able to easily build our GPL'ed app on OS X for themselves because there will never be a release version of GTK that corresponds to what is required. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ 2.21.6
On Wed, Aug 18, 2010 at 12:27 PM, Paul Davis p...@linuxaudiosystems.com wrote: On Wed, Aug 18, 2010 at 12:21 PM, Bastien Nocera had...@hadess.net wrote: New functionality is available in both when it makes sense to do so, and deprecated functionality is marked as much. You shouldn't see any difference in usage if you don't use the new functionality. We distribute a version of GTK as part of our product for OS X. We had selected 2.22 as the branch to follow for this, on an apparently faulty understanding that 2.22 was a relatively stable branch at this point. Replacing every gdk_draw_* method doesn't qualify for relatively stable in my opinion. We now have to drop our tracking of 2.22 entirely and simply sit at the current (arbitrary) revision that we currently use for the build. Frustrating. I don't see how that follows. All that is happening in 2.22 is that some things are getting deprecated. You can still use them. We are not going to take them away from you during 2.x ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ 2.21.6
On Wed, Aug 18, 2010 at 12:44 PM, Matthias Clasen matthias.cla...@gmail.com wrote: I don't see how that follows. All that is happening in 2.22 is that some things are getting deprecated. You can still use them. We are not going to take them away from you during 2.x i wasn't really worried about the deprecations. replacing the implementation of all internal drawing methods is OK to do in a stable branch? ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ 2.21.6
On 08/18/10 12:50, Paul Davis wrote: On Wed, Aug 18, 2010 at 12:44 PM, Matthias Clasen matthias.cla...@gmail.com wrote: I don't see how that follows. All that is happening in 2.22 is that some things are getting deprecated. You can still use them. We are not going to take them away from you during 2.x i wasn't really worried about the deprecations. replacing the implementation of all internal drawing methods is OK to do in a stable branch? From what I understand reading the thread, that's your wrong impression. The rendering-cleanup branch is NOT being merged into 2.22. Just that some new functions where added, and some old ones marked deprecated. You are imagining things that are simply not true. behdad ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ 2.21.6
On Wed, Aug 18, 2010 at 12:57 PM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: On 08/18/10 12:50, Paul Davis wrote: On Wed, Aug 18, 2010 at 12:44 PM, Matthias Clasen matthias.cla...@gmail.com wrote: I don't see how that follows. All that is happening in 2.22 is that some things are getting deprecated. You can still use them. We are not going to take them away from you during 2.x i wasn't really worried about the deprecations. replacing the implementation of all internal drawing methods is OK to do in a stable branch? From what I understand reading the thread, that's your wrong impression. The rendering-cleanup branch is NOT being merged into 2.22. Just that some new functions where added, and some old ones marked deprecated. You are imagining things that are simply not true. the announcement declared: Overview of Changes from GTK+ 2.21.5 to 2.21.6 == * Most drawing done by GTK+ itself has been ported from GDK drawing APIs to cairo did I interpret that incorrectly? ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Installing GTK Binary Packages Into MINGW on MS Windows Using Wascana and Eclipse
Hello, I would like to use mingw to port and compile a simple GTK application under MS Windows. The download page for windows located at: http://www.gtk.org/download-windows.html recommends the mingw tool chain and contains tables of relevant packages as well as dependencies. I have downloaded the various required packages and dependencies marked 'Dev' on that page. What is unclear from any installation instructions I have been able to find is where and how to install these packages into mingw. Do I simply decompress the archives in the mingw directory hierarchy so that the files end up in the respective directories there? *or* Do I need to make separate hierarchies for each of the zip files and point GCC at the 'lib' and 'header' directories using '-L -l' and '-I -i' flags respectively? Thanks Peter ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ 2.21.6
On Wed, Aug 18, 2010 at 2:01 PM, Jose Aliste jose.ali...@gmail.com wrote: After looking at the git log, you interpret correctly, but I fail to see why do you perceive this as being bad. So, some GDK API is marked as deprecated, it seems fair to me that Gtk+ maintainers ensure the deprecated API is not used in gtk+ itself anymore. It is also a good test that you are not deprecating something that can't be deprecated (i.e. there is no equivalent functionality in cairo). i think you missed my point. this is not about the deprecations. its about the fact that 2.22 will contain a complete reimplemenation of the GDK draw routines. this is happening in a branch this is supposedly stable. i don't understand how this can reconciled. no API is changed in order for this to happen, but the implementations are all new. existing programs will compile and run, but if linked against 2.22 they will be testing an implementation that was (i thought) aimed at the 3.0 release line. surely this stuff that should be in 2.90 ? ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Installing GTK Binary Packages Into MINGW on MS Windows Using Wascana and Eclipse
On Wed, Aug 18, 2010 at 8:07 PM, Peter Willis pwil...@aslenv.com wrote: Hello, I would like to use mingw to port and compile a simple GTK application under MS Windows. The download page for windows located at: http://www.gtk.org/download-windows.html recommends the mingw tool chain and contains tables of relevant packages as well as dependencies. I have downloaded the various required packages and dependencies marked 'Dev' on that page. What is unclear from any installation instructions I have been able to find is where and how to install these packages into mingw. Do I simply decompress the archives in the mingw directory hierarchy so that the files end up in the respective directories there? *or* Do I need to make separate hierarchies for each of the zip files and point GCC at the 'lib' and 'header' directories using '-L -l' and '-I -i' flags respectively? I've used GTK and glib with mingw for many years now, and I've always put mingw in c:\mingw and all the gtk stuff in c:\gtk. This works perfectly, and I usually also add some simple unix-ish tools such that I can mimic a unix system at a dos prompt. To make all include and linking simple I usually have a makefile that contains these lines: INCLUDE = -I/C/GTK/include $(shell pkg-config --cflags gtk+-2.0) LIBS = $(shell pkg-config --libs gtk+-2.0) ... or somthing similar depending on what I need. I would not recommend to put GTK and MinGW in the same directories! -Øystein ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
