pointer grab
Dear list, my app has a button, when it is pressed it waits till the pointer clicks somewhere in a drawing area. I have implemented this by calling gdk_device_grab() in the button-press callback. As such it works OK, but a small detail is that after the drawing area has been clicked, the button is still in the hoover mode. So the button thinks the pointer is still on the button. The only way to reset the button to it's true state is by moving the pointer and make sure it enters and leaves the button again. What do I need to do to prevent this behavior? I would like to see that after clicking the drawing area the button is in it's normal/natural state, i.e. it has received a leave signal. regards, CH ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Correct way to package win32 gtk programs
No doubt you will get other replies telling you to do it in a completely different way... And no doubt some may think the above is ridiculously complicated. But remember, constructing an installer for [...] --tml Hi Tor, I was just thinking a bit about this topic myself. Your method makes sense to me, thanks for sharing your thoughts. CH ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: FW: compiling gtk-engines under mingw
Has anyone been able to successfully compile and create libmist.dll, libclearlooks.dll under windows? Yes I have done that a year ago or so, I compiled and used clearlooks under Windows using mingw. Libtool generates warnings saying that the shared libraries for gtk, pango, etc.. are not found. Indeed, there are only static libraries. True, libtool fails. Since usually I compile by hand I never use libtool, and therefore I didn't bother finding out why libtool failed. Instead, I manually adjusted the failed compile/link command. As far as I remember I just did something like gcc all object files -o libclearlooks.dll or something like that. If you really want to know what exact command I used I can compile (find out) it again. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: FW: compiling gtk-engines under mingw
Thank you for suggesting that. I finally got it to compile after realizing that I was missing the 'dlltool' utility found under the 'binutils' package of mingw. This was key to having libtool create the DLLs. Otherwise it simply was creating archived library packages. That's funny, when my compiling clearlooks failed I had dlltool installed, but it didn't work. Did you do something else in addition? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Building and packaging for Windows - theme?
You copied some mingw dlls? That doesn't sound right. mingwm10.dll is usually required for thread support. Are you sure about that? As far as I understood mingw dll's are only used during compile time, the result should be completely independant on mingw or other unixish help dll's. I've compiled my linux gtk app using mingw. I've also installed ldd. Let's run this on my mingw compiled exe: $ ldd ./foo.exe ntdll.dll = ntdll.dll (0x7c90) kernel32.dll = C:\WINDOWS\system32\kernel32.dll (0x7c80) libglib-2.0-0.dll = c:\mingw\bin\libglib-2.0-0.dll (0x1000) iconv.dll = c:\mingw\bin\iconv.dll (0x54) MSVCRT.dll = C:\WINDOWS\system32\MSVCRT.dll (0x77be) intl.dll = c:\mingw\bin\intl.dll (0x3d) ADVAPI32.DLL = C:\WINDOWS\system32\ADVAPI32.DLL (0x77f4) RPCRT4.dll = C:\WINDOWS\system32\RPCRT4.dll (0x77da) OLE32.dll = C:\WINDOWS\system32\OLE32.dll (0x774a) GDI32.dll = C:\WINDOWS\system32\GDI32.dll (0x77e4) USER32.dll = C:\WINDOWS\system32\USER32.dll (0x77d1) SHELL32.DLL = C:\WINDOWS\system32\SHELL32.DLL (0x7c9c) SHLWAPI.dll = C:\WINDOWS\system32\SHLWAPI.dll (0x77e9) WS2_32.DLL = C:\WINDOWS\system32\WS2_32.DLL (0x71a3) WS2HELP.dll = C:\WINDOWS\system32\WS2HELP.dll (0x71a2) libgthread-2.0-0.dll = c:\mingw\bin\libgthread-2.0-0.dll (0x3e) LIBMYSQL.dll = c:\Program Files\MySQL\MySQL Server 5.0\bin\LIBMYSQL.dll (0x62) WSOCK32.dll = C:\WINDOWS\system32\WSOCK32.dll (0x71a5) As you can see it's threaded (libgthread) but independant on custom dll's. So your app should work by having all relevant gtk dll's in PATH. regards, CH ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Building and packaging for Windows - theme?
$ ldd ./foo.exe ntdll.dll = ntdll.dll (0x7c90) kernel32.dll = C:\WINDOWS\system32\kernel32.dll (0x7c80) libglib-2.0-0.dll = c:\mingw\bin\libglib-2.0-0.dll (0x1000) iconv.dll = c:\mingw\bin\iconv.dll (0x54) MSVCRT.dll = C:\WINDOWS\system32\MSVCRT.dll (0x77be) intl.dll = c:\mingw\bin\intl.dll (0x3d) ADVAPI32.DLL = C:\WINDOWS\system32\ADVAPI32.DLL (0x77f4) RPCRT4.dll = C:\WINDOWS\system32\RPCRT4.dll (0x77da) OLE32.dll = C:\WINDOWS\system32\OLE32.dll (0x774a) GDI32.dll = C:\WINDOWS\system32\GDI32.dll (0x77e4) USER32.dll = C:\WINDOWS\system32\USER32.dll (0x77d1) SHELL32.DLL = C:\WINDOWS\system32\SHELL32.DLL (0x7c9c) SHLWAPI.dll = C:\WINDOWS\system32\SHLWAPI.dll (0x77e9) WS2_32.DLL = C:\WINDOWS\system32\WS2_32.DLL (0x71a3) WS2HELP.dll = C:\WINDOWS\system32\WS2HELP.dll (0x71a2) libgthread-2.0-0.dll = c:\mingw\bin\libgthread-2.0-0.dll (0x3e) LIBMYSQL.dll = c:\Program Files\MySQL\MySQL Server 5.0\bin\LIBMYSQL.dll (0x62) WSOCK32.dll = C:\WINDOWS\system32\WSOCK32.dll (0x71a5) As you can see it's threaded (libgthread) but independant on custom dll's. So your app should work by having all relevant gtk dll's in PATH. I forgot to say, the above example is for a glib dependant program which in addition uses mysql. So for a gtk program you'll see many more dll's, but not some mingw dll. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Menu with stuff in multiple columns?
On 11/5/07, Reed Hedges [EMAIL PROTECTED] wrote:
I have a large list of small names I want to display in a popup menu. Is
there
any way to tell GTK to allow more than one column, rather than having the
popup
menu fill the screen from top to bottom?
Yes there is. For example, I've made once some calendar like thing
where you can select a month from a 2 columns menu.
Untested code, but should work:
GtkWidget *combo;
GtkListStore *store;
GtkTreeIter iter;
GtkCellRenderer *renderer;
int i;
char**p;
char*months[]={jan,jul,feb,aug,mar,sep,apr,oct,may,
nov,jun,dec,NULL};
store=gtk_list_store_new(1,G_TYPE_STRING);
combo=gtk_combo_box_new_with_model(GTK_TREE_MODEL(store));
renderer=gtk_cell_renderer_text_new();
gtk_cell_layout_pack_start (GTK_CELL_LAYOUT(combo),renderer,TRUE);
gtk_cell_layout_set_attributes(GTK_CELL_LAYOUT(combo),renderer,
text,0,NULL);
gtk_combo_box_set_wrap_width (GTK_COMBO_BOX (combo),2);
for(p=months;*p;p++){
gtk_list_store_append(store,iter);
gtk_list_store_set(store,iter,0,*p,-1);
}
gtk_combo_box_set_active(GTK_COMBO_BOX(combo),0);
g_object_unref(store);
Good luck.
CH
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: cairo canvas
Yes there are quite some canvases based on gtk/cairo out there, some more mature than the other ones, for a table of comparison look at [1]. [1] http://live.gnome.org/ProjectRidley/CanvasOverview?highlight=%28canvas%29#Features I would suggest you to have a look at goocanvas, it comes with a lot of really cool and useful examples and a complete reference manual. Yes I saw this one, but since the last version is more than a year old, I got the impression it's not really develloped anymore. Well, maybe instead of premature it's just perfect! :) Anyway, thanks for your link. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
cairo canvas
hello, My app can draw lines, circles etc. on a gtk drawing area (cairo based). However, later on I want to be able to pick up the line, circle etc. and move them around the canvas or resize them. So in effect I want to be able to put graphical objects on the drawing area, and later be able to manipulate them. Like in inkscape. After quite some googling I didn't find a standard method to do this; there are different projects being develloped but all premature. Does anybody have suggestions what I could best use? In addition, I'm interested in how such a canvas could be implemented. However I have no idea, and I couldn't find some gtk/cairo canvas implementation HOWTO. So any info about that is welcome as well! Thanks all for suggestions. regards, CH ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
stock icons RTL
When I use gtk stock icons but change the orientation to RTL, the size changes a little bit (at least for GTK_STOCK_MEDIA_PLAY). Is this normal behaviour or a bug? Regards, CH ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: cairo pixmap
Ah, I just found out the solution is trivial.
GdkPixmap *pixmap;
/* Create a new backing pixmap of the appropriate size */
static gint
configure_event (GtkWidget *widget, GdkEventConfigure *event)
{
cairo_t *cr;
if (pixmap)
gdk_pixmap_unref(pixmap);
pixmap = gdk_pixmap_new(widget-window,
widget-allocation.width,
widget-allocation.height,
-1);
cr = gdk_cairo_create (pixmap);
/* do your drawing here */
cairo_destroy (cr);
return TRUE;
}
static gint
expose_event_cb (GtkWidget *widget, GdkEventExpose *event)
{
/* copy relevant part of pixmap back to screen */
gdk_draw_pixmap(widget-window,
widget-style-fg_gc[GTK_WIDGET_STATE (widget)],
pixmap,
event-area.x, event-area.y,
event-area.x, event-area.y,
event-area.width, event-area.height);
return FALSE;
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: cairo pixmap
The signal handler for the expose event is passed some parameters specifying which part of the screen has become invalidated. If you use these in a Cairo drawing mask, then redraw your canvas, it should be quite fast, as Cairo will ignore all operations to areas outside the mask. But this means -if I understand correctly- that I still have to redraw from scratch, be it not the complete drawing area but only the invalidated part. Therefore, it will still be slower than in my old GDK based situation, especially when the to be drawn picture becomes more complex (which in my situation is the case). Do you/does anybody know what the technical reason is why cairo contexts fail outside the expose signal? I'm just curious. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
label line wrap en resize
Hi, does anyone know why when resizing the window, a label doesn't get adjusted/updated? I mean, when you have a label and use gtk_label_set_line_wrap(GTK_LABEL(label),TRUE) I would expect that a line of text gets rewrapped to fit the new situation. When I replace the label with say a button, I can see that it gets the new space allocated (the button size changes when resizing the window). cheers c.h. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Switching theme
hi, another example of runtime changing the theme can be found in The Widget Factory, see http://www.stellingwerff.com/?page_id=10 The source is straight forward. On 12/19/06, Madhusudan E [EMAIL PROTECTED] wrote: Hi... Probably u can even use existing applications on net to change themes on the fly http://www.muhri.net/nav.php3?node=gts download gtk-theme-switch Hope this helps. Rgds, Madhusudan E This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -Original Message- From: Paolo Franzetti [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 19, 2006 1:41 PM To: Madhusudan E Subject: Re: Switching theme Madhusudan E wrote: Hi, On selecting the theme, Use, say gtk_rc_parse(/home/Madhu/gtk/Themes/AquaX/gtk-2.0/gtkrc); Then reset the window rc styles using gtk_widget_reset_rc_styles(window); Then reparse all... gtk_rc_reparse_all(); I hope this helps Rgds, Madhusudan Thanks for the suggestion. It almost works ... The first time I switch theme it works (a part for the menu from which I launch the command); then it works no more, or it works partially (some widgets updated, some not). I am using libglade to build my application; it could be a problem? Thanks again, Paolo ___ 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: A question about deprecated widget
Hi,
A year ago I posted my comments about the GtkComboBox to this list,
this link shows the thread:
http://marc.theaimsgroup.com/?t=11324387691r=1w=2
Still, the GtkComboBox is the biggest problem in my application. I'm
sorry to say, but the combo control is both ugly and clumsy. But as
you can read in the thread, it won't be changed soon if at all because
it's been designed this way to follow Gtk policies and UI
consistency.
Paul Pogonyshev:
Not having such a limit is a conscious decision by GTK+ team. Not a
missed feature.
It IS a missed feature. Because:
1. A too big list overlaps other widgets containing useful
information. Suppose you have a form with lots of labels and entries
like a database frontend. Usually you fill in the fields from top to
bottom. So if the combobox is nearer the bottom of the screen than
top, the popuplist will popup above the gtkcombobox, therefore your
just filled in entries become invisible. This is bad and at the moment
not controllable. Being able to limit the number of rows in the
scrolled popup is useful because now it will be placed below the
gtkcombobox widget itself. Replacing gtkcombobox with a treeview is
often not suitable, see below.
2. It's ugly. This widget crosses the line where visual apealingness
becomes more important than sticking to design philosophies. The fact
that every now and then someone posts a question about setting the
maximum number of rows shows that there clearly is demand for such
features. In addition, apps like gnumeric show they come up with some
alternative selection (like the font selection in gnumeric) where the
natural choice would be GtkComboBox.
3. Gtk+ current behaviour is inconsistent. The fact that
GtkEntryCompletion does not take as much space a possible is in my
opinion contradicting to GtkComboBox. So why doesn't completion take
as much screen space as possible?
I'm not opposed to GtkTreeView, however what I want to have is a widget
that displays a list only durring selection and (sometimes) has a single
editable entry field, visible all of the time, just like GtkCombo did.
The best alternative would be GtkTreeView, but in so many places it
just doesn't fit because it takes too much space, like a fontselection
in a toolbar. So you could make it into a separate window which opens
when you push the selector button (like GtkFontButton). This makes
selection not really economic: first, you have to click selector
button to open the treeview window, then you select, and then yet
another click to close the treeview window. With a proper GtkComboBox
one click could suffice.
And please, stop taking it personally, cause that makes me take it
personally too.
I understand :)
And please don't take my comments personally, I'm not trying to piss
people off or being a pessimist. Gtk+ as it is now is very
good. Having a decent combobox would make it really good for me.
BTW: appears-as-list is a read-only style property but you can force
an individual GtkComboBox to set this property like this:
combo_box=gtk_combo_box_new_text();
gtk_rc_parse_string(style \list-combo-style\ {\n
GtkComboBox::appears-as-list=1}
widget \*.list-combo\ style
\list-combo-style\);
gtk_widget_set_name(combo,list-combo);
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: textview scrolling fails
Thanks a lot Michael, that turned out to be the problem! Man did I spent much time on this problem. Wonder why I used the _add_with_viewport() call anyway. Anyway, thanks a lot. ^H On 12/14/06, Michael 'Mickey' Lauer [EMAIL PROTECTED] wrote: control H wrote: This search does find what I'm searching: on the console the match is printed, and also the tag is aplied to the textbuffer at the found section. But no scrolling occurs. Just a shot in the dark, but I once had the same problem and it turned out I accidantly added the TreeView to a ScrolledWindow with add_with_viewport(), which breaks some of the scrolling logics. TreeView needs to be added to a ScrolledWindow without an additional viewport, since it has a direct interface for using GtkAdjustment. Regards, :M: -- Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de ___ 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: gtkentry grab-focus
For those interested, here's a way to get the desired result. The
source of gtkentry.c shows that if the entry receives a click, it
resets the selection to the current position of the cursor. Hence the
following button-press-event callback works:
static gboolean event_cb(GtkWidget*w,GdkEvent*event,gpointer p)
{
if(!GTK_WIDGET_HAS_FOCUS(w)){
gtk_widget_grab_focus(w);
return TRUE;
}
return FALSE;
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtkentry grab-focus
Say you have some widgets, one of them being a gtkentry. When you tab through the widgets towards the entry, its text will be selected when the entry gets focus. I would like that behaviour also when I just click the text in the entry. I connect to the grab-focus signal where I select all available text in the callback function. But as soon as I click some text in the widget, the text gets deselected as soon as I release the left mouse button press. Which signals should I connect to to get the desired result? thanks in advance. ps Why don't I get the move-cursor signal when I change the cursor position in the entry by clicking with the mouse? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
changing pango attributes
Hi,
I've made a gtklabel with an underline attribute:
pango_attr_underline_new(PANGO_UNDERLINE_ERROR);
The label shows up fine with this attribtute.
However, later on I want to dynamically change this attribute
to PANGO_UNDERLINE_NONE.
The code basically looks like this:
attrlist=gtk_label_get_attributes(label);
iter=pango_attr_list_get_iterator(attrlist);
do{
attribute=pango_attr_iterator_get(iter,PANGO_ATTR_UNDERLINE);
}while(pango_attr_iterator_next(iter));
Now, the problem is this:
attribute=pango_attr_iterator_get(iter,PANGO_ATTR_UNDERLINE);
doesn't really give me the attribute, does it? After all,
typedef struct {
const PangoAttrClass *klass;
guint start_index;/* in bytes */
guint end_index;/* in bytes. The character at this index is not included */
} PangoAttribute;
typedef struct {
PangoAttrType type;
PangoAttribute * (*copy) (const PangoAttribute *attr);
void (*destroy) (PangoAttribute *attr);
gboolean (*equal) (const PangoAttribute *attr1, const
PangoAttribute *attr2);
} PangoAttrClass;
and in this last struct I only can acces the type, but not it's values.
I'm looking for a way to get the struct used for
typedef struct {
PangoAttribute attr;
int value;
} PangoAttrInt;
so that I can set the int value to PANGO_UNDERLINE_NONE.
I have studied the pango API a lot, but can't find a way to get
access to the underline attribute itself. Am I missing something
simple here?
Thanks in advance for your help.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
tab stops in gtkcellrenderertext
Hi, I try to change the default tab stops setting in a gtkcellrenderertext. However, I can't find a possibility to do this. There isn't for example a pango property that does the job. And I can't find another link to the underlying pango structures. Any ideas on this? 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
pack cells vertically
Hi all, I've made some treeview and I want to pack some cellrenderers vertically into GtkCellLayout. Thus, I'm looking for some anologue of gtk_cell_layout_pack_end and friends, but in vertical direction. Is that possible? Or is it possible to merge two adjecent rows into one? I've also been trying iconview things, but that's not exactly what I want. Thanks for your help. ___ 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
[snip] 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'm not that negative about a combo control. After all, a good combo like the Windows one lets me select the item I want quickly and simple (enough), and in an acceptable style. 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. When you have a working prototype please let me know, I'd like to see it for sure. ___ 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
Well, I must admit that I haven't used Windows more than occasionaly for the last three or four years, but the last time I checked, Windows combo box was much _worse_ than GTK+'s, in my opinion. You would often get a five-line combo where you'd have to scroll like hell to skip all those 200 items to get to the one you want. Ok it certainly sucks when you have to scroll those 200 items within a five-line combo. But that's part of the programmers job I think. At least you are able to force a five-line combo on Windows! And that's what I miss. A function where you can scale such things, as I stated in my original email. I'm not saying GTK+'s combo is perfect, but I think it is generally better than anything else I've seen. At least it always uses all the screen space it has. But this is one of my other objections: it merely _tries_ to use all the screen space available. It draws the menu layout, but without all items: you have to scroll them in if current selection item is near the beginning, using those scroll arrows. It's not the most economic handling of a selection. After all, if you have no more items than would fit on the screen, it could have shown the menu compleet, ie, showing all items at once (but would of course require that the current selected item may be located at a different height than the combo widget itself, but tha'ts no problem to me. I even think that should be configurable). The main problem, to me, is when the combo is too close to the screen edge, especially to the bottom one. Then you can easily get a too small popup. I'm happy you agree on this one :) And yes, I agree that a real scroll bar could be helpful. While you should avoid presenting the user with a hundreds-items combo box in the first place, it doesn't mean GTK+ should make such combos even less usable. I agree completely. Thanks for you comments. ___ 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
