I find that I often use specific window sizes and positions:
- Full screen (= maximized, supported by OB)
- Left half of screen
- Right half of screen
- Top left quarter of screen
- Top right ...
- Bottom left ...
- Bottom right ...
- On a widescreen monitor, it may make sense to have 6 positions in three columns.
WIBNI the Move-and-Resize operation supported entering these positions/sizes?
One idea is to say that if the width/height are less than one, then they are fractions of the screen width/height. Or if the value ends in %, then it is percentage of screen dimension. Or support entering ratios with "/", such as "1/2" or "1/3" or "2/3".
Similar values could be used for x and y position.
For practical usage, it may be sufficient to bind keys to "set the width of this window to 1/2 of screen width" and similar commands, then use the "move in a direction until you hit a window border or screen edge" commands to position the windows.
I guess all computations should take into account the usable screen area, i.e. the area of the screen that would be covered by a maximized window. When using OB with a panel, that would exclude a margin near a screen edge.
What do people think?
If you want to know "what do people think?" you probably want the ml, i'm most likely the only one to look at this :).
i think this is probably a good idea, but for putting windows aligned to the right edge or bottom edge, you can already do that. (see http://icculus.org/openbox/index.php/Help:Actions#MoveResizeTo ).
I just wonder if there has been a discussion about this bug. Apparently, many people use MoveResizeTo as a way to mimic tiling (a rather effective one, I think) and it seems to me calculating pixels is not a good way of defining something like 50% of vertical screen size, especially if you switch between different display sizes, like I do.
Therefore, is there any chance this feature might get implemented, although the bug has been on "ASSIGNED" status for a long time?
I'd accept a patch for this. I like the idea of ratios cuz you can be as precise as you like without using decimal points. Ratios of > 1 should be treated as 1.
Created attachment 2334[details]
First go
This applies to work and lets you say "32%" or "23/74" instead of a pixel position, and currently applies to moveresizeto and per-app positions only.
right now it applies to the left/top edge (or right/bottom if you give a - before as it has always been), but it might make more sense for this stuff to have 0% be aligned to the left and 100% to be aligned to the right.
(In reply to comment #5)
> right now it applies to the left/top edge (or right/bottom if you give a -
> before as it has always been), but it might make more sense for this stuff to
> have 0% be aligned to the left and 100% to be aligned to the right.
for width, 100% aligned to the left should be the same as 100% aligned to the right. for position it would be the same as 0% to the right. right ?
(In reply to comment #6)
> (In reply to comment #5)
> > right now it applies to the left/top edge (or right/bottom if you give a -
> > before as it has always been), but it might make more sense for this stuff to
> > have 0% be aligned to the left and 100% to be aligned to the right.
>
> for width, 100% aligned to the left should be the same as 100% aligned to the
> right. for position it would be the same as 0% to the right. right ?
Yeah, but I can see you wanting to put a window that isn't half the width of the screen to the right of the center line, and you can't do both that and center a window without something more clever.
My current idea is to allow you to say <x anchor="foo">bar</x>, foo can be anything that bar can be, but also left/center/right (and top/bottom for y), so that position foo in the window will be aligned with the given position bar on the screen.
This is of course not an issue for sizes, only for positions.
(In reply to comment #8)
> Is this patch already applied in current openbox? Also, how it behaves in a
> multi-monitor setup?
Searching in the git log and trying it myself I see that this patch have already been applied, but no documentation about it was added in the wiki.
Looks like OpenBox 3.5.0 has this patch applied and both 50% and 1/2 style ratios work.
The problem is that they are not "pixel-perfect":
If I have two windows:
a) MoveResizeTo - height:50%, y:0
b) MoveResizeTo - height:50%, y:-0
then they overlap vertically.
If both windows have window decorators disabled then the overlap is only ~2px.
But if the decorators (title bar, close button etc) are turned on then the overlap is bigger.
I could be wrong but looks like the geometry does not take decorators into account.
Should I file this report as a separate bug?
I tried to look up the source but not sure if http://git.icculus.org/?p=mikachu/openbox.git is the latest head, release-3.5.0 tag does not seem to be there.
the moveresizeto action has an option for setting client or frame size, and defaults to frame size. the per-app settings always use client size (eg, not including decor).
Created attachment 2334 [details] First go This applies to work and lets you say "32%" or "23/74" instead of a pixel position, and currently applies to moveresizeto and per-app positions only.