Re: GtkFileChooserButton::file-set
Il Thu, 4 Oct 2012 02:00:39 +0200 Rafał Mużyło galtge...@gmail.com scrisse: On Thu, Oct 04, 2012 at 12:33:24AM +0200, Nicola Fontana wrote: Il Wed, 3 Oct 2012 23:28:23 +0200 Rafał Mużyło galtge...@gmail.com scrisse: but the change on cancel was recently fixed in bug . in regard of gtk 3.4 and 3.6 (unfortunately, not in 2.24 though, even if it seems to be only a matter of a cherry-pick). What I mean is pressing ESC or clicking cancel unset the file name and I didn't find a way to catch it: this is not the same issue. I'm using gtk 3.4.4 but I don't think it is relevant. It's in fact not only the *very same* problem, but also while it *was* fixed on 3.4 branch, there was no release there yet containing this commit from this branch - it's post 3.4.4. I'm interested in the notification not in the fact it is unset: this hardly makes them *very same*. Anyway thanks for pointing out it is unwanted behavior: I'll wait for the fix. Ciao. -- Nicola ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handle Enter pressing at GtkEntry
On Wed, Oct 03, 2012 at 08:19:39PM -0700, Andrew Potter wrote: On Wed, Oct 3, 2012 at 7:42 AM, Yury Alyaev muta...@rambler.ru wrote: What is the right way to catch Enter pressing at the end of the text input to GtkEntry gtk_entry_set_activates_default() is probably what you want. If you actually want what it does. Usually, I do not want that at all. I want to recalculate and update something once user has finished editing the value there (but not during the editing). This means namely when the entry loses focus, however, it should be also possible to invoke the update without leaving the entry, by pressing Enter. So, instead of gtk_entry_set_activates_default() I use something like set-activate-on-unfocus and then just handle activate. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handle Enter pressing at GtkEntry
On Thu, Oct 4, 2012 at 5:55 PM, David Nečas y...@physics.muni.cz wrote: On Wed, Oct 03, 2012 at 08:19:39PM -0700, Andrew Potter wrote: On Wed, Oct 3, 2012 at 7:42 AM, Yury Alyaev muta...@rambler.ru wrote: What is the right way to catch Enter pressing at the end of the text input to GtkEntry gtk_entry_set_activates_default() is probably what you want. If you actually want what it does. Usually, I do not want that at all. I want to recalculate and update something once user has finished editing the value there (but not during the editing). This means namely when the entry loses focus, however, it should be also possible to invoke the update without leaving the entry, by pressing Enter. So, instead of gtk_entry_set_activates_default() I use something like set-activate-on-unfocus and then just handle activate. I'm curious about this, out of my own personal interest... do we have a workable solution for this commit-on-focus-out paradigm ? As I understand, it's not very stable to use focus-out events and, I recall reading a detailed blog about this I can't seem to find at the moment (but it seems the problem is not at all limited to GTK+, just broken by design). Note in many cases validation/apply/commit user input on focus-out does work but... here is a case where I expect it to break: a.) User is presented a form full of entries b.) User tabs or clicks into an entry c.) User modifies data d.) User selects another entry e.) Focus-out causes the previous entry to commit, yay ! f.) User modifies data in new entry g.) User presses OK h.) Dialog full of entries is destroyed... oops... previous entry is destroyed before ever receiving focus-out notification. That scenario, easy enough to deal with because you have a commit button which can take care of things... (in which case you dont need focus-out in the first place)... but... lets take another example: a.) Editor is loaded into a notebook tab because some object is selected (consider Glade's property editor, and a widget is selected for instance) b.) Each property gets it's current value filled with new data c.) User modifies one of the entries d.) User selects a new entry, YAY we received focus-out e.) User modifies the currently focused entry f.) User selects a new object in the workspace g.) Entries are cleared of previous data, a new widget is loaded into the editing context and new values are loaded into the entries h.) Entry receives focus-out ... OOPS... what change did I have to commit ? As far as I know, it's an interesting, classic problem (which I knew to exist years ago), perhaps focus event delivery is ordered now in such a way that this wont happen ? ... it's really hard to say. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handle Enter pressing at GtkEntry
On Thu, Oct 04, 2012 at 06:55:08PM +0900, Tristan Van Berkom wrote: I'm curious about this, out of my own personal interest... do we have a workable solution for this commit-on-focus-out paradigm ? As I understand, it's not very stable to use focus-out events and, I recall reading a detailed blog about this I can't seem to find at the moment (but it seems the problem is not at all limited to GTK+, just broken by design). Note in many cases validation/apply/commit user input on focus-out does work but... here is a case where I expect it to break: ... Validation is a different problem. For validation, the user should have an instataneous visual clue whether the input would be considered valid (but no blocking of non-conforming inputs, of course). In the second case you mentioned, loading of new values must not happen when there are uncommited changes and that should be also easy to achieve – except it may come a bit too late from the user's perspective if validation needs also be performed. However, if the GUI is constructed so that the user expects immediate commit, as it seems from your description, then it should be probably really immediate. Imagine the case I was talking about as function plotting. You may attempt to plot the function as the user types the expression but (1) the ‘plotting’ thing is not something really instanteneous and so doing it after each keystroke would interfere with typing (2) the user is essentially never interested in displaying the intermediate rubbish, in fact, he may be strongly intereseted in seeing the last meaningful, i.e. commited, output while editing. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Partial frame synchronization TODO
This all sounds fantastic, but I have a stupid question: On Thursday, October 4, 2012, Owen Taylor wrote: * When there is a frame where no painting ends up being done, we still at the moment are sending increments to the frame serial and waiting for_NET_WM_FRAME_DONE. It may be worth tracking when we are about to damage a toplevel window (by drawing or configuring it) and only at that point start a frame. Then we'll avoid asking the compositor to tell us when it's done painting a frame that involves no painting. Does this mean we have a busy idle? Does this have implications for laptop battery life? John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Frame synchronization open questions
Some open questions in my head about the frame synchronization work: * Is GdkPaintClock the right name? It might imply that it only has to do about painting and not about other things like layout. GdkFrameClock would be an alternative. GdkClock is possible but likely too generic. I agree that Paint is confusing, GdkFrameClock seems to be the right name to me. Frame is what this is always called in gameloop style code. * For pausing the main event delivery, what we currently do is that we queue events but don't dispatch them. This could conceivably cause ordering problems for apps that use filters, or for work in GDK that is done at the translate stage - since we are not pausing translation, just pausing delivery. Alternatives: Are you sure that is really a problem? The x11 gdk_event_source_check() code will never even look for a message if there is any GdkEvent queued. And if there is nothing queued _gdk_x11_display_queue_events() will stop as soon any X event was converted to a queued GdkEvent. And, since this queued event will not be read due to the pause we will never process more X events until resume events. So, we may process multiple events that are not queued into gdk events and at most one that is queued, but no more until the queued event is handled. This does not look like it could ever cause a reordering problem to me. At most it means we may handle some filtered X events during the frame cycle, I'm not sure that is as much of a problem. What I do however worry about is the combination of multiple GdkPaintClocks and gdk_display_set_events_paused(). It seems to me that each paint clock assumes it has full ownership of the display, calling set_events_paused(FALSE) whenever it has finished its paint cycle. However, could there not be other paintclocks (say for another toplevel) being active at that time? Another thing I worry about is offscreen window animation. If you have an window with an embedded offscreen inside, then queueing a redraw on a widget inside the offscreen will cause a repaint cycle. When drawing to the offscreen this will generate damage events that will cause the embedding widget to repaint itself. However the damage events will be emitted during the paint phase, and the parent widget will not get these until the next frame. This will cause a delay of on frame which may look weird. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Partial frame synchronization TODO
? Implement paint throttling for the Broadway backend. (I'm not sure what this means exactly - the default throttling to 60fps may be OK.) Not sure what the best thing is here. If you have a low bandwidth connection then you would like to do a roundtrip to the client before sending the next frame to avoid just filling up the pipe with frames and then blocking on socket write. However, if you have a high bandwidth but high latency link then you could theoretically keep sending new frames and they would display fine on the client, although somewhat delayed. Doing the roundtrip in this case would just unnecessary skip frames in the animation. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Frame synchronization open questions
On Thu, 2012-10-04 at 08:09 -0400, Alexander Larsson wrote: Some open questions in my head about the frame synchronization work: [...] * For pausing the main event delivery, what we currently do is that we queue events but don't dispatch them. This could conceivably cause ordering problems for apps that use filters, or for work in GDK that is done at the translate stage - since we are not pausing translation, just pausing delivery. Alternatives: Are you sure that is really a problem? The x11 gdk_event_source_check() code will never even look for a message if there is any GdkEvent queued. And if there is nothing queued _gdk_x11_display_queue_events() will stop as soon any X event was converted to a queued GdkEvent. And, since this queued event will not be read due to the pause we will never process more X events until resume events. That gets into the details of exactly how I implemented event pausing, but logically speaking, if event delivery is paused, and a new event happens, it needs to be queued up in GDK, Xlib, or in the X server. If we don't translate events, then either: * Event is queued in Xlib, XPending() starts returning TRUE * Event is queued in XServer, the file descriptor Either situation is going to make us start spinning currently. But leaving that aside, we *need* to translate events or we'll never get _NET_WM_FRAME_DONE and unfreeze event delivery. My current preference is to just unfreeze all event delivery at the end of drawing the frame, and not wait for _NET_WM_FRAME_DONE. Then we can make pausing *really* pausing - not unqueue, not translate, etc. I don't see any real disadvantage of doing things that way. [...] What I do however worry about is the combination of multiple GdkPaintClocks and gdk_display_set_events_paused(). It seems to me that each paint clock assumes it has full ownership of the display, calling set_events_paused(FALSE) whenever it has finished its paint cycle. However, could there not be other paintclocks (say for another toplevel) being active at that time? Yes, this is an issue. However, if you switch to the above approach, then all you have to do is to properly reference count the event-pausing - once we reach the GDK_PRIORITY_EVENTS + 1 idle, we want to pause *all* event delivery until we are done with new frame handling. Another thing I worry about is offscreen window animation. If you have an window with an embedded offscreen inside, then queueing a redraw on a widget inside the offscreen will cause a repaint cycle. When drawing to the offscreen this will generate damage events that will cause the embedding widget to repaint itself. However the damage events will be emitted during the paint phase, and the parent widget will not get these until the next frame. This will cause a delay of on frame which may look weird. Hmm. So your concern is that the connection between the embedded offscreen and the embedder is purely at the GTK+ level - if GDK_DAMAGE events are not delivered to GTK+, then the the embedder won't know to repaint. I think the normal way it would end up working is: offscreen paints a frame, damage events are generated damage events are delivered, new frame is queued for the embedder embedder paints a frame, waits for _NET_WM_FRAME_DONE offscreen paints a frame, damage events are generated damage events are delivered, new frame is queued for the embedder _NET_WM_FRAME_DONE arrives embedder paints a frame, waits for _NET_WM_FRAME_DONE offscreen paints a frame, damage events are generated damage events are delivered, new frame is queued for the embedder _NET_WM_FRAME_DONE arrives So the offscreen will generally paint during the wait for _NET_WM_FRAME_DONE, and immediately get incorporated into the next output frame. Though once things get loaded down and slow, there is no guarantee of this. To do better than this, I think you need to slave the clock for the offscreen into the clock for the window that is embedding it. If the size of the embedded widget is free-floating and not constrained by the allocation of the embedder, then the slave clock would simply do the complete cycle inside an ::update handler. If you want integration of size-negotiation, then you'd have to do different phases at different points in the master clock cycle. And yes, the delivery of damage as events is problematical for that kind of slaving - maybe we would need to have a signal on GdkOffscreenWindow to allow getting as-it-happens notification of damage. - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Partial frame synchronization TODO
On Thu, 2012-10-04 at 08:18 -0400, Alexander Larsson wrote: ? Implement paint throttling for the Broadway backend. (I'm not sure what this means exactly - the default throttling to 60fps may be OK.) Not sure what the best thing is here. If you have a low bandwidth connection then you would like to do a roundtrip to the client before sending the next frame to avoid just filling up the pipe with frames and then blocking on socket write. However, if you have a high bandwidth but high latency link then you could theoretically keep sending new frames and they would display fine on the client, although somewhat delayed. Doing the roundtrip in this case would just unnecessary skip frames in the animation. The client asynchronously acks the frames it receives, GTK+ uses those acks to estimate the latency and bandwidth of the connection, you keep track of how full the link is, and at the point of saturation, you avoid processing a new frame until there is room in the link for the new frame. Trivial! Could not possibly go wrong! ;-) - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ at the Boston summit
This coming weekend, a bunch of people will meet at the MIT for annual Boston summit. A number of GTK+ developers will be there too, so it makes sense to spend some time together and discuss the roadmap for the next cycle. One obvious topic will be Owen's animation work that he just posted here. Another one might be Benjamins plans for actors. So far, I have just put these on the agenda: https://live.gnome.org/Boston2012 If you are interested in GTK+ development and think you have a topic we should talk about, feel free to come bye. See you there, Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_size_request stopped working with GTK3
On Fri, Oct 5, 2012 at 1:57 AM, Steffen Gutmann muib...@yahoo.com wrote: Hi Tristan! Right, the bug might have to do more with cropping/scaling support GtkImage, rather than it's size request. Filed as [Bug 685506] New: GtkImage and size/space management Regarding size request: We add a new property of type boolean to GtkImage. If it is set (default), the size request for GtkImage will be the size of the underlying image (or the pixel-size), i.e. the exact same behaviour as it is now. If it is set to FALSE then the minimum size will be (1, 1) and an application can use width-request and height-request for making the widget size larger. I am not sure what a good name for this new property would be, but maybe you have a suggestion?. Something like min-size-is-image-size would probably make the property self-explanatory but is obviously too long compared to other existing property names. Maybe full-image or image-size-request? Any comment about how to allow a smaller size request? Any good name for this property? Regading placement: In GTK2, GtkImage cropped the image such that only the center is shown, i.e. it took off an equal amount of image content on the left and right, and top and bottom. It probably just sets the right clipping mask when drawing the image for achieving this. We could simply use the same policy, or we modify the usage of GtkWidget's halign and valign properties. Currently the docs reads: halign GtkAlign : Read / Write While it's true that the align properties make no sense when the widget's natural size is equal to, or exceeds the widget's allocation; From a programmer's point of view, the align properties also make sense when the widget size is smaller than its allocation. For example, for centering, one would draw the contents at (allocation.width/height - contents.width/height) / 2 which works in both cases, when there is extra space as well when there is insufficient space (assuming clipping is done by cairo correctly). I'm not exactly sure it's a good idea to use the GtkWidget's halign/valign properties directly (i.e. it's like hidden candy, people wont see it evidently in the docs/headers for GtkImage and so will probably not discover it). We could cross-ref the halign/valign properties in the docs of above new property that describes how to obtain a smaller size request for GtkImage. However I do like the idea of GtkAlign properties for that, where FILL would mean scale and CENTER/START/END have the obvious clipping behaviors. Right. Actually I tried the FILL alignment with a GtkImage having extra space. The image becomes centered but not streched. For keeping compatibility, I guess we want to keep it this way. Also, it should have reasonable behaviors defined for the various configurations of a GtkImage I think we are shooting too far here. For icons and such I think the pixel-size property is the right approach and the new property suggested above should have no effect. Otherwise, if we are trying to support all combinations of configurations, pixel-sizes and the new property then we will likely end up in open problems and the chance that any patch will be accepted is going to be small. I disagree with this. What we definitely want to avoid in GTK+, is overextending the API in ways that only apply to special case configurations (remember that in most cases, once you introduce a new API it can not be removed in a later release, this imposes more and more constraints on code maintainability in the long term). i.e., it's already annoying that pixel-size only applies to an icon loaded from the icon theme (and so if we were to add some scaling/cropping features that are more general, it would be better to deprecate the pixel-size property if the same effect can be achieved with a newer API). It's a priority for the API to be readable, and to avoid additions of properties which introduce 'crowding' into the api, we should keep GTK+ API as short and sweet as possible. Yes, that requires more thought and consideration when writing platform code, that pays off when the user is satisfied that user facing apis such as pixel-size does what it says; regardless of other property settings. If for instance, it is not possible to respect a property for a given configuration of a widget, or it clutters the code to much and the code becomes unreadable due to the attempt to manage all configurations, then a good approach to that problem is to introduce subclasses to handle that in a sensible way (i.e. it would have probably made sense originally that only the GtkImageIconTheme subclass exports a 'pixel-size' property) Like for instance, how we've split out the convenience apis for GtkComboBox into a separate GtkComboBoxText class. For now I think we've taken up enough valuable list space and should probably move this conversation to the bug report. Regards,
