Re: Signal handling questions
Great! I just had to block myself when calling the other expose handler as
follows:
:
g_signal_handler_block(widget, selfp->expose_handler_id);
int retval;
g_signal_emit_by_name (widget, "expose-event", event, &retval);
g_signal_handler_unblock(widget, selfp->expose_handler_id);
:
// cairo drawing follows
This way there is no need to deal with a generic "event" handler.
Thanks!
Dov
On Tue, Aug 17, 2010 at 09:08, Tristan Van Berkom wrote:
> A nice way to do it would be to subclass your widget and chain up to
> the parent expose
> method where needed.
>
> if you need to draw generically on widgets, it wont work for all
> widgets (some widgets
> can have floating subwindows)... but you can be bold and connect to
> the "event" signal
> and do something like:
>
> if (event_type == GDK_EXPOSE)
> {
>g_signal_emit_by_name (widget, "expose-event", event, &retval);
>do_my_overlay_drawing (widget);
>
>return TRUE;
> }
> else
> return FALSE;
>
> On Tue, Aug 17, 2010 at 1:51 AM, Dov Grobgeld
> wrote:
> > While playing around with a general system for doing polygon overlays
> (e.g.
> > for rectangle or line selection) I got stuck on the following problem.
> >
> > Assume that I have a widget A that has an expose handler exp_A().
> >
> > Now assume that I would temporarily like to draw an "overlay on A" from
> the
> > code in expose handler exp_B(). I.e. after exp_A() has finished its work,
> > exp_B() should be called.
> >
> > I am in control of exp_B() but cannot touch exp_A().
> >
> > I trigger the calling of expose events by calling
> > gdk_window_invalidate_rect() from update_B().
> >
> > The problem is as follows:
> >
> > If I do g_signal_connect_after(widget, "expose-event", exp_B, me) then I
> set
> > up the correct order of exposure through A and B, but if exp_A() does
> > "return TRUE", then exp_B() will not be called.
> > If I do g_signal_connect(widget, "expose-event", exp_B, me) then exp_B()
> > will always be called, but in the wrong order.
> >
> > So how is can this be solved?
> >
> > If I do g_signal_connect(), can exp_B() e.g. block itself as a signal
> > handler and rethrow() the signal to the other handlers and then return?
> How
> > is this done?
> >
> > Thanks!
> > Dov
> >
> >
> >
> >
> > ___
> > 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: gtk_widget_draw()
On Mon, 2010-08-16 at 21:36 -0400, Allin Cottrell wrote: > On Mon, 16 Aug 2010, Alexander Larsson wrote: > > > - "Benjamin Otte" wrote: > > > > > > Here's an email detailing my thought process for what I want to do > > > with rendering in the master branch following the rendering-cleanup > > > merge. It's mostly a brain dump, so treat it as such. > > > > So, I read this thread and thought about it a bit (not a lot though, > > obviously this whole thing needs a lot of careful thought). Its a > > complex area, and while I share your enthusiasm for many of the > > changes I think in some places it might oversimplify things. > > > > Anyway, lets start on a positive side with things where we are wildly > > in agreement. > > > > Getting rid of GdkPixmap seems like a good think. Its not used a lot > > in the current rendering-cleanup branch... > > Wait a minute: "Not used a lot"(!) App developers are in limbo > here. Not so long ago we were told that if our apps compiled OK > with all the appropriate DISABLE_DEPRECATED flags with the latest > stable versions of the libraries (GTK and friends) we'd be fine > for GTK+ 3. There will be a new gtk 2.x release with all the stuff being removed in gtk3 being deprecated, and it will have any required new functions added, like gdk_window_create_similar_surface() which can be used to create offscreen cairo surfaces to be used as GdkPixmap replacement. > Then Benjamin came along with phase 1 of his GDK cleanup and that > seemed sensible, though not without problems for app developers. > I've now "cleaned up" my app so that it does not use GdkGC if GTK > is new enough. But my replacement code for GdkGC uses GdkPixmap -- > and now we can't have that either?! Switching from GdkPixmap to using a cairo x surface is not a large change though. Its mainly in how you construct it. The actual use of it is almost all the same. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a fiendish coffee-fuelled shaman haunted by an iconic dead American confidante She's an elegant mute cab driver descended from a line of powerful witches. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
cairo drawing commands to gdk_invalidate_region
Assume I have a routine: int draw(cairo_t *cr) used to draw an overlay in a GdkWindow. In order to minimize redrawing, I would like to get the minimal (up to some accuracy to be determined) set of GdkRegion's that encompasses all the drawing of draw(). I thought of doing this by creating a low resolution cairo image surface that I pass to draw() and check if pixels are "dirty" in which case it indicates that the corresponding rectangle in the source GdkWindow needs to redrawn. Is there a better method? Thanks! Dov ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
rendering-cleanup worries
I don't have very much time to work on the rendering-cleanup stuff, but I do look at it now and then. This change caught my eye today: http://git.gnome.org/browse/gtk +/commit/?h=rendering-cleanup&id=eb6e2bddc86746bd90f617489d1c423c17c1959b It may seem correct and easier, and in most cases it will work. But things like that were added for a reason. In this case it is to make things like notification icon work, where there the parent of the window we paint in is a foreign window (the tray) so we don't know what background it has set. Using a native X clear function means we'll get this right anyway. Without this change all systray icons get a black background. In general I'm a bit worried about the rendering cleanup branch wrt non-obvious issues like this. After doing the "simple" part of the csw work I spent many months chasing minute issues like this to make the full desktop with all its apps work with csw. I fear that we will not be able to do this with gtk3, because there are not enough apps to expose all the corner case issues we might hit before we release, and by then we're frozen and may be unable to fix some issue. Note, I'm not fundamentally against the cleanups, in fact I like them. I'm just worried that they will cause unforseen problems down the line unless we can really get it fully battle tested (i.e. not only demos and tests) before being frozen. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a deeply religious guitar-strumming werewolf for the 21st century. She's a strong-willed renegade advertising executive looking for love in all the wrong places. They fight crime! ___ 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, 2010-08-17 at 10:35 +0300, Dov Grobgeld wrote: > Assume I have a routine: > > int draw(cairo_t *cr) > > used to draw an overlay in a GdkWindow. > > In order to minimize redrawing, I would like to get the minimal (up to > some accuracy to be determined) set of GdkRegion's that encompasses > all the drawing of draw(). > > I thought of doing this by creating a low resolution cairo image > surface that I pass to draw() and check if pixels are "dirty" in which > case it indicates that the corresponding rectangle in the source > GdkWindow needs to redrawn. > > Is there a better method? Just call gdk_cairo_region (cr, event->region); cairo_clip (cr); right after creating the context, and after that, draw as if you didn't need to care about the dirty regions at all. The clipping will take care of the rest. This assumes that you only draw as a response to your expose-event handler, of course. Claudio -- Claudio Saavedra ___ 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
Thanks, but this is not what I am looking for. Here is a description of my flow, which might e.g. be used to draw a rubber band box: 1. motion event calls update() 2. update() calls draw() in order to get regions to expose. 3. update() calls gdk_invalidate_region() based on output from draw 4. exposure-event callback calls draw() to carry out the drawing for each region I.e. draw() is called twice with different purposes. (That's part of the beauty of the generic cairo_t structure). The first call in 2 should be used to determine where we are drawing. The second call in 4 is used to do the drawing. update() holds a list of rectangle corresponding to the old draw() and the new draw() and expose both of these. (The exposure of the old commands are needed to restore the background). Your example indeed shows how to carry out the drawing as response of a exposure-event (point 4 above), but doesn't answer my question of what regions to invalidate (point 2-3). Meanwhile I already have working code in which the user chooses what regions to expose, but I would like to make it automatic to make this unnecessary. Note that I assume that exposing the entire widget for each motion event is too slow. Dov On Tue, Aug 17, 2010 at 11:14, Claudio Saavedra wrote: > On Tue, 2010-08-17 at 10:35 +0300, Dov Grobgeld wrote: > > Assume I have a routine: > > > > int draw(cairo_t *cr) > > > > used to draw an overlay in a GdkWindow. > > > > In order to minimize redrawing, I would like to get the minimal (up to > > some accuracy to be determined) set of GdkRegion's that encompasses > > all the drawing of draw(). > > > > I thought of doing this by creating a low resolution cairo image > > surface that I pass to draw() and check if pixels are "dirty" in which > > case it indicates that the corresponding rectangle in the source > > GdkWindow needs to redrawn. > > > > Is there a better method? > > Just call > > gdk_cairo_region (cr, event->region); > cairo_clip (cr); > > right after creating the context, and after that, draw as if you didn't > need to care about the dirty regions at all. The clipping will take care > of the rest. This assumes that you only draw as a response to your > expose-event handler, of course. > > Claudio > > > -- > Claudio Saavedra > > ___ > 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: cairo drawing commands to gdk_invalidate_region
On Tue, Aug 17, 2010 at 4:39 AM, Dov Grobgeld wrote: > Thanks, but this is not what I am looking for. > > Here is a description of my flow, which might e.g. be used to draw a rubber > band box: based on an IRC exchange about this a couple of days ago, the answer is two-fold: 1) you assume that cairo_clip() was called with ev->region before draw() is invokved 2) you call something like cairo_clip_rectangle_lists() to get the list of rects that need to be redrawn there have been some suggestions that one should ignore this and just redraw everything and let cairo clipping deal with it, but i think this is clearly wrong when the drawing is computationally expensive. --p ___ 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
Sorry, I still don't get it. In my scenario there is initially is no
external request of a region that should be drawn. The only source of what
should be drawn, including what areas should be exposed, are in the draw()
routine. The challenge is to translate a set of drawing routines to a set of
invalidation areas.
In any case I solved it as follows:
- Generate a low resolution ARGB32 image surface
- Call the draw() routine (which receives the information whether it is
in mask mode)
- Convert all "dirty" pixels into rectangle tiles.
- Invalidate the lits of tiles.
I hope to post the entire code on github in the next few days.
// Call drawing_cb to and use it to generate the rectangle list
DovtkLassoRectangleList *rect_list = NULL;
int scale_factor = 32;
int low_res_width =
(selfp->widget->allocation.width+scale_factor-1) / scale_factor;
int low_res_height =
(selfp->widget->allocation.height+scale_factor-1) / scale_factor;
int i;
// This should be created in the creation of DovtkLasso
cairo_t *cr = NULL;
cairo_surface_t *surf = NULL;
if (selfp->do_calc_expose_from_cairo) {
surf=cairo_image_surface_create(CAIRO_FORMAT_ARGB32,
low_res_width,
low_res_height);
cr = cairo_create(surf);
cairo_set_source_rgba(cr,0,0,0,0);
cairo_rectangle(cr, 0,0,low_res_height,low_res_width);
cairo_fill(cr);
cairo_set_source_rgba(cr,0,0,0,1);
}
cairo_scale(cr,1.0/scale_factor,1.0/scale_factor);
selfp->drawing_cb(cr, TRUE, &rect_list);
// Turn surf into a list of rectangles
if (selfp->do_calc_expose_from_cairo) {
int row_idx, col_idx;
// Allocate worse case space
rect_list =
dovtk_lasso_rectangle_list_new(low_res_width*low_res_height);
guint8 *buf = cairo_image_surface_get_data(surf);
int rect_idx = 0;
int row_stride = cairo_image_surface_get_stride(surf);
for (row_idx=0; row_idx 0) {
cairo_rectangle_t *rect =
&rect_list->rectangles[rect_idx++];
rect->x = col_idx*scale_factor;
rect->y = row_idx*scale_factor;
rect->width = scale_factor;
rect->height = scale_factor;
}
}
}
rect_list->num_rectangles = rect_idx;
cairo_destroy(cr);
cairo_surface_destroy(surf);
}
//printf("num_rectangles = %d\n", rect_list->num_rectangles);
// Build a list of expose rectangles from the old and the new lists.
// Better done as a linked list.
DovtkLassoRectangleList *expose_rect_list
= dovtk_lasso_rectangle_list_new(selfp->old_rect_list->num_rectangles
+ rect_list->num_rectangles);
int num_old_rects = selfp->old_rect_list->num_rectangles;
for (i=0; irectangles[i] = selfp->old_rect_list->rectangles[i];
for (i=0; inum_rectangles; i++)
expose_rect_list->rectangles[num_old_rects + i] =
rect_list->rectangles[i];
// Expose the old and the new list of rectangles!
for (i=0; inum_rectangles; i++) {
// Shortcut
cairo_rectangle_t *lasso_rect = &expose_rect_list->rectangles[i];
GdkRectangle rect;
rect.x = lasso_rect->x;
rect.y = lasso_rect->y;
rect.width = lasso_rect->width;
rect.height = lasso_rect->height;
#if 0
printf("Invalidate region (%d,%d,%d,%d).\n",
rect.x,rect.y,rect.width,rect.height);
#endif
gdk_window_invalidate_rect(selfp->widget->window,
&rect,
TRUE);
}
On Tue, Aug 17, 2010 at 15:42, Paul Davis wrote:
> On Tue, Aug 17, 2010 at 4:39 AM, Dov Grobgeld
> wrote:
> > Thanks, but this is not what I am looking for.
> >
> > Here is a description of my flow, which might e.g. be used to draw a
> rubber
> > band box:
>
>
> based on an IRC exchange about this a couple of days ago, the answer
> is two-fold:
>
> 1) you assume that cairo_clip() was called with ev->region before
> draw() is invokved
> 2) you call something like cairo_clip_rectangle_lists() to get the
> list of rects that need to be redrawn
>
> there have been some suggestions that one should ignore this and just
> redraw everything and let cairo clipping deal with it, but i think
> this is clearly wrong when the drawing is computationally expensive.
>
> --p
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Signal handling questions
For the record, I was mistaken. It does not work to use "expose-event"
handler for the temporary handle. If the "permanent" expose-event handle
returns TRUE, the temporary expose-event handler is never called. This
surprised me as I thought that a later call to g_signal_connect() takes
precedence over an earlier call. I will try using a "generic" handler and
will see if it works better.
On Tue, Aug 17, 2010 at 10:04, Dov Grobgeld wrote:
> Great! I just had to block myself when calling the other expose handler as
> follows:
>
> :
> g_signal_handler_block(widget, selfp->expose_handler_id);
> int retval;
>
> g_signal_emit_by_name (widget, "expose-event", event, &retval);
> g_signal_handler_unblock(widget, selfp->expose_handler_id);
> :
> // cairo drawing follows
>
> This way there is no need to deal with a generic "event" handler.
>
> Thanks!
> Dov
>
>
> On Tue, Aug 17, 2010 at 09:08, Tristan Van Berkom wrote:
>
>> A nice way to do it would be to subclass your widget and chain up to
>> the parent expose
>> method where needed.
>>
>> if you need to draw generically on widgets, it wont work for all
>> widgets (some widgets
>> can have floating subwindows)... but you can be bold and connect to
>> the "event" signal
>> and do something like:
>>
>> if (event_type == GDK_EXPOSE)
>> {
>>g_signal_emit_by_name (widget, "expose-event", event, &retval);
>>do_my_overlay_drawing (widget);
>>
>>return TRUE;
>> }
>> else
>> return FALSE;
>>
>> On Tue, Aug 17, 2010 at 1:51 AM, Dov Grobgeld
>> wrote:
>> > While playing around with a general system for doing polygon overlays
>> (e.g.
>> > for rectangle or line selection) I got stuck on the following problem.
>> >
>> > Assume that I have a widget A that has an expose handler exp_A().
>> >
>> > Now assume that I would temporarily like to draw an "overlay on A" from
>> the
>> > code in expose handler exp_B(). I.e. after exp_A() has finished its
>> work,
>> > exp_B() should be called.
>> >
>> > I am in control of exp_B() but cannot touch exp_A().
>> >
>> > I trigger the calling of expose events by calling
>> > gdk_window_invalidate_rect() from update_B().
>> >
>> > The problem is as follows:
>> >
>> > If I do g_signal_connect_after(widget, "expose-event", exp_B, me) then I
>> set
>> > up the correct order of exposure through A and B, but if exp_A() does
>> > "return TRUE", then exp_B() will not be called.
>> > If I do g_signal_connect(widget, "expose-event", exp_B, me) then exp_B()
>> > will always be called, but in the wrong order.
>> >
>> > So how is can this be solved?
>> >
>> > If I do g_signal_connect(), can exp_B() e.g. block itself as a signal
>> > handler and rethrow() the signal to the other handlers and then return?
>> How
>> > is this done?
>> >
>> > Thanks!
>> > Dov
>> >
>> >
>> >
>> >
>> > ___
>> > 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: Query on Multiple row selection in a GtkTreeView
Dear Tadej, Thanks a lot for your response. Using your trick I could resolve the multi selection issue. But I am now stuck with another problem. In my implementation, GtkTreeView is multicolumner. The multi selection is working fine when I click on the first column, but when I click on other columns it's acting like a singly selectable treeview. I am using Gtk version 2.0, which is a quite older one. Can you please tell me whether it's an issue of older Gtk version or with my implementation. Thanks, Debapriya On Fri, Jul 16, 2010 at 7:58 PM, Tadej Borovšak wrote: > Hi. > > I think that returning TRUE from your button-press-event handler > should fix this. > > Tadej > > -- > Tadej Borovšak > tadeboro.blogspot.com > tadeb...@gmail.com > tadej.borov...@gmail.com > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkToolBar Button size issue in RHEL4 and RHEL5
Hi, I've created a window containing a toolbar with 6 toolbarbuttons using GTK ver2.0. When I run this in RHEL4, all the toolbar buttons are visiblein the toolbar. But when i Run it in RHEL5, the last 2 toolbar buttons become hidden. By expanding the toolbar the buttons can be visible. This is happening just because the toolbar button size gets increased automatically in RHEL5. Is there any way by which the button size can be made same in both RHEL4 and RHEL5 ? Is it a problem with GTK version I am using? Looking forward for your help. Thanks and regards, Debapriya ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GVolumeMonitor and Nautilus with mount --bind
I have been investigating a bug in nautilus that occurs when mounting folders with the --bind option. This bug is described in https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/452049 Yesterday I have had some time to go through the nautilus source that takes care of adding the volumes and mount points to the nautilus places sidebar (nautilus-places-sidebar.c). I believe that the wrong behaviour is not caused by nautilus itself, but instead by glib (or GIO). For mounts with the --bind option Glib creates a GVolume repesenting the bind, but not a GMount for the mount point. Nautilus then treats the mount point as not mounted, and when clicking on it an error occours that it can not be mounted. I have filed bug 625552 which describes this problem. Since I have managed to track the bug so far I would like to investigate it further, but I need some additional information: * Am I right with my assumptions that this is a bug in glib? Or am I wrong and this can be fixed in nautilus? * Can anyone suggestion where to look in the glib to find more about the mounting and volume detection process? Particularly g_volume_monitor_get_volumes() * Finally: What kind of mounts would cause glib to return a GVolume without a corresponding GDrive and GMount? Best Regards Sebastian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup
At Thu, 22 Jul 2010 10:24:05 +0100, Emmanuele Bassi wrote: > > > Also, I'm aware that we are very close to a release. I'd understand if > > that'd make people not want to merge it. But I think it's worth it and > > the impact is very small compared to the other changes in Gtk3. > > I tend to agree, though we really need app developers to look at this. > fpeters has been kind enough to generate usage reports in the platform: > > http://people.gnome.org/~fpeters/reports/gdkdraw.html > http://people.gnome.org/~fpeters/reports/gdkgc.html > http://people.gnome.org/~fpeters/reports/gdkimage.html > > and we should try to get them to the green all over at least the desktop > suite. # I can't access gnome.org at this moment for some network problem. so # I haven't checked the above pages. I'm for one wandering how to port my application to gtk+ 3.0. My problem is that the current gdk pixbuf nor cairo does not have a client side pixel buffer other than RGB888 or RGBA. I have been happily using GdkImage, which can support RGB565, but now GdkImage seems to be a candidate for removal for Gtk+ 3.0. I've checked Benjamin's blog[1], but it seems like his page is not touching non-24/32bit client side buffer issue. [1]:http://blogs.gnome.org/otte/2010/07/27/rendering-cleanup/ RGB565 does not seem to be a popular format for a desktop anymore, but it is still used in embedded platform. so, I'd love to see a good RGB565 support in Gtk+. so, what should I do to port a RGB565 application to new platform? Thanks in advance, -- yashi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib 2.24.2 released
--- On Sun, 8/8/10, Ryan Lortie wrote: > From: Ryan Lortie > Subject: GLib 2.24.2 released > To: gnome-announce-l...@gnome.org, gtk-devel-list@gnome.org, > gtk-app-devel-l...@gnome.org, gtk-l...@gnome.org > Date: Sunday, August 8, 2010, 12:12 PM > Glib 2.24.2 is out: > > http://download.gnome.org/sources/glib/2.24/ > > 3aeb521abd3642dd1224379f0e54915957e5010f888a4ae74afa0ad54da0160c > glib-2.24.2.tar.bz2 > a6874b847d99618edb4bf86732ce00357711529a2592ded17e246063ad9f3374 > glib-2.24.2.tar.gz > > This is a small bugfix release. Its primary purpose > is to get the > long-since-fixed data corruption issue in > GConverterOutputStream into a > packaged release. > > There is also a workaround for the long-standing race > condition in > gtester that sometimes causes 'make check' to hang. > > Some other small fixes and translation updates are > included. > > I avoided more extensive backporting of fixes because the > nature of the > master branch of glib has been quite hectic lately and > because a 2.26.0 > release of glib will be out within a month or so anyway. > > > Overview of Changes from GLib 2.24.1 to GLib 2.24.2 > === > > * Bugs fixed: > 578295 gtester has a race condition > 619945 GConverterOutputStream triggers assertion and > corrupts data > 621168 GKeyFile memory leak on Windows platform > 616216 glib compile from remote directory fails > > * Translation updates: > Estonian > French > Galician > Indonesian > Italian > Latvian > Romanian > Spanish > > Thanks to all who contributed: > Christian Dywan > Jürg Billeter > Tor Lillqvist > Matthias Clasen > > > August 8, 2010 > Ryan Lortie > Sorry to disappoint you, but 'make check' is still stuck here: 2701 PASS: run-bookmark-test.sh and there is 0 CPU load. Regards, Sergei. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Website proposal for usability
WOW. Well done. I really the new design. Separating out the permenant information in a side box from the on going information makes it really nice. Great to see the amount of testing you did on different platforms as well!. -Ghee P.S. Though I am not sure if this is the mailing list to post suggestion of changes for website. I hope the relevant person will get in touch with you. On 08/ 9/10 10:54 PM, Devin Samarin wrote: I posted this on Bugzilla (https://bugzilla.gnome.org/show_bug.cgi?id=626380) and I was recommended by Martyn to post the details here. I was browsing around gtk.org and I thought that it could use some adjustments. So I downloaded the web files with git and made some changes. I attached some screenshots and example file on Bugzilla (the design changed a little since then), but if my computer is up, you can see it at http://eboyjr.homelinux.org:8080/gtk/ . I made the width of the content area wider and added either columns or a sidebar for pages that needed it. Having columns makes it easier to read by making it so that you don't have to scroll for everything. For styling, I added some rounded corners with CSS for some of the elements. For all of the pages, I made the HTML more semantic by removing replacing some of the with 's. I changed the color of the headers to the shade of blue. For the features page, I separated each section into blocks and added some pictures to spice it up. For the commerce (success stories) page, I did the same thing so that it is easier to read, and looks nicer. I made a template.php file which has the outer content of the HTML pages, so as a consequence, the pages' extension is changed from .html to .php. I think it's better so that for some changes, you wont need to edit every single page of the site. So with this design, some external links might need to be updated unless PHP can be run with the .html extension. Since it uses PHP, I made it easy to update changes to the tables. Specifically the language bindings page. There is a PHP array that stores all the information about the bindings and then formats it into a table automatically. I attached that file so you can see it. I have tested it so far in: * Internet Explorer 6, 7,& 8 Everything works except the rounded corners, except for the header which is a single image so that works. Personally I don't think rounded corners are necessary, but if you think I should hack them in I'll do it * Firefox 2 Everything is messed up. This is because I am using HTML5 elements... I made the CSS not specific to tag names, so changing to would make it work fine. This also means that in IE, JavaScript must be enabled. I thought I'd try something new but HTML5 just causes pains. So I'll change them tos. * Firefox 2 and 3 on Windows and Firefox 3 on Linux * Safari 3 and 4 on Mac * Google Chrome 3 and 5(beta) on Windows The design is not complete and still requires changes to be compatible with all browsers, but once it's done I really think it would make gtk.org much more usable. I am open to any suggestions. Devin Samarin ___ 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: gtk_widget_draw()
On Thu, 2010-08-12 at 20:48 +0200, Benjamin Otte wrote: > > > EOG uses this to good effect, for example - scaling an image is > > expensive, so it only scales the areas that absolutely need to be > > repainted. > > > Cairo does that automatically. On the GPU, too. So I suppose EOG > doesn't yet upload the pixbuf to a native cairo surface and uses that > for rendering? Just FYI, I have been playing a bit with this, in order to replace current's eog code for handling with the scaling/rendering and rely completely on cairo; but it is clearly noticeably that this becomes really slow when the image is over certain dimensions, say 4096×4096. In any other case, performance is *really* great. The patches are in bug https://bugzilla.gnome.org/show_bug.cgi?id=626795 , if you care to see. Claudio ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_draw()
On Mon, Aug 16, 2010 at 11:23 PM, Alexander Larsson wrote: > [...] > > Just doing this is a great cleanup and simplification of gdk and the > backends, which is clearly a good step towards further work. > Great. This is what I've been hacking on in the rendering-cleanup branch (yes, you cannot make it die, even by merging it) since it was merged last time. I do not inted to touch any GdkWindow internals in that branch until it's merged again. The branch right now focusses on getting rid of GdkPixmap and providing suitable replacements. More on that in a separate mail though. > However, the next step, getting rid of the wrappers/impls and > restructuring the window class hierarchy is not really right > imho. Having impls be a separate object type is quite nice for CSW, it > models pretty well the situation where GdkWindow are the client side > things, and GdkWindowImpls are the native part that GdkWindows draw > in, etc. It also matches the dynamic status of "nativeness". I.e. a > window can get a native window when needed rather than having to do > this upfront. If nativeness was encoded in the typesystem things like > that just wouldn't work. > The biggest problem for me when reading the GdkWindow code is that I have no idea what a window is. So I have a hard time understanding the code and if what it does is sane. - Does a GdkWindow mirror a window provided by the windowing system? Obviously no, because offscreen windows do not own a windowing system window and csw windows do grab onto the native parent's window. So the relationship between GdkWindows and X Windows is 1:N (where N can be 0). - Does a GdkWindow have a matching Cairo surface? Well, kinda, but csw windows share the surface with of the native window, so when drawing to it, we need to clip before we draw. - Is a GdkWindow an implementation detail or available in the public API? Again, it depends. If you have a GdkWindowImplFoo, it's private, otherwise it's public. Can I even call the same (internal or public) functions on these two types of windows? - Does a GdkWindow describe a window hierarchy? Again, kinda. Mostly you can restack and reparent windows fine, but stuffing a toplevel into an offscreen window does not work at all. - What's a GdkWindowType? When I restack a TOPLEVEL into a CHILD, will it change type? Should it? - Who's responsible for what? Who decides when to repaint a window? Is it the same for offscreen windows? Who creates damage events? - Can windows be translucent? Should they be? - Is a GdkWindow the only way to get enter/leave events to widgets? Do widget authors know these thing? - What do we do with event masks? I learned yesterday that widgets without EXPOSURE_MASK don't get their background cleared. Is that documented? Or should that even be the case? Do we even need event masks? - Shoud every widget have its own window now that we have lightweight client-side windows? Or should almost no widget have a window because we can synthethically create all the events widgets need? Do we have a list for widget authors somewhere for when they want to create their own window? Note that I don't describe the current state of things in GTK2, I can look that up in the code if I have to. I'm more interested in how things should be. > Similarly a problem is encoding things like toplevel/subwindowness in > the typesystem (i.e. GdkSubwindow or GdkToplevel). A subwindow is a > subwindow purely based on where its in the hierarchy, which is easily > changed with gdk_window_reparent. This means windows can go from > toplevels and back at runtime. > But there are operations that do not make sense at all on a non-toplevel window. Like setting the icon or the title. And I'd argue that it's confusing for widget implementors that they need to think about this stuff when creating a window for their widget. For offscreen windows, a lot more of the window operations don't make sense. > This part of things has been very concrete stuff, now we get to the > more abstract parts about rendering using cairo only. First of all I > must say your description is kinda handwavy in the details. For > instance, its not at all obvious how multi-window widgets are supposed > to render themselves, or how the window hierarchy is traversed while > rendering. > I think in retrospect, that that is mostly related to the question outlined above about what a GdkWindow is and what it does. It's hard to be concrete if you have no idea about the underlying design. ;) > Secondly, while I think your description of a no-exposes cairo_t-only > rendering system sounds very nice I fear that it is to simple to > handle everything a full featured toolkit will meet in > practice. People will want to put all kinds of weird stuff inside a Gtk > window, including things like: OpenGL rendered stuff, Xv magic, > socket/plug X embedding, embedding things like a flash plugin or old > motif plugins in a browser, etc. There is just no way you can take > things like these and put them
Re: cairo drawing commands to gdk_invalidate_region
On Tue, Aug 17, 2010 at 9:11 AM, Dov Grobgeld wrote: > Sorry, I still don't get it. In my scenario there is initially is no > external request of a region that should be drawn. The only source of what > should be drawn, including what areas should be exposed, are in the draw() > routine. The challenge is to translate a set of drawing routines to a set of > invalidation areas. This is how you described it: >Here is a description of my flow, which might e.g. be used to draw a rubber >band box: > > 1. motion event calls update() > 2. update() calls draw() in order to get regions to expose. > 3. update() calls gdk_invalidate_region() based on output from draw > 4. exposure-event callback calls draw() to carry out the drawing for each > region this is wrong. update() should just call gdk_invalidate_region(). this will cause expose to be invoked with the region passed in. the way you've described it above, your draw() method does two entirely separate tasks. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 2.90.6
GTK+ 2.90.6 is now available for download at:
ftp://ftp.gtk.org/pub/gtk/2.90/
http://download.gnome.org/sources/gtk+/2.90/
31d5afda85fe0d9b4dbfdc265fed2f07cd0ed214bc2055310816f471e2f762dc gtk
+-2.90.6.tar.bz2
231cda8623f478101bf4a8397f312aed16c4a3e8efa41f82b8570760c0a13e46 gtk
+-2.90.6.tar.gz
This is the a development release leading toward 3.0.
Notes:
* GTK+ 3 will be parallel installable with GTK+ 2.x, and
this release has been prepared to test this by renaming
all .pc files, libraries, include paths, and so forth,
to include a '3.0' component.
* GTK+ 3 will remove deprecated API from the GTK+ 2.x series
and make struct members unavailable that have been GSEALed
in 2.x. Therefore, applications can be prepared for porting
to GTK+ 3 by making sure that they build with
-DGTK_DISABLE_DEPRECATED
and -DGSEAL_ENABLE.
* Bugs should be reported to http://bugzilla.gnome.org.
What is GTK+
GTK+ is a multi-platform toolkit for creating graphical user
interfaces. Offering a complete set of widgets, GTK+ is suitable for
projects ranging from small one-off tools to complete application
suites.
GTK+ has been designed from the ground up to support a range of
languages, not only C/C++. Using GTK+ from languages such as Perl and
Python (especially in combination with the Glade GUI builder) provides
an effective method of rapid application development.
GTK+ is free software and part of the GNU Project. However, the
licensing terms for GTK+, the GNU LGPL, allow it to be used by all
developers, including those developing proprietary software, without
any license fees or royalties.
Where to get more information about GTK+
Information about GTK+ including links to documentation can be
found at:
http://www.gtk.org/
An installation guide for GTK+ 2.x is found at:
http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html
Common questions:
http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html
http://www.gtk.org/faq/
Contributing
GTK+ is a large project and relies on voluntary contributions.
We are actively searching for new contributors in various areas
and invite everyone to help project development.
If you are willing to participate, please subscribe to the project
mailing lists to offer your help and read over our list of vacant
project tasks:
http://live.gnome.org/GtkTasks
Overview of Changes from GTK+ 2.90.5 to 2.90.6
==
* All drawing done by GTK+ itself has been ported from
GDK drawing APIs to cairo
* GtkExpander and GtkFrame now implement GtkSizeRequest
* GtkExpander gained a ::label-fill property to make the label
fill the entire horizontal space
* Allow windows to be dragged by clicking on empty
areas in menubars and toolbars
* GtkAboutDialog can now refer to licenses using a ::license-type
enumeration instead of embedding the license text
* Deprecations and cleanups:
- Remove GtkNotebookPage
- Remove public struct members in many classes
- Remove the GtkRecentManager::limit property
- Remove all GDK drawing functions, ie gdk_draw_*. Use cairo instead
- Remove all GdkGC functions. Use cairo instead
- Remove all of GdkImage. Use cairo instead
- Remove all of GdkRGB. Use cairo instead
- Remove gdk_{bit,pix}map_create_from_data
- GDK no longer depends on the render X extension
* New accessors:
- gdk_cursor_get_cursor_type
- gdk_device_get_n_axes
- gdk_display_is_closed
- gtk_notebook_get_tab_[hv]border
* New cairo-related APIs:
- gdk_window_create_similar_surface
- gdk_window_get_background_pattern
* Bugs fixed:
90935 GtkIMContextClass inheritance ...
97414 gtkaccellabel: s/seperator/separator/
336225 Support for common licenses in about dialog
554926 gtk_init_with_args: not setting translation domain...
557263 Notebooks return 1 selection even if they have no pages
579583 GtkStatusIcon's scroll-event documentation missing "Since: ..."
580291 Gail does not work with custom treemodels
596125 Property string fixes
604391 Gtk-CRITICAL when switching between tab
605190 Should delete the description of xim related options...
609264 gtk_(tree/list)_store_set documentation unclear about ownership
611313 Window dragging from menubars/toolbars
612919 crash in System Monitor: I was moving up-down wit...
614049 Allow packing options for GtkExpander label widgets
614443 Doxygen 'forgets' #define documentation under certain conditions
615474 gtk_widget_set_has_window() documentation is not correct
618327 GtkNotebookPage should be deprecated
621571 Fix damage events on offscreen windows
622658 GTK_STOCK_FILE Stock Label
623603 meld built with pygtk-2.16.0 giving warnings
623865 gtkdnd: pointer grab may never finish (ungrab before grab)
624087 Missing accessor for GdkCursor.type
624224 Missing accessor for GdkDisplay.closed
624270 crash in gtk_entry_completion_default_completion_func
624333 Deprecate G
Re: GVolumeMonitor and Nautilus with mount --bind
Hi, On Fri, Jul 30, 2010 at 2:22 AM, Sebastian Geiger wrote: > I have filed bug 625552 I've asked for some more information in that bug. > which describes this problem. Since I have managed > to track the bug so far I would like to investigate it further, but I need > some additional information: > > * Am I right with my assumptions that this is a bug in glib? Or am I wrong > and this can be fixed in nautilus? Bug is most likely not in Nautilus - Nautilus is just a user of the GVolumeMonitor APIs as is the GTK+ file chooser and other apps. The bug is likely in GVfs's GVolumeMonitor implementation - see http://git.gnome.org/browse/gvfs/tree/monitor/gdu for the code. The correct solution is probably to completely ignore bind mounts in the UI. But please provide the information requested in the bug and we can take it from there. David ___ 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
How is update() supposed to know what region to invalidate? By a list of GdkRegions as a parameters? The dual functionality of draw is just a way of automizing this. Dov On Tue, Aug 17, 2010 at 18:50, Paul Davis wrote: > On Tue, Aug 17, 2010 at 9:11 AM, Dov Grobgeld > wrote: > > Sorry, I still don't get it. In my scenario there is initially is no > > external request of a region that should be drawn. The only source of > what > > should be drawn, including what areas should be exposed, are in the > draw() > > routine. The challenge is to translate a set of drawing routines to a set > of > > invalidation areas. > > This is how you described it: > > >Here is a description of my flow, which might e.g. be used to draw a > rubber band box: > > > > 1. motion event calls update() > > 2. update() calls draw() in order to get regions to expose. > > 3. update() calls gdk_invalidate_region() based on output from draw > > 4. exposure-event callback calls draw() to carry out the drawing for > each region > > this is wrong. update() should just call gdk_invalidate_region(). this > will cause expose to be invoked with the region passed in. > the way you've described it above, your draw() method does two > entirely separate tasks. > ___ 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 17:28 +0200, Benjamin Otte wrote: > On Mon, Aug 16, 2010 at 11:23 PM, Alexander Larsson wrote: > > [...] > > > > However, the next step, getting rid of the wrappers/impls and > > restructuring the window class hierarchy is not really right > > imho. Having impls be a separate object type is quite nice for CSW, it > > models pretty well the situation where GdkWindow are the client side > > things, and GdkWindowImpls are the native part that GdkWindows draw > > in, etc. It also matches the dynamic status of "nativeness". I.e. a > > window can get a native window when needed rather than having to do > > this upfront. If nativeness was encoded in the typesystem things like > > that just wouldn't work. > > > The biggest problem for me when reading the GdkWindow code is that I > have no idea what a window is. So I have a hard time understanding the > code and if what it does is sane. Yeah, this is simultaneously very simple and very hard to explain. The simple version is "its behaves like if there was a X window there, except some minor changes". Of course, the hard version includes having to read the full Xlib specification and knowing all the minor historic ways that gdk arbitrarily differs from the X behavior. Clearly this is not a great setup. I definitely would not propose something like this were we to start over with a new toolkit. However, its what we have, and even minor changes to the semantics (like tiny event ordering issues or minute grab event property differences) cause weird and very hard to track down bugs. I know, I had to track them all down... Additionally, while GdkWindows are complex and underdocumented they are not really something that most users of Gtk+ ever touch, which limits the problem. > - Does a GdkWindow mirror a window provided by the windowing system? > Obviously no, because offscreen windows do not own a windowing system > window and csw windows do grab onto the native parent's window. So the > relationship between GdkWindows and X Windows is 1:N (where N can be > 0). > - Does a GdkWindow have a matching Cairo surface? Well, kinda, but csw > windows share the surface with of the native window, so when drawing > to it, we need to clip before we draw. This is one of the major deficiencies with csw actually. I requested sub-surface support in cairo multiple times and got positive feedback, but it just hasn't happened yet. Ideally we should use that so that we can avoid hacks like gdk_cairo_reset_clip(). > - Is a GdkWindow an implementation detail or available in the public > API? Again, it depends. If you have a GdkWindowImplFoo, it's private, > otherwise it's public. Can I even call the same (internal or public) > functions on these two types of windows? All GdkWindows visible to external parties are public API. The impls are internal stuff that behave in somewhat weird ways, but again, this is not something normal people see. > - Does a GdkWindow describe a window hierarchy? Again, kinda. Mostly > you can restack and reparent windows fine, but stuffing a toplevel > into an offscreen window does not work at all. With offscreen windows its more like a forest than a tree, with the limit that no window with a native window can be a child of an offscreen. > - What's a GdkWindowType? When I restack a TOPLEVEL into a CHILD, will > it change type? Should it? I think it does now, at least if CHILD goes to TOPLEVEL. I dunno what the perfect behaviour would be. In a GdkToplevel world such a reparent operation would have to just fail. But what if the reparenting happens anyway? For instance when the parent GtkSocket X window dies and your GtkPlug becomes a toplevel? > - Who's responsible for what? Who decides when to repaint a window? Is > it the same for offscreen windows? Who creates damage events? > - Can windows be translucent? Should they be? Right now they are typically not, but you can enable the optional composite feature to make them translucent. This is sort of a hack that was added to do some features that can now be done with offscreen widget embedding. > - Is a GdkWindow the only way to get enter/leave events to widgets? Do > widget authors know these thing? GdkWindows are the main source of events, without them you never get any events. The features that windows give are: * Something you can render on and display * Invalid region tracking (internal and from the window system) * Implicit clipping based on the "environment" of the window * Easy scrolling of window hierarchies * Event generation > - What do we do with event masks? I learned yesterday that widgets > without EXPOSURE_MASK don't get their background cleared. Is that > documented? Or should that even be the case? Do we even need event > masks? They should get the background of the GdkWindow cleared, but of course there will be no expose event so any widget-specific background will not be drawn. > - Shoud every widget have its own window now that we have lightweight > cl
Re: gtk_widget_draw()
On Tue, 2010-08-17 at 17:28 +0200, Benjamin Otte wrote:
> The biggest problem for me when reading the GdkWindow code is that I
> have no idea what a window is. So I have a hard time understanding the
> code and if what it does is sane.
One pattern we see a lot is when widgets want to paint themselves on
their parent container's background, but still receive events. They are
NO_WINDOW widgets, which means "I want to share my parent's window", and
then they also create INPUT_ONLY windows to catch events.
This is a very useful pattern. Such widgets are basically saying:
- "Just give me a nicely-prepared surface to draw on" (i.e. with the
parent's contents already drawn)
- "And let me catch events, too".
The funny thing is that not only "non-square" widgets like labels do
this; buttons also do this for aesthetic purposes.
I think it seems sane to move to a model where
1. The only native windows (with an XID) are toplevels, with a few
exceptions (see below),
2. All subwindows are all GDK-side abstractions. They define a clipping
region and a coordinate system. See below for transparency issues.
3. The exception is when you need a native window to do funky stuff
(OpenGL, plug/socket, xv, etc.). These (sub)windows are understood to
be limited - you may not be able to transform them and such.
The interesting part is (2), or what happens with subwindows.
Non-square widgets that want to paint to their parent's background would
still benefit from having a "transparent" window to paint on - this
would give you an already-prepared surface (with whatever the parent
painted), a clipping region and a coordinate system. That is, GtkLabel
wouldn't have to clip the text itself and add allocation->{x,y} all the
time.
Square widgets that completely cover their area are of course trivial to
implement in that model - they would just overwrite their parent's
contents with their own. I don't know if we want to be able to avoid
painting the parent's regions that we *know* will be completely
obscured. Think of a white text area over a gradient window background
- drawing that gradient may be expensive and so you certainly want to
paint only the areas that will *not* be the white text area... or maybe
not, if you can just ask the GPU to draw the whole gradient.
Do we need a "window->need_parent_background" flag? I.e. the "paint the
parent first, don't clip to the subwindow" flag?
I don't think these "transparent windows" should store any contents at
all to composite them later. GDK doesn't store window contents, and
starting to do that sounds painful. Keep subwindows just as an
abstraction for clipping/coordinates/initial-background.
With the model above, the repaint cycle looks pretty much like the
current one - you paint recursively, and you just set the clip region
(or not) based on a subwindow's "need_parent_background" flag.
> - Does a GdkWindow describe a window hierarchy? Again, kinda. Mostly
> you can restack and reparent windows fine, but stuffing a toplevel
> into an offscreen window does not work at all.
> - What's a GdkWindowType? When I restack a TOPLEVEL into a CHILD, will
> it change type? Should it?
This is the core of Alex's argument for keeping the impls separate, I
think. GdkWindow exposes a public API (with a few leaks such as
gimme_the_native_window_id()); the internal impls switch in and out as
you reparent things.
Who uses reparenting, anyway?
Restacking our abstracted subwindows should be trivial; you just repaint
them in order.
> - Can windows be translucent? Should they be?
See above.
> - Is a GdkWindow the only way to get enter/leave events to widgets? Do
> widget authors know these thing?
If they don't know offhand, they learn pretty fast :) Basically, having
a window is the *only* way to get events. Whether you do it with an
InputOutput or an InputOnly window depends on each particular widget.
> - What do we do with event masks? I learned yesterday that widgets
> without EXPOSURE_MASK don't get their background cleared. Is that
> documented? Or should that even be the case? Do we even need event
> masks?
Clearing the background or not depends on the hypothetical
"is-this-window-transparent" flag that we discussed above.
Event masks are an X-ism, I think... I really don't know if they matter
much with local connections (except maybe to save context switches);
they may definitely help in remote connections. Something tells me that
Owen will know more about this from when he was profiling GTK+'s X
stream.
> - Shoud every widget have its own window now that we have lightweight
> client-side windows? Or should almost no widget have a window because
> we can synthethically create all the events widgets need? Do we have a
> list for widget authors somewhere for when they want to create their
> own window?
If we move to the model I described above, then it should be pretty
clear that all widgets can have windows (for convenience) and yet be
able to draw themselves as the
Re: cairo drawing commands to gdk_invalidate_region
On Tue, 2010-08-17 at 10:35 +0300, Dov Grobgeld wrote: > Assume I have a routine: > > int draw(cairo_t *cr) > > used to draw an overlay in a GdkWindow. > > In order to minimize redrawing, I would like to get the minimal (up to > some accuracy to be determined) set of GdkRegion's that encompasses > all the drawing of draw(). You may have a different case, but let me tell you about a cute trick I had to do for iogrind [1]. One of iogrind's displays is essentially a point-cloud on which you move a crosshair with the mouse: +-+ | . . | . .. . . .| | . . . |.. . . . .| |-+---| |.. .. . |... . . . | | . . |. . .. .. | +-+ The crosshair spans the whole width and height of the widget. Drawing the points is expensive, as there may be thousands of them. With each mouse motion event, you must repaint the crosshair. My solution went like this: 1. The widget keeps a GdkPixmap where it draws the point-cloud at startup. The points don't move (thankfully), so that pixmap is basically read-only after initialization. 2. My motion-notify handler does this: invalidate_vertical_line (w->cursor_x); invalidate_horizontal_line (w->cursor_y); w->cursor_x = event->x; w->cursor_y = event->y; invalidate_vertical_line (w->cursor_x); invalidate_horizontal_line (w->cursor_y); 3. My expose handler does this: bitblt (w->pixmap_with_points, widget->window); paint_vertical_line (w->cursor_x); paint_horizontal_line (w->cursor_y); So, repaints are very fast as I can avoid regenerating the points; I basically just paint the crosshair and that's it. If your drawing can be done with mostly-static contents and an occasional rubberband rectangle, this is a good way to do it. [1] http://live.gnome.org/iogrind Federico ___ 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 13:43 -0500, Federico Mena Quintero wrote:
> On Tue, 2010-08-17 at 17:28 +0200, Benjamin Otte wrote:
> > The biggest problem for me when reading the GdkWindow code is that I
> > have no idea what a window is. So I have a hard time understanding the
> > code and if what it does is sane.
>
> One pattern we see a lot is when widgets want to paint themselves on
> their parent container's background, but still receive events. They are
> NO_WINDOW widgets, which means "I want to share my parent's window", and
> then they also create INPUT_ONLY windows to catch events.
>
> This is a very useful pattern. Such widgets are basically saying:
>
> - "Just give me a nicely-prepared surface to draw on" (i.e. with the
> parent's contents already drawn)
>
> - "And let me catch events, too".
>
> The funny thing is that not only "non-square" widgets like labels do
> this; buttons also do this for aesthetic purposes.
Yeah, they do it to avoid the window resize being asynchronous with
respect to the repainting, etc, causing ugly looking resizes.
> I think it seems sane to move to a model where
>
> 1. The only native windows (with an XID) are toplevels, with a few
> exceptions (see below),
>
> 2. All subwindows are all GDK-side abstractions. They define a clipping
> region and a coordinate system. See below for transparency issues.
>
> 3. The exception is when you need a native window to do funky stuff
> (OpenGL, plug/socket, xv, etc.). These (sub)windows are understood to
> be limited - you may not be able to transform them and such.
This is exactly the current model with client side windows.
> The interesting part is (2), or what happens with subwindows.
>
> Non-square widgets that want to paint to their parent's background would
> still benefit from having a "transparent" window to paint on - this
> would give you an already-prepared surface (with whatever the parent
> painted), a clipping region and a coordinate system. That is, GtkLabel
> wouldn't have to clip the text itself and add allocation->{x,y} all the
> time.
Yes. I've long thought about having something like this. Then we could
just drop no-window widgets. This might make widget rendering a bit more
regular as there is at least a simple relationship between a window and
a widget (each window belongs to a single widget, one widget may have
multiple windows).
This is very similar to input-only window really. Its kinda inbetween.
Input only windows only do the events, transparent windows do the
rendering and clipping, but render the parent first without clipping to
the transparent childs (like it doesn't clip to input-only children).
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.
> Square widgets that completely cover their area are of course trivial to
> implement in that model - they would just overwrite their parent's
> contents with their own. I don't know if we want to be able to avoid
> painting the parent's regions that we *know* will be completely
> obscured. Think of a white text area over a gradient window background
> - drawing that gradient may be expensive and so you certainly want to
> paint only the areas that will *not* be the white text area... or maybe
> not, if you can just ask the GPU to draw the whole gradient.
Well, the white text area would just not be transparent and then the
drawing in the parent would be clipped to the child just like now.
Also, for the current no-window widget this is what we do already
anyway.
> Do we need a "window->need_parent_background" flag? I.e. the "paint the
> parent first, don't clip to the subwindow" flag?
Not sure what you mean. We need a single flag "is this window
transparent". If it is that means:
1) It does not add to its parents clip-region
2) When redrawing it we must draw all parents and lower stacked siblings
before drawing it.
> This is the core of Alex's argument for keeping the impls separate, I
> think. GdkWindow exposes a public API (with a few leaks such as
> gimme_the_native_window_id()); the internal impls switch in and out as
> you reparent things.
>
> Who uses reparenting, anyway?
Dnd of toolbars items, detachable docks, putting plugs in sockets, etc.
> > - What do we do with event masks? I learned yesterday that widgets
> > without EXPOSURE_MASK don't get their background cleared. Is that
> > documented? Or should that even be the case? Do we even need event
> > masks?
>
> Clearing the background or not depends on the hypothetical
> "is-this-window-transparent" flag that we discussed above.
>
> Event masks are an X-ism, I think... I really don't know if they matter
Re: cairo drawing commands to gdk_invalidate_region
I uploaded my solution that I gave the working name dovtk-lasso to github at: http://github.com/dov/dovtk-lasso On the one hand it works beautifully as it allows drawing dynamic overlays with cairo with very little overhead. On the other hand it still has some problems: - 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? Have a look at the png file at github to see an example of a caliper like measuring tool that I made with dovtk-lasso. Again, the graphics is arbitrary, and could just as well be a rectangle, a cross hair, or whatever the user feels like. Looking forward to comments. Regards, Dov On Tue, Aug 17, 2010 at 22:03, Federico Mena Quintero wrote: > On Tue, 2010-08-17 at 10:35 +0300, Dov Grobgeld wrote: > > Assume I have a routine: > > > > int draw(cairo_t *cr) > > > > used to draw an overlay in a GdkWindow. > > > > In order to minimize redrawing, I would like to get the minimal (up to > > some accuracy to be determined) set of GdkRegion's that encompasses > > all the drawing of draw(). > > You may have a different case, but let me tell you about a cute trick I > had to do for iogrind [1]. > > One of iogrind's displays is essentially a point-cloud on which you move > a crosshair with the mouse: > > +-+ > | . . | . .. . . .| > | . . . |.. . . . .| > |-+---| > |.. .. . |... . . . | > | . . |. . .. .. | > +-+ > > The crosshair spans the whole width and height of the widget. Drawing > the points is expensive, as there may be thousands of them. With each > mouse motion event, you must repaint the crosshair. > > My solution went like this: > > 1. The widget keeps a GdkPixmap where it draws the point-cloud at > startup. The points don't move (thankfully), so that pixmap is > basically read-only after initialization. > > 2. My motion-notify handler does this: > >invalidate_vertical_line (w->cursor_x); >invalidate_horizontal_line (w->cursor_y); >w->cursor_x = event->x; >w->cursor_y = event->y; >invalidate_vertical_line (w->cursor_x); >invalidate_horizontal_line (w->cursor_y); > > 3. My expose handler does this: > > bitblt (w->pixmap_with_points, widget->window); > paint_vertical_line (w->cursor_x); > paint_horizontal_line (w->cursor_y); > > So, repaints are very fast as I can avoid regenerating the points; I > basically just paint the crosshair and that's it. > > If your drawing can be done with mostly-static contents and an > occasional rubberband rectangle, this is a good way to do it. > > [1] http://live.gnome.org/iogrind > > Federico > > > ___ 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 21:10 +0200, Alexander Larsson wrote: [Widgets with an InputOnly window for events] > Yeah, they do it to avoid the window resize being asynchronous with > respect to the repainting, etc, causing ugly looking resizes. Oh, I thought they did it to get the parent's background. So there are multiple reasons to do this :) > This is exactly the current model with client side windows. Perfect, so we are on the same page and I just need to re-understand the current state of GDK :) > 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...) > > Do we need a "window->need_parent_background" flag? I.e. the "paint the > > parent first, don't clip to the subwindow" flag? > > Not sure what you mean. We need a single flag "is this window > transparent". If it is that means: > 1) It does not add to its parents clip-region > 2) When redrawing it we must draw all parents and lower stacked siblings > before drawing it. Yes, that's exactly what I mean :) A single flag that does exactly that. > > 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. [Anyway, this was about the impls being separate - if we keep reparenting, then impls may need to stay... no idea.] > 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... So, apart from the general pending cleanup, are we just lacking the "don't clip" flag discussed above for transparent windows? Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Minutes of the GTK+ Team Meeting - 2010-08-17
• rendering cleanup - four parts: + removal of GC, Image, etc. [done] + removal of Pixmap. [in progress] + re-org of GdkWindow. [still in discussion] + expose-event → draw. - general consensus: good to have - some tricky bits still need to be defined & discussed - deprecations will require a new 2.24 release in parallel with 3.0 for application developers • releases and dates - glib 2.26 and gtk+ 2.22 for GNOME 2.32 (Sep '10) - glib 2.28, gtk+ 2.24 and gtk+ 3.0 for December '10 • gapplication - refactoring of the API - 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 • gtk_init - move all arguments to environment variables - hide it under GtkApplication • soname - gtk 2.90 has weird sonames, e.g.: libgtk-x11-3.0.so.0.9005.0 - change soname to: libgtk-x11-3.so.0.0.0, when we get to 3.0 - alternate: libgtk-x11-3.0.so.1.0.0 • small 3.0 clean-ups - 84188: non-fully homogeneous ButtonBoxes - 426924: draw-border removal - 426924: stock icon names • G_DEFINE_BOXED_TYPE - 50 insertions, 263 deletions - chpe requests a review - everyone agrees it should go in ASAP • gtk+ hackfest - register! register! register! log: http://live.gnome.org/GTK+/Meetings next meeting: 2010-08-31, 20:00 UTC -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ 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 09:27 +0800, Zhang, Qiang Z wrote: > Hi developers, > > I am from MeeGo distribution team. > > We have planned to use glib 2.26 in MeeGo 1.1, and I want to know when the > new stable glib 2.26 will be released. > > Is there any webpage for special gnome projects' detail release plan? GLib 2.26 will be available in time for GNOME 2.32. The GNOME 2.32 schedule can be found here: http://live.gnome.org/TwoPointThirtyone ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
