java-gnome-hackers

[java-gnome-hackers] GTK, DisplayManager and multihead X

[Stefan P. <st...@pr...>]

Hi all,

I was experimenting with multiheaded display support for java-gnome.
For this purpose I wrote coverage for org.gnome.gdk.DisplayManager and
org.gnome.gdk.Display.

I ran into two problems. One may be missing understanding on the
java-gnome internals, the other may be X/GTK related.

1. When requesting a list of displays from the DisplayManager
   I got the message that there is no mapping for 'GdkDisplayX11'
   in the typeMapping.properties. So just for testing I changed
     GdkDisplay=org.gnome.gdk.Display
   to
     GdkDisplayX11=org.gnome.gdk.Display
   which seemed to work.
   What would be the correct way to add this mapping?

2. I have a dual headed workstation with Xinerama. GTK identifies
   this as 1 display with 1 screen ":0.1" (2560x1024).
   When I use the Java Swings GraphicsEnvironment/GraphicsConfiguration
   this is identified as 2 screens ":0.0" and ":0.1" (1280x1024).

   When testing to open applications on a specific screen, it looks
   like I really do have one screen when it comes to X.
   "xterm -display :0.0" works, "xterm -display :0.1" doesn't.

   I hoped I would get java-gnome to behave like Swing, which allows me
   (in my setup) to decide on which monitor a window shows up.
   Any idea what I can do? How can I tell X/GTK that I do have multiple
   screens on my display?

If you want to try it out, I attached a patch against the mainline and
an additional test program.

Regards,
  Stefan

Re: [java-gnome-hackers] GTK, DisplayManager and multihead X

[Vreixo F. L. <met...@ya...>]

> I was experimenting with multiheaded display support for
> java-gnome.
> For this purpose I wrote coverage for
> org.gnome.gdk.DisplayManager and
> org.gnome.gdk.Display.
> 
> I ran into two problems. One may be missing understanding
> on the
> java-gnome internals, the other may be X/GTK related.
> 
> 1. When requesting a list of displays from the
> DisplayManager
>    I got the message that there is no mapping for
> 'GdkDisplayX11'
>    in the typeMapping.properties. So just for testing I
> changed
>      GdkDisplay=org.gnome.gdk.Display
>    to
>      GdkDisplayX11=org.gnome.gdk.Display
>    which seemed to work.
>    What would be the correct way to add this mapping?

mmm, this seems to be the same problem I get with GStreamer. One thing is the API object we map (GdkDisplay) and another the concrete implementation in a given environment (GdkDisplayX11). My solution was to modify our mapping code to find a proxy of parent type if a direct mapping can't be found. But it is still experimental code, so I cannot recommend it to you.

Cheers,
Vreixo


      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

Re: [java-gnome-hackers] GTK, DisplayManager and multihead X

[Andrew C. <an...@op...>]

Hey Stefan,

On Sun, 2008-05-18 at 14:25 +0200, Stefan Prelle wrote:
> 1. When requesting a list of displays from the DisplayManager
>    I got the message that there is no mapping for 'GdkDisplayX11'

The workaround is the same as for GdkScreenX11; see
org.gnome.gdk.Plumbing and add a registerType() call there for the case
you're running up against.

In the medium term, I'm not in a huge rush to see this class of problem
go away. An error that results from us not having coverage of something
means that someone should probably write coverage of it if they need it.
Certainly this has driven a lot of activity to date.

        (oh, you want a signal that uses something called
        GtkMovementStep that has no constants registered for it yet?
        Hey! Guess what? Maybe it's time you researched it and wrote up
        some coverage for it. I dealt with that one today)

Over all, the real issue is preserving strong typedness. This applies
both to the "what do I do if I don't have a concrete subtype for this
yet" and also applies to plugins. If we know a give type of capability
will be built in or is likely to be built in, then create a concrete
subclass for it already. org.freedesktop.cairo.Surface and
org.gnome.gdk.PixbufFormat come to mind.

Anyway, yes, long term we'll want to "do" something about the case where
an instance shows up that we don't have a concrete Proxy type for. It's
not really that clear to me what shape that should take.

Vreixo suggested something like "UnknownSurface" and what not. That
might work, but I'm not really in a rush to create an Unknown concrete
subclass of bloody everything, especially when roughly the same effort
would just see the necessary public coverage added. I'd rather just see
the bindings improve when people need them to.

AfC
Sydney

Re: [java-gnome-hackers] GTK, DisplayManager and multihead X

[Vreixo F. L. <met...@ya...>]

--- Em qua, 21/5/08, Andrew Cowie <an...@op...> escreveu:

> Vreixo suggested something like "UnknownSurface"

Not really! My approach is to use as proxy the nearest parent we have a proxy for. For example, if in GStreamer we don't have a proxy for a given plugin that provides, for example, a XXXElement, we just proxy it as a GstElement.

While not so good solution as having the concrete type proxied, it makes our bindings work properly, and at the same time it hides implementation details we actually don't need to expose. 

>  I'd
> rather just see
> the bindings improve when people need them to.

This is not a good idea for things like GStreamer, where users can install 3rd party plugins. While it may be (it is) a good idea to add coverage for common plugins, it would be really bad to have a bindings architechture that doesn't work for "all" plugins...

The "use parent proxy if actual type is unknown" approach works ok, and it is type safe, it just hides implementation details. In cases where those implementation details need to be exposed, then adding the missing coverage is the only solution, but it works ok as a general purpose approach.

Cheers
Vreixo



      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/