Skip Menu |

This queue is for tickets about the Prima CPAN distribution.

Report information
The Basics
Id: 68187
Status: resolved
Priority: 0/
Queue: Prima

People
Owner: Nobody in particular
Requestors: user42 [...] zip.com.au
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: open_help() raise window
Date: Sat, 14 May 2011 12:00:27 +1000
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
In my help menu I open_help() to stuff about current settings, or to the main application pod. If the help window is already open but buried under other windows I think I'd like to raise it up. Is there something for that hidden somewhere? The Prima::Application docs of open_help() could cross-reference if I've missed it. I see the focus is moved to the help window, but it can be underneath other windows. I don't think the window manager is supposed to raise automatically for a focus move. Not sure if the NETWM spec fancy ideas about raising or presenting another window within a client. I use fvwm which does some or most of netwm I think, but for plain ICCCM wm's I suppose just a raise would the thing.
Птн Май 13 22:00:47 2011, user42@zip.com.au писал: Show quoted text
> In my help menu I open_help() to stuff about current settings, or to the > main application pod. If the help window is already open but buried > under other windows I think I'd like to raise it up.
Good idea, agree. Show quoted text
> I see the focus is moved to the help window, but it can be underneath > other windows. I don't think the window manager is supposed to raise > automatically for a focus move.
No, absolutely - that's just focus. Window::bring_to_front got to be called for that. BTW we're now on github (https://github.com/dk/Prima), so if you feel like playing with the code and sending a patch, you're mostly welcome.
Subject: Re: [rt.cpan.org #68187] open_help() raise window
Date: Mon, 16 May 2011 09:00:38 +1000
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"KARASIK via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > a patch
Oh, well, I was unsure if open_help() ought to raise, or if that was a matter for the menu/context/etc it was called from. I suspect if open_help() moves the focus then it ought to do something toward making that window visible. I'd probably start with a plain raise and worry later if something subtle like only put it on top of the application's own windows, not other client windows.
Finally got around to the bug. Indeed, I couldn't figure it out long time because it seems that all just works on win32. At last I've got an Ubuntu installation that indeed reproduces the problem where help viewer (and other windows using select()) don't pop up to the front, but just got focused. The problem is, that XMapRaised() call that supposed to bring an X window on top of window stack, can be (and apparently is) ignored by Ubuntu's default window manager. Not a problem by itself, because window managers are supposed to be doing just that - intercept top-level window positioning, sizing etc requests. But there's an inconsistency. Interestingly enough, I couldn't find a working X incantation that actually would bring a window forward. It seems, that if a window manager is hell-bent on not letting a program doing that, one just cannot by using standard X11 calls. I'm guessing there are netwm- or other extensions, that let the programmer doing that, but I don't know any. But so far the behavior in such particular X11 environment is at least consistent with other X11 applications. So I see no point in fighting a WM here, and thus pausing the bug until a reliable way to bring forward a top-level window is found.
Subject: Re: [rt.cpan.org #68187] open_help() raise window
Date: Sat, 23 Jul 2011 08:58:37 +1000
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"KARASIK via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > win32
It always raises the focused toplevel or something does it? Show quoted text
> The problem is, that XMapRaised() call that supposed to bring an X > window on top of window stack, can be (and apparently is) ignored by > Ubuntu's default window manager.
Are you sure? Which wm is that? I tried the program below doing a bring_to_front() and it has the effect I think I want, under fvwm at least. Clicking on "open_help" moves the focus to the help window but doesn't raise it, whereas clicking "open_help and raise" does raise it. Might open_help() do a bring_to_front() like that? Show quoted text
> It seems, that if a window > manager is hell-bent on not letting a program doing that, one just > cannot by using standard X11 calls.
That's so, but it's supposed to have a reason for doing or not doing of course :-). Show quoted text
> I'm guessing there are netwm- or > other extensions, that let the programmer doing that, but I don't know any.
My reading of the netwm is that applications can/should use the normal ConfigureRequest for stacking order. There's a _NET_WM_USER_TIME thing which is supposed to prevent a badly lagged application from raising or focusing away from something else you've switched to in the interim, but if I'm not mistaken you never set that so it shouldn't apply.
#!/usr/bin/perl -w use strict; use Prima 'Buttons', 'Application'; my $w = Prima::MainWindow->create (height => 100, width => 200); $w->insert(Button => origin => [ 0,50], selectable => 1, text => "open_help", onClick => sub { $::application->open_help ("Prima"); }, ); $w->insert(Button => origin => [ 0,0], selectable => 1, text => "open_help and raise", onClick => sub { $::application->open_help ("Prima"); my $help = $Prima::HelpViewer::helpWindows[0]; $help->bring_to_front; }, ); Prima->run; exit 0;
-- These prestigious wrought-iron security gates are bullet-proof, bomb-proof, and battering-ram resistant.
Subject: Re: [rt.cpan.org #68187] open_help() raise window
Date: Sat, 23 Jul 2011 19:44:47 +0200
To: Kevin Ryde via RT <bug-Prima [...] rt.cpan.org>
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
On Fri, Jul 22, 2011 at 06:58:44PM -0400, Kevin Ryde via RT wrote: Show quoted text
> Queue: Prima > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=68187 > > > "KARASIK via RT" <bug-Prima@rt.cpan.org> writes:
> > > > win32
> > It always raises the focused toplevel or something does it?
Always, and automatically. Show quoted text
> > The problem is, that XMapRaised() call that supposed to bring an X > > window on top of window stack, can be (and apparently is) ignored by > > Ubuntu's default window manager.
> Are you sure? Which wm is that?
Almost sure. I did all kinds of debug prints and added XMapRaised and XRaiseWindow calls in arbitrary places in the code. The WM is metacity. Show quoted text
> > It seems, that if a window > > manager is hell-bent on not letting a program doing that, one just > > cannot by using standard X11 calls.
> That's so, but it's supposed to have a reason for doing or not doing of > course :-).
It works fine when XMapRaised is called on a hidden window. Show quoted text
> My reading of the netwm is that applications can/should use the normal > ConfigureRequest for stacking order.
Indeed. Metacity does an interesting thing - when I do bring_to_front on the only window in the Prima app, its icon blinks on the taskbar, and as soon I navigate the mouse outside the currently focused app, it brings the Prima app up the stack. However, when I do that on a two-window Prima app, the icon still blinks, but metacity doesn't bring forward the window. But anyways. I've committed an extra bring_to_front in HelpViewer.pm, which even though doesn't do much, still feels in line with the expected behavior. Show quoted text
> There's a _NET_WM_USER_TIME thing which is supposed to prevent a badly > lagged application from raising or focusing away from something else > you've switched to in the interim, but if I'm not mistaken you never set > that so it shouldn't apply.
Agree, it's kind of too much. Show quoted text
> > >
Show quoted text
> #!/usr/bin/perl -w > use strict; > use Prima 'Buttons', 'Application'; > > my $w = Prima::MainWindow->create (height => 100, > width => 200); > $w->insert(Button => > origin => [ 0,50], > selectable => 1, > text => "open_help", > onClick => sub { > $::application->open_help ("Prima"); > }, > ); > $w->insert(Button => > origin => [ 0,0], > selectable => 1, > text => "open_help and raise", > onClick => sub { > $::application->open_help ("Prima"); > my $help = $Prima::HelpViewer::helpWindows[0]; > $help->bring_to_front; > }, > ); > Prima->run; > exit 0;
Show quoted text
> > > > -- > These prestigious wrought-iron security gates are bullet-proof, > bomb-proof, and battering-ram resistant.
-- Sincerely, Dmitry Karasik
Subject: Re: [rt.cpan.org #68187] open_help() raise window
Date: Mon, 25 Jul 2011 11:19:21 +1000
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Dmitry Karasik via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > Almost sure. I did all kinds of debug prints and added XMapRaised and XRaiseWindow calls > in arbitrary places in the code.
There's a cute "xwit" program to experiment with things externally, like "xwit -raise -id 12345". Normally any client can act on any window. Show quoted text
> Indeed. Metacity does an interesting thing - when I do bring_to_front > on the only window in the Prima app, its icon blinks on the taskbar, and > as soon I navigate the mouse outside the currently focused app, it brings > the Prima app up the stack. However, when I do that on a two-window Prima app, > the icon still blinks, but metacity doesn't bring forward the window.
Sounds like a bug. For the help I had the prima main win as the focused window and open_help from there. You'd have to want the wm to allow a raise of a newly focused window belonging to the same app. I wonder if the window_group field of the WM_HINTS property would tell it the help belongs to the mainwin -- if that's not already what you do and if it doesn't already work that out ... Do you use the WM_TAKE_FOCUS thingie too? That might be slightly unusual so maybe you're exploring interesting corners of the wm :-) Show quoted text
> But anyways. I've committed an extra bring_to_front in HelpViewer.pm, which even > though doesn't do much, still feels in line with the expected behavior.
Should work for sensible ones like fvwm, I'll try the next release. -- The sigfile food series: (Jackie French) "Carob" -- Doesn't have chocolate's caffine, its theobromine, or its taste. On the other hand it's brown, can be made sweet, and has roughly the same texture. The same might be said for dog droppings.
Subject: Re: [rt.cpan.org #68187] open_help() raise window
Date: Mon, 25 Jul 2011 09:28:06 +0200
To: Kevin Ryde via RT <bug-Prima [...] rt.cpan.org>
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
Show quoted text
> There's a cute "xwit" program to experiment with things externally, like > "xwit -raise -id 12345". Normally any client can act on any window.
Ooh cool! Thanks! That should help a lot. Show quoted text
> Sounds like a bug. For the help I had the prima main win as the focused > window and open_help from there. You'd have to want the wm to allow a > raise of a newly focused window belonging to the same app.
Or a default behavior that can be changed somewhere in WM settings... Show quoted text
> I wonder if the window_group field of the WM_HINTS property would tell > it the help belongs to the mainwin -- if that's not already what you do > and if it doesn't already work that out ...
No, that's not I'm doing. Frankly, I never paid attention to window_group before, I guess that needs experimenting how it works with different window managers. This quote is though a bit unnerving: "or example, if a single application manipulates multiple top- level windows, this allows you to provide enough information that a window manager can iconify all of the windows rather than just the one window." . Which raises a question, is that a good idea to use that field at all? Is it something that WM always does, or one can count on WM doing that, or ... ? Show quoted text
> Do you use the WM_TAKE_FOCUS thingie too? That might be slightly > unusual so maybe you're exploring interesting corners of the wm :-)
Yes, I'm handling that. It's not that important a message, if I ignore that, the WM raises a window anyway ... it just helps to assign the focus to the last focused widget in the hierarchy inside the window. Show quoted text
> Should work for sensible ones like fvwm, I'll try the next release.
You're very welcome to try the github version before it hits CPAN. Also, if you could give me your github ID, I add you to the collaborators there (if you don't mind that of course). -- Sincerely, Dmitry Karasik
Hi, Just tested your suggestions. Behaviors with and without window_group hints are identical. xwit got me a glimpse of hope because of its "-pop" and "-raise" options, where the latter called XConfigureWindow(CWStackMode:Above) while I do XMapRaised(). But studying x11 source revealed that these are just identical. And yes, xwit couldn't bring forward a window too; metacity just blinks the window and that's it. So I guess that's just metacity stuff, not a general problem.
Subject: Re: [rt.cpan.org #68187] open_help() raise window
Date: Sat, 06 Aug 2011 11:00:13 +1000
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Dmitry Karasik via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > "or example, if a single application manipulates multiple top- level > windows, this allows you to provide enough information that a window > manager can iconify all of the windows rather than just the one > window."
Might be a good thing to iconify a help window together with the main window it's helping ... sometimes at least. Show quoted text
> Which raises a question, is that a good idea to use that > field at all?
Dunno. Just wondered if metacity needed it somehow. Leave it out for now if unsure. Show quoted text
> github version
I forgot I'd already downloaded that too :). Show quoted text
> XConfigureWindow(CWStackMode:Above) while I do XMapRaised(). But > studying x11 source revealed that these are just identical.
Yes, I think so. The xlib docs aren't very clear on such things. Show quoted text
> So I guess that's just metacity stuff, not a general problem.
Alas.
Птн Авг 05 21:00:14 2011, user42@zip.com.au писал: Show quoted text
> "Dmitry Karasik via RT" <bug-Prima@rt.cpan.org> writes:
> > > > "or example, if a single application manipulates multiple top- level > > windows, this allows you to provide enough information that a window > > manager can iconify all of the windows rather than just the one > > window."
> > Might be a good thing to iconify a help window together with the main > window it's helping ... sometimes at least.
Indeed, we can't do (or at least propose) that feature using window grouping. OTOH HelpViewer can be smart enough to track main window's onWindowState, but that's another story. Show quoted text
>
> > Which raises a question, is that a good idea to use that > > field at all?
> > Dunno. Just wondered if metacity needed it somehow. Leave it out for > now if unsure. >
> > github version
> > I forgot I'd already downloaded that too :). >
> > XConfigureWindow(CWStackMode:Above) while I do XMapRaised(). But > > studying x11 source revealed that these are just identical.
> > Yes, I think so. The xlib docs aren't very clear on such things. >
> > So I guess that's just metacity stuff, not a general problem.
> > Alas.
Ok, closing then