Menu
▾
▴
#263 Reordering of layers
After I have checked this bug (https://sourceforge.net/tracker/?func=detail&aid=3300797&group_id=156956&atid=801864) and can confirm it is fixed I have noticed that this is a more generic problem. Other subwindows like the attribute menu or creating a new object aren't on the first layer too. But hiding the copy subwindow could be a problem too.
But there is a solution that solves all of these problems: What I would change:
1. The last opened subwindow orders itself to the top.
2. It should be possible to reorder these subwindows. This should be happen for example if I click the menus on my panel. The last clicked subwindow will reorder itself to the top.
Discussion
Anonymous
All places where widows are opened were already corrected to open them exactly above of other pcmanfm window. And behavior when application enforces all own windows to be "always on top" is abusive and therefore forbidden, we will never do that. If the window manager orders windows badly then that should be reported to the window manager bug tracker. BTW, there are bugs in ubuntu bugtracker against this behavior of openbox 3.5.0 - see https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/957808 for example. I'm sorry but this isn't pcmanfm bug.
Also look into https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/906692
The windows shall not be "always on top" but "reordered to top". But you said already this is an Openbox bug and I will make a look on it.
But I'm wondering now why the deletion prompt is on the top but other windows not.
Edit: I have made a look into the 2 tickets and if I understand it correctly:
https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/906692
This is a total different problem.
https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/957808
I have encountered this problem too and can reproduce it (try to open 2 terminals with F4 while a PCManFM window is opened _and_ focused). But it seems to have nothing to do with this problem because: The subwindows of PCManFM are not ordered to the top even if clicked directly. This is even easy to reproduce:
1. Copy some big data (so that you have enough time to do alll the steps) from one directory to another (let's say to /tmp).
2. Open the attribute window of a random file or directory in /tmp.
3. The attribute window spawned behind the copy window (which sounds like https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/957808\).
4. Click on the attribute window.
5. The attribute window doesn't move to the top (which is not https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/957808 anymore).
Deletion prompt is on top in your case since it is an emergency window and I've enforced the flag "always on top". That is a bit wrong but I decided it can be in such case. But I would not set "always on top" flag for other windows.
Application has no possibility to reorder windows - that is function of window manager, application only can set tip "always on top" or "over of main window" to ask window manager keep the window above or ask window manager to enforce focus to the window. But every window operation is done by window manager (i.e. Openbox in such case).
I've added some request to window manager on progress dialog though. Change is in Git. Check it, please, it should solve mentioned problem, it works on Openbox 3.5.0 at least.
> Application has no possibility to reorder windows
Firefox is able on my system to reorder subwindows (or give a request to the window manager that does this successfully). This means that PCManFM should theoretically be able to do this too (maybe there are some functions about the X-Server or some related API which you don't know).
> I've added some request to window manager on progress dialog though. Change
is in Git. Check it, please, it should solve mentioned problem, it works on
Openbox 3.5.0 at least.
I'm now a little confused. I will wait until PCManFM 1.0.2 is out and in the Ubuntu repository to check if there is any difference.
Probably there are low-level requests to window manager but if pcmanfm will take over window manager functions it will make pcmanfm bloated monster not lightweight anymore. I'm sorry, I'm not going to do that.
There is a PPA with LXDE daily git builds, you can use them to get fresh git version each next day and test it. It has not so much up-to-date package splitting but it should be installable at least.
I have figured out something very interesting: PCManFM is already doing such a reordering with some subwindows (but not all). Just open the attribute window of any directory/file and the configuration window of PCManFM. Both subwindows are correctly ordered if clicked. Why is this done with these subwindows but not with all?
I've said you already - pcmanfm does nothing with windows. All of that you've found is done by openbox. And as I've added one more hint for progress dialog I want you to test last git version of libfm and I think your problem is fixed. Thank you.
I have looked which xlib related function describes what I want and I have found it: http://tronche.com/gui/x/xlib/window/XRaiseWindow.html
It is just simple again:
If a PCManFM subwindow is clicked then apply XRaiseWindow() on it.
Thank you very much. But, please, don't give suggestions until you checked latest change in git which I asked you to do few times already.