You are not logged in.
In obconf, under Windows, I have:
√ Focus new windows when they appear
...
√ Center new windows when they are placed
Prefer to place new windows on: The monitor with the mouse
Primary monitor: Monitor With Mouse Pointer
...
But in the corresponding rc.xml, I have
<placement>
<policy>Smart</policy>
<!-- 'Smart' or 'UnderMouse' -->
<center>yes</center>
<!-- whether to place windows in the center of the free area found or
the top left corner -->
<monitor>Mouse</monitor>
<!-- with Smart placement on a multi-monitor system, try to place new windows
on: 'Any' - any monitor, 'Mouse' - where the mouse is, 'Active' - where
the active window is, 'Primary' - only on the primary monitor -->
<primaryMonitor>Mouse</primaryMonitor>
<!-- The monitor where Openbox should place popup dialogs such as the
focus cycling popup, or the desktop switch popup. It can be an index
from 1, specifying a particular monitor. Or it can be one of the
following: 'Mouse' - where the mouse is, or
'Active' - where the active window is -->
</placement>
And the behaviour is this:
Windows try to get as close to the top left corner as possible without overlapping any other windows. This does sound like what "Smart" policy would refer to, but it is not listening to the <center>yes</center> tag.
Last edited by jameh0 (2014-03-22 17:59:40)
Life is very short, and there's no time for fussing and fighting, my friends.
Offline
Ohhhhhhh, I think I know what the problem is.
Which Openbox package are you using specifically? Are you using openbox or openbox-git?
Because, if I remember correctly, "smart placement" in the development version of Openbox has been changed to be REALLY crappy.
Offline
I think you're right , I did only notice the problem when I switched to using the git master branch.
Life is very short, and there's no time for fussing and fighting, my friends.
Offline
NOOOOOO So that new "smart" placement is still the way it's currently done in openbox-git? I hate it! When I open a new window on my nice fancy LCD monitor, why would I want to move my head / eyes to the upper left corner?
Oh, well. Maybe enough nerds will complain and it will be put back to center placement. If not, it's not hard to patch, so no problem.
Offline
Gosh darn it, it's official. As of Openbox 3.5.2, this stupid feature is now standard.
I'm gonna scour the Openbox tracker and mailing list to try to understand the logic behind changing this behaviour. Maybe they'll convince me that the new way is smarter than the old smart placement.
Offline
Adding the following lines to the application section of rc.xml partially solves the problem for me
<application class="*">
<position force="no">
<x>center</x>
<y>center</y>
</position>
</application>
Offline
You signed up to the Arch Linux forums last year and waited all this time to write this as your first post? I want to kiss you!
I'll try it out when I get home.
EDIT: ...I mean the "rc.xml" file additions. Not kissing you.
Last edited by drcouzelis (2013-08-12 14:41:25)
Offline
After upgrading form Openbox 3.5.0 to Openbox 3.5.2 I am also noticing this change. I am finding it hard to adjust, and I think the fact that I am using a large monitor is making matters worse.
It seems that the behavior of the "Smart" window placement policy has changed as of version 3.5.1. See the Openbox changelog.
Giving a new policy the same name as the old one seems like... well, a bad policy. Further, "Smart" is a subjective term and doesn't say much about the actual behavior, but I digress.
I'm curious to know if the old window placement policy is still available under a different name. Regardless of the default, it would be nice to give the user option to revert to the old policy; in my case, it seems to be a better fit. I would imagine that this feature is mostly a matter of personal preference.
A cursory glance at the Openbox documentation and source code reveals only two policies: "Smart" and "UnderMouse".
Offline
Yeah, I've been reviewing the code too. I'm usually pretty good at making a small patch to revert an undesired modification, but I just can't wrap my head around this one. Nor can I wrap my head around why this is considered better than the former Smart Placement.
There's a (currently rather boring) bug report for it here: https://bugzilla.icculus.org/show_bug.cgi?id=5946
There's an unanswered "thread" on the mailing list here: http://icculus.org/pipermail/openbox/20 … 07741.html
For convenience, the Openbox git repository: http://git.openbox.org/?p=dana/openbox.git;a=summary
If it can pretty much be reverted just by editing the "rc.xml" file then that's fine by me. This also might be a good opportunity to try the latest version of my first love: Window Maker.
Last edited by drcouzelis (2013-08-15 19:57:51)
Offline
Today i updated to openbox 3.5.2 and i also find this very annoying
Offline
Adding the following lines to the application section of rc.xml partially solves the problem for me
<application class="*"> <position force="no"> <x>center</x> <y>center</y> </position> </application>
Cool, now i have tint2 on the center of screen
http://gjm.rootedker.nl/screenshots/10_ … _scrot.png
Offline
sullenel wrote:Adding the following lines to the application section of rc.xml partially solves the problem for me
<application class="*"> <position force="no"> <x>center</x> <y>center</y> </position> </application>
Cool, now i have tint2 on the center of screen
Right, hence the "partially solves". I have that trick in my "rc.xml" file at the moment but haven't yet decided what I'm going to do long term.
Part of me wonders if this was just a developer oversight, like how the right click drag-and-drop menu was removed not too long ago from Thunar (when we complained that it was removed, the developer was like, "Ohhh, so THAT'S what that code does. LOL No problem, I'll put it back."), but I have a feeling that's not the case in this scenario.
Offline
Isn't it possible to add a specific application section for tint2 after the general one, to replace it only for tint2, like that:
<application class="*">
<position force="no">
<x>center</x>
<y>center</y>
</position>
</application>
<application type="dock">
<position force="no">
<x>default</x>
<y>default</y>
</position>
</application>
'<application type="dock">' can be replaced by '<application title="tint2">'
and 'default' by a desired value for the placement of tint2 on the screen.
According to the doc the last rule should be applied only to tint2 which matches the type or the title.
Last edited by berbae (2013-08-13 13:54:41)
Offline
@gjm
Seems you use tint2 as a dock application. You can disable that by setting panel_dock to 0 in tint2rc, but still the rc.xml trick is nowhere near a good solution.
Offline
Isn't it possible to add a specific application section for tint2 after the general one, to replace it only for tint2, like that:
<application class="*"> <position force="no"> <x>center</x> <y>center</y> </position> </application> <application type="dock"> <position force="no"> <x>default</x> <y>default</y> </position> </application>
'<application type="dock">' can be replaced by '<application title="tint2">'
and 'default' by a desired value for the placement of tint2 on the screen.
According to the doc the last rule should be applied only to tint2 which matches the type or the title.
It works, but now the windows are windows are positioned in a weird place (right from the center of the screen).
Offline
According to the bug report in https://bugzilla.icculus.org/show_bug.cgi?id=5946 the center feature appears to be removed only temporarily.
Center would need to be reimplemented in the new code. The configuration option was removed since this algorithm does not support it currently.
So hopefully center will be back in the next release. For the time being I do work around this with a center window command bound to a simple key combination.
To know or not to know ...
... the questions remain forever.
Offline
My (hopefully) temporary yet cheeky solution: https://aur.archlinux.org/packages/open … -centered/
I can't even tell the difference between this old version and the new version, besides the obnoxious window placement. I'm still checking out other window managers (and maybe even go back to KDE), but in the meantime this "openbox-smart-centered" package provides a simple way to install the older version without pacman complaining.
Offline
My (hopefully) temporary yet cheeky solution: https://aur.archlinux.org/packages/open … -centered/
You fixed the problem with crashing Openbox with gtk3 applications? (hint: fixed in Openbox 3.5.0-6, your version: 3.5.0-1). Also, downgrade is more convenient for me.
Last edited by gjm (2013-08-15 18:49:49)
Offline
Sorry about the confusion. My package is equivalent to openbox-3.5.0-9, the latest release to [community] before the code changes.
Since I made a new package I put the release count number back down from 9 to 1.
Offline
This is where the discussion is happening: https://bugzilla.icculus.org/show_bug.cgi?id=5946
Solowolf is looking into it
"At some point in the not too distant future."
Edit: just noticed this bug was linked to already.
Last edited by jameh0 (2013-08-16 14:31:29)
Life is very short, and there's no time for fussing and fighting, my friends.
Offline
There's an open pull request in Openbox' repo that fixes this. Lets hope it gets included in the next version.
It's all GNU to me.
Offline
This still isn't fixed in the new update, so I have just reverted to the old version (Assuming you have it cached):
pacman -U /var/cache/pacman/pkg/openbox-3.5.0-9-x86_64.pkg.tar.xz
And then will ignore openbox when I run my updates till this is fixed.
Offline
As the bug report states, this issue is now resolved. You can start using it by installing the "openbox-git" package from the AUR.
Sadly, I haven't quite figured out what I'll do about the other recent change to "Smart Placement": if there's no room to place the new window, it's now loads in one of the four corners (instead of random placement like before) which means my Conky information gets covered often.
Offline
it's not hard to patch, so no problem.
I just finished patching Openbox to restore the former random window placement behavior. You can find it here: openbox-git-random-placement
It works but I didn't fully test all scenarios (multi-monitors, different window states, and so on...) so if you find any bugs in my patch or random window placement code please let me know!
Last edited by drcouzelis (2014-03-27 01:58:19)
Offline
drcouzelis wrote:it's not hard to patch, so no problem.
I just finished patching Openbox to restore the former random window placement behavior. You can find it here: openbox-git-random-placement
It works but I didn't fully test all scenarios (multi-monitors, different window states, and so on...) so if you find any bugs in my patch or random window placement code please let me know!
Im having trouble discerning what exactly you mean. I could build your version to find out, but the current openbox-git seems to work exactly this way?
I have smart placement and center set. When I open a new window on a blank workspace, its placed centered. If I open another, it will be placed in empty space. It will keep placing in empty space until the desktop is completely hidden, and then it will start randomly placing the window.
I have considered talking to the Openbox devs about possibly implementing the placement algorithm of Fluxbox- Flux will evenly distribute the windows even after the entire screen is filled/covered.
**EDIT** Do you mean your version starts to random place the moment it cant fit the window in empty space without even partially obscuring an existing window?
Last edited by GSF1200S (2014-03-27 04:18:56)
Offline