New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implemented corner tiling #359

Closed
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@ozeidan
Contributor

ozeidan commented Dec 2, 2017

Hi,
this is my attempt at implementing the corner tiling feature requested in issues #218.
It works fairly well already when dragging the window with the mouse. I tried implementing the keyboard shortcuts for this but I didn't manage to understand how I can get the shortcuts to show up in gsettings. A little help on this would be appreciated.

@ozeidan ozeidan changed the title from Feature/corner tiling to Implemented corner tiling Dec 2, 2017

@ozeidan

This comment has been minimized.

Contributor

ozeidan commented Dec 6, 2017

So I managed to get the keybindings running. Here is a small preview:
corner-tiling
I will continue to look through the code once more because I am not sure if I am causing any side effects with this change.

@raveit65

raveit65 requested changes Dec 10, 2017 edited

I am using only keybindings for side-by-side-tiling normal.
With left/right tiling i can toogle back to previous window position.
This doesn't work with the new corner tiling.
Would be nice if all tilings have the same features.
Beside from that it works nice here.

@lukefromdc

This worked with mouse dragging after a bit of initial fiddling. It turned out that the window for dconf-editor 1.18 has some odd property to it causing the tiling preview to show but the windo itself not to resized to a corner tile. Half screen and full screen tiling worked. Brasero (SSD) and gedit (CSD) quarter-tiled fine, so that's not just all the GNOME apps. Cmake-gui and kdenlive (QT5 apps) also tiled without issue, though any resize of Kdenlive forces manual rearrangement of its internal elements afterwards.

I did not try any keybindings, I have never used them for this and don't really understand them in this context.

@ozeidan

This comment has been minimized.

Contributor

ozeidan commented Dec 11, 2017

@raveit65 I applied a quick fix for this, please try it out again.

Currently, when a window is tiled into a corner it is maximized_vertically, which intuitively doesn't make much sense, but technically it seems to be the intended behaviour. Is that fine to leave in?

@ozeidan

This comment has been minimized.

Contributor

ozeidan commented Dec 11, 2017

@lukefromdc I also noticed this behavior with Skype Preview, I'll try to fix this.

@lukefromdc

This comment has been minimized.

Member

lukefromdc commented Dec 11, 2017

I don't know what anyone else uses, but I have compiz setup to corner tile windows dragged to corners and ignore the top, bottom, left, and right edges entirely as far as tiling is concerned. It would seem to me that the only reason to use the corner as a target for dragging a window to tile it would be to tile the window quarter-screen from that corner.

@ozeidan

This comment has been minimized.

Contributor

ozeidan commented Dec 11, 2017

@lukefromdc what are you trying to say? Isn't how you describe it the exact current behaviour?

I am not able to 100% reproduce the bug with some windows not tiling to corners. Some hints to this would be appreciated.

@lukefromdc

This comment has been minimized.

Member

lukefromdc commented Dec 12, 2017

I normally do not use tiling with Marco at all because I move windows around a lot (and have jittery hands) and tiling any window on the edges acts in a way I find hard to control. The suggestion that windows should tile to halfscreen(maximized vertically) rather than quarterscreen on being dragged to a corner is what I was objecting to and could not understand being the intended behavior.

@raveit65

Thanks,
restoring windows to prevous position is working now if using keybindings.
Is it possible to allow vertical resizing for corner tiling?

@raveit65

This comment has been minimized.

Member

raveit65 commented Dec 13, 2017

I am pretty sure some users will point with the finger on it, if vertical resizing doesn't work.

The issue with dconf-editor i can't reproduce.
Here the preview and the tiling is working well, tested with f26 and dconf-editor-3.23.4-2.fc26.x86_64.
Same behaviour with other gnome apps like gnome-abrt, gnome-mpv, gitg.
The only issue i see with csd windows is that resizing a tiled window don't work.
But csd windows are using invisible borders for resizing and not a decorator edge,
This affects also our side-by-side-tiling, so this is a complete other story and not related to PR.
I recall we have already a report about and it's save to ignore it for the moment, imo.

I normally do not use tiling with Marco at all because I move windows around a lot (and have jittery hands) and tiling any window on the edges acts in a way I find hard to control.

For me only the top edge is problematic because of the resizing to max window size, which can be a unwanted result if you move a window, especially with small notebook monitors.
But that's another story too :-)

@lukefromdc

This comment has been minimized.

Member

lukefromdc commented Dec 13, 2017

I am using an old version of deconf-editor (3.18) because I prefer its UI

@ozeidan

This comment has been minimized.

Contributor

ozeidan commented Dec 18, 2017

Hi, so again I changed quite a few things. The resizing should work properly now. There might still be bugs, so please test as much as you can.

@vkareh

@ozeidan - CSD windows don't corner-tile for me with this change. FWIW, I use the gtk3-nocsd package.

Another thing is that this changes the behavior when trying to restore the size. Before this patch, if I tile to one side, then do an "unmaximize" (restore window), it used to go back to it's unmaximized size - with this patch, the window either remains tiled, or gets into a "maximumized" state (appears maximized, but it's not really). It's not consistent in how it does that - probably has to do with the saved_rect?

@vkareh

This comment has been minimized.

Member

vkareh commented Dec 19, 2017

Awesome - latest commit fixes the unmaximization issue for me - it works great!

I was wrong about the CSD windows - they tile just fine, except for dconf-editor, as @lukefromdc mentioned... not sure why that is, but everything else is behaving correctly.

Code looks good to me as well :)

@vkareh

vkareh approved these changes Dec 19, 2017

considering the only app with any issues for me is dconf-editor, I'd say the problem is dconf-editor itself. This PR looks fine for me.

@raveit65

horz and vert resizing works well now, and i see no other issues.

@ozeidan

This comment has been minimized.

Contributor

ozeidan commented Dec 19, 2017

I checked the issue with dconf-editor. It seems like the culprit is that the height of the size_hints of the dconf window is smaller than the height we want to resize it to when corner tiling. If I understand it correctly, those come from the application?

@raveit65

This comment has been minimized.

Member

raveit65 commented Dec 19, 2017

@ozeidan
Are you familiar with the 'git rebase command?
It looks like some commits can be squashed together.

git rebase -i <last-good-commit>

-i means interactive and it opens an editor (vi), you will see how it works.
I think you know it better than me how much commits you need.

Btw. i don't have the issue here with dconf-editor-3.23.4-2.fc26.x86_64
So, i am thinking it's a problem with d-e-3.25

@raveit65

This comment has been minimized.

Member

raveit65 commented Dec 19, 2017

@lukefromdc
Do you like to test more?

@ozeidan

This comment has been minimized.

Contributor

ozeidan commented Dec 19, 2017

@raveit65 So if my assumption is true, tiling dconf-editor (or other programs) may work on some screens but not on others. On bigger screens, the height of a 'corner' might be bigger than the minimum height that dconf-editor supplies.

I renamed and squashed some commits on my local branch. Can I just force push them?

@raveit65

This comment has been minimized.

Member

raveit65 commented Dec 19, 2017

@ozeidan
yeah, i forgot to say. git push -f will update yor repo and the PR automatic

@raveit65

This comment has been minimized.

Member

raveit65 commented Dec 19, 2017

@ozeidan
You're right with dconf-editor. I works well on my my main box with a 27“ monitor, but not with the same rpm on my notebook with a (17,3“) Widescreen Display.

@raveit65

This comment has been minimized.

Member

raveit65 commented Dec 20, 2017

merged
b471b91
8828bd7
01f68e8
6219f8e
d8ef314
Thanks a lot for this feature.

@raveit65 raveit65 closed this Dec 20, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment