Re: GTK 3 support status
hi; On 4 December 2011 02:41, John Lindgren john.lindg...@aol.com wrote: I am wondering what the status of GTK 3 is at this time with regard to bugs reported by application developers. the status is always the same: bugs reported will be looked at by the gtk maintainers depending on time. you may want to join the #gtk+ IRC channel, on irc.gnome.org if you want to poke a maintainer. I reported a rather serious bug (https://bugzilla.gnome.org/show_bug.cgi?id=662043) a month and a half ago, and there is still no comment from any GTK developer. The bug affects the Audacious project to the point that we will be forced to go back to using GTK 2.x if it is not resolved soon. I agree with the conclusion of another user that this is a bug breaking [the] UI design of GTK applications. the source of the issue is that gtk3 does not allow widget underallocations, unlike gtk2. underallocations were a huge source of edge cases, code complexity, and nasty bugs in gtk2 and when the time came to review the size negotiation implementation, and add support for height-for-width and width-for-height, keeping support for underallocations would have made the code balloon out of the maintainership capabilities of the gtk team - as well as introduce new and exciting bugs. this is why setting the minimum size using set_size_request() will not work in your case: the label's minimum size is bigger than the size you requested. long story short: if you want to set the minimum size on a label you can do it with the set_width_chars() method: http://developer.gnome.org/gtk3/stable/GtkLabel.html#gtk-label-set-width-chars ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK 3 support status
hi; On 4 December 2011 02:56, Michael Cronenworth m...@cchtml.com wrote: I agree that yours, and a few other GTK3 bugs[1][2], have kept me from porting my apps from GTK2. My suggestion would be to post your e-mail to the gtk-devel list[3], and as a last resort open a bug on the Red Hat bugzilla as Red Hat does the most GTK work AFAIK. bugs opened on the RH bugzilla a) will not be visible to the non-RedHat maintainers of gtk+ and, more importantly, b) will be closed immediately by the RedHat maintainers. so, please, don't do that. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK 3 support status
On 12/04/2011 04:02 AM, Emmanuele Bassi wrote: the status is always the same: bugs reported will be looked at by the gtk maintainers depending on time. So the status at this moment is that no developers have time to look at bugs reported by application developers. Or is there something wrong with my report in particular? the source of the issue is that gtk3 does not allow widget underallocations, unlike gtk2. underallocations were a huge source of edge cases, code complexity, and nasty bugs in gtk2 and when the time came to review the size negotiation implementation, and add support for height-for-width and width-for-height, keeping support for underallocations would have made the code balloon out of the maintainership capabilities of the gtk team - as well as introduce new and exciting bugs. this is why setting the minimum size using set_size_request() will not work in your case: the label's minimum size is bigger than the size you requested. long story short: if you want to set the minimum size on a label you can do it with the set_width_chars() method: http://developer.gnome.org/gtk3/stable/GtkLabel.html#gtk-label-set-width-chars Thank you for the suggestion. Unfortunately, when I tried it just now, that method also no longer works in GTK+ 3.x. Accordingly, I have reported this problem also: https://bugzilla.gnome.org/show_bug.cgi?id=665560 -- John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK 3 support status
On Mon, Dec 5, 2011 at 9:21 AM, John Lindgren john.lindg...@aol.com wrote: On 12/04/2011 04:02 AM, Emmanuele Bassi wrote: the status is always the same: bugs reported will be looked at by the gtk maintainers depending on time. So the status at this moment is that no developers have time to look at bugs reported by application developers. Or is there something wrong with my report in particular? the source of the issue is that gtk3 does not allow widget underallocations, unlike gtk2. underallocations were a huge source of edge cases, code complexity, and nasty bugs in gtk2 and when the time came to review the size negotiation implementation, and add support for height-for-width and width-for-height, keeping support for underallocations would have made the code balloon out of the maintainership capabilities of the gtk team - as well as introduce new and exciting bugs. this is why setting the minimum size using set_size_request() will not work in your case: the label's minimum size is bigger than the size you requested. long story short: if you want to set the minimum size on a label you can do it with the set_width_chars() method: http://developer.gnome.org/gtk3/stable/GtkLabel.html#gtk-label-set-width-chars Thank you for the suggestion. Unfortunately, when I tried it just now, that method also no longer works in GTK+ 3.x. Accordingly, I have reported this problem also: https://bugzilla.gnome.org/show_bug.cgi?id=665560 Hi John, I am responsible for a large part of your pain. And I'm also surprised that this code is not working for you. The last time I looked at size negotiation, the toplevel window constraints have always been based on the minimum-for-minimum request of the window contents (minimum height for minimum width). However, some observations while running your test: o The minimum size constraint of your window is correct, it's set to about 20 chars of width, this is the smallest size your window can be (firing up your test case allows me to shrink the window to that size) o A *bad* ugly bug here is that your label does not ellipsize, what is up with that ? How come your label wraps when it was not asked to wrap ? o If the label were configured to wrap, then it *must* require at least the minimum height for it's minimum width, however the broken label does not require that width... instead when shrinking the window it wraps out of view o Heightening the window will give some random extra allocation to the child label, showing the wrapped text... So, I can observe a behavioural change here, the toplevel window is behaving actually quite nicely, it seems to be constraining the window size to the minimum-for-minimum request, and then setting a default size to the natural width/height request. So I'm attaching my version of your test case, actually except for the label being somehow severely broken here, your code works nicely... I added a line that says gtk_window_set_default_size() and I think that will fix all your problems. Actually anyway I have an outdated branch of GTK+ here so I suspect I'm just running into a *really bad* label bug which probably never made it to any production release... In short, the behavioural change is that the default size of a window is now also derived from the natural request of it's content, you can easily override that by adding the 2 lines of code which I added to your test case, no waiting for realize hacks involved. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK 3 support status
On Mon, Dec 5, 2011 at 4:18 PM, Tristan Van Berkom t...@gnome.org wrote: On Mon, Dec 5, 2011 at 9:21 AM, John Lindgren john.lindg...@aol.com wrote: On 12/04/2011 04:02 AM, Emmanuele Bassi wrote: the status is always the same: bugs reported will be looked at by the gtk maintainers depending on time. So the status at this moment is that no developers have time to look at bugs reported by application developers. Or is there something wrong with my report in particular? the source of the issue is that gtk3 does not allow widget underallocations, unlike gtk2. underallocations were a huge source of edge cases, code complexity, and nasty bugs in gtk2 and when the time came to review the size negotiation implementation, and add support for height-for-width and width-for-height, keeping support for underallocations would have made the code balloon out of the maintainership capabilities of the gtk team - as well as introduce new and exciting bugs. this is why setting the minimum size using set_size_request() will not work in your case: the label's minimum size is bigger than the size you requested. long story short: if you want to set the minimum size on a label you can do it with the set_width_chars() method: http://developer.gnome.org/gtk3/stable/GtkLabel.html#gtk-label-set-width-chars Thank you for the suggestion. Unfortunately, when I tried it just now, that method also no longer works in GTK+ 3.x. Accordingly, I have reported this problem also: https://bugzilla.gnome.org/show_bug.cgi?id=665560 Hi John, I am responsible for a large part of your pain. And I'm also surprised that this code is not working for you. The last time I looked at size negotiation, the toplevel window constraints have always been based on the minimum-for-minimum request of the window contents (minimum height for minimum width). However, some observations while running your test: o The minimum size constraint of your window is correct, it's set to about 20 chars of width, this is the smallest size your window can be (firing up your test case allows me to shrink the window to that size) o A *bad* ugly bug here is that your label does not ellipsize, what is up with that ? How come your label wraps when it was not asked to wrap ? o If the label were configured to wrap, then it *must* require at least the minimum height for it's minimum width, however the broken label does not require that width... instead when shrinking the window it wraps out of view o Heightening the window will give some random extra allocation to the child label, showing the wrapped text... So, I can observe a behavioural change here, the toplevel window is behaving actually quite nicely, it seems to be constraining the window size to the minimum-for-minimum request, and then setting a default size to the natural width/height request. So I'm attaching my version of your test case, actually except for the label being somehow severely broken here, your code works nicely... I added a line that says gtk_window_set_default_size() and I think that will fix all your problems. Actually anyway I have an outdated branch of GTK+ here so I suspect I'm just running into a *really bad* label bug which probably never made it to any production release... In short, the behavioural change is that the default size of a window is now also derived from the natural request of it's content, you can easily override that by adding the 2 lines of code which I added to your test case, no waiting for realize hacks involved. Clarification: in the code I sent here... I queried the minimum width of the label, ideally if you just want the window to show by default at it's minimum width, you should query the window itself, not one of it's children. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GObjectClass.dispose and bringing objects back to life
hi; On 4 December 2011 13:23, Benjamin Otte o...@gnome.org wrote: Tristan Van Berkom tvb at gnome.org writes: Yes, real-world well-written GObjects *must* not crash after being disposed, code that crashes because apis are called after dispose time are bugs, and you should fix them as specially if you have possible circular object references. This is of course not true. Because if it were true, the whole GNOME stack would not be real-world well-written GObject code and I think we all agree that a lot of our code is pretty damn good. this is, of course, not true: GNOME is full of badly written GObject code, mostly because it has been written at various stages of the learning process of various people. plus, the documentation is not entirely clear in a lot of places, thus the learning process can (and effectively is) broken. So why does GObject even have dispose? Why does it ship this obviously wrong documentation? And why do some people believe that objects must survive after a dispose? objects should obviously not be in a fully functional state after dispose - but they should be in a stable state, so that other objects referencing them from outside of the boundaries of their code space can still hold a valid reference to them, until such time that every reference can be released. What we probably also should do is deprecate one of the two virtual functions, so people use the same one to clean up everywhere. this would be insane and wrong on so many levels that it's not even funny to contemplate them. the double-step in the object lifecycle end is necessary in a refcounted system with reference cycles. you cannot just release references to an object on finalize() if there is even the slightest chance of a cycle; any attempt at doing so introduces instabilities, segfaults, or leaks. ciao, Emmanuele. -- 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: GObjectClass.dispose and bringing objects back to life
What we probably also should do is deprecate one of the two virtual functions, so people use the same one to clean up everywhere. That would be a _really_ bad idea. _finalize gets rid of the last fragments of the object. Since random code could have obtained refs to the object, the object designer can generally not control when this happens. _dispose has two functions: (1) break reference cycles by getting rid of as many objects as it can, and (2) getting rid of externally- visible parts of the object and subobjects it owns. (2) tells you why you can't merge the two methods. Widgets, for example, really need to go away from the screen when you tell them, not whenever something else decides to release a ref. Objects that have open files really need to close them at dispose time, not next Wednesday. Gtk1 didn't have dispose in name, but it had the destroy method instead. Same thing. [...] we [...] know that trying to support objects functioning after dispose is like trying to make your code handle NULL returns I don't think we know that, not do I think it's true. Making _dispose work really comes down to following one simple rule: after _dispose, the object should be as well defined as it was after _init. I.e., anything you free you set to NULL and you don't free anything that was allocated in _init[*]. M. [*] Unless you allocate a new dummy object to put in its place. That wouldn't make much sense unless you have big trouble with circular references. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObjectClass.dispose and bringing objects back to life
On Sun, Dec 04, 2011 at 01:40:58PM +, Emmanuele Bassi wrote: this is, of course, not true: GNOME is full of badly written GObject code, mostly because it has been written at various stages of the learning process of various people. plus, the documentation is not entirely clear in a lot of places, thus the learning process can (and effectively is) broken. ... objects should obviously not be in a fully functional state after dispose - but they should be in a stable state, so that other objects referencing them from outside of the boundaries of their code space can still hold a valid reference to them, until such time that every reference can be released. So, who thinks this idea is not actually inherently inconsistent please please specify in the documentation, based on your rationale, how are objects supposed to behave in the disposed state. Namely with respect to (not) keeping impossible invariants, returning nontrivial no-longer-available values, methods that normally create or acquire something before returning it and other practical issues. Or say that there can be certain things the object owners may not do with disposed objects. Or anything. This The object is also expected to be able to answer client method invocations (with possibly an error code but no memory violation) until finalize is executed. has as, a practical guide, approximately the same value as ‘people should live together in peace’. Thank you in advance, Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObjectClass.dispose and bringing objects back to life
2011/12/5 David Nečas y...@physics.muni.cz: On Sun, Dec 04, 2011 at 01:40:58PM +, Emmanuele Bassi wrote: this is, of course, not true: GNOME is full of badly written GObject code, mostly because it has been written at various stages of the learning process of various people. plus, the documentation is not entirely clear in a lot of places, thus the learning process can (and effectively is) broken. ... objects should obviously not be in a fully functional state after dispose - but they should be in a stable state, so that other objects referencing them from outside of the boundaries of their code space can still hold a valid reference to them, until such time that every reference can be released. So, who thinks this idea is not actually inherently inconsistent please please specify in the documentation, based on your rationale, how are objects supposed to behave in the disposed state. Namely with respect to (not) keeping impossible invariants, returning nontrivial no-longer-available values, methods that normally create or acquire something before returning it and other practical issues. Or say that there can be certain things the object owners may not do with disposed objects. Or anything. This The object is also expected to be able to answer client method invocations (with possibly an error code but no memory violation) until finalize is executed. has as, a practical guide, approximately the same value as ‘people should live together in peace’. It's a gray area that has not needed real clarification with real-world code thus far, and I doubt it really absolutely needs clarification. 'Let us live in peace' is actually pretty much the gist of it afaics. Why is this a non-issue ? Because during the dispose cycle of objects, sane people don't call apis which would ever fail at dispose time. People might however call functions/macros like: - g_object_get_qdata(), i.e. I have some explicitly attached data I want to inspect once while disposing, and for whatever reason I chose not to call g_object_set_data_full() - g_type_name_from_instance() (i.e., sometimes I like to print the type names and reference counts of object hierarchies being destroyed, just to debug my own code) Probably much existing code will fire run-time assertions when asked to actually perform a task at dispose time after an important resource is already discarded. I think the policy right now, and has always been, don't crash because your api has been accessed at dispose time. Do we need a more explicit policy ? Do we need to define what code should do when asked to do something useful after dispose time ? Considering that any sane code does not ever ask an object to do anything useful after dispose time, no... it would just be an exercise of planning for what to do in code that is anyway, not meant to be reached. That said, policy about locking and sharing of objects in MT environments (related more to GIO than pure GObject) _might_ need clarification. Implementing MT-safe singleton objects (as was I think the case in the referred bug report) is probably just damn complex to do, definitely needs to be done with some manual locking around the access to the singleton static pointer and probably just a really bad idea to use in conjunction with GObject weak references. That is anyway, IMO, a separate discussion than the one we are having about policy at dispose time. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObjectClass.dispose and bringing objects back to life
I would be somewhat tempted to listen to all the stuff you're saying below. But then I looked at the code you maintain[1], and I realized it doesn't do anything of that. So I'm inclined to think that what you're talking about is more about an ideal world that you wish we all aspired to, but is not in any way related to how people write code in the real world. Benjamin 1: http://git.gnome.org/browse/gnumeric/tree/gnumeric.doap On Sun, Dec 4, 2011 at 3:15 PM, Morten Welinder mort...@gnome.org wrote: What we probably also should do is deprecate one of the two virtual functions, so people use the same one to clean up everywhere. That would be a _really_ bad idea. _finalize gets rid of the last fragments of the object. Since random code could have obtained refs to the object, the object designer can generally not control when this happens. _dispose has two functions: (1) break reference cycles by getting rid of as many objects as it can, and (2) getting rid of externally- visible parts of the object and subobjects it owns. (2) tells you why you can't merge the two methods. Widgets, for example, really need to go away from the screen when you tell them, not whenever something else decides to release a ref. Objects that have open files really need to close them at dispose time, not next Wednesday. Gtk1 didn't have dispose in name, but it had the destroy method instead. Same thing. [...] we [...] know that trying to support objects functioning after dispose is like trying to make your code handle NULL returns I don't think we know that, not do I think it's true. Making _dispose work really comes down to following one simple rule: after _dispose, the object should be as well defined as it was after _init. I.e., anything you free you set to NULL and you don't free anything that was allocated in _init[*]. M. [*] Unless you allocate a new dummy object to put in its place. That wouldn't make much sense unless you have big trouble with circular references. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObjectClass.dispose and bringing objects back to life
Benjamin Otte o...@gnome.org wrote: But then I looked at [gnumeric] and I realized it doesn't do anything of that. So I'm inclined to think that what you're talking about is more about an ideal world that you wish we all aspired to, but is not in any way related to how people write code in the real world. We take bug reports. We even fix bugs. I cannot really use pointing 400k lines of code for anything, so throw me a bone -- a class name, for example -- and I can actually do something. (And if you just meant to throw a few insults my way, well I hope you feel better.) M. (not quite an angel himself) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
