Re: Multiple GdkScreens?
> Are there other platforms on which Gdk may have more than one screen? > Or if multiple X servers are running, with multiple copies of Gnome, > do they still share the same gdk? Gnumeric under X can use multiple screens (or displays for that matter). It's quite useful to have multiple screens if xinerama doesn't fit your needs. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Multiple GdkScreens?
ok, thanks, that answers my questions. Pascal On 7/30/07, Havoc Pennington <[EMAIL PROTECTED]> wrote: > Hi, > > Pascal Schoenhardt wrote: > > As far as I know, the number > > of screens in X is hard coded to 1, and always will be (hence > > xinerama, and now RandR 1.2). > > It isn't hardcoded to 1 in X, there can be multiple. > > There's no real reason to have multiple and few people do it anymore, > but in the days before Xinerama people used to do multiple monitors by > having multiple screens. There are probably still people running various > kinds of legacy apps or hardware that use multiple screens. > > > Are there other platforms on which Gdk may have more than one screen? > > Or if multiple X servers are running, with multiple copies of Gnome, > > do they still share the same gdk? > > Multiple X servers would show up as multiple GdkDisplay. > > The way to think of a screen is that it's a root window (a window with > no parent). Xinerama spreads a root window across multiple monitors, but > with multiple screens you have multiple root windows. > > Back in the day one reason for multiple screens was to use a different > visual (color depth, etc.) on each screen. Since each window has a fixed > visual, if you have two root windows one could be say 256-color for > email and stuff, and one could be your 3D graphics. > > Nowadays almost nobody cares what the visual is, they just always use a > 24-bit color depth for everything. > > Havoc > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Multiple GdkScreens?
Hi, Pascal Schoenhardt wrote: > As far as I know, the number > of screens in X is hard coded to 1, and always will be (hence > xinerama, and now RandR 1.2). It isn't hardcoded to 1 in X, there can be multiple. There's no real reason to have multiple and few people do it anymore, but in the days before Xinerama people used to do multiple monitors by having multiple screens. There are probably still people running various kinds of legacy apps or hardware that use multiple screens. > Are there other platforms on which Gdk may have more than one screen? > Or if multiple X servers are running, with multiple copies of Gnome, > do they still share the same gdk? Multiple X servers would show up as multiple GdkDisplay. The way to think of a screen is that it's a root window (a window with no parent). Xinerama spreads a root window across multiple monitors, but with multiple screens you have multiple root windows. Back in the day one reason for multiple screens was to use a different visual (color depth, etc.) on each screen. Since each window has a fixed visual, if you have two root windows one could be say 256-color for email and stuff, and one could be your 3D graphics. Nowadays almost nobody cares what the visual is, they just always use a 24-bit color depth for everything. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Multiple GdkScreens?
On 7/30/07, Pascal Schoenhardt <[EMAIL PROTECTED]> wrote: > Hi everyone, > > I am working on the Gnome SOC project for RandR 1.2 in Gnome. > > I just have a quick question about GdkScreens. In what scenario is > there ever more than one GdkScreen? If I understand things correctly, > a GdkScreen is the same as a screen in X: one large virtual "canvas" > which can consist of multiple monitors. As far as I know, the number > of screens in X is hard coded to 1, and always will be (hence > xinerama, and now RandR 1.2). > > Are there other platforms on which Gdk may have more than one screen? > Or if multiple X servers are running, with multiple copies of Gnome, > do they still share the same gdk? X is that platform. Try Xnest -scrns 4 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Multiple GdkScreens?
Hi everyone, I am working on the Gnome SOC project for RandR 1.2 in Gnome. I just have a quick question about GdkScreens. In what scenario is there ever more than one GdkScreen? If I understand things correctly, a GdkScreen is the same as a screen in X: one large virtual "canvas" which can consist of multiple monitors. As far as I know, the number of screens in X is hard coded to 1, and always will be (hence xinerama, and now RandR 1.2). Are there other platforms on which Gdk may have more than one screen? Or if multiple X servers are running, with multiple copies of Gnome, do they still share the same gdk? Thanks, Pascal ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtkspinbutton key press handler
hi
Actually i was trying to modify the code of gtkspinbutton so that if i press
up and down arrow keys it should change focus between other gtkspinbuttons
(i don't want to use tab key). By default it increments or decrements the
value.
What i found that arrow keys have been binded to "change_value" signal. So
when arrow key press is there "change_value" function handler is being
called and behaves accordingly.
And also i found that there is no key_press_event handler defined in
class_init() function.
so inorder to have the behavior i want, i provided a keypress handler which
looks like
static gint
gtk_spin_button_key_press (GtkWidget *widget,
GdkEventKey *event)
{
gboolean retval;
switch(event->keyval)
{
case GDK_Up:
retval = FALSE;
break;
case GDK_Down:
retval = FALSE;
break;
case GDK_Right:
gtk_spin_button_real_change_value
(GTK_SPIN_BUTTON(widget),GTK_SCROLL_STEP_UP);
retval = TRUE;
break;
case GDK_Left:
gtk_spin_button_real_change_value
(GTK_SPIN_BUTTON(widget),GTK_SCROLL_STEP_DOWN);
retval = TRUE;
break;
}
return retval;
}
now it behaves as i want but whats happening is a mystery to me.
what i suppose is key_press_handler is being called instead of
change_value_handler
but how gtk decides whether to call a keypress handler or handler of the
signal binded by using gtk_binding_entry_add_signal()?
I just tried to experiment by providing a key press handler.
can any one help please
bye
--
View this message in context:
http://www.nabble.com/gtkspinbutton-key-press-handler-tf4169823.html#a11862791
Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_widget_set_has_tooltip()
On Sat, Jul 28, 2007 at 03:22:29PM +0200, Murray Cumming wrote: > I don't understand why gtk_widget_set_has_tooltip() exists. This is set > automatically when calling gtk_widget_set_tooltip_text(). Yes it is, but only because gtk_widget_set_tooltip_text() is really a convenience function, which hooks up a default handler for you and sets the property. > If it's only for use when implementing widgets with more complex tooltip > APIs, such as GtkTreeView and GtkIconView, then I think the > documentation should say so. If you don't decide to use the convenience function, you will have to write a query-tooltip callback and set the has-tooltip property yourself. Also on "simple" widgets where you need something more advanced than just a single tooltip you might want to write your own callback, and thus have to set has-tooltip yourself -- it isn't strictly limited to "complex" widgets. I think the documentation for the tooltip-text and tooltip-markup properties is currently very clear in saying that they are convenience functions, setting up exactly these two things for you. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkRecentChooser API glitch
On Sun, 2007-07-29 at 18:49 +0200, Murray Cumming wrote: > > gtk_recent_chooser_menu_set_show_numbers() > > gtk_recent_chooser_menu_get_show_numbers() > > > > Language binding authors should not bind those functions, but bind the > > GtkRecentChooserMenu functions instead. > > > > These functions will be marked as deprecated as soon as GTK+ will branch > > off for the 2.11/2.12 cycle, > > While reviewing this change for gtkmm, I noticed that you didn't use the > "Deprecated:" syntax so these don't show up in the list of deprecated > symbols. yeah, I didn't know about the deprecation markers back then. I also forgot to add the deprecation guards. both issues are fixed in SVN, now. many thanks for the reminder. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkRecentChooser API glitch
On Sun, 2007-07-29 at 18:49 +0200, Murray Cumming wrote: > > These functions will be marked as deprecated as soon as GTK+ will branch > > off for the 2.11/2.12 cycle, > > While reviewing this change for gtkmm, I noticed that you didn't use the > "Deprecated:" syntax so these don't show up in the list of deprecated > symbols. when I added the markers I didn't know about the new syntax; then I completely forgot about adding the deprecation guards. I have committed a documentation patch for GtkRecentChooser properties, and fixed both issues. thanks for the reminder. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
