[EMAIL PROTECTED] writes: > Hi all; I just saw that gtk 2 is coming out soon. It's probably > too late for 2.0, but could I get folks to consider the following > features for a future release? These comments stem from frustrations > I encountered while developing under gtk. > > Most of these could be considered bug reports rather than changes > to the API.
Both features and bug reports should go in bugzilla - http://bugzilla.gnome.org, otherwise they typically get lost. If you put the report in bugzilla you also get the nice advantage that you will be able to monitor patches and discussion relating to the feature and add your own comments, and you'll be notified when the fix goes in. Certainly a number of these comments would be useful in bugzilla. > * Toolkit should recognize traditional "-g WxH+X+Y" commandline > arguments. gtk_window_parse_geometry(). Toolkit can't do more than that for you, as Paul points out. > * It would be very handy to be able to somehow specify the > width of a TextEntry widget in terms of displayed characters > instead of pixels. gtk_entry_set_width_chars() > * Scrollbars and scales desperately need a way for callbacks to > differentiate a scroll-in-progress from a scroll-completed type > event. I would suggest a "value-done" signal to supplement > the "value" event. (Example: a cad program that takes a long > time to rebuild the display. I want to scroll it without > rebuilding while the user manipulates the scroll bar, and then > do the rebuild when the user releases the mouse.) gtk_range_set_update_policy() is the intended feature here, though it doesn't handle the case you mention. > * It would be nice to add a scale factor option to sliders and > scrollbars so that a large mouse motion results in a small > change in slider position (very useful feature when dealing > with very small sliders. See > > http://www.efalk.org/Widgets/#slider > > for an example of one I wrote for the X intrinsics many years > ago. Wouldn't it make more sense for the slider to autocompute the scale factor depending on its size and range and step increment? > * It would be nice for TextEntry widgets to have signals which > indicate that the widget has received/lost keyboard focus. > This is especially important when losing focus, as this is > a good time for the application to validate and/or reformat > the input. There are focus_in_event and focus_out_event signals that do this as Paul pointed out. > * It would be nice to have an option for TextEntry widgets to > select their contents when gaining focus (although this could > be done manually given a focus-received signal.) GtkEntry does this by default now - now the usual request is to have an option to disable it. ;-) We may have made it a user option, I don't remember. > * I found the toolkit's habit of highlighting the widget under the > cursor rather than highlighting the widget with keyboard focus > to be confusing. I don't think it's "rather than", there are two separate kinds of indication - focus outline and prelight. This is in some sense entirely a function of the theme (a theme can disable or modify how either thing is displayed). > * It would be a nice feature to add "focus follows mouse" to the > keyboard focus mechanism. That is, moving the mouse from widget > to widget would change the focus without needing to click on > the new widget. The tab keys would still change the focus as > before. (I implemented this in my XawM toolkit, see > http://www.efalk.org/Widgets/#xawm) Hrm, I think you'll find little enthusiasm for that... no modern toolkit does this. > * Buttons should provide visual feedback when activated from keyboard > (i.e. button-pressed on key down, button-released on key up.) GTK 2 has this feature. > * It would be nice to be able to expand/collapse tree widgets with > the +/- keys. I believe GtkTreeView in GTK 2 has this feature. If not it has some other keybinding for it. > * It would be nice if I could use my own select loop with gtk; > something like: > GLib 2 is set up to allow integration with other main loops, though again Paul is right - it's a bit more complex than you were hoping. ;-) GTK has more "event sources" than just the X event queue. Havoc _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
