Inner window size issue
Hey List, How on earth do I open a window containing a couple of widgets, one of which is a ScrolledWindow?? This ScrolledWindow displays an image, and now I'd like to fit the size of the ScrolledWindow to the size of the image in pixels. I have read up on the geometry stuff, but it doesn't really seem to fit my needs. I don't want to set minimum sizes but rather default sizes. Right now, it seems all I can do is to open the top-level window and keep programmatically resizing it until the contained ScrolledWindow has the proper size?!?! Thanx Nikolaj :o) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
[gimpwin-users] How to iconify in systray??
This is off-topic for the gimpwin-users list. Please ask GTK+ programming questions on gtk-app-devel-list (see http://www.gtk.org/mailinglists.html). It's perfectly OK to ask also Windows-specific questions there. efl65 writes: I just wanna know if it's possible to cionify a window in systray under Windows with GTK+?? and how to do this.. Not really. In Windows you cannot have windows in the notification area (systray). Instead there is a separate API to add/remove just icons in the systray. Look up Shell_NotifyIcon on MSDN. In GTK+ 2.10 there will be a platform-independent API to manage status icons. I think it would be relatively trivial (if you know what you are doing) to lift that code (gtkstatusicon.c) out of HEAD GTK+ and use in an application together with an older GTK+, too. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
combo rant
[I already posted this to the gtk-list, I'm not sure which list I should use] I'll start with apologies for upcoming rant. In general I like Gtk: I'm programming with it for a couple of years now and it's easy to learn, reasonably fast, has many bindings, runs on windows, and is highly themable. However, an ever returning frustration for me is the lack of a decent combobox. With every release of Gtk I hoped for a better combo, but to be fair, GtkCombo is in some ways still a better option than GtkComboBox. I notice several problems, that don't seem to be solved soon, if at all. Since I don't understand the inner workings of Gtk and I also don't have time for that, I'll write to this list with the hope that something will change, or at least that I know _why_ it is the way it is. 1. Could someone please explain to me why we don't have a gtkcombobox widget that's comparable with the Windows one or QT's combo? Please give me at least a good reason! I'll address some specific things now: 2. Popup behaviour. Lots about this is already in this thread: http://mail.gnome.org/archives/gtk-devel-list/2005-March/msg00149.html I can only agree. For me, the most important things are the direction of the popup, and the size. Because of screenspace menus are sometimes poped up above the widget, sometimes below, therefore covering information you just filled in those widgets. A function where you can specify the popup behaviour would be nice, eg gtk_combo_box_set_popup_direction(DOWN) or gtk_combo_box_set_popup_direction(SELECTED) for current behaviour. When I make a multi column combo it already behaves much more the way I'd like to. 3. Default mode (so no apears-as-list mode) pops up the menu with the current selected item at the location (height) of the widget itself. If an item from somewhere of the midle was chosen, the menu appears both above and below the widget. If you don't know what I mean, start gimp and save something. The filetype (extension) selection shows this problem. Also, when the active item was near the beginning, you already see the full height of menu list, with some scrollbar-like thing on top and bottom. Not only does that look bad, it's also quite useless, because you'll almost by definition want to scroll down, therefore filling the menu; it could have shown all items imediately. When the menu is filled with all options, these scroll things disappear. If you have so many options that they can't fit on the screen, these scroll things remain. Since these scroll things are not a scrollbar, you can't quickly drag the bar and go quickly to the item you're iterested in. So, why not make A) a scrollbar like in treeview, or B) make long items branch like in windows 4. In apears-as-list mode, again te popup direction and size are a problem. This time we have a scrollbar however, so a function where you can specify the maximum number of items before forcing a scrollbar would be nice. Just like in html. I think this really should be possible. Others want this as well: http://mail.gnome.org/archives/gtk-app-devel-list/2004-June/msg00342.html Unfortunately, nobody gave a reaction to this. I really hope at least someone will share his thaughts about this. I know I know, the Gnome Human Interface Guidelines say that with many items a treeview selection may be a better solution, but I disagree. There are just too many situations where you want a single row widget where you can select from, instead of a space consuming treeview. Even the big Gtk examples are suffering from this problem: I already mentioned Gimp, but also Dia (realy obvious), Gnumeric (has its own combo, eg the font selector) and gftp (still uses the deprecated GtkCombo). On with the problems: A When you click in the textbox (and not the arrow), you have to keep mouse button pressed B When you click the double arrow and just start typing for completion you have te type enter twice. In my opinion one time should be enough, even in the situation where there's no match (just return currect selection) C The width is not optimal. When showing the list it should use the width of the biggest item, or provide a horizontal scrollbar if necesary as well OK, this is a lot of text for maybe not-so-important details. But these details are annoying. And I suspect I'm not the only one. Please give some reaction and possible solutions. Thanks a lot. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: combo rant
My current project requires that I write wrappers around all common GTK and Win32 .NET controls to give them a common functionality set. Sort of like what wxWindows would do but much much more simple with much less functionality. I mention this because with the exception of the GtkComboBox control, GTK flat out embarrasses the .NET widgets. Most of the time I'm struggling to make the .NET controls do something simple while scaling the GTK functionality back dramatically. It isn't so much that the GTK combo is bad, but way to complex. I would say the Win32 combo is much better, but at least it's simple. To be fair, I've worked with combo controls from at least 4 different widget sets and they all were horrible. Win32, GTK, Web, Borland, Java, they all suck. I think as a control, the combo control is just a bad concept. I will probably create my own combo type control in addition to the native Win32/GTK combo box controls. It will basically be a text field with a button directly to the right of it. When the button is clicked a separate window will be opened with a grid inside it. This allows me to bypass all the horrible problems with combos on each platform. It will be a little slower for a user to use than a combo, but the ease of use should be better since the user/developer can resize the grid, etc if needed. On Wed, 2005-11-23 at 13:55, control H wrote: [I already posted this to the gtk-list, I'm not sure which list I should use] I'll start with apologies for upcoming rant. In general I like Gtk: I'm programming with it for a couple of years now and it's easy to learn, reasonably fast, has many bindings, runs on windows, and is highly themable. However, an ever returning frustration for me is the lack of a decent combobox. With every release of Gtk I hoped for a better combo, but to be fair, GtkCombo is in some ways still a better option than GtkComboBox. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
SIGABRT due double free
Hi, I'll try to explain my problem as clear as possible: I'm developing a gtk/gnome application with two threads. An schema of the application is this: void thread_func(){ blah blah ... } main(){ blah blah ... pthread_create(thread_func); ... ... gtk_main(); } thread_func is updating data periodically with a sleep pause. At this point, I suppose the other thread is catching events normally (in fact, tabs of the notebook changes without problems). Well, at short time from run app, I get: *** glibc detected *** double free or corruption (!prev): 0x006115a0 *** Program received signal SIGABRT, Aborted. or *** glibc detected *** realloc(): invalid size: 0x006122e0 *** Program received signal SIGABRT, Aborted. The curious thing is that I _have not_ any free, realloc or malloc in my code, only those that gtk/glib functions like g_file_get_contents can perform. In fact, debugging with gdb and typing a bt after crash, I get: #0 0x002a97ebb4dd in raise () from /lib64/tls/libc.so.6 #1 0x002a97ebcc8e in abort () from /lib64/tls/libc.so.6 #2 0x002a97eefb41 in __libc_message () from /lib64/tls/libc.so.6 #3 0x002a97ef546f in _int_free () from /lib64/tls/libc.so.6 #4 0x002a97ef5a06 in free () from /lib64/tls/libc.so.6 #5 0x002a9715540f in gdk_region_union () from /usr/lib64/libgdk-x11-2.0.so.0 #6 0x002a9715ac19 in gdk_window_invalidate_maybe_recurse () from /usr/lib64/libgdk-x11-2.0.so.0 #7 0x002a9715aebc in gdk_window_invalidate_rect () from /usr/lib64/libgdk-x11-2.0.so.0 #8 0x002a96e4ecf5 in gtk_notebook_new () from /usr/lib64/libgtk-x11-2.0.so.0 #9 0x002a96e50fb8 in gtk_notebook_get_tab_label () from /usr/lib64/libgtk-x11-2.0.so.0 #10 0x002a96e5177d in gtk_notebook_get_tab_label () from /usr/lib64/libgtk-x11-2.0.so.0 #11 0x002a979c4faa in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #12 0x002a979d9b30 in g_signal_has_handler_pending () from /usr/lib64/libgobject-2.0.so.0 #13 0x002a979dbcd6 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 ---Type return to continue, or q return to quit--- #14 0x002a979dc023 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #15 0x002a96f2af07 in gtk_widget_size_allocate () from /usr/lib64/libgtk-x11-2.0.so.0 #16 0x002a96f208a5 in gtk_vbox_new () from /usr/lib64/libgtk-x11-2.0.so.0 #17 0x002a979c4faa in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #18 0x002a979d9b30 in g_signal_has_handler_pending () from /usr/lib64/libgobject-2.0.so.0 #19 0x002a979dbcd6 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #20 0x002a979dc023 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #21 0x002a96f2af07 in gtk_widget_size_allocate () from /usr/lib64/libgtk-x11-2.0.so.0 #22 0x002a96f353b9 in gtk_window_reshow_with_initial_size () from /usr/lib64/libgtk-x11-2.0.so.0 #23 0x002a979c4faa in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #24 0x002a979d9b30 in g_signal_has_handler_pending () from /usr/lib64/libgobject-2.0.so.0 #25 0x002a979dbcd6 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #26 0x002a979dc023 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #27 0x002a96f2af07 in gtk_widget_size_allocate () ---Type return to continue, or q return to quit--- from /usr/lib64/libgtk-x11-2.0.so.0 #28 0x002a96f371d8 in gtk_window_get_position () from /usr/lib64/libgtk-x11-2.0.so.0 #29 0x002a979c4faa in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #30 0x002a979d9ebc in g_signal_has_handler_pending () from /usr/lib64/libgobject-2.0.so.0 #31 0x002a979dbcd6 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #32 0x002a979dc023 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #33 0x002a96dc4403 in gtk_container_check_resize () from /usr/lib64/libgtk-x11-2.0.so.0 #34 0x002a97d2a606 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #35 0x002a97d2c21e in g_main_context_acquire () from /usr/lib64/libglib-2.0.so.0 #36 0x002a97d2c58a in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0 #37 0x002a96e39471 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0 #38 0x00406209 in main (argc=1, argv=0x7fb798) at main.c:121 am I doing something wrong? I don't know what to do. I have: glib2-2.4.7-1 glibc-2.3.4-2 gtk2-2.4.13-14 gtk-engines-0.12-5 Any ideas? PS: I'm so, so sorry for this terrible long mail. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
SubWindows
Hi guys, Anyone knows if the gtk support sub-windows? Daniel Alves ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list