[openbox] resize maximized windows

[Clay Barnes]

On 19:48 Wed 11 Apr     , Martin Lucina wrote:
> clay.barnes at gmail.com said:
> > In a sentence---the idea of maximization is that it's a state where
> > the window cannot fill the screen more (or less) completely.  If you
> > could resize the window, that state would lose its meaning.  I know
> 
> I presume you meant "... can fill the screen ...".

I actually did mean "cannot," which, if you look carefully does work
(though I'll admit I syntactically parallelized what was not
semantically parallel---the necessity of full usage (". . .cannot fill
the screen more. . .") of the screen with the requirement of fixed
size (". . .cannot not fill the screen [...] less. . .").  I apologize
(to the whole list) for my poor style.  I should know better (being a
native English speaker *and* a Linguist!).

> 
> I'd actually find this use case useful, along with it's sister case,
> moving a maximized window:

I agree it's a useful case to be able to maximize a window and then
take a little space from it on some edge.  The real question is what
happens for the maximize state?  Do we toggle only dimensions that
have changed (still horizontally maximized if we only make the window
shorter, or do we make it just floating again?)

> 
> With a multi-head setup, a maximimzed window will cover only one head.
> It's sometimes easier to maximize an app, then go and resize it.  Being
> able to move it (to the other head(s)) just by dragging would also be
> useful.

Similar question:  do we toggle out of states for the move?  Do we
just snap between screens?  What about different-sized heads?

> 
> I can certainly remember trying to do this a few times and going 
> "Hey, why can't I do that?".

If well done, it could be a boon to OB3 to have these features (I
think), but keep in mind people like OB3 the way it is too, so if you
code it, make sure to make it a configurable feature!

>
> 
> -mato

-- 
Clay Barnes