From: <ka...@ca...> - 2009-10-16 16:24:58
|
Hi, we want to open new windows on different displays, and we found Graphics.UI.Gtk.Windows.Window.windowSetScreen that sounds like it should be the right tool to implement that. However, in Graphics.UI.Gtk.Gdk.Screen, the only functions ever returning a Screen are screenGetDefault, castToScreen, and toScreen. Now I have no idea what kind of things might be successfully cast to Screen, and the presence and documentation of screenGetDisplay and screenGetNumber suggests that Screens don't even correspond to X11 DISPLAYs. But the Display return type of screenGetDisplay appears to be opaque and undocumented (no link in the haddock-generated docs). The screen module also mentions displayGetDefault and displayOpen, both without links --- and I cannot even find relevant files: gtk2hs-0.10.1 # find . -name Display\* ./gtk/Graphics/UI/Gtk/Display # nothing relevant in there gtk2hs-0.10.1 # find . -type f | xargs grep -n displayOpen /dev/null ./gtk/Graphics/UI/Gtk/Gdk/Screen.chs:652:-- | Determines the name to pass to 'displayOpen' to get a 'Display' with this ./gtk/Graphics/UI/Gtk/Gdk/Screen.hs:669:-- | Determines the name to pass to 'displayOpen' to get a 'Display' with this ./gtk/Graphics/UI/Gtk/Gdk/Screen.chs.pp:356:-- | Determines the name to pass to 'displayOpen' to get a 'Display' with this ./docs/reference/Graphics-UI-Gtk-Gdk-Screen.html:1436:>Determines the name to pass to displayOpen to get a <TT Is there any existing interface I am overlooking? Wolfram |
From: Brandon S. A. K. <al...@ec...> - 2009-10-17 01:12:35
Attachments:
PGP.sig
|
On Oct 16, 2009, at 11:57 , ka...@ca... wrote: > Now I have no idea what kind of things might be successfully cast to > Screen, > and the presence and documentation of screenGetDisplay and > screenGetNumber > suggests that Screens don't even correspond to X11 DISPLAYs. I think you need to study the X11 API before going any farther; Screens are defined by that API, and a Display can have multiple Screens. Just to be confusing, $DISPLAY specifies both a Display and a Screen (":0" means ":0.0", the first number is the display, the second the screen). screenGetDisplay and screenGetNumber are wrappers for standard Xlib macros that extract information from the XScreen structure. If you're talking about multiple monitors, with Xinerama they are all part of the same Screen and without it they are separate Screens --- but in both cases they are part of the same Display. (And just to complicate things, a quick Google suggests to me that Gdk may not use the same terminology as X11. <sarcasm>Joy.</sarcasm>) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] al...@kf... system administrator [openafs,heimdal,too many hats] al...@ec... electrical and computer engineering, carnegie mellon university KF8NH |
From: Felipe L. <fel...@gm...> - 2009-10-17 02:04:39
|
On Fri, Oct 16, 2009 at 08:14:20PM -0400, Brandon S. Allbery KF8NH wrote: > If you're talking about multiple monitors, with Xinerama they are > all part of the same Screen and without it they are separate Screens > --- but in both cases they are part of the same Display. Nowadays Xinerama is deprecated, with RandR being the replacement, AFAIK. Now you have to read all the manuals again ;-). -- Felipe. |
From: Axel S. <Axe...@en...> - 2009-10-17 16:08:38
|
Hi Wolfram, On Oct 16, 2009, at 17:57, ka...@ca... wrote: > Hi, > > we want to open new windows on different displays, > and we found Graphics.UI.Gtk.Windows.Window.windowSetScreen > that sounds like it should be the right tool to implement that. > > However, in Graphics.UI.Gtk.Gdk.Screen, the only functions ever > returning a > Screen are screenGetDefault, castToScreen, and toScreen. > > Now I have no idea what kind of things might be successfully cast > to Screen, > and the presence and documentation of screenGetDisplay and > screenGetNumber > suggests that Screens don't even correspond to X11 DISPLAYs. > But the Display return type of screenGetDisplay appears to be > opaque and > undocumented (no link in the haddock-generated docs). > The screen module also mentions displayGetDefault and displayOpen, > both without links --- and I cannot even find relevant files: > I think we simply haven't bound any functions related to Display. As for terminology: A Screen in Gtk+ is one connected area of pixels (one monitor or several with the RandR or Xinemera or whatever extension). A Display is a mouse/keyboard/set of screens combination. Have a look at http://library.gnome.org/devel/gdk/stable/GdkScreen.html and http://library.gnome.org/devel/gdk/stable/GdkDisplay.html and tell us what you need! Cheers, Axel. > gtk2hs-0.10.1 # find . -name Display\* > ./gtk/Graphics/UI/Gtk/Display > > # nothing relevant in there > > gtk2hs-0.10.1 # find . -type f | xargs grep -n displayOpen /dev/null > ./gtk/Graphics/UI/Gtk/Gdk/Screen.chs:652:-- | Determines the name > to pass to 'displayOpen' to get a 'Display' with this > ./gtk/Graphics/UI/Gtk/Gdk/Screen.hs:669:-- | Determines the name to > pass to 'displayOpen' to get a 'Display' with this > ./gtk/Graphics/UI/Gtk/Gdk/Screen.chs.pp:356:-- | Determines the > name to pass to 'displayOpen' to get a 'Display' with this > ./docs/reference/Graphics-UI-Gtk-Gdk-Screen.html:1436:>Determines > the name to pass to displayOpen to get a <TT > > > Is there any existing interface I am overlooking? > > > Wolfram > > ---------------------------------------------------------------------- > -------- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market > and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users |
From: <ka...@ca...> - 2009-10-20 14:52:13
|
Hi Alex, > I think we simply haven't bound any functions related to Display. > > As for terminology: A Screen in Gtk+ is one connected area of pixels > (one monitor or several with the RandR or Xinemera or whatever > extension). A Display is a mouse/keyboard/set of screens combination. > Have a look at > > http://library.gnome.org/devel/gdk/stable/GdkScreen.html > > and > > http://library.gnome.org/devel/gdk/stable/GdkDisplay.html > > and tell us what you need! Thank you! With a quick look, I think we would need the following from GdkDisplay: GdkDisplay type gdk_display_open () gdk_display_close () gdk_display_get_default () gdk_display_get_name () gdk_display_get_default_screen () -- definitely gdk_display_get_n_screens () -- to be on the safe side gdk_display_get_screen () -- to be on the safe side gdk_display_flush () gdk_display_sync () Once we actually have something working, we may find that we also want to use some of the input handling in GdkDisplay. From GdkScreen, most things I imagine we may need are already bound, except perhaps: gdk_screen_get_monitor_geometry (). Are g_spawn_async* bound in any way? I found http://www.gtk.org/api/2.6/glib/glib-Spawning-Processes.html If they are bound, the following might also come in handy at some point, but I would hope that we can do without them for our current plans. gdk_spawn_on_screen () gdk_spawn_on_screen_with_pipes () gdk_spawn_command_line_on_screen () Wolfram |