gtkLabel resize itself and resize the whole window
Hello I have a Window containing (gtk_container_add(window, box);) a GtkBox (which is a GtkVBox in reality) ; this GtkBox containing a GtkHBox which contain a GtkLabel. With Gtk2 : the text get cut off by the edge of the widget if it exceeds the widget size. But with Gtk3 the window extend itself when the text is too long. How can I avoid this behaviour ? I tried the set the window, the VBox and the HBox hexpand-set and vexpand-set properties to FALSE. But it doesn't change anything. I tried to set the Label gtk_label_set_max_width_chars but it increase the heigh of the Label ... I am not used at Gtk+ programming so I search in the doc ... but until now I didn't found anything useful. Could you help me please. Thanks in advance. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Different looking toolbars and missing shadows with GTK3
Hi, I just ported my application to GTK3 (gtkmm-3.0 more specifically). The process went smoothly, but a few minor questions relating to the looks of my application in GTK3 remains. I'm using the Adwaita theme (the GNOME default I believe) and all my GUIs are made in Glade and loaded through GtkBuilder. So: 1. The toolbar in my app looks different from the ones in e.g. Nautilus and Evolution. The toolbar in Nautilus has a nice dark, gradient look, whereas my toolbar does not; no gradient, a different button look etc. Question: how come and what do I do to fix it? 2. I get no shadows (as in GtkShadowType) on any of my widgets (toolbar excepted, it has an out-shadow), no matter what I try. Is this intentional, a Glade/GtkBuilder bug or a stupid mistake on my part? Other apps such as Evolution still has shadows so I'm guessing its one of the latter two. I'm guessing both my problems are some glaring omission on my part, hopefully someone can point me in the right direction :D Thanks! /Staffan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkLabel resize itself and resize the whole window
Thanks for your answer. What I want exactly is : When the text in the GtkLabel is too long (it exceeds the widget size), I want the text to get cut off by the edge of the widget. Instead of increasing automatically the size of the Widget (and so the whole window). Le Tue, 31 May 2011 14:46:20 +0200, Emmanuel Thomas-Maurin manutm...@gmail.com a écrit : On 05/31/2011 12:32 PM, Maxime de Roucy wrote: Hello I have a Window containing (gtk_container_add(window, box);) a GtkBox (which is a GtkVBox in reality) ; this GtkBox containing a GtkHBox which contain a GtkLabel. With Gtk2 : the text get cut off by the edge of the widget if it exceeds the widget size. But with Gtk3 the window extend itself when the text is too long. How can I avoid this behaviour ? I tried the set the window, the VBox and the HBox hexpand-set and vexpand-set properties to FALSE. But it doesn't change anything. I tried to set the Label gtk_label_set_max_width_chars but it increase the heigh of the Label ... You may check out gtk_widget_set_size_request(). BTW, it's not clear what you want to do exactly. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Different looking toolbars and missing shadows with GTK3
On Tue, 2011-05-31 at 14:57 +0200, Staffan Gimåker wrote: 2. I get no shadows (as in GtkShadowType) on any of my widgets (toolbar excepted, it has an out-shadow), no matter what I try. Is this intentional, a Glade/GtkBuilder bug or a stupid mistake on my part? Other apps such as Evolution still has shadows so I'm guessing its one of the latter two. Turns out the shadows had just gotten lost in translation. Annoying, but fixable. Still interested in hearing how to get uniformly looking toolbars. /Staffan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkLabel resize itself and resize the whole window
On 05/31/2011 03:06 PM, Maxime de Roucy wrote: What I want exactly is : When the text in the GtkLabel is too long (it exceeds the widget size), I want the text to get cut off by the edge of the widget. Instead of increasing automatically the size of the Widget (and so the whole window). You can get label width with gtk_label_get_layout() and pango_layout_get_pixel_size(). What you could do is making a little function to determine where the text string must be cut off, depending on max width, sth like: text length = 1 while (label width max label width) text length ++ -- Emmanuel Thomas-Maurin manutm...@gmail.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Different looking toolbars and missing shadows with GTK3
Hi, Still interested in hearing how to get uniformly looking toolbars. The toolbar should have the 'primary-toolbar' style class, e.g. do gtk_style_context_add_class (gtk_widget_get_style_context (toolbar), primary-toolbar); in the code, or object class=GtkToolbar style class name=primary-toolbar/ /style /object in the GtkBuilder ui definition. Florian ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Different looking toolbars and missing shadows with GTK3
On Tue, 2011-05-31 at 15:35 +0200, Florian Max wrote: Still interested in hearing how to get uniformly looking toolbars. The toolbar should have the 'primary-toolbar' style class, e.g. do gtk_style_context_add_class (gtk_widget_get_style_context (toolbar), primary-toolbar); in the code, or object class=GtkToolbar style class name=primary-toolbar/ /style /object in the GtkBuilder ui definition. Thank you, that works. It looks kind of messed up for vertical toolbar, but that's a different issue. It also seems like you cannot set this from within Glade (3.10.0) at the moment, but I can live with that. /Staffan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkLabel resize itself and resize the whole window
Problem solved Solution : use gtk_label_set_ellipsize Thanks a lot :-D I didn't know that I have to set the ellipsize mode to tell the Label to cut the text when there is not enough space. I thought that : gtk_label_set_line_wrap(myLabel, FALSE); would have been sufficient since the doc say : gtk_label_set_line_wrap : Toggles line wrapping within the GtkLabel widget. TRUE makes it break lines if text exceeds the widget's size. FALSE lets the text get cut off by the edge of the widget if it exceeds the widget size. Thanks again Le Tue, 31 May 2011 15:32:12 +0200, Vivien Malerba vmale...@gmail.com a écrit : gtk_label_set_ellipsize()? Vivien 2011/5/31 Maxime de Roucy maxime.dero...@gmail.com: Thanks for your answer. What I want exactly is : When the text in the GtkLabel is too long (it exceeds the widget size), I want the text to get cut off by the edge of the widget. Instead of increasing automatically the size of the Widget (and so the whole window). Le Tue, 31 May 2011 14:46:20 +0200, Emmanuel Thomas-Maurin manutm...@gmail.com a écrit : On 05/31/2011 12:32 PM, Maxime de Roucy wrote: Hello I have a Window containing (gtk_container_add(window, box);) a GtkBox (which is a GtkVBox in reality) ; this GtkBox containing a GtkHBox which contain a GtkLabel. With Gtk2 : the text get cut off by the edge of the widget if it exceeds the widget size. But with Gtk3 the window extend itself when the text is too long. How can I avoid this behaviour ? I tried the set the window, the VBox and the HBox hexpand-set and vexpand-set properties to FALSE. But it doesn't change anything. I tried to set the Label gtk_label_set_max_width_chars but it increase the heigh of the Label ... You may check out gtk_widget_set_size_request(). BTW, it's not clear what you want to do exactly. ___ 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: About gsettings aborting on unkown schemas
Le lundi 30 mai 2011 à 20:17 -0400, Morten Welinder a écrit : Doing a g_return_val_if_fail is fine here. That will give the user a chance of saving his work. This is in contrast to g_error which is a sure way of eating data. There's no work of data here. Programs load GSettings on start, and OTC it's far better for users' data to ensure a program won't start without schemas. If it pretends to work, it might crash at any point because the code paths run when schemas are not present are poorly tested (if at all), and do nasty things to the data it works with. Regards ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Am Mon, 30 May 2011 21:13:16 -0400 schrieb Havoc Pennington: Hi, On Mon, May 30, 2011 at 8:37 PM, Shaun McCance sha...@gnome.org wrote: But I want to point out that my point was never that GLib should behave like a language with exceptions. Just that it should let bindings in those languages behave like they should. I agree that would be ideal if you were optimizing for non-C. But the only way to do that is to replicate the entire API currently lacking an error indicator, with a second _with_error version of every function. Some functions may happen to have some other ad hoc way to do an error (like returning NULL) but it'd just be some subset without rhyme or reason. If you aren't prepared to do the _with_error() replication of the API, then doing it here and there at random is kinda weird. Either it's needed or not, it isn't needed here and there at random. This is a great argument. There was a mistake. It made you notice the API is inconsistent, so you suddenly insist that GLib can't be improved further without rewriting all the functions I would personally prefer it if you were honest and would say that your opinion is set, instead of giving bogus arguments. Including the one about g_error. Then nobody would continue wasting time on trying to explain his point of view to deaf ears. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
On Mon, May 30, 2011 at 8:17 PM, Morten Welinder mort...@gnome.org wrote:
The core principle that allows most functions to always succeed is
that programming bugs are not thrown, they just terminate the
program.
Havoc, the data doesn't agree with that assertion.
Let's look at numbers:
glib, number of not-crashing on programmer errors:
# find glib -type f -name '*.c' -print | xargs -n100 grep -E
'g_return_(val_)?if_fail' | wc -l
1509
glib, number of crashing on programmer errors:
# find glib '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_assert|g_error' | wc -l
213
gtk+, number of not-crashing on programmer errors:
# find gtk '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_return_(val_)?if_fail' |
wc -l
5637
gtk+, number of crashing on programmer errors:
# find gtk '(' -type f -name '*.c' -print ')' -o '(' -type d -name
tests -prune ')' | xargs -n100 grep -w -E 'g_assert|g_error' | wc -l
693
So the overwhelming conclusion is that glib and gtk+ handle programmer
errors by issuing a critical and returning. Not by crashing.
It tips even more in that direction when you realize that a good
fraction of the crashing calls do not actually catch (library user)
programmer errors, but problems more in the memory-corruption
department.
We know that not having the schema around is not good. Going postal
and killing the program is not the solution.
Doing a g_return_val_if_fail is fine here. That will give the user a
chance of saving his work. This is in contrast to g_error which is a
sure way of eating data.
This is getting very tiresome. Your statistics don't make any sense. A
programming error is a programming error, and the fact that we
indicate some of them with g_return_if_fail instead
of g_assert is a mere convention, not an invitation to handle them at runtime.
How about everybody who wants their programs to stumble along when
installed incorrectly just use g_settings_list_schemas() to determine
the presence of their schemas, instead of prolonging this discussion
even further ?
Thanks,
Matthias
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I have a problem
On Mon, May 30, 2011 at 11:02 AM, Benjamin Otte o...@gnome.org wrote: That said, let me get into how I think this whole interaction between designers and developers should work inside GTK. I envision the design process for new widgets or interactions to go something like this: 1) GNOME designers come up with an idea 2) GTK developers implement the idea 3) application developers and designers (both inside GNOME and ISVs) use it in their applications There's maybe a 1.5) GNOME ships a prototype application to test things in between. (Of course, this is not a top-down approach. Ideally the application developers provide feedback about how they think GTK should work to the GTK developers and the GTK developers I think this is a bit backwards. Your afterthought of 1.5 is very essential, and is exactly what is happening in the contacts app now. We cannot go straight from design to toolkit, having a prototype and using it in a number of apps for a while is important for weeding out the good ideas from the bad. (Designers are only humans too, after all, and come up with plenty of ideas that don't work out, just like the rest of us). Going from design/mockup straight into the toolkit is a recipe for the kind of issues we've had with e.g. the switch. And I don't think GTK+ developers implement the idea is scalable at all. If creating new widgets is too hard for average application developers, we need to make it easier. Of course, there is a big difference between a prototype that matches the mockup and a widget that meets the quality standards of GTK+, and this is where I see GTK+ developers come in: reviewing the prototype, making sure it matches the API conventions of GTK+ and is properly bindable, flippable, accessible, themable, etc... One thing that seems clear is that we can't have the toolkit become just a collection of UI paradigms of the past. It needs to keep evolving. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Clarification need help on GTK+ tooltip ( custom tool tip)
Hi all, Actually i am trying to create my own tooltip with image in GTK+, ( the tooltip should be like a rectangle with rectange contaning an image and text ,provided with arrow) let me know how i can do it i tried with voidgtk_tooltip_set_text http://developer.gnome.org/gtk3/stable/GtkTooltip.html#gtk-tooltip-set-text (*GtkTooltip http://developer.gnome.org/gtk3/stable/GtkTooltip.html *tooltip*, *const gchar http://developer.gnome.org/glib/unstable/glib-Basic-Types.html#gchar *text*);voidgtk_tooltip_set_icon http://developer.gnome.org/gtk3/stable/GtkTooltip.html#gtk-tooltip-set-icon (*GtkTooltip http://developer.gnome.org/gtk3/stable/GtkTooltip.html *tooltip*, *GdkPixbuf http://developer.gnome.org/gdk-pixbuf/unstable//gdk-pixbuf-The-GdkPixbuf-Structure.html#GdkPixbuf *pixbuf*);voidgtk_tooltip_set_icon_from_stock http://developer.gnome.org/gtk3/stable/GtkTooltip.html#gtk-tooltip-set-icon-from-stock (*GtkTooltip http://developer.gnome.org/gtk3/stable/GtkTooltip.html *tooltip*, *const gchar http://developer.gnome.org/glib/unstable/glib-Basic-Types.html#gchar *stock_id*, *GtkIconSize http://developer.gnome.org/gtk3/stable/gtk3-Themeable-Stock-Images.html#GtkIconSize size*);voidgtk_tooltip_set_icon_from_icon_name http://developer.gnome.org/gtk3/stable/GtkTooltip.html#gtk-tooltip-set-icon-from-icon-name (*GtkTooltip http://developer.gnome.org/gtk3/stable/GtkTooltip.html *tooltip*, *const gchar http://developer.gnome.org/glib/unstable/glib-Basic-Types.html#gchar *icon_name*, *GtkIconSize http://developer.gnome.org/gtk3/stable/gtk3-Themeable-Stock-Images.html#GtkIconSize size*);voidgtk_tooltip_set_icon_from_gicon http://developer.gnome.org/gtk3/stable/GtkTooltip.html#gtk-tooltip-set-icon-from-gicon (*GtkTooltip http://developer.gnome.org/gtk3/stable/GtkTooltip.html *tooltip*, *GIcon http://developer.gnome.org/gio/unstable/GIcon.html *gicon*, *GtkIconSize http://developer.gnome.org/gtk3/stable/gtk3-Themeable-Stock-Images.html#GtkIconSize size*); but could not succed in getting as i wanted let me know the ways/posssibilites, Thanks in advance for your valuable input -- regards , Arun Kumar R, *Aim High - Think Deeply- Act Quickly* ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[ANN] Girlook 0.1.2 Released
News: = * Fix a bug on searching data_files location reported by Erick Pérez Castellanos. * Better search function. README: === Girlook is a GUI inspector for GObject Introspection Repository (.gir) file. Copyright Mozbugbox 2011 License: GPL v3.0 or later. Requirement: * lxml * PyGObject with GIR enabled * Distribute (or setuptools) Website: https://sourceforge.net/projects/girlook/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Hi, On Tue, May 31, 2011 at 5:47 AM, Christian Dywan christ...@lanedo.com wrote: This is a great argument. There was a mistake. It made you notice the API is inconsistent, so you suddenly insist that GLib can't be improved further without rewriting all the functions It didn't make me notice - I've known about this issue for many years, including in all the other threads about it. I also wrote the GError API docs 11 years ago, which explain the issue. You can find years-old emails with me making the same duplicate error-throwing API for bindings point about libdbus, if you do some googling. This is a 15-year-old issue, or so. It's a tradeoff. We could redo thousands of functions with duplicate functions to be used only from language bindings, or we could live with this design decision. I personally think 15 years of experience show that we can survive without a major API redo. I agree that g_warning/critical can be nicer than g_error in a certain way, fwiw, though when it's up to me I make both abort and consider them the same. Anyway, I don't make the decision on this. I'm just trying to tell you why it is how it is and just how long it's been that way. This thread is hardly the first one to suddenly realize this is how GLib works and get upset about it. But GLib has always worked this way. There are other people you'd have to convince if you wanted to change anything. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
On Fri, 2011-05-27 at 11:57 -0400, Matthias Clasen wrote: On Fri, May 27, 2011 at 7:42 AM, ecyrbe ecy...@gmail.com wrote: I just filled this bug : https://bugzilla.gnome.org/show_bug.cgi?id=651225 Mathias closed it as wontfix, this is by design.. i'm told that it's not a bug it's a feature! So if my desktop is crashing it's a feature and nobody is willing to fix it?I really would like to have another answer than this one. The fix is to install the missing schema. Sorry to pick on Matthias, by responding to his mail, but I think that general-purpose thinking is preventing people from realizing that there is a real problem that needs to be fixed here. Yes, programs should not be written to run with missing schemas. Yes, we don't have ways clean ways of raising exceptions for programmer or system configuration errors. But that doesn't change the fact that if from some interactive environment (GNOME Shell looking glass console, python command line, etc), I try to use GSettings and typo the name of a schema, it should not; _should not_ make the entire environment go boom. So, let's add alternate API that allows for failure without going boom and blowing up the world, and let's figure out how to get that hooked up to languages with exceptions automatically. Yes, this is made harder by the fact that it's a constructor, not a normal function, but it's certainly doable; we just have to come up with a convention. (The idea that comes t mind is that we add a construct-only property that means construct in an error state, and and a getter to check for and retrieve the GError.) - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
On 05/31/2011 03:12 PM, Owen Taylor wrote: So, let's add alternate API that allows for failure without going boom and blowing up the world, and let's figure out how to get that hooked up to languages with exceptions automatically. Yes, this is made harder by the fact that it's a constructor, not a normal function, but it's certainly doable; we just have to come up with a convention. We already have it; GInitable. -- Dan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
