I just thought of a nice feature, during a discussion about Gimp's interface. There could be an "intelligent" maximization which would take all available place without masking other windows. So the current window receiving such event will try to take all the place it can as long as nothing else is hidden.
Some option which would be nice also is that you can flag a window if this one can be hidden, so that the intelligent maximization won't take it into account.
This is more or less the purpose of the "grow to edge" actions. Tagging windows like this is getting really complicated, I think. Maybe a "grow to edge in all directions" action would be alright, that doesn't grow a side past an edge if another side was able to grow. i.e. it won't jump past over window until all 4 edges are able to do so (excluding monitor edges maybe)
(In reply to comment #0)
This is possible right now with this:
<keybind key="A-m">
<!-- <action name="ToggleMaximizeFull"/> -->
<action name="GrowToEdgeNorth"/>
<action name="GrowToEdgeSouth"/>
<action name="GrowToEdgeWest"/>
<action name="GrowToEdgeEast"/>
</keybind>
Now, what really be nice to get is the possibility of
not FullMaximize a window, but instead to only Maximize
it, i.e., not to remove the bottom and side decorations,
maybe as an option to FullMaximize, or based on the "keepBorder"
directive.
Best regards,
Fernando
It will be nice if we can restore "inteligent maximized" windows to his previous size... in this aspect, his behaviour is more like the maximize instead of the grow to edges.
Other suggestion: windows that want this behavior on his maximization can be 'tagged' by some kind of rule in rc.xml. Aditionally, there can be an global option that disable this behaviour or that set this behaviour as default for maximization on all the system...
Another aspect to think is wether to consider the space used by other applications windows while computing the available space... On Gimp, that has many windows, we probably want that the opened picture use all space not occupied by gimp windows. On single windowed applications, we need to consider all opened applications while maximizing, not only the application windows.
Created attachment 2379[details]
Created a "GrowToFill" action
Proposed a "GrowToFill" action that try to fit the current window to the maximum available area in all directions.
Anyone tried the patch?
(In reply to comment #7)
> Created an attachment (id=2380) [details]
> Patch reformated according the unified diff format
>
> Proposed a "GrowToFill" action.
(In reply to comment #8)
> Anyone tried the patch?
>
> (In reply to comment #7)
> > Created an attachment (id=2380) [details] [details]
> > Patch reformated according the unified diff format
> >
> > Proposed a "GrowToFill" action.
Here is a sample video with the proposed "GrowToFill" action:
http://www.youtube.com/watch?v=Xmg8IVyu-0g
The name GrowToFill is only a suggestion... I cannot find a better name...
Here is my openbox GIT repo with the "GrowToFill" patch:
https://github.com/deters/openbox.git
And this is the modifications done in the patch:
https://github.com/deters/openbox/commit/8c5daf876a7a74783be5479ab1b1ab99d833b545
Instructions to test this patch on Ubuntu:
1) Compiling and installing:
sudo apt-get install build-essential automake autoconf git gettext autopoint
sudo apt-get build-dep openbox
git clone https://github.com/deters/openbox.git
cd openbox
autopoint
./configure
make
sudo make install
2) Configure a keybind on the file "~/.config/openbox/rc.xml":
<keybind key="W-Return">
<action name="GrowToFill"/>
</keybind>
3) run openbox
openbox --replace
Thanks all
Is there anything different about this action's behaviour than just doing the following?
<action name="GrowToEdgeNorth"/>
<action name="GrowToEdgeSouth"/>
<action name="GrowToEdgeWest"/>
<action name="GrowToEdgeEast"/>
I'm not seeing the difference right now..
(In reply to comment #10)
> Is there anything different about this action's behaviour than just doing
> the following?
>
> <action name="GrowToEdgeNorth"/>
> <action name="GrowToEdgeSouth"/>
> <action name="GrowToEdgeWest"/>
> <action name="GrowToEdgeEast"/>
>
> I'm not seeing the difference right now..
Oh I see, this new action prevents shrinking. We could just add an option for that.
(In reply to comment #11)
> (In reply to comment #10)
> > Is there anything different about this action's behaviour than just doing
> > the following?
> >
> > <action name="GrowToEdgeNorth"/>
> > <action name="GrowToEdgeSouth"/>
> > <action name="GrowToEdgeWest"/>
> > <action name="GrowToEdgeEast"/>
> >
> > I'm not seeing the difference right now..
>
> Oh I see, this new action prevents shrinking. We could just add an option
> for that.
Oh, also, by doing an atomic action, the window can grow more than it would otherwise.
If you have a terminal window with 50px characters, positioned at 40y, and you grow North, it won't move. Then grow South, it could leave up to 50px below it. If these were combined it could move up to the top and grow and extra character down.
I merged the github branch in #9 to my work branch, with a few nit fixes, and reduced code duplication by reusing client_find_resize_directional() in the patch in https://github.com/danakj/openbox/commit/6cae774d48f337b256850571b1cf8446f915d5e0
I don't think this fixes this bug, as you can't "unmaximize", for that we'd need to track state across actions - and probably more likely extend all the maximize code in client.c which would be more tricky.
(In reply to comment #11)
> (In reply to comment #10)
> > Is there anything different about this action's behaviour than just doing
> > the following?
> >
> > <action name="GrowToEdgeNorth"/>
> > <action name="GrowToEdgeSouth"/>
> > <action name="GrowToEdgeWest"/>
> > <action name="GrowToEdgeEast"/>
> >
> > I'm not seeing the difference right now..
>
> Oh I see, this new action prevents shrinking. We could just add an option
> for that.
Hi,
The main advantage of this action: it will stop growing to an edge if that edge is
already "touching" other window edge, but will grow on other edges...
As an example, if your window is touching another window at north, but have space to grow in the other directions, then it will grow only on those directions it has space to grow...
(In reply to comment #14)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > Is there anything different about this action's behaviour than just doing
> > > the following?
> > >
> > > <action name="GrowToEdgeNorth"/>
> > > <action name="GrowToEdgeSouth"/>
> > > <action name="GrowToEdgeWest"/>
> > > <action name="GrowToEdgeEast"/>
> > >
> > > I'm not seeing the difference right now..
> >
> > Oh I see, this new action prevents shrinking. We could just add an option
> > for that.
>
> Hi,
>
> The main advantage of this action: it will stop growing to an edge if that
> edge is
> already "touching" other window edge, but will grow on other edges...
>
> As an example, if your window is touching another window at north, but have
> space to grow in the other directions, then it will grow only on those
> directions it has space to grow...
Oh I see. Looks like I broke that in my followup CL then. Thanks!
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #11)
> > > (In reply to comment #10)
> > > > Is there anything different about this action's behaviour than just doing
> > > > the following?
> > > >
> > > > <action name="GrowToEdgeNorth"/>
> > > > <action name="GrowToEdgeSouth"/>
> > > > <action name="GrowToEdgeWest"/>
> > > > <action name="GrowToEdgeEast"/>
> > > >
> > > > I'm not seeing the difference right now..
> > >
> > > Oh I see, this new action prevents shrinking. We could just add an option
> > > for that.
> >
> > Hi,
> >
> > The main advantage of this action: it will stop growing to an edge if that
> > edge is
> > already "touching" other window edge, but will grow on other edges...
> >
> > As an example, if your window is touching another window at north, but have
> > space to grow in the other directions, then it will grow only on those
> > directions it has space to grow...
>
> Oh I see. Looks like I broke that in my followup CL then. Thanks!
My trick to achieve "not growing when touching other window" was decrease 1 pixel the position of the edge relative to some direction before calling client_find_edge_directional... so I will always find the already "touched" edge and will not grow in that direction.
(In reply to comment #16)
> My trick to achieve "not growing when touching other window" was decrease 1
> pixel the position of the edge relative to some direction before calling
> client_find_edge_directional... so I will always find the already "touched"
> edge and will not grow in that direction.
Yup! Makes sense. I'm extending the client_find_resize_directional() method to support this use case :)
I thought about allowing the action to grow further, if all edges are already blocked. I'm not sure if that's good or not, but it would more closely match the behaviour of the other grow actions. So I think I'll implement that for now. We could always make it an option too.
(In reply to comment #20)
> Added the new behaviour in
> https://github.com/danakj/openbox/commit/
> e1973cfbaa35e990b4eebaa591e182e79bf6374d
Thanks Dana! Right now I'm facing problems to compile latest openbox releases, something wrong with my autotools or so... as soon as I can I will try the new action. Thanks again! :)
Ok thanks. When you figure it out, if there's anything you need to change in Openbox to make it work please file a bug.
I've using the latest ubuntu without any funny hacks and compiling okay, FWIW. If the problem is due to librsvg, you can use --disable-librsvg. Some users (slackware) have reported this. But I have no idea what I should be doing to make it compile correctly there with librsvg yet.
Thanks (In reply to comment #22)
> Ok thanks. When you figure it out, if there's anything you need to change in
> Openbox to make it work please file a bug.
>
> I've using the latest ubuntu without any funny hacks and compiling okay,
> FWIW. If the problem is due to librsvg, you can use --disable-librsvg. Some
> users (slackware) have reported this. But I have no idea what I should be
> doing to make it compile correctly there with librsvg yet.
Got it working here just by reading readme.git...
Done some tests here... it's working ok, except the new "keep growing" behaviour... just do not make sense to me the need to keep growing when all empty space are ocuppied... can this behaviour be optional?
(In reply to comment #23)
> Thanks (In reply to comment #22)
> > Ok thanks. When you figure it out, if there's anything you need to change in
> > Openbox to make it work please file a bug.
> >
> > I've using the latest ubuntu without any funny hacks and compiling okay,
> > FWIW. If the problem is due to librsvg, you can use --disable-librsvg. Some
> > users (slackware) have reported this. But I have no idea what I should be
> > doing to make it compile correctly there with librsvg yet.
>
> Got it working here just by reading readme.git...
>
> Done some tests here... it's working ok, except the new "keep growing"
> behaviour... just do not make sense to me the need to keep growing when all
> empty space are ocuppied... can this behaviour be optional?
Sure, want to add a "once" tag to the action, which defaults false, and send me a pull request on github?
Just occured to me, we need to add this thing to rc.xsd also.
(In reply to comment #23)
> Thanks (In reply to comment #22)
> > Ok thanks. When you figure it out, if there's anything you need to change in
> > Openbox to make it work please file a bug.
> >
> > I've using the latest ubuntu without any funny hacks and compiling okay,
> > FWIW. If the problem is due to librsvg, you can use --disable-librsvg. Some
> > users (slackware) have reported this. But I have no idea what I should be
> > doing to make it compile correctly there with librsvg yet.
>
> Got it working here just by reading readme.git...
>
> Done some tests here... it's working ok, except the new "keep growing"
> behaviour... just do not make sense to me the need to keep growing when all
> empty space are ocuppied... can this behaviour be optional?
(In reply to comment #24)
> (In reply to comment #23)
> > Thanks (In reply to comment #22)
> > > Ok thanks. When you figure it out, if there's anything you need to change in
> > > Openbox to make it work please file a bug.
> > >
> > > I've using the latest ubuntu without any funny hacks and compiling okay,
> > > FWIW. If the problem is due to librsvg, you can use --disable-librsvg. Some
> > > users (slackware) have reported this. But I have no idea what I should be
> > > doing to make it compile correctly there with librsvg yet.
> >
> > Got it working here just by reading readme.git...
> >
> > Done some tests here... it's working ok, except the new "keep growing"
> > behaviour... just do not make sense to me the need to keep growing when all
> > empty space are ocuppied... can this behaviour be optional?
>
> Sure, want to add a "once" tag to the action, which defaults false, and send
> me a pull request on github?
>
> Just occured to me, we need to add this thing to rc.xsd also.
Thinking more, if the GrowToEdge* actions had this option to stop growing then facing some edge, the GrowToFill would almost be unnecessary...
(In reply to comment #25)
> (In reply to comment #23)
> > Thanks (In reply to comment #22)
> > > Ok thanks. When you figure it out, if there's anything you need to change in
> > > Openbox to make it work please file a bug.
> > >
> > > I've using the latest ubuntu without any funny hacks and compiling okay,
> > > FWIW. If the problem is due to librsvg, you can use --disable-librsvg. Some
> > > users (slackware) have reported this. But I have no idea what I should be
> > > doing to make it compile correctly there with librsvg yet.
> >
> > Got it working here just by reading readme.git...
> >
> > Done some tests here... it's working ok, except the new "keep growing"
> > behaviour... just do not make sense to me the need to keep growing when all
> > empty space are ocuppied... can this behaviour be optional?
>
> (In reply to comment #24)
> > (In reply to comment #23)
> > > Thanks (In reply to comment #22)
> > > > Ok thanks. When you figure it out, if there's anything you need to change in
> > > > Openbox to make it work please file a bug.
> > > >
> > > > I've using the latest ubuntu without any funny hacks and compiling okay,
> > > > FWIW. If the problem is due to librsvg, you can use --disable-librsvg. Some
> > > > users (slackware) have reported this. But I have no idea what I should be
> > > > doing to make it compile correctly there with librsvg yet.
> > >
> > > Got it working here just by reading readme.git...
> > >
> > > Done some tests here... it's working ok, except the new "keep growing"
> > > behaviour... just do not make sense to me the need to keep growing when all
> > > empty space are ocuppied... can this behaviour be optional?
> >
> > Sure, want to add a "once" tag to the action, which defaults false, and send
> > me a pull request on github?
> >
> > Just occured to me, we need to add this thing to rc.xsd also.
>
>
> Thinking more, if the GrowToEdge* actions had this option to stop growing
> then facing some edge, the GrowToFill would almost be unnecessary...
Correcting:
Thinking more, if the GrowToEdge* actions had this option to stop growing WHEN facing some edge, the GrowToFill would be unnecessary...
(In reply to comment #24)
> (In reply to comment #23)
> > Thanks (In reply to comment #22)
> > > Ok thanks. When you figure it out, if there's anything you need to change in
> > > Openbox to make it work please file a bug.
> > >
> > > I've using the latest ubuntu without any funny hacks and compiling okay,
> > > FWIW. If the problem is due to librsvg, you can use --disable-librsvg. Some
> > > users (slackware) have reported this. But I have no idea what I should be
> > > doing to make it compile correctly there with librsvg yet.
> >
> > Got it working here just by reading readme.git...
> >
> > Done some tests here... it's working ok, except the new "keep growing"
> > behaviour... just do not make sense to me the need to keep growing when all
> > empty space are ocuppied... can this behaviour be optional?
>
> Sure, want to add a "once" tag to the action, which defaults false, and send
> me a pull request on github?
>
> Just occured to me, we need to add this thing to rc.xsd also.
Will try to do it... I'm not what you can call a "great developer"... :)
> > Thinking more, if the GrowToEdge* actions had this option to stop growing
> > then facing some edge, the GrowToFill would almost be unnecessary...
>
> Correcting:
>
> Thinking more, if the GrowToEdge* actions had this option to stop growing
> WHEN facing some edge, the GrowToFill would be unnecessary...
SO, that's what I was thinking too, but then I realized it's very useful to grow (at least opposite) edges together as an atomic action. One reason is terminal windows will grow to fill the space more accurately. And the other is you can choose to grow all edges again if all edges were previously blocked. So I think this has a usefulness separate from individual actions.
(In reply to comment #27)
> > Sure, want to add a "once" tag to the action, which defaults false, and send
> > me a pull request on github?
> >
> > Just occured to me, we need to add this thing to rc.xsd also.
>
> Will try to do it... I'm not what you can call a "great developer"... :)
Cool! You can use another action with a bool parameter to see example code for reading a bool, such as https://github.com/danakj/openbox/blob/master/openbox/actions/cyclewindows.c#L85
(In reply to comment #29)
> (In reply to comment #27)
> > > Sure, want to add a "once" tag to the action, which defaults false, and send
> > > me a pull request on github?
> > >
> > > Just occured to me, we need to add this thing to rc.xsd also.
> >
> > Will try to do it... I'm not what you can call a "great developer"... :)
>
> Cool! You can use another action with a bool parameter to see example code
> for reading a bool, such as
> https://github.com/danakj/openbox/blob/master/openbox/actions/cyclewindows.
> c#L85
Thanks... I was already doing the wrong way...
Nice to see activity there! I have not been using Openbox lately (shame on me!) but I miss it. I think I will reinstall it and try this all soon. :-) Sorry for the off-topic.
(In reply to comment #24)
> (In reply to comment #23)
> > Thanks (In reply to comment #22)
> > > Ok thanks. When you figure it out, if there's anything you need to change in
> > > Openbox to make it work please file a bug.
> > >
> > > I've using the latest ubuntu without any funny hacks and compiling okay,
> > > FWIW. If the problem is due to librsvg, you can use --disable-librsvg. Some
> > > users (slackware) have reported this. But I have no idea what I should be
> > > doing to make it compile correctly there with librsvg yet.
> >
> > Got it working here just by reading readme.git...
> >
> > Done some tests here... it's working ok, except the new "keep growing"
> > behaviour... just do not make sense to me the need to keep growing when all
> > empty space are ocuppied... can this behaviour be optional?
>
> Sure, want to add a "once" tag to the action, which defaults false, and send
> me a pull request on github?
>
> Just occured to me, we need to add this thing to rc.xsd also.
After hours changing options in the wrong place, finally is done...
Made the pull request: https://github.com/danakj/openbox/pull/7
Please feel free to fix any mistake I could possible done.
I have done some tests and I think it is working ok for both GrowToEdges and GrowToFill actions...
(In reply to comment #28)
> > > Thinking more, if the GrowToEdge* actions had this option to stop growing
> > > then facing some edge, the GrowToFill would almost be unnecessary...
> >
> > Correcting:
> >
> > Thinking more, if the GrowToEdge* actions had this option to stop growing
> > WHEN facing some edge, the GrowToFill would be unnecessary...
>
> SO, that's what I was thinking too, but then I realized it's very useful to
> grow (at least opposite) edges together as an atomic action. One reason is
> terminal windows will grow to fill the space more accurately. And the other
> is you can choose to grow all edges again if all edges were previously
> blocked. So I think this has a usefulness separate from individual actions.
The atomic behaviour solves the terminal problem, but cause other worst: window overlaping. Supposing you have two small windows: one at top left of the display, and one at bottom right. If his positions dont allow them to see each other edges, they can will grow how much they want in any direction, overlaping the other window...
If we do non-atomic Growing, we get back with problems growing terminal windows...
The solution would be to replace GrowTo by MoveTo when growing to up or to left... this solves the terminal problem, solves the window overlaping, but has a problem: if the window is already touching the right or bottom edge of the display, then the GrowTo actions will actually shrink the window... so, we need also a new option to block shrink when doing GrowTo...
(In reply to comment #33)
> (In reply to comment #28)
> > > > Thinking more, if the GrowToEdge* actions had this option to stop growing
> > > > then facing some edge, the GrowToFill would almost be unnecessary...
> > >
> > > Correcting:
> > >
> > > Thinking more, if the GrowToEdge* actions had this option to stop growing
> > > WHEN facing some edge, the GrowToFill would be unnecessary...
> >
> > SO, that's what I was thinking too, but then I realized it's very useful to
> > grow (at least opposite) edges together as an atomic action. One reason is
> > terminal windows will grow to fill the space more accurately. And the other
> > is you can choose to grow all edges again if all edges were previously
> > blocked. So I think this has a usefulness separate from individual actions.
>
> The atomic behaviour solves the terminal problem, but cause other worst:
> window overlaping. Supposing you have two small windows: one at top left of
> the display, and one at bottom right. If his positions dont allow them to
> see each other edges, they can will grow how much they want in any
> direction, overlaping the other window...
>
> If we do non-atomic Growing, we get back with problems growing terminal
> windows...
>
> The solution would be to replace GrowTo by MoveTo when growing to up or to
> left... this solves the terminal problem, solves the window overlaping, but
> has a problem: if the window is already touching the right or bottom edge of
> the display, then the GrowTo actions will actually shrink the window... so,
> we need also a new option to block shrink when doing GrowTo...
<!--
This is an use-case to do "non-atomic" GrowToFill, by
only using MoveToEdge* and GrowToEdge* actions.
I'm proposing two new actions: "confined" (now called "once")
and "strict" (proposed bellow).
The option "confined" would not allow MoveTo* and GrowTo*
actions to jump past their current block points.
The new "strict" action would force GrowTo* actions
to behaviour strict to what their name means: grow.
So, this option would prevent GrowTo from shrinking.
This name could be valid to other actions who have
special behaviours.
-->
<keybind key="W-space">
<action name="MoveToEdge">
<direction>north</direction>
<confined>yes</confined> <!-- prevents bypassing edges -->
</action>
<action name="GrowToEdge">
<direction>south</direction>
<confined>yes</confined> <!-- prevents bypassing edges -->
<strict>yes</strict> <!-- prevents shrinking -->
</action>
<action name="MoveToEdge">
<direction>west</direction>
<confined>yes</confined> <!-- prevents bypassing edges -->
</action>
<action name="GrowToEdge">
<direction>east</direction>
<confined>yes</confined> <!-- prevents bypassing edges -->
<strict>yes</strict> <!-- prevents shrinking -->
</action>
</keybind>
(In reply to comment #34)
> (In reply to comment #33)
> > (In reply to comment #28)
> > > > > Thinking more, if the GrowToEdge* actions had this option to stop growing
> > > > > then facing some edge, the GrowToFill would almost be unnecessary...
> > > >
> > > > Correcting:
> > > >
> > > > Thinking more, if the GrowToEdge* actions had this option to stop growing
> > > > WHEN facing some edge, the GrowToFill would be unnecessary...
> > >
> > > SO, that's what I was thinking too, but then I realized it's very useful to
> > > grow (at least opposite) edges together as an atomic action. One reason is
> > > terminal windows will grow to fill the space more accurately. And the other
> > > is you can choose to grow all edges again if all edges were previously
> > > blocked. So I think this has a usefulness separate from individual actions.
> >
> > The atomic behaviour solves the terminal problem, but cause other worst:
> > window overlaping. Supposing you have two small windows: one at top left of
> > the display, and one at bottom right. If his positions dont allow them to
> > see each other edges, they can will grow how much they want in any
> > direction, overlaping the other window...
> >
> > If we do non-atomic Growing, we get back with problems growing terminal
> > windows...
> >
> > The solution would be to replace GrowTo by MoveTo when growing to up or to
> > left... this solves the terminal problem, solves the window overlaping, but
> > has a problem: if the window is already touching the right or bottom edge of
> > the display, then the GrowTo actions will actually shrink the window... so,
> > we need also a new option to block shrink when doing GrowTo...
>
> <!--
> This is an use-case to do "non-atomic" GrowToFill, by
> only using MoveToEdge* and GrowToEdge* actions.
>
> I'm proposing two new actions: "confined" (now called "once")
> and "strict" (proposed bellow).
>
> The option "confined" would not allow MoveTo* and GrowTo*
> actions to jump past their current block points.
>
> The new "strict" action would force GrowTo* actions
> to behaviour strict to what their name means: grow.
> So, this option would prevent GrowTo from shrinking.
> This name could be valid to other actions who have
> special behaviours.
>
> -->
> <keybind key="W-space">
>
> <action name="MoveToEdge">
> <direction>north</direction>
> <confined>yes</confined> <!-- prevents bypassing edges -->
> </action>
>
> <action name="GrowToEdge">
> <direction>south</direction>
> <confined>yes</confined> <!-- prevents bypassing edges -->
> <strict>yes</strict> <!-- prevents shrinking -->
> </action>
>
> <action name="MoveToEdge">
> <direction>west</direction>
> <confined>yes</confined> <!-- prevents bypassing edges -->
> </action>
>
> <action name="GrowToEdge">
> <direction>east</direction>
> <confined>yes</confined> <!-- prevents bypassing edges -->
> <strict>yes</strict> <!-- prevents shrinking -->
> </action>
>
> </keybind>
in "two new actions", please read "two new options".
(In reply to comment #35)
> (In reply to comment #34)
> > (In reply to comment #33)
> > > (In reply to comment #28)
> > > > > > Thinking more, if the GrowToEdge* actions had this option to stop growing
> > > > > > then facing some edge, the GrowToFill would almost be unnecessary...
> > > > >
> > > > > Correcting:
> > > > >
> > > > > Thinking more, if the GrowToEdge* actions had this option to stop growing
> > > > > WHEN facing some edge, the GrowToFill would be unnecessary...
> > > >
> > > > SO, that's what I was thinking too, but then I realized it's very useful to
> > > > grow (at least opposite) edges together as an atomic action. One reason is
> > > > terminal windows will grow to fill the space more accurately. And the other
> > > > is you can choose to grow all edges again if all edges were previously
> > > > blocked. So I think this has a usefulness separate from individual actions.
> > >
> > > The atomic behaviour solves the terminal problem, but cause other worst:
> > > window overlaping. Supposing you have two small windows: one at top left of
> > > the display, and one at bottom right. If his positions dont allow them to
> > > see each other edges, they can will grow how much they want in any
> > > direction, overlaping the other window...
> > >
> > > If we do non-atomic Growing, we get back with problems growing terminal
> > > windows...
> > >
> > > The solution would be to replace GrowTo by MoveTo when growing to up or to
> > > left... this solves the terminal problem, solves the window overlaping, but
> > > has a problem: if the window is already touching the right or bottom edge of
> > > the display, then the GrowTo actions will actually shrink the window... so,
> > > we need also a new option to block shrink when doing GrowTo...
> >
> > <!--
> > This is an use-case to do "non-atomic" GrowToFill, by
> > only using MoveToEdge* and GrowToEdge* actions.
> >
> > I'm proposing two new actions: "confined" (now called "once")
> > and "strict" (proposed bellow).
> >
> > The option "confined" would not allow MoveTo* and GrowTo*
> > actions to jump past their current block points.
> >
> > The new "strict" action would force GrowTo* actions
> > to behaviour strict to what their name means: grow.
> > So, this option would prevent GrowTo from shrinking.
> > This name could be valid to other actions who have
> > special behaviours.
> >
> > -->
> > <keybind key="W-space">
> >
> > <action name="MoveToEdge">
> > <direction>north</direction>
> > <confined>yes</confined> <!-- prevents bypassing edges -->
> > </action>
> >
> > <action name="GrowToEdge">
> > <direction>south</direction>
> > <confined>yes</confined> <!-- prevents bypassing edges -->
> > <strict>yes</strict> <!-- prevents shrinking -->
> > </action>
> >
> > <action name="MoveToEdge">
> > <direction>west</direction>
> > <confined>yes</confined> <!-- prevents bypassing edges -->
> > </action>
> >
> > <action name="GrowToEdge">
> > <direction>east</direction>
> > <confined>yes</confined> <!-- prevents bypassing edges -->
> > <strict>yes</strict> <!-- prevents shrinking -->
> > </action>
> >
> > </keybind>
>
> in "two new actions", please read "two new options".
(In reply to comment #34)
> (In reply to comment #33)
> > (In reply to comment #28)
> > > > > Thinking more, if the GrowToEdge* actions had this option to stop growing
> > > > > then facing some edge, the GrowToFill would almost be unnecessary...
> > > >
> > > > Correcting:
> > > >
> > > > Thinking more, if the GrowToEdge* actions had this option to stop growing
> > > > WHEN facing some edge, the GrowToFill would be unnecessary...
> > >
> > > SO, that's what I was thinking too, but then I realized it's very useful to
> > > grow (at least opposite) edges together as an atomic action. One reason is
> > > terminal windows will grow to fill the space more accurately. And the other
> > > is you can choose to grow all edges again if all edges were previously
> > > blocked. So I think this has a usefulness separate from individual actions.
> >
> > The atomic behaviour solves the terminal problem, but cause other worst:
> > window overlaping. Supposing you have two small windows: one at top left of
> > the display, and one at bottom right. If his positions dont allow them to
> > see each other edges, they can will grow how much they want in any
> > direction, overlaping the other window...
> >
> > If we do non-atomic Growing, we get back with problems growing terminal
> > windows...
> >
> > The solution would be to replace GrowTo by MoveTo when growing to up or to
> > left... this solves the terminal problem, solves the window overlaping, but
> > has a problem: if the window is already touching the right or bottom edge of
> > the display, then the GrowTo actions will actually shrink the window... so,
> > we need also a new option to block shrink when doing GrowTo...
>
> <!--
> This is an use-case to do "non-atomic" GrowToFill, by
> only using MoveToEdge* and GrowToEdge* actions.
>
> I'm proposing two new actions: "confined" (now called "once")
> and "strict" (proposed bellow).
>
> The option "confined" would not allow MoveTo* and GrowTo*
> actions to jump past their current block points.
>
> The new "strict" action would force GrowTo* actions
> to behaviour strict to what their name means: grow.
> So, this option would prevent GrowTo from shrinking.
> This name could be valid to other actions who have
> special behaviours.
>
> -->
> <keybind key="W-space">
>
> <action name="MoveToEdge">
> <direction>north</direction>
> <confined>yes</confined> <!-- prevents bypassing edges -->
> </action>
>
> <action name="GrowToEdge">
> <direction>south</direction>
> <confined>yes</confined> <!-- prevents bypassing edges -->
> <strict>yes</strict> <!-- prevents shrinking -->
> </action>
>
> <action name="MoveToEdge">
> <direction>west</direction>
> <confined>yes</confined> <!-- prevents bypassing edges -->
> </action>
>
> <action name="GrowToEdge">
> <direction>east</direction>
> <confined>yes</confined> <!-- prevents bypassing edges -->
> <strict>yes</strict> <!-- prevents shrinking -->
> </action>
>
> </keybind>
Hi Dana,
I tried to create a pull request in github but some obscure reason prevents github from completing it.
Here the modifications:
https://github.com/deters/openbox-1/compare/danakj:work...growtofill_option
I'm proposing this 2 new actions on GrowTo* actions:
1) "once": will restrict growing-up to the nearest blocking edges.
2) "strict": forces GrowTo* actions to do strictly what they name says it does: grow. So, this option will prevent GrowTo from shrinking.
The name "strict" is just a suggestion, I tryed to think in a generic name who could be applied to any other methods who have "controversal" behaviours.
I think we need to add the "once" option on MoveToEdge action too, but this would require changing "client.c" again... What do you think?
Thanks.
Hi, Dana.
Just finished implementing the "once" option to work on MoveToEdge too:
https://github.com/deters/openbox-1/compare/danakj:work...growtofill_option
This 2 new options together allows the GrowTo* and MoveToEdge* actions to be used in more complex actions, like implementing customized GrowToFill... as a sample, follow my current configuration to do this:
<keybind key="W-s">
<action name="MoveToEdge">
<direction>north</direction>
<once>yes</once> <!-- prevents bypassing edges -->
</action>
<action name="GrowToEdge">
<direction>south</direction>
<once>yes</once> <!-- prevents bypassing edges -->
<strict>yes</strict> <!-- prevents shrinking -->
</action>
<action name="MoveToEdge">
<direction>west</direction>
<once>yes</once> <!-- prevents bypassing edges -->
</action>
<action name="GrowToEdge">
<direction>east</direction>
<once>yes</once> <!-- prevents bypassing edges -->
<strict>yes</strict> <!-- prevents shrinking -->
</action>
</keybind>
Created attachment 2379 [details] Created a "GrowToFill" action Proposed a "GrowToFill" action that try to fit the current window to the maximum available area in all directions.Created attachment 2380 [details] Patch reformated according the unified diff format Proposed a "GrotToFill" action.> > Thinking more, if the GrowToEdge* actions had this option to stop growing > > then facing some edge, the GrowToFill would almost be unnecessary... > > Correcting: > > Thinking more, if the GrowToEdge* actions had this option to stop growing > WHEN facing some edge, the GrowToFill would be unnecessary... SO, that's what I was thinking too, but then I realized it's very useful to grow (at least opposite) edges together as an atomic action. One reason is terminal windows will grow to fill the space more accurately. And the other is you can choose to grow all edges again if all edges were previously blocked. So I think this has a usefulness separate from individual actions.