Smooth window resizing
Hi, All! I wonder if there is a way to resize a window gradually (as if animated) when a, for examle, set_size_request(...) is issued. Now the window is resized abruptly as a treeview is expanded (and that bothers the users). Igor Gorbounov ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Selecting the region in GtkFileSelection
Hi, I have created a GtkFileSelection, set the filename and want the filename region to be selected. Here's what I am doing: GtkWidget *a = gtk_file_selection_new(Hmmm); gtk_file_selection_set_filename(GTK_FILE_SELECTION(a),TestFile); GtkWidget *ase = (GTK_FILE_SELECTION(a))-selection_entry; gtk_entry_set_text(GTK_ENTRY(ase),Hope); gtk_editable_select_region(GTK_EDITABLE(ase),0,-1); gtk_widget_show(ase); gtk_widget_show(a); But this doesn't work. Any ideas what's wrong here and how to get the filename region selected? (I am using GTK 2.0.9) Thanks -Pramod __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Smooth window resizing
Igor Gorbounov wrote: Hi, All! I wonder if there is a way to resize a window gradually (as if animated) when a, for examle, set_size_request(...) is issued. Now the window is resized abruptly as a treeview is expanded (and that bothers the users). I'm not sure about this one, but I think that this will help: http://developer.gnome.org/doc/API/2.0/gtk/GtkContainer.html#gtk-container-set-resize-mode Cheers, -Tristan ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
gtk_widget_add_accelerator
Hi All, I am trying to add an accelerator. Here's a sample code: GtkWidget *w=gtk_window_new(GTK_WINDOW_TOPLEVEL); GtkWidget *e=gtk_button_new_from_stock(GTK_STOCK_OK); GtkAccelGroup *gag = gtk_accel_group_new(); gtk_window_add_accel_group(GTK_WINDOW(w),gag); g_signal_connect(G_OBJECT(e),clicked,G_CALLBACK(print),NULL); guint mod = GDK_SHIFT_MASK; mod |= GDK_CONTROL_MASK; gtk_widget_add_accelerator(e,clicked,gag,'6',GDK_CONTROL_MASK|GDK_SHIFT_MASK,GTK_ACCEL_VISIBLE); gtk_container_add(GTK_CONTAINER(w),e); gtk_widget_show(e); gtk_widget_show(w); When the application is run, Ctrl+6 calls the callback but not Ctrl+Shift+6. Any idea what's going on here? (I am using GTK 2.0.9) Thanks -Pramod __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Selecting the region in GtkFileSelection
On Wed, 2004-09-08 at 09:37, Pramod Patangay wrote: Hi, I have created a GtkFileSelection, set the filename and want the filename region to be selected. Here's what I am doing: GtkWidget *a = gtk_file_selection_new(Hmmm); gtk_file_selection_set_filename(GTK_FILE_SELECTION(a),TestFile); GtkWidget *ase = (GTK_FILE_SELECTION(a))-selection_entry; gtk_entry_set_text(GTK_ENTRY(ase),Hope); gtk_editable_select_region(GTK_EDITABLE(ase),0,-1); gtk_widget_show(ase); gtk_widget_show(a); But this doesn't work. Any ideas what's wrong here and how to get the filename region selected? (I am using GTK 2.0.9) I think if you do it after gtk_widget_show(a) it might work. I remember fixing this a year or two ago.. 2.0.9 is a pretty old version of GTK+. Regards, Owen signature.asc Description: This is a digitally signed message part ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Clearing the selection in a GtkCalendar
Hi all. Is there any way a *user* can clear out the date selected in a GtkCalendar? I'm developing apps with Perl / Gtk2 and I can get the desired effect in code by setting the day to 0 ( which visually de-selects all days ) but I want to know if there is some way the user can do this without me giving them a button to do so. Dan -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: [EMAIL PROTECTED] website: http://www.nusconsulting.com.au Title: CanIt Vote for ID 97144 The following links have been inserted by the NUS Consulting internal spam filter and are for NUS Consulting staff only Spam Not spam Forget previous vote ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
MDI (not winMDI) frameworks ... again
Firstly, I agree with all prior posts that M$ has destroyed the concept of MDI by having the window in window approach using a window menu and having maximized sub windows, tiled or cascaded. This type of MDI is what another user called winMDI and I totally agree that it sucks big time. However, MDI is still used (very well I might add) by other applications such as IDE's (KDevelop, Netbeans, Eclipse and even Apples X-Code). Many have suggested that MDI should be the job of the window manager. This cannot work for the time being since no *nix app should ever be tied into one window manager. Maybe someday in the long future when the WM world stabilizes sufficiently, this would work but for the foreseeable future this is an unrealistic ideal. In the meantime, developers are left hanging with putting out apps that have just way too many windows. I've used Gimp on my OSX box and it totally sucks having to first clicking the window to get focus before being able to click the item. If the app ran on a MDI framework, this would not be necessary. I have ton's of apps open at one time and if I did not have MDI for those apps, I'd have too many windows to manage. Tim winMDI == evil MDI != evil (potentially) ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: MDI (not winMDI) frameworks ... again
On Wed, 08 Sep 2004 17:43:25 -0400, Tim [EMAIL PROTECTED] wrote: Firstly, I agree with all prior posts that M$ has destroyed the concept of MDI by having the window in window approach using a window menu and having maximized sub windows, tiled or cascaded. This type of MDI is what another user called winMDI and I totally agree that it sucks big time. However, MDI is still used (very well I might add) by other applications such as IDE's (KDevelop, Netbeans, Eclipse and even Apples X-Code). Many have suggested that MDI should be the job of the window manager. This cannot work for the time being since no *nix app should ever be tied into one window manager. Maybe someday in the long future when the WM world stabilizes sufficiently, this would work but for the foreseeable future this is an unrealistic ideal. In the meantime, developers are left hanging with putting out apps that have just way too many windows. I've used Gimp on my OSX box and it totally sucks having to first clicking the window to get focus before being able to click the item. If the app ran on a MDI framework, this would not be necessary. I have ton's of apps open at one time and if I did not have MDI for those apps, I'd have too many windows to manage. Lots of GTK apps (Gaim, Galeon, gedit, and Epiphany, to name a few) implement a sort of MDI using windows as containers and tabs with close buttons for documents, but each application has to invent its own framework for managing them. It'd be really convenient to have that stuff built into GTK. If you're interested, I've implemented such a framework in Ruby: http://ruby-gnome2.sourceforge.jp/hiki.cgi?MDI I could try my hand at porting it to C, but I'm not sure if my model is the right way. Tim Sam winMDI == evil MDI != evil (potentially) ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: MDI (not winMDI) frameworks ... again
have just way too many windows. I've used Gimp on my OSX box and it totally sucks having to first clicking the window to get focus before being able to click the item. If the app ran on a MDI framework, this would not be necessary. its also not necessary if you use a window manager that doesn't enforce click-to-focus, or if you turn off the WM's click-to-focus policy. there are people who apparently *like* click-to-focus. what you perhaps want is focus-follows-application, which is a bit more subtle, but relatively easily enforced by the application itself, using X enter/leave events on its windows combined with focus grabs. --p ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: MDI (not winMDI) frameworks ... again
Tim wrote: In the meantime, developers are left hanging with putting out apps that have just way too many windows. I've used Gimp on my OSX box and it totally sucks having to first clicking the window to get focus before being able to click the item. If the app ran on a MDI framework, this would not be necessary. Incidentally, you can make Apple's quartzwm behave in a more sensible manner. At a terminal: defaults write com.apple.x11 wm_click_through -bool true I've found this makes Gimp actually usable... :P -- brion vibber (brion @ pobox.com) signature.asc Description: OpenPGP digital signature ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: MDI (not winMDI) frameworks ... again
On Wed, 2004-09-08 at 19:42, Brion Vibber wrote: Tim wrote: In the meantime, developers are left hanging with putting out apps that have just way too many windows. I've used Gimp on my OSX box and it totally sucks having to first clicking the window to get focus before being able to click the item. If the app ran on a MDI framework, this would not be necessary. Incidentally, you can make Apple's quartzwm behave in a more sensible manner. At a terminal: defaults write com.apple.x11 wm_click_through -bool true Thank you so much!!! I've been wanting to know this for a long time. I've found this makes Gimp actually usable... :P -- brion vibber (brion @ pobox.com) __ ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list -- Michael Torrie [EMAIL PROTECTED] ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: MDI (not winMDI) frameworks ... again
In the meantime, developers are left hanging with putting out apps that have just way too many windows. I've used Gimp on my OSX box and it totally sucks having to first clicking the window to get focus before being able to click the item. If the app ran on a MDI framework, this would not be necessary. This has nothing to do with MDI, or Gimp, or even click-to-focus. This is about click-through. On the Mac, click-through determines whether you can click on an item in an un-focused window directly, or if you have to click on the window to focus it first. Typically, things like Delete buttons don't get click-through, so you can switch to another application easily without fear of doing something dangerous. X -- or specifically, toolkits for X, like Gtk+ -- have no concept of click-through. Window managers simply make everything click-through (or nothing, depending on your window manager, apparently). I haven't used Gimp on the Mac, but I suspect they simply disabled click-through for all X windows. I use Gimp on my Linux box with Metacity (click-to-focus) and it works just fine. No need to click twice here. An interesting project would be to add support for (real, developer-gets-to-choose-per-widget) click-through to Gtk+. - Ken ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: MDI (not winMDI) frameworks ... again
Tim wrote: Firstly, I agree with all prior posts that M$ has destroyed the concept of MDI by having the window in window approach using a window menu and having maximized sub windows, tiled or cascaded. This type of MDI is what another user called winMDI and I totally agree that it sucks big time. However, MDI is still used (very well I might add) by other applications such as IDE's (KDevelop, Netbeans, Eclipse and even Apples X-Code). Many have suggested that MDI should be the job of the window manager. This cannot work for the time being since no *nix app should ever be tied into one window manager. Maybe someday in the long future when the WM world stabilizes sufficiently, this would work but for the foreseeable future this is an unrealistic ideal. In the meantime, developers are left hanging with putting out apps that have just way too many windows. I've used Gimp on my OSX box and it totally sucks having to first clicking the window to get focus before being able to click the item. If the app ran on a MDI framework, this would not be necessary. I have ton's of apps open at one time and if I did not have MDI for those apps, I'd have too many windows to manage. If you need the effect of lots of sub-windows in a larger window, then each sub-window can be implemented as an object derived from a GtkWidget or GtkContainer. The titlebar of each subwindow can have a close/maximize/minimize button. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
