• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: 2.3.3_rc5
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2.3.3_rc5


  • Subject: Re: 2.3.3_rc5
  • From: Jeremy Huddleston <email@hidden>
  • Date: Fri, 10 Apr 2009 12:08:17 -0700

What is the version reported by X11->About X11?  This "windows are covered by the root" issue is what should have been fixed in the 1.4.2-apple41 server in 2.3.3_rc5.

On 04/10/2009 04:49 AM, Zulli, Louis P wrote:
Hi,

Something is amiss. The situation seems complicated. Let me describe one set of actions and the result:

I have Safari assigned to Space 1 and Terminal.app assigned to Space 3. My X11 is unassigned. Start with all apps closed.

1) Click on Safari dock icon; Safari opens in Space 1.

2) Click on Terminal dock icon; Terminal opens in Space 3.

3) In Terminal, invoke xterm; get an xterm on the root background.

4) In the xterm, invoke xeyes; get eyes in the upper left corner of the root window.

5) Slide the eyes window off the xterm window, and leave the cursor arrow on the xeyes titlebar.

6) Command-opt-A; get Apple desktop in Space 3.

7) Click on Safari dock icon; get switched to Safari in Space 1.

8) Click on X11 dock icon; get root background with xeyes but with xterm window missing.

9) Command-opt-A; get Apple desktop in Space 1 with Safari showing but X11 active.

The above sequence of actions seems to generate the results indicated every time. Different behaviors seem to occur if the xeyes window is not moved or if the cursor is not left on the titlebar, but the situation is complicated and I may be mistaken.

Louis

My X11 defaults:

{
    "NSWindow Frame x11_apps" = "170 69 872 465 0 0 1280 778 ";
    "NSWindow Frame x11_prefs" = "740 279 484 330 0 0 1280 778 ";
    "app_to_run" = "/usr/X11/bin/xterm";
    "apps_menu" =     (
                (
            Terminal,
            xterm,
            n
        )
    );
    "cache_fonts" = 1;
    depth = -1;
    "done_xinit_check" = 1;
    dpi = 112;
    "enable_fake_buttons" = 0;
    "enable_key_equivalents" = 1;
    "enable_system_beep" = 0;
    "fullscreen_menu" = 0;
    "login_shell" = "/bin/sh";
    "no_auth" = 0;
    "nolisten_tcp" = 1;
    rootless = 0;
    "startx_script" = "/usr/X11/bin/startx";
    "sync_clipboard_to_pasteboard" = 1;
    "sync_keymap" = 0;
    "sync_pasteboard" = 1;
    "sync_pasteboard_to_clipboard" = 1;
    "sync_pasteboard_to_primary" = 1;
    "sync_primary_on_select" = 1;
    "wm_click_through" = 1;
    "wm_ffm" = 0;
    "wm_focus_on_new_window" = 1;
}



----- Original Message -----
From: "Pierre Baguis" <email@hidden>
To: email@hidden
Sent: Friday, April 10, 2009 6:43:32 AM GMT -05:00 US/Canada Eastern
Subject: Re: 2.3.3_rc5


It is nice to see such a fast response in issues reported. In this case however, I think some more work is needed.

Here are my findings. Assume that we are in the setting I have used as example in a previous message, i.e. X11 full screen in workspace 4 and Safari in workspace 1 and that I have just switched from X11 to Safari, which of course always works fine. Note that this application switch will move us from workspace 4 to workspace 1.

Now let us say that we want to move back to X11 (either by clicking its Dock icon or by using the cmd-tab combination). This time X11 will reveal its active windows at once, but the Mac OS X desktop is not hidden. Performing cmd-alt-a reveals why: while X11 comes to the foreground, we are still in workspace 1! Going to workspace 4 (where X11 runs) "by hand", will show the X11 windows and hide the OS X background.

Also, in my case, X11 is assigned to workspace 4. So every time I start it up, it is meant to switch the active workspace to 4 (it did that before RC5). However, now it just remains in the workspace where I launch it and it exhibits the same behaviour as previously, that is it does not hide the OS X desktop. Changing again "by hand" the workspace to 4 solves the problem.

Pierre



--- On Fri, 4/10/09, Jeremy Huddleston <email@hidden> wrote:

> From: Jeremy Huddleston <email@hidden>
> Subject: 2.3.3_rc5
> To: "Developer talk about Xquartz" <email@hidden>, "X11 List Mailing" <email@hidden>
> Date: Friday, April 10, 2009, 9:44 AM
> As promised, here's an updated rc with the spaces /
> window-levels fixes.  It also includes updates to
> libX11-1.2.1, xpyb-1.1, the libxcb patch mentioned on the
> list last week, xinput-1.4.1, and xrandr-1.3.0.  Please give
> it a good testing, and the next one really should be final.
>
> http://static.macosforge.org/xquartz/downloads/X11-2.3.3_rc5.dmg
>
> Thanks,
> Jeremy
>
> _______________________________________________
> Do not post admin requests to the list. They will be
> ignored.
> X11-users mailing list      (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> >
> This email sent to email@hidden


      
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list      (email@hidden)

This email sent to email@hidden

  • Follow-Ups:
    • Re: 2.3.3_rc5
      • From: "Zulli, Louis P" <email@hidden>
References: 
 >Re: 2.3.3_rc5 (From: "Zulli, Louis P" <email@hidden>)

  • Prev by Date: Re: 2.3.3_rc5
  • Next by Date: Re: 2.3.3_rc5
  • Previous by thread: Re: 2.3.3_rc5
  • Next by thread: Re: 2.3.3_rc5
  • Index(es):
    • Date
    • Thread