User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.6) Gecko/20060804 Firefox/1.5.0.6 Build Identifier: It would be nice to have a shortcut that could make a window fill the rest of the window without overlapping any other windows... You could even expand this to the point that you can also stretch horizontally and vertically untill you meet another window... At first sight it doesn't look very usefull but take these two examples: 1. you're listening to music with xfmedia, you're chatting a bit with whomever in gaim (both windows fit under neath each other and you want to program a bit in the meanwhile... Instead of manually grabbing the window border of your gvim session you can just push that shortcut so the whole gvim window get's maximized in the available screen space (so without overlapping gaim or your music) 2. You are working with The Gimp... you have tons of windows... and everything is laying around but and your image window is somewhere there in the middle... Instead of just having to stretch that window to the furthest possible border of your other gimp windows, you can just push the shortcut... simple clean and easy way of maximizing your working place (the image) without having to move everthing around an around :) just a suggested thing of course :) no priority just tell me what you think of it Olivier :) Reproducible: Always
Well, it makes sense. Not necessarily trivial to implement properly though. Patch welcome ;)
Using XFCE 4.2.3.2, "upper workspace" and "bottom workspace" don't seem to do anything, they are for "vertical scrolling/switching of workspaces? I've never known something like that exists in XFCE, and i can switch workspaces or drag apps to neighbouring workspaces only horizontally. left/right workspace shortcuts work, and i don't loose those settings upon restart..
(In reply to comment #2) > Using XFCE 4.2.3.2, "upper workspace" and "bottom workspace" don't seem to do > anything, they are for "vertical scrolling/switching of workspaces? I've never > known something like that exists in XFCE, and i can switch workspaces or drag > apps to neighbouring workspaces only horizontally. > > left/right workspace shortcuts work, and i don't loose those settings upon > restart.. This is unrelated to the current bug. It's not a bug, it works and depends on the pager layout (ie 4x1, 2x2 or 1x4, etc.)
whoops, sorry, i just see that my comment got submitted to this bug, too... it wasn't meant for this bug, i guess i didnt pay enough attention while submitting... :(
seems like both pekwm and e17 have this option... it's called "filling"
This is a duplicate of Bug #858.
I'll take a look at this if it is alright with you guys.
Created attachment 1189 This patch should add the feature to xfwm4 Should be fixed this way :-)
(In reply to comment #8) > This patch should add the feature to xfwm4 > Should be fixed this way :-) Interesting, but... Can you make sure it follows the coding guidelines (no hardware tab, 4 spaces per tab, opening/closing brackets even if there is only one statement in the if, a space after functions names and if, etc)? Also, it doesn't maximize quite well, window frames seems to be overlapping, can you check that too? TIA
(In reply to comment #9) > (In reply to comment #8) > > This patch should add the feature to xfwm4 > > Should be fixed this way :-) > > Interesting, but... Can you make sure it follows the coding guidelines (no > hardware tab, 4 spaces per tab, opening/closing brackets even if there is only > one statement in the if, a space after functions names and if, etc)? Oops, yeah. i will. > Also, it doesn't maximize quite well, window frames seems to be overlapping, > can you check that too? Sure, and perhaps adding its behaviour as an option for the title-bar double-click behaviour?
Created attachment 1191 Clean patch to add this feature to xfwm4. Ok, coding-style is fixed now. This patch adds the following features: - Toggle Horizontal and vertical filling, controlled by shortcuts. - Add an option to toggle filling by double-clicking the title-bar. I have added some comments to describe what it actually does ;-)
(In reply to comment #11) > Ok, coding-style is fixed now. Not really, it's still uses hard tabs. No matter, I removed them. > This patch adds the following features: > > - Toggle Horizontal and vertical filling, controlled by shortcuts. > - Add an option to toggle filling by double-clicking the title-bar. Filling cannot be a toggle. It expands the window as much as it can, that's it. Maximizing, fullscreen, shading, etc. are toggles, but not window's filling. Also it needed some fixes (Cannot fill in all cases, like maximized or fullscreen) and was not filtering hidden windows. Your patch was applied with these fixes as part of rev. 25836. However, it still needs quite a lot more work, like: 1) It is not compatible with Xinerama 2) It doesn't take struts into account 3) It doesn't use the frame() functions and access client fields directly, making the code hard to read
Features added, lot of cleanup and fixes committed in trunc. Please make sure you resync.
(In reply to comment #12) > (In reply to comment #11) > > Ok, coding-style is fixed now. > > Not really, it's still uses hard tabs. No matter, I removed them. Hehe, I was sure i did a sed -i 's/\t/ /g' on the files... > > > This patch adds the following features: > > > > - Toggle Horizontal and vertical filling, controlled by shortcuts. > > - Add an option to toggle filling by double-clicking the title-bar. > > Filling cannot be a toggle. It expands the window as much as it can, that's it. > Maximizing, fullscreen, shading, etc. are toggles, but not window's filling. Too bad, because it did feel more natural to me that way. Restoring the window back to it's original size. Making it something like an almost-maximized state. > > Also it needed some fixes (Cannot fill in all cases, like maximized or > fullscreen) and was not filtering hidden windows. > > Your patch was applied with these fixes as part of rev. 25836. > > However, it still needs quite a lot more work, like: > > 1) It is not compatible with Xinerama > 2) It doesn't take struts into account > 3) It doesn't use the frame() functions and access client fields directly, > making the code hard to read > I will look into that, sure it can't be an extra window-state?
(In reply to comment #14) > Too bad, because it did feel more natural to me that way. Restoring the window > back to it's original size. Making it something like an almost-maximized state. Yes, this is why I don't want this ;) > I will look into that, sure it can't be an extra window-state? No need, I took care of it...
Hi Olivier, I think the patch works well (at least here on my single screen WS, will try on a xinerama machine soon enough). Still i'd like to be able to toggle quickly back to the previous size of the screen. I believe this is what Stephan originally planned in the patch, and i can't really see why you wouldn't like that? gr,S. Stephan thnx again for this marvelous work :)
No, the patch was not working well, it required a lot of work...
(In reply to comment #17) > No, the patch was not working well, it required a lot of work... > Sorry about that. I will take a close look at how you fixed it. You mentioned issues i didn't even know they could exist... but that's why you are the window-manager guru :-).
A bit of explanation on why I would not consider the "fill" function as a state. The "fill" function is supposed to expand a window to the available space around. So it depends on what's around, it's obvious. Now, let's say you expand a window, then later hide one of the adjacent windows and call the fill function again. What would you expect? the window to fill the additional available space or the window to shrink to its original (probably forgotten) original size? As a user, I would expect the window to enlarge to the available size when I call the fill function, don't you? That's why "fill" is a function, not a state by itself. I guess this BZ can be closed now. Further developpemnts go to SVN trunk now.