GtkIconView displaying ellipsized label
Hi all,
I try to used a GtkIconViewer for displaying icons with very long labels. So
I used a custom layout and set the ellipsize property to the text cell.
It works well as long as the items are not selected. When an item is
selected, the size request for its text label (and focus box) is get from
the width-chars property (see GtkCellRendererText::width-chars doc) which
renders ugly.
Note I am using GTK+ 2.12.
Here is a sample code :
#include gtk/gtk.h /* GTK+ 2.12.12 */
enum
{
ICON_COLUMN =0,
NAME_COLUMN,
N_COLUMN
};
static void _fill_model(GtkListStore* list_model);
static GtkWidget* create_main_window();
static GtkWidget* _create_icon_view();
static void _fill_model(GtkListStore* list_model)
{
GtkWidget* render_widget;
GdkPixbuf* pixbuf;
GtkTreeIter iter;
const gchar* long_text = a sometime very long icon name description;
int i =0;
render_widget = gtk_invisible_new();
pixbuf = gtk_widget_render_icon (render_widget,
GTK_STOCK_DIRECTORY,
GTK_ICON_SIZE_DIALOG,
NULL);
for( i = 0; i 10; ++i)
{
gtk_list_store_append(list_model, iter);
gtk_list_store_set(list_model, iter,
ICON_COLUMN, pixbuf,
NAME_COLUMN, long_text,
-1);
}
gtk_object_sink(GTK_OBJECT(render_widget));
g_object_unref(G_OBJECT(pixbuf));
}
static GtkWidget* create_main_window()
{
GtkWidget* main_window;
GtkWidget* scolled_window;
GtkWidget* icon_view;
main_window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
scolled_window = gtk_scrolled_window_new(NULL, NULL);
icon_view = _create_icon_view();
gtk_container_add(GTK_CONTAINER(main_window), scolled_window);
gtk_container_add(GTK_CONTAINER(scolled_window), icon_view);
g_signal_connect(G_OBJECT(main_window),delete-event,
G_CALLBACK(gtk_main_quit), NULL);
return main_window;
}
static GtkWidget* _create_icon_view()
{
GtkWidget* icon_view;
GtkCellRenderer* text_cell;
GtkCellRenderer* pixbuf_cell;
GtkListStore* list_model;
list_model = gtk_list_store_new(N_COLUMN, GDK_TYPE_PIXBUF, G_TYPE_STRING);
icon_view = gtk_icon_view_new_with_model(GTK_TREE_MODEL(list_model));
/* pixbuf*/
pixbuf_cell = gtk_cell_renderer_pixbuf_new();
g_object_set( G_OBJECT(pixbuf_cell),
follow-state, TRUE,
NULL);
gtk_cell_layout_pack_start (GTK_CELL_LAYOUT (icon_view), pixbuf_cell,
FALSE);
gtk_cell_layout_add_attribute (GTK_CELL_LAYOUT (icon_view), pixbuf_cell,
pixbuf, ICON_COLUMN);
/* text : if too long we ellipsize */
text_cell= gtk_cell_renderer_text_new ();
g_object_set(G_OBJECT(text_cell),
ellipsize-set, TRUE, ellipsize, PANGO_ELLIPSIZE_END,
/* width-chars, 20, */
NULL);
gtk_cell_layout_pack_start (GTK_CELL_LAYOUT (icon_view), text_cell,
FALSE);
gtk_cell_layout_add_attribute (GTK_CELL_LAYOUT (icon_view), text_cell,
text, NAME_COLUMN);
/* tooltip for long text */
gtk_icon_view_set_tooltip_column(GTK_ICON_VIEW(icon_view),
NAME_COLUMN);
/* fill model */
_fill_model(list_model);
return icon_view;
}
gint main(gint argc, gchar** argv)
{
GtkWidget* main_window;
gtk_init(argc, argv);
main_window = create_main_window();
gtk_widget_show_all(main_window);
gtk_main();
return 0;
}
Regards
Nicolas
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Website proposal for usability
On 27/08/10 11:05, Devin Samarin wrote: 2010/8/27 Martyn Russellmar...@lanedo.com: On 27/08/10 01:53, Devin Samarin wrote: On Thu, Aug 26, 2010 at 3:22 AM, Martyn Russellmar...@lanedo.comwrote: On 21/08/10 12:12, Devin Samarin wrote: I finished the re-design of the GTK-Doc area: http://eboyjr.homelinux.org:8080/gtk/gtk-doc/ Hmm, is the site down? Doesn't seem to be available at the moment: http://eboyjr.homelinux.org:8080/gtk/ -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Website proposal for usability
Oh sorry I didn't e-mail you directly. I moved it to http://eboyjr.homelinux.org:8081/ to solve some directory issues. On 8/31/10, Martyn Russell mar...@lanedo.com wrote: On 27/08/10 11:05, Devin Samarin wrote: 2010/8/27 Martyn Russellmar...@lanedo.com: On 27/08/10 01:53, Devin Samarin wrote: On Thu, Aug 26, 2010 at 3:22 AM, Martyn Russellmar...@lanedo.com wrote: On 21/08/10 12:12, Devin Samarin wrote: I finished the re-design of the GTK-Doc area: http://eboyjr.homelinux.org:8080/gtk/gtk-doc/ Hmm, is the site down? Doesn't seem to be available at the moment: http://eboyjr.homelinux.org:8080/gtk/ -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
On Mon, 2010-08-30 at 18:20 -0400, Behdad Esfahbod wrote: On 08/24/10 13:42, Tristan Van Berkom wrote: Is this a kind of widget that we are interested in adding to GTK+ ? What are the usecases for such a container? The selection of features looks a bit arbitrary to me. I wanted it for Glom, which has vertical columns of widgets, flowing the widgets into the next column, like text in newspaper columns: http://www.glom.org/wiki/index.php?title=File:Small_glom_data_details.png Glom currently uses an awful buggy hacky C++ widget that I wrote, but GtkWrapBox should work properly. Gimp apparently has something similar, maybe for its tool pallete or tool preference windows: http://developer.gimp.org/api/2.0/app/GtkWrapBox.html -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: (Style) Property review
Hi Matthias, On Sun, Aug 29, 2010 at 5:16 AM, Matthias Clasen matthias.cla...@gmail.com wrote: 5) We have an indicator-size property in GtkCellRendererToggle , but indicator-size style-property in GtkCheckButton and GtkCheckMenuItem. This was unavoidable, since cell renderers are not widgets and can't have style properties. Maybe the style-context work will let us fix that. Oh yes, if style-context makes such things possible, that would be great. 'opt-in' style properties: These were added over time to let themes opt-in to some new GTK feature, typically more detailed detail strings. 6) GtkEntry::state-hint GtkTreeView::row-ending-details row-ending-details is indeed a property that enables richer detail strings. I think if we hadn't done it this way, themes would have broken. What's the exact plan with such properties? The properties are removed and themes will be expected to update to handle the different and richer detail strings? regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: (Style) Property review
On Sat, 2010-08-28 at 23:16 -0400, Matthias Clasen wrote: I took some time last night to look over the impressive list of properties of all widgets. Here are some cleanups that we might consider for GTK3: Thanks for looking into this. There are several cases where we seem to have a mixup between style and non-style properties: 4) We have a shadow-type property in GtkEntry, GtkFrame, GtkScrolledWindow, GtkArrow, GtkHandleBox and GtkViewport. But we have a shadow-type style property in GtkStatusbar, GtkSpinButton, GtkMenuBar, GtkToolbar and GtkComboBox. Not sure what the best way forward is here. I would imagine the most common developer requirement here is to be able to turn the border (i.e. shadow) on or off. For example, a GtkEntry may be used in some composite widget where a border is drawn by something else. It's probably best to allow the themes to choose the style of the shadow and allow application developers to just determine if there should be a shadow at all. 'opt-in' style properties: These were added over time to let themes opt-in to some new GTK feature, typically more detailed detail strings. 6) GtkEntry::state-hint GtkTreeView::row-ending-details GtkRange::activate-slider GtkRange::stepper-position-details GtkRange::trough-side-details GtkWidget::wide-separators I think all of these should be removed, and themes will be expected to handle the richer details. Agreed. 7) There's a whole zoo of layout (padding, spacing) related properties and style properties. I haven't had the time to sort those out yet. One thing I would like to see is the removal of focus as an additional drawing operation. Many themes don't want to draw a simple rectangle to indicate focus state and the focus style properties (for example, interior-focus) can make the widget geometry much more complex (see http://live.gnome.org/GnomeArt/Tutorials/GtkThemes/GtkButton for an illustration). A simplification of padding and border properties would also help to make it easier to write themes. The CSS definitions of margin, border and padding may be useful in making the naming of these properties more consistent and may allow the removal of style properties that duplicate the behaviour (for example vertical-padding and horizontal-padding in GtkMenu, and internal-padding in GtkMenuBar). Regards, Thomas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
On Mon, Aug 30, 2010 at 11:46 PM, Michael Torrie torr...@gmail.com wrote: This is only partially true. Some apps ship as an .mpkg installer, which is really a bunch of separate, dependant packages that install together. But under the hood they are installed as separate packages with dependency resolution. That's true, I did ignore mpkg's. I'm not sure what the split is between apps that distribute as a .app or a .mpkg ... As for users not expecting to have to install some dependency, on app in common use, MacFusion, requires that the MacFuse .pkg be installed. This is an exception that proves the rule. Also Office 2008 requires the Rosetta .pkg package to be installed, but helpfully offers to install it for you. Actually, this appears to just be just laziness on the part of MS. Rosetta seems not to be needed: http://forums.mactalk.com.au/11/72330-install-microsoft-office-2008-snow-leopard-without-rosetta.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [GObjectIntrospection] Cleaning up GIRepository
On Tue, Aug 31, 2010 at 9:01 AM, Giovanni Campagna scampa.giova...@gmail.com wrote: Il giorno lun, 23/08/2010 alle 09.10 -0300, Johan Dahlin ha scritto: [not on gtk-devel, so CC me replies] On Fri, 20 Aug 2010 01:59:09 Giovanni Campagna scampa giovanni gmail com wrote: First of all, sorry if this is not the correct mailing list but I did not find a more suited one (and Glib discussion happens here anyway). I started looking for GObjectIntrospection API recently and I've seen a lot of overlap with the original GObject/GType system. In particular, I would like to ask why the following were reimplemented (using the typelib and not run time type information): There are three primary reasons for not doing things within the GType system. A) GLib was up until last year moving very slowly, it seems that multiple year processes were the norm for even the smallest functional additions. B) the GIRepsitory API reflects the internals of a binary typelib which will be loaded from disk via mmap. It's intended to be used by multiple processes within a gnome desktop and needs to use as little writable memory as possible. I'm not sure how many bytes that needs to be allocated for a GObject, but it's in the multiple 100 byte range, while creating a GIBaseInfo only requires 44 bytes on 32-bit systems. Well, if so much memory is required for a GObject, then making GObject more lightweight (possibly without signals and properties) would make sense. Secondly, little is gained by sharing the typelib, if the information is *also* contained in a different private writable memory area. I'd welcome you to do the math, but I would be surprised if the savings are less than in the MB range per application using the full gnome stack. No such applications exists as far as I know, the best comparisons will be old python bindings vs new ones, but they also improve/change several other things that will make the memory requirement drastically decreased with the new g-i based bindings. C) in many cases we want to avoid using the GType because it is not registered at that point. Registering the GType means that we have to recursively register the type and all its parents. Writing a lazy binding for dynamic languages like python and javascript means that the type registration should only be done when needed, eg such as when the class wrapper is accessed - usually when the first instance of specific class is created. And why you would ever need information about a class which is not used and/or available to use? For a library such as Gtk+ which provides hundres of types it is just not efficient to create wrappers as soon as they become available. GObjectInfo needs to know about properties and signals which are also available in the glib type system because annotations might override them. For instance, we want to include array/transfer/direction metadata which is only available in the typelib. Direction doesn't make sense for properties and I proposed how to encode array and transfer in GParamFlag. When you get these modifications designed, implemented and included into glib let me know so we can continue this discussion. Registering an unref/ref method requires glib extensions as far as I understand. No, the (un)ref method is exposed in the GTypeValueTable. The value transformation routines were added since the dynamic bindings for objects such as GstMiniObject use gst_mini_object_set/get_value They should be able to use g_value_set_instance / g_value_peek_pointer, keeping gst_mini_object_*_value for C convenience. Patches are welcome to move over to that scheme, remember that you'll need update the gjs to use the new API as well. Why does the GIRepository API reflect the typelib? The typelib design should only be an implementation detail of libgirepository, that can be fixed at any time by recompiling gir files. It is unfortunate that implementation details leaks up to the API, but it is unavoidable in this case as the performance requirements made it impossible to design a nice GObject based api. I would love to be proved wrong in this case, but I don't have the time to rewrite the whole API, update the bindings, the applications and benchmark it against the current system to find out if it's worth it. -- Johan Dahlin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
On Aug 31, 2010, at 6:56 AM, Martyn Russell wrote: On 27/08/10 17:48, Matthias Clasen wrote: As long as the people working on GTK-OSX do it with a us-vs-them attitude (like you display here by talking about the GTK developers in third person), things are not going to change. If you start considering yourself part of the team and actively engage, things can and will change. After reading the thread, I have a few thoughts on the matter. 1. I agree with Matthias, I did get the feeling there is an us vs them in the thread. 2. Equally I agree, when something new comes along, Win32/OSX are often an after thought (that's just my perception). I have spent time building packages for proprietary apps to run on Windows in the past and I know how this can be disconcerting. BUT, GTK+ is targeted mostly with X11 in mind we should not forget that. X11 has the larger use base. I think that people that maintain backends really need to get involved more in meetings, planning, designing, etc if they want to change either of the above issues. About having ONE sanctioned package (for Windows or MAC) I think Yes, we should be doing that, as an app developer before I was more involved in the community, there was no right this is the distributed package we should be using, I had to download it myself and build it myself. Why not channel the work used to make the Pidgin/GIMP downloads with GTK+ into a useful package hosted on gtk.org? Ultimately, having GTK+ packaged *with* each app also has its benefits, like stability on Windows when others GTK+ versions exist/get upgraded for GIMP/Pidgin/etc. Additionally, one of the MAJOR features we boasted when selling our apps was that we could guarantee it worked on ALL versions of Windows (though that later changed) without needing to download .NET for that version of Windows or because something got deprecated. About having Mac on the gtk.org site, I think this does make sense. As a *user* of GTK+ porting my app to these operating systems, I don't have confidence in GTK+ when a port of it is hosted off site. I haven't checked, but I am pretty sure QT doesn't do this. Generally, we should be presenting a more united front for application developers looking to invest time in GTK+. Perhaps this is where we should be focusing some of the GNOME foundation's money if resources are short? Qt is a bit of a strawman: Its sole reason for existing is to provide a cross-platform toolkit. It's also a commercial product, maintained by a huge corporation; it would indeed be strange if some of its functionality were developed outside. WxWidgets might be a better comparison, except that it, too, is solely a cross-platform toolkit. AFAIK, Qt doesn't ship a feature until it's working on all supported OSes. OTOH, they also don't let outsiders see their VCS repos. Wx strives for the same ploicy, but being a volunteer project doesn't always make the goal. They've been struggling for a couple of years with switching their primary Mac port from Carbon to Cocoa. None of which has much of anything to do with Gtk+: As is abundantly clear from this thread, Gtk+ is primarily a backend for the Gnome desktop on Linux, which happens to support most of its basic features on Win32 and Quartz. The reason that this thread (and similar ones in the past) get going is largely because of false advertising: Gtk+ claims to be a cross-platform toolkit. The warnings on the Gtk-OSX website that have sparked this long and vituperative thread merely point out to developers that if they want to write an application that they can distribute to the majority platforms (sorry, that most certainly does *not* include X11) should look elsewhere. I don't know why Gtk-OSX isn't on Gnome.org. (Gtk.org is just a PR website; all of the development resources are provided by Gnome.org.) The project was originated by Richard Hult, who had AFAICT full privs on Gnome for project creation both in VCS and on Bugzilla, but he chose to use Github for VCS and to provide PR, documentation, and support on his former company's (Imendio.AB) website, and downloads at a private domain (www.gtk-macosx.org). It's now on Sourceforge because when Richard decided with his partner wind up Imendio and to withdraw from Gtk+, he asked on his forum for someone to take over maintaining the build system. I bit, and after some probing discovered that he'd not been successful in getting anyone to take over *any* of the components; he had some hope that one or more of his former Imendio employees who were still involved with Gtk+ would take over maintaining the Gtk+ parts. I quickly discovered that it would take some time and a lot of work to get a project started at Gnome.org. It took a week at Sourceforge, and only that long because I did a hostile takeover of a moribund project that was a fork of Gtk 1 whose name I wanted. Pidgin doesn't support quartz; the OSX
Re: Website proposal for usability
Okay there's kind of a problem :/ The Ethernet cord that connected the server to the router is damaged since my friend sort of yanked it too hard when he tripped over it! :/ So until I get a new cord the website won't be working and I won't have the opportunity to get a new one for a while... Maybe I can e-mail the files for it to someone as a zip? Sorry guys, Devin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk_container_new_child (was Re: Wrapping Box Container)
Hi, On Mon, Aug 30, 2010 at 9:51 PM, Havoc Pennington h...@pobox.com wrote: With my proposed padding cleanup though that issue goes away: child = g_object_new(TYPE_MYCHILD, padding, 5, h-align, GTK_ALIGN_FILL_HORIZONTAL, NULL); insert_child(layout, child, 2, GTK_WRAP_BOX_PACK_Y_EXPAND); Really great would be: gtk_container_add_with_properties(layout, child, position, 2, y-expand, TRUE, padding, 5, h-align, GTK_ALIGN_FILL_HORIZONTAL, NULL); which would work if we made gtk_container_set() and friends fall back to props on the child if not finding a child prop on the container. Kind of magic, but also really handy and results in very readable code. The patch is kind of a pain because gtkcontainer.c relies on weird gobject internals (seriously, #include gobject/gobjectnotifyqueue.c ?) and stealing part of g_object_set() with public GObject API basically isn't possible. However, either a bit of a hack in here or a quick API addition to libgobject would make this a simple feature to accomplish. EVEN MORE AWESOME would be: child = gtk_container_new_child(layout, MY_TYPE_WHATEVER, position, 2, y-expand, TRUE, padding, 5, h-align, GTK_ALIGN_FILL_HORIZONTAL, NULL); sweet! even construct-only properties could be set here. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
