GTK 3 support status
Hi, I am wondering what the status of GTK 3 is at this time with regard to bugs reported by application developers. 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. Thank you for your attention. -- John Lindgren ___ 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 2011-12-06, at 8:12 PM, Andrew Cowie wrote: > On Tue, 2011-12-06 at 17:47 +0900, Tristan Van Berkom wrote: > >> gtk_widget_set_size_request() should still succeed with the expected >> behaviour >> of setting the minimum size of a widget, > > So, does it do so for GtkLabel? ie, is it acceptable to call it? > > [this thread has become a bit confusing] Yes, gtk_widget_set_size_request() will set the minimum size for a label, as it will for any widget. Don't confuse that with limiting a widget's size, a label will request a minimum size based on it's content and configuration, it may require more width than the explicit minimum size set by the user. A widget's size can only be limited by limiting what content will be displayed inside it (for label widgets this is done using width-chars/max-width-chars in conjunction with ellipsizing/wrapping). Cheers, -Tristan > AfC > Sydney > > > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK 3 support status
On Tue, 2011-12-06 at 17:47 +0900, Tristan Van Berkom wrote: > gtk_widget_set_size_request() should still succeed with the expected behaviour > of setting the minimum size of a widget, So, does it do so for GtkLabel? ie, is it acceptable to call it? [this thread has become a bit confusing] AfC Sydney ___ 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 Tue, Dec 6, 2011 at 1:15 AM, John Lindgren wrote: > Hi Tristan, > > This makes a bit more sense now. > > > On 12/05/2011 09:27 AM, Tristan Van Berkom wrote: >> >> On Mon, Dec 5, 2011 at 11:18 PM, John Lindgren >> wrote: >>> >>> It looks to me as though there are 3 separate problems contributing here: >>> >>> 1. GtkLabel does not take into account gtk_widget_set_size_request() when >>> reporting its "natural" size: >>> https://bugzilla.gnome.org/show_bug.cgi?id=662043 >> >> Not a bug. >> >> No widgets should ever peek at the explicit user set size request to >> implement the size negotiation vfuncs. >> >> Those are handled in GtkWidgetClass.adjust_size_request() base class >> implementation. > > > So using gtk_widget_set_size_request() as a way to set the width of a label > is no longer valid in GTK+ 3. Fair enough. That is true, GtkLabel in GTK+2 did do some sneaky things like peeking at the user set size request, it no longer does this. gtk_widget_set_size_request() should still succeed with the expected behaviour of setting the minimum size of a widget, however it does not limit the size of any widget. > > >>> 2. Nor does it take into account gtk_label_set_width_chars(): >>> https://bugzilla.gnome.org/show_bug.cgi?id=665560 >> >> It does, width-chars, as always, only effects the minimum size, not >> the natural size. > > > I get it now. You set the minimum width of a label with > gtk_label_set_width_chars() and the natural/default width with > gtk_label_set_max_width_chars(). > > The documentation is very misleading; actually, the entire documentation for > gtk_label_set_width_chars() consists of the sentence fragment, "Sets the > desired width in characters of label to n_chars." I do not think that most > people would make the connection between "desired width" and "minimum > width". > > Likewise, the documentation for gtk_label_set_max_width_chars() is, "Sets > the desired maximum width in characters of label to n_chars." I do not > think that most people would make the connection between "desired maximum > width" and "natural/default width". > I couldn't agree more, and I'm sorry for lack of time and patience for documenting GtkLabel properties better. Would you like to re-phrase that documentation yourself and send it back to the list ? I'll take that and correct anything that might be inaccurate and send it back to this list... (perhaps we should CC gtk-devel-list in this case). Others will have a (short) chance to interject... and if there are no objections to the new documentation within a short time I'll go ahead and commit that to GTK+ so that next time around the online docs will be better. Reasonable plan ? > >>> 3. GtkWindow ignores gtk_window_set_default_size() and instead goes to >>> its >>> "natural" size if the window is not resizable: >>> https://bugzilla.gnome.org/show_bug.cgi?id=665596 >> >> As I mentioned in the previous mail, I believe this has *always* been the >> case, >> GtkWindow always shrinks down to minimum size (or now in GTK+3 'natural >> size') >> >> This is how you get the shrinking dialogs when closing the expander in >> them >> (for non-resizable windows). >> >> However, it could be considered a bug, one would expect GtkWindow to make >> an attempt to honor a user set default size for a non-resizable window. >> >> Perhaps it's even a regression from GTK+2, not so sure. > > > I think it should be considered a bug; however, I do not care so much about > gtk_window_set_default_size() now that I can set the size of the label > directly. Using gtk_window_set_default_size(), you might recall, was your > suggestion from an earlier mail: Yes, whether it is a regression or not I think it's a valid bug, apis in GTK+ should definitely make an attempt at succeeding ;-) However, GtkWindow itself is a very tricky object to not break (on X11 platform it has to deal with this 'window constraint' api to cooperate with the X server), it's possible that it just doesn't make sense to implement this properly. In which case the fix might be adding documentation to gtk_window_set_resizable() to indicate that the window will always be forced to the natural size requests of its content, regardless of any previously set default size. >> 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. > > > Thanks for your help. I will close #662043 and #665560 but add a comment > that the documentation is wrong and needs to be updated. > > -- 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 Tue, Dec 6, 2011 at 2:22 AM, Costin Chirvasuta wrote:
> I don't really understand what max-width-chars would be useful for.
The max-width-chars property is intended to limit the overall size request
of a label.
if max-width-chars is set, the label will not by default request a natural
width of 'max-width-chars'... but if the label's actual width is larger, then
the natural width request will be *limited* to a maximum of 'max-width-chars'.
And of course, using either 'width-chars' or 'max-width-chars' is only
legal if the label is ellipsizing or wrapping.
The usefulness of limiting the natural width request of a label becomes
more obvious when you try to, for instance fit a wrapping label beside
an ellipsizing label in the same GtkBox:
you don't want the wrapping label to compete for size after acquiring
a fixed natural width.
> Can't you set a "natural" size for a widget instead of a "natural" max
gtk_widget_set_natural_size() has been suggested and is probably a good
addition to the api (for this, patches are most probably welcome...)
However, it might not always work as you would desire:
gtk_widget_set_size_request() can only logically set the minimum size, since
the GtkWidget api has no knowledge of the content to display, the
real content
might require more size.
gtk_widget_set_natural_size_request() could hypothetically set a hard coded
natural size request which is going to always be *at least minimum size*.
> char width? If I want to ellipsize it won't do me any good if
> "..." is the same as "...".
>
Using a width in terms of charachters up until now has always been more
practical than using pixel sizes.
Because the width-chars property will ultimately use:
pango_font_metrics_get_approximate_char_width()
Which will take into account the chosen font and resolution.
If you are setting 'width-chars', then your text is dynamic text which
you are uncertain if it will fit in the ui or not.
Instead of asking yourself the irrelevant question about the width
of an 'i' vs the width of an 'a', you should be asking yourself
"what does 50 pixels mean on this machine"... perhaps when
displayed on a huge LCD panel, 50 pixels is less than the width
of one character...
> I can see there is gtk_set_size_request for setting minimum width,
> gtk_window_set_default_size for setting maximum ("natural") width (if
> I understand correctly) but for windows. What can I use to set the
> maximum or "natural" size for a widget?
gtk_window_set_default_size() does not effect any size request, its
just supposed to set the default size of the GtkWindow when it initially
shows up.
However if you do NOT call set_default_size() manually, GTK+ will
use the natural request as the default size.
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
I don't really understand what max-width-chars would be useful for.
Can't you set a "natural" size for a widget instead of a "natural" max
char width? If I want to ellipsize it won't do me any good if
"..." is the same as "...".
I can see there is gtk_set_size_request for setting minimum width,
gtk_window_set_default_size for setting maximum ("natural") width (if
I understand correctly) but for windows. What can I use to set the
maximum or "natural" size for a widget?
___
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 Tristan, This makes a bit more sense now. On 12/05/2011 09:27 AM, Tristan Van Berkom wrote: On Mon, Dec 5, 2011 at 11:18 PM, John Lindgren wrote: It looks to me as though there are 3 separate problems contributing here: 1. GtkLabel does not take into account gtk_widget_set_size_request() when reporting its "natural" size: https://bugzilla.gnome.org/show_bug.cgi?id=662043 Not a bug. No widgets should ever peek at the explicit user set size request to implement the size negotiation vfuncs. Those are handled in GtkWidgetClass.adjust_size_request() base class implementation. So using gtk_widget_set_size_request() as a way to set the width of a label is no longer valid in GTK+ 3. Fair enough. 2. Nor does it take into account gtk_label_set_width_chars(): https://bugzilla.gnome.org/show_bug.cgi?id=665560 It does, width-chars, as always, only effects the minimum size, not the natural size. I get it now. You set the minimum width of a label with gtk_label_set_width_chars() and the natural/default width with gtk_label_set_max_width_chars(). The documentation is very misleading; actually, the entire documentation for gtk_label_set_width_chars() consists of the sentence fragment, "Sets the desired width in characters of label to n_chars." I do not think that most people would make the connection between "desired width" and "minimum width". Likewise, the documentation for gtk_label_set_max_width_chars() is, "Sets the desired maximum width in characters of label to n_chars." I do not think that most people would make the connection between "desired maximum width" and "natural/default width". 3. GtkWindow ignores gtk_window_set_default_size() and instead goes to its "natural" size if the window is not resizable: https://bugzilla.gnome.org/show_bug.cgi?id=665596 As I mentioned in the previous mail, I believe this has *always* been the case, GtkWindow always shrinks down to minimum size (or now in GTK+3 'natural size') This is how you get the shrinking dialogs when closing the expander in them (for non-resizable windows). However, it could be considered a bug, one would expect GtkWindow to make an attempt to honor a user set default size for a non-resizable window. Perhaps it's even a regression from GTK+2, not so sure. I think it should be considered a bug; however, I do not care so much about gtk_window_set_default_size() now that I can set the size of the label directly. Using gtk_window_set_default_size(), you might recall, was your suggestion from an earlier mail: 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. Thanks for your help. I will close #662043 and #665560 but add a comment that the documentation is wrong and needs to be updated. -- 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 11:18 PM, John Lindgren wrote: > It looks to me as though there are 3 separate problems contributing here: > > 1. GtkLabel does not take into account gtk_widget_set_size_request() when > reporting its "natural" size: > https://bugzilla.gnome.org/show_bug.cgi?id=662043 Not a bug. No widgets should ever peek at the explicit user set size request to implement the size negotiation vfuncs. Those are handled in GtkWidgetClass.adjust_size_request() base class implementation. > > 2. Nor does it take into account gtk_label_set_width_chars(): > https://bugzilla.gnome.org/show_bug.cgi?id=665560 It does, width-chars, as always, only effects the minimum size, not the natural size. > > 3. GtkWindow ignores gtk_window_set_default_size() and instead goes to its > "natural" size if the window is not resizable: > https://bugzilla.gnome.org/show_bug.cgi?id=665596 As I mentioned in the previous mail, I believe this has *always* been the case, GtkWindow always shrinks down to minimum size (or now in GTK+3 'natural size') This is how you get the shrinking dialogs when closing the expander in them (for non-resizable windows). However, it could be considered a bug, one would expect GtkWindow to make an attempt to honor a user set default size for a non-resizable window. Perhaps it's even a regression from GTK+2, not so sure. 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 10:56 PM, John Lindgren wrote: > On 12/05/2011 02:22 AM, Tristan Van Berkom wrote: >> >> On Mon, Dec 5, 2011 at 4:18 PM, Tristan Van Berkom wrote: >>> >>> 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. > > > This works for resizable windows. For fixed-size windows, however, the > label still does not ellipsize. I am attaching another test case. > Uncomment line 8, and suddenly the label expands to its full, unellipsized > width again. Interesting. The api around non-resizable windows needs clarification/more documentation. It should be noted that historically in GTK+2, non-user resizable windows are the corner case where windows are actually meant to 'shrink' down to the smallest possible size. However in GTK+3 now we have a natural and minimum size, I dont think it would make sense to shrink down to the minimum size on a non-resizable window, instead non-resizable windows should always fit the natural size (that seems to make sense). In order to limit the GtkLabel's natural size request (separate from it's minimum size request), I've added the 'max-width-chars' property. Sending you back a working test case ;-) I'll leave it to you to close the filed bug as a non-issue. ___ 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
It looks to me as though there are 3 separate problems contributing here: 1. GtkLabel does not take into account gtk_widget_set_size_request() when reporting its "natural" size: https://bugzilla.gnome.org/show_bug.cgi?id=662043 2. Nor does it take into account gtk_label_set_width_chars(): https://bugzilla.gnome.org/show_bug.cgi?id=665560 3. GtkWindow ignores gtk_window_set_default_size() and instead goes to its "natural" size if the window is not resizable: https://bugzilla.gnome.org/show_bug.cgi?id=665596 -- John On 12/05/2011 08:56 AM, John Lindgren wrote: This works for resizable windows. For fixed-size windows, however, the label still does not ellipsize. I am attaching another test case. Uncomment line 8, and suddenly the label expands to its full, unellipsized width again. -- 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 12/05/2011 02:22 AM, Tristan Van Berkom wrote: On Mon, Dec 5, 2011 at 4:18 PM, Tristan Van Berkom wrote: 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. This works for resizable windows. For fixed-size windows, however, the label still does not ellipsize. I am attaching another test case. Uncomment line 8, and suddenly the label expands to its full, unellipsized width again. -- 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 4:18 PM, Tristan Van Berkom wrote: > On Mon, Dec 5, 2011 at 9:21 AM, John Lindgren 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: GTK 3 support status
On Mon, Dec 5, 2011 at 9:21 AM, John Lindgren 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 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
hi; On 4 December 2011 02:56, Michael Cronenworth 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
hi; On 4 December 2011 02:41, John Lindgren 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/03/2011 07:41 PM, John Lindgren wrote: > Hi, > > I am wondering what the status of GTK 3 is at this time with regard > to bugs reported by application developers. 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. > > Thank you for your attention. > > -- John Lindgren Does the hint in this blog post help any? http://oli.wordpress.com/2011/11/30/gtktable-and-gtklabel-with-wrap-on-gtk-3-and-trying-to-stay-compatible-with-gtk-2/ Kevin - -- Get my public GnuPG key from http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7a/j0ACgkQ6w2kMH0L1dHTZQCfajSSs/sETm+7XhpM5vFhfrGO IS4An3wQU1GMIqoBq2IqeSUEleOU6wBX =3FNL -END PGP SIGNATURE- ___ 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/03/2011 08:41 PM, John Lindgren wrote: I am wondering what the status of GTK 3 is at this time with regard to bugs reported by application developers. 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. Thank you for your attention. Hi John, 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. [1] https://bugzilla.gnome.org/show_bug.cgi?id=660797 [2] Resizing of GtkTreeView columns resizes a window similar to your label bug. [3] http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK 3 support status
Hi, I am wondering what the status of GTK 3 is at this time with regard to bugs reported by application developers. 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. Thank you for your attention. -- John Lindgren ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
