Window Management, Keyboard shortcut - The grid keybindings are behaving inconsistently

Reported by Carlos Andrés Rocha on 2011-10-20
386
This bug affects 87 people
Affects Status Importance Assigned to Milestone
Ayatana Design
High
John Lea
Compiz
High
MC Return
Compiz Grid Plugin
High
Unassigned
Compiz Main Plugins
High
Unassigned
compiz (Ubuntu)
High
Unassigned
compiz-plugins-main (Ubuntu)
High
Unassigned

Bug Description

When placing windows on left or right (ctrl+alt+4, ctrl+alt+6), the windows do not cycle through different sizes, occupying only half of the screen. The rest of placing locations works perfectly.

The problem was initially reported in bug #862260, and supposedly fixed. I am using compiz-plugins-main and compiz-plugins-main-default version 1:0.9.6-0ubuntu4, and the problem persists.

------------------------------------------------------------

At the moment we are in a halfway house with some of the absolute positioning shortcuts working and some of the variable positioning shortcuts working, and we need to take a decision as to which path to follow. The absolute positioning shortcuts have the benefit of greater simplicity and less scope for confusion so this is the path I propose we should follow. When using absolute positioning users to not need to be aware of the current window state before pressing the key combo, which makes the operation quicker and less prone to unwanted results.

Desired Resolution - the default behaviour should be:

Ctrl-Alt-Numpad 7 - Place window in top left corner of screen. Pressing a second time does nothing.

Ctrl-Alt-Numpad 8 - Place window in top half of screen. Pressing a second time does nothing.

Ctrl-Alt-Numpad 9 - Place window in top right corner of screen. Pressing a second time does nothing.

Ctrl-Alt-Numpad 4 - Place window on the left side of the screen in *semi-maximised* state (it is important that the window is actually semi-maximised, not just the same size and position as a semi-maximised window) Pressing a second time does nothing.

Ctrl-Alt-Numpad 5 - Maximize window. If window is already Maximised, pressing this key combo restores the window to the exact same size, shape and position it was before it was Maximised.

Ctrl-Alt-Numpad 6 - Place window on the right side of the screen (it is important that the window is actually semi-maximised, not just the same size and position as a semi-maximised window). Pressing a second time does nothing.

Ctrl-Alt-Numpad 1 - Place window in the bottom left corner of the screen. Pressing a second time does nothing.

Ctrl-Alt-Numpad 2 - Place window in the bottom half of the screen. Pressing a second time does nothing.

Ctrl-Alt-Numpad 3 - Place window in the bottom right corner of the screen. Pressing a second time does nothing.

Ctrl-Alt-Numpad 0 - Minimise window.

Note: in order for this bug to be fixed, Compiz needs to be amended to support multiple key bindings

Edward Faulkner (ef) wrote :

I'm seeing the same problem as Carlos, but in addition the top-right position doesn't work at all. Instead it behaves just like center-top. So my Ctr-Alt-KP8 and Ctr-Alt-KP9 buttons do the exact same thing.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in compiz-plugins-main (Ubuntu):
status: New → Confirmed
Karim Moussa (karim-moussa) wrote :

I've found out that reverting the package "compiz-plugins-main-default" version 0.9.6-0ubuntu4 to version 0.9.6-0ubuntu2 solves this problem, as well as the incorrect Ctrl-Alt-KP_9 behaviour.

Changed in compiz-plugins-main (Ubuntu):
importance: Undecided → High
assignee: nobody → Sam Spilsbury (smspillaz)
description: updated
Sebastien Bacher (seb128) wrote :

Settings to High, it's a SRU regression

Changed in compiz-plugins-main (Ubuntu Oneiric):
importance: Undecided → High
assignee: nobody → Sam Spilsbury (smspillaz)
description: updated
description: updated
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in compiz-plugins-main (Ubuntu Oneiric):
status: New → Confirmed

In addition, if you push Ctr-Alt-KP9 to adjust a windows to the top right corner and after you change to another viewport using "expo pluguin" then the windows previously adjusted is showed in the 'new' viewport. In fact, the window is showed there but it is not there, since you canot access to it. The only way to access to it is changing again with the "expo plugin" to the original viewport.

The same happens with Ctr-Alt-KP7, Ctr-Alt-KP1 and Ctr-Alt-KP3.

Changed in compiz-grid-plugin:
status: New → Incomplete
status: Incomplete → New
Laurent Vaills (laurent-vaills) wrote :

I installed the ppa https://launchpad.net/~lbrulet-8/+archive/ppa as described on bug #876591 but this does not solve the issue reported on the bug about the missing cycling feature on Ctr-Alt-KP4 and Ctr-Alt-KP6 .

Is there a way to unmark this bug as a duplicate? Bug bug #876591 is related, but not exactly the same bug described here. As described above, the patch posted there does not fix the issue.

Sebastien Bacher (seb128) wrote :

Sam mentioned that the behaviour there is not a bug, the side placements are not supposed to split in half every time there are used, that requires design input on the wanted behaviour

Changed in compiz-plugins-main (Ubuntu):
assignee: Sam Spilsbury (smspillaz) → nobody
Changed in compiz-plugins-main (Ubuntu Oneiric):
assignee: Sam Spilsbury (smspillaz) → nobody
Changed in compiz-plugins-main (Ubuntu):
status: Confirmed → Incomplete
Changed in compiz-plugins-main (Ubuntu Oneiric):
status: Confirmed → Incomplete

Oh, bumb, I loved that behavior. It was how the Grid plugin has always worked. It is specially useful with widescreen monitors. I normally use 1/3 of the screen for a terminal and the other 2/3 for a browser, ide, etc.

I guess what remains is to make the other movements consistent. Move Top/Bottom-Left/Right do split in half every time they are used.

I thought it was a bug since the behavior I described was available previous to the lasted update.

Thanks.

Mal (mal-gamble) wrote :

I find it hard to accept that the lack of cycling behavior for the left and right window placements could be a "feature". It worked in natty and still seems to work in oneiric for the top, bottom and corner placements.

I think this bug remains valid. I don't see why it should require design input.

Mal

Agreed, it's very convenient to be able to split the screen in, saiy, one third for one window and two thirds for another, or 1/4 and 3/4, etc.

Omer Akram (om26er) wrote :

Would be nice to see design team involved in this bug though I believe this behavior would take a few hours of careful thinking.

Jacob Buys (wjbuys) wrote :

Does anyone have a workaround for this? Is there perhaps a different version of the grid plugin we can install? This feature is *extremely* useful for widescreen monitors.

John Lea (johnlea) on 2011-11-23
description: updated
tags: added: udp
Changed in ayatana-design:
assignee: nobody → John Lea (johnlea)
importance: Undecided → High
status: New → Triaged
Changed in compiz-plugins-main (Ubuntu):
status: Incomplete → Confirmed
Changed in compiz-plugins-main (Ubuntu Oneiric):
status: Incomplete → Confirmed
John Lea (johnlea) on 2011-11-23
description: updated
Sebastien Bacher (seb128) wrote :

Thanks John.

We know that some users liked the old way better but we are aiming for consistency and to avoid confusion there.

It doesn't prevent us to work on solving the "it should be easy to make dialogs take 25% of the screen" scenario in a way which doesn't abuse the grid placement combos (could be to use another modifier than ctrl-alt for example for those), could somebody open a new bug to request that features to be included in some way?

summary: - Grid plugin behaviour is incorrect since last update. Resizing left or
- right only changes the size of the window to half-screen.
+ The grid keybindings are behaving inconsistently

In my opinion the best solutions is giving to both sides. For ease of usability, by *default* the behavior of the grid plugin should use only half of the screen. However, this can reverted to the old behavior (1/2, 1/3, 1/4) using the grid plugin configuration panel via ccsm. New users get a less confusing experience, and more experience users can still setup their systems for maximum productivity.

psypher (psypher246) wrote :

AGREED! Please!

Thanks

John Lea (johnlea) on 2011-11-25
description: updated
John Lea (johnlea) on 2011-12-12
summary: - The grid keybindings are behaving inconsistently
+ Keyboard shotcut - The grid keybindings are behaving inconsistently
John Lea (johnlea) on 2011-12-12
tags: added: keybinding
John Lea (johnlea) on 2011-12-16
summary: - Keyboard shotcut - The grid keybindings are behaving inconsistently
+ Keyboard shortcut - The grid keybindings are behaving inconsistently

I fully agree with #16, I think the old behavior makes the grid plugin *very* useful when arranging several windows on the same workspace. Just making everything occupy half the screen isn't as useful. I like to get the "Ubuntu really is much more useful than Windows 7" feeling.

For example, maybe I want Firefox to occupy 75% of the screen (so I can use the Treestyle tab addon to put my tabs on the left side of the window and still see the web page I'm on), and then keep a text editor on the left side. With the old behavior, this just required a couple of ctrl+alt+6 and ctrl+alt+4 to get it *just right*, whereas with the new behavior I have to drag stuff around with the mouse and probably won't get it *just right*. I like the old behavior. Why not have an option to activate it in CCSM? Both easy for newcomers, and easy to activate for people that want it.

Jose Luis Tirado (txelu70) wrote :

One vote more for #16. I really think the old behaviour should be available by some way.

Karl Brand (brandk) wrote :

I was a new user to unity/compiz when i upgraded to 11.04 (from my very first linux experience on 10.10). And it was this feature that i found so compelling to stick with Ubuntu - it's now installed on four machines which had MS OSs previously. There's nothing confusing about it - its just great for gui productivity. No reason to dumb-down it's functionality by default. Until the feature is 're-introduced' are there any work arounds worth trying for those like i who struggle without it? Cheers all -K

John Lea (johnlea) on 2012-01-11
description: updated
psypher (psypher246) wrote :

I still vote we have multiple window sizes available when repeat pressing the same number key as it does everybody else as well. Please please keep this feature.

Tim Penhey (thumper) on 2012-02-03
Changed in ayatana-design:
status: Triaged → Fix Committed
TomasHnyk (sup) wrote :

Is there going to be a way to restore old behaviour (i.e. more windows sizes available)? Grid plugin would be much more useful to me then.

no longer affects: compiz-grid-plugin
John Lea (johnlea) on 2012-02-09
Changed in compiz-plugins-main:
status: New → Confirmed
summary: - Keyboard shortcut - The grid keybindings are behaving inconsistently
+ Window Management, Keyboard shortcut - The grid keybindings are behaving
+ inconsistently
tshirtman (gabriel-pettier) wrote :

I don't get either why the cycling works for ctrl-alt-5, but not for ctrl-alt-4 and ctrl-alt-6, which are much more useful.

Any plan to restore the behaviour by precise release? it's still like this in precise beta.

psypher (psypher246) wrote :

Agreed, also don't get why? Please restore, and PLEASE PLEASE do NOT take away the ability to do so with 1,2,3,5,7,8 & 9. I can't stress enough how usefull this is!! I use it everyday all day.

Gary (gary-mcelroy) wrote :

I'm chiming in too as someone who extremely highly values the original behavior (repeated presses resize the window repeatedly for all numpad keys).

I'm a software engineer who switched over to Ubuntu on 11.04. My work process immediately became more productive due to the combination of the workspace/desktop switcher, the spinning wheel type alt-tab window switcher and this grid plug-in.

I saved immense amounts of time placing each little debug/project/etc. window from Eclipse in a different position on each of my two widescreen monitors because of this plug-in.

To be candid, this is the deal breaker for me regarding sticking with Ubuntu. If I can't get this functionality, Ubuntu as a solution doesn't compete well with my alternatives.

Hell, I contemplated quitting my job to contribute to Compiz development. I don't know how I'd make that work financially. Oops, off-topic.

Matt B (matthew-berginski) wrote :

I agree with comment #16, I'd like to see the old behavior an option.

John Lea (johnlea) on 2012-02-22
description: updated
Didier Roche (didrocks) wrote :

Ok, new keybindings done as per design request. However, note that multiple press on “place window” is currently continuing to resize the window, this need to be fixed in compiz in a separate bug, preferably, I guess.

Changed in compiz (Ubuntu Oneiric):
status: New → Won't Fix
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in compiz (Ubuntu):
status: New → Confirmed
Didier Roche (didrocks) on 2012-02-22
Changed in compiz-plugins-main:
status: Confirmed → Invalid
Changed in compiz (Ubuntu):
assignee: nobody → Didier Roche (didrocks)
Changed in compiz-plugins-main (Ubuntu):
assignee: nobody → Didier Roche (didrocks)
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package compiz - 1:0.9.7.0~bzr2995-0ubuntu5

---------------
compiz (1:0.9.7.0~bzr2995-0ubuntu5) precise; urgency=low

  * Change some keybindings as per design (LP: #878820, #891757, #751050)
    debian/patches/ubuntu-config.patch:
    - Show desktop is now Super + d
    - Super + Up maximize the window
    - Super + Down restore the window
    - Super + W initiate scale for all windows on current ws
    - Control + Alt + NumPad 5 is used to switch/restore maximize state
    - Control + Alt + NumPad 0 is used to minimize current window
    - Ensure we don't have any conficting keys anymore (LP: #922354)
  * 01_ctrl_alt_*tea*.patch:
    - Merged into ubuntu-config.patch, no reason to keep it separated
  * debian/compiz-gnome.gconf-defaults, debian/rules, debian/unity.ini:
    - Set the new plugin order with the incoming unity change as the default
 -- Didier Roche <email address hidden> Wed, 22 Feb 2012 13:44:25 +0100

Changed in compiz (Ubuntu):
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package compiz-plugins-main - 1:0.9.7.0~bzr19-0ubuntu3

---------------
compiz-plugins-main (1:0.9.7.0~bzr19-0ubuntu3) precise; urgency=low

  * apply design changes for the keybindings (LP: #878820, #891757, #751050),
    debian/patches/ubuntu_config.patch:
    - Control + Alt + KP_5: don't center, used for toggling maximize state
      by core
    - Remove Control + Alt + KP_0 to not maximize, (used to minimize in core)
    - Super + Left, Right key to semi maximize and stack on left or right
    - Remove zoom in/out/box (like in oneiric and before). Those should be
      enabled in g-c-c with the a11y tools.
 -- Didier Roche <email address hidden> Wed, 22 Feb 2012 15:04:30 +0100

Changed in compiz-plugins-main (Ubuntu):
status: Confirmed → Fix Released
TomasHnyk (sup) wrote :

Is there going to be some way to enable second pressess to do something? If not, another useful feature gone away. Anyway, I do not undestand it - this is a keyboard shortcut, that is not something the ordinary user uses much, do they? (you are doing user testing - I wonder how many of the tested "ordinary users" use shortcuts).

psypher (psypher246) wrote :

After updating this feature is now completely broken. Pressing ctl-alt-4 or 6 does nothing. If you have an open terminal it actually types 4 and 6 on the screen.

I don't understand. Every single comment in this bug says they prefer the old way of being able to place the window anywhere on the screen and then being able to repeat press that key and cycle through several different sizes, including half screen.

These are the kinds of features that users and most importantly the power users love and it's features like this that compels me to use ubuntu and recommend to everyone else. I literally use it everyday repeatedly. It has become part of my workflow and it's one of the main features which makes me MORE productive on linux than on any other OS. None of them have this feature which gives Unity an edge. please don't alienate more power users!

This feature worked fine in the past and all of us have grown used to it and depend on it. Please figure it out and fix it.

But like I said, right now it does nothing. THANK GOODNESS ctrl-alt 1/2/3/5/7/8/9 still works.

Le ven. 24 févr. 2012 07:02:00 CET, psypher a écrit :
> After updating this feature is now completely broken. Pressing ctl-alt-4
> or 6 does nothing. If you have an open terminal it actually types 4 and
> 6 on the screen.
>
> I don't understand. Every single comment in this bug says they prefer
> the old way of being able to place the window anywhere on the screen and
> then being able to repeat press that key and cycle through several
> different sizes, including half screen.
>
> These are the kinds of features that users and most importantly the
> power users love and it's features like this that compels me to use
> ubuntu and recommend to everyone else. I literally use it everyday
> repeatedly. It has become part of my workflow and it's one of the main
> features which makes me MORE productive on linux than on any other OS.
> None of them have this feature which gives Unity an edge. please don't
> alienate more power users!
>
> This feature worked fine in the past and all of us have grown used to it
> and depend on it. Please figure it out and fix it.
>
> But like I said, right now it does nothing. THANK GOODNESS ctrl-alt
> 1/2/3/5/7/8/9 still works.
>

I started a discussion on unity-design mailing list (require joining
the unity-design launchpad team), but no answer yet.

There are keyboard changes on the way, you might be able to place
windows left/right with super+→ and super+← but it's still the broken
version, we need to raise this issue with design, or the same behaviour
for 1, 2, 3, 5, 7, 8, 9 *will* be broken for Precise+1

For anyone that finds this change as annoying as I do, I have compiled a version of grid from the upstream git sources in natty. I don't know how / have time to debify this but if anyone else wishes to please be my guest;

http://quicksilver.umbralservices.com/eric/fixed_grid_oneiric.tar.bz2

psypher (psypher246) wrote :

Has there been any progress with this issue. ctrl alt 4 and 6 still does nothing, only way to set an app to half screen is to drag it to the left or right.

tshirtman (gabriel-pettier) wrote :

Le ven. 16 mars 2012 10:06:52 CET, psypher a écrit :
> Has there been any progress with this issue. ctrl alt 4 and 6 still does
> nothing, only way to set an app to half screen is to drag it to the left
> or right.
>

the currently configured way to put a window half left or half right is
super+left or super+right, however you can change that in CCSM (i
changed back to ctrl-alt-4 ctrl-alt-6 until there is a coherent way to
manage all the stuff without numpad), look at the binding part of the
grid plugin.

still no cycling, howether, i think that's gone forever :/

tshirtman (gabriel-pettier) wrote :

the currently configured way to put a window half left or half right is super+left or super+right, however you can change that in CCSM (i changed back to ctrl-alt-4 ctrl-alt-6 until there is a coherent way to manage all the stuff without numpad), look at the binding part of the grid plugin.

still no cycling, howether, i think that's gone forever :(

psypher (psypher246) wrote :

Thanks I have fixed it.

HIGHLY disappointing that despite not ONE person here saying they are happy losing that functionality yet still an extremely useful feature which worked fine in the past is not working anymore.

I don't get the logic...

Greg A (etulfetulf) wrote :

If (as seems likely) this won't be fixed for 12.04, I think it is important that the keybindings used in 11.10 continue to work.

For example, whilst I support the addition of Super+Left and Super+Right for people without a numberpad, it is important that Ctrl+Alt+Numpad4 and Ctrl+Alt+Numpad6 continue to work.

It doesn't make sense to ask people to relearn keyboard shortcuts for the 12.04 release, especially if things are going to change again in a future release.

Karl Brand (brandk) wrote :
Download full text (4.0 KiB)

Hi Eric,

I'd really appreciate if you could explain what exactly to do with
"fixed_grid_oneiric.tar.bz2" or maybe point to similar resource as such.
For those like myself who dearly miss this functionality but lack the
expertise to implment your fix. I suspect we may need to do this all over
again come 12.04.

With thanks in advance,

Karl

On Sat, Feb 25, 2012 at 11:06, Eric Bennett <email address hidden> wrote:

> For anyone that finds this change as annoying as I do, I have compiled a
> version of grid from the upstream git sources in natty. I don't know how
> / have time to debify this but if anyone else wishes to please be my
> guest;
>
> http://quicksilver.umbralservices.com/eric/fixed_grid_oneiric.tar.bz2
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/878820
>
> Title:
> Window Management, Keyboard shortcut - The grid keybindings are
> behaving inconsistently
>
> Status in Ayatana Design:
> Fix Committed
> Status in Compiz Main Plugins:
> Invalid
> Status in “compiz” package in Ubuntu:
> Fix Released
> Status in “compiz-plugins-main” package in Ubuntu:
> Fix Released
> Status in “compiz” source package in Oneiric:
> Won't Fix
> Status in “compiz-plugins-main” source package in Oneiric:
> Confirmed
>
> Bug description:
> When placing windows on left or right (ctrl+alt+4, ctrl+alt+6), the
> windows do not cycle through different sizes, occupying only half of
> the screen. The rest of placing locations works perfectly.
>
> The problem was initially reported in bug #862260, and supposedly
> fixed. I am using compiz-plugins-main and compiz-plugins-main-default
> version 1:0.9.6-0ubuntu4, and the problem persists.
>
> ------------------------------------------------------------
>
> At the moment we are in a halfway house with some of the absolute
> positioning shortcuts working and some of the variable positioning
> shortcuts working, and we need to take a decision as to which path to
> follow. The absolute positioning shortcuts have the benefit of
> greater simplicity and less scope for confusion so this is the path I
> propose we should follow. When using absolute positioning users to
> not need to be aware of the current window state before pressing the
> key combo, which makes the operation quicker and less prone to
> unwanted results.
>
> Desired Resolution - the default behaviour should be:
>
> Ctrl-Alt-Numpad 7 - Place window in top left corner of screen.
> Pressing a second time does nothing.
>
> Ctrl-Alt-Numpad 8 - Place window in top half of screen. Pressing a
> second time does nothing.
>
> Ctrl-Alt-Numpad 9 - Place window in top right corner of screen.
> Pressing a second time does nothing.
>
> Ctrl-Alt-Numpad 4 - Place window on the left side of the screen in
> *semi-maximised* state (it is important that the window is actually
> semi-maximised, not just the same size and position as a semi-
> maximised window) Pressing a second time does nothing.
>
> Ctrl-Alt-Numpad 5 - Maximize window. If window is already Maximised,
> pressing this key combo restores the window to the exact same size,
> shape and positi...

Read more...

Hi Karl,

I should note in advance that at the end of the day, the fix posted up there ended up segfaulting my compiz after a few random updates to oneiric in mainline, I recompiled it a few times and eventually got so tired of it I just reverted back to natty after trying pangolin (it's not just broken there but *totally* broken, if I recall correctly the plugin completely fails to work) and finding it no better.

I also tried nuking the *entire* compiz distro and all supporting infrastructure and rebuilding from source, but this is not much of a better solution either, random segfaults aplenty still.

For those that wish to continue with this line of wrestling in oneiric or pangolin you will want to be checking http://wiki.compiz.org/Plugins/Grid , you can grab the source via git and recompile like so;

git clone http://cgit.compiz-fusion.org/compiz/plugins/grid/

cd grid
mkdir build
cd build
cmake ../
make
sudo make install

But please keep in mind the problems I've iterated above and consider if you really want to go through this yourself.

Best of luck.

tshirtman (gabriel-pettier) wrote :

Le lun. 19 mars 2012 23:34:55 CET, Eric Bennett a écrit :
> Hi Karl,
>
> I should note in advance that at the end of the day, the fix posted up
> there ended up segfaulting my compiz after a few random updates to
> oneiric in mainline, I recompiled it a few times and eventually got so
> tired of it I just reverted back to natty after trying pangolin (it's
> not just broken there but *totally* broken, if I recall correctly the
> plugin completely fails to work) and finding it no better.
>
> I also tried nuking the *entire* compiz distro and all supporting
> infrastructure and rebuilding from source, but this is not much of a
> better solution either, random segfaults aplenty still.
>
>
> For those that wish to continue with this line of wrestling in oneiric or pangolin you will want to be checking http://wiki.compiz.org/Plugins/Grid , you can grab the source via git and recompile like so;
>
> git clone http://cgit.compiz-fusion.org/compiz/plugins/grid/
>
> cd grid
> mkdir build
> cd build
> cmake ../
> make
> sudo make install
>
> But please keep in mind the problems I've iterated above and consider if
> you really want to go through this yourself.
>
> Best of luck.
>

I think it's probably easier to look at compiz-plugins-main history on
launchpad
(http://bazaar.launchpad.net/~compiz-team/compiz-plugins-main/0.9.7/changes
or one of the others, or maybe
http://bazaar.launchpad.net/~lbrulet-8/compiz-plugins-main/fix-876591/revision/21),
find the first offending commit, and revert it in the current package
source to rebuild the package.

note that i didn't say «easy» i said «easier». But anybody finding the
time to restore the cycling on left/right (whatever key si configured
to them) will have my gratitude.

tshirtman (gabriel-pettier) wrote :

Le lun. 19 mars 2012 23:57:00 CET, Gabriel Pettier a écrit :
> Le lun. 19 mars 2012 23:34:55 CET, Eric Bennett a écrit :
>> Hi Karl,
>>
>> I should note in advance that at the end of the day, the fix posted up
>> there ended up segfaulting my compiz after a few random updates to
>> oneiric in mainline, I recompiled it a few times and eventually got so
>> tired of it I just reverted back to natty after trying pangolin (it's
>> not just broken there but *totally* broken, if I recall correctly the
>> plugin completely fails to work) and finding it no better.
>>
>> I also tried nuking the *entire* compiz distro and all supporting
>> infrastructure and rebuilding from source, but this is not much of a
>> better solution either, random segfaults aplenty still.
>>
>>
>> For those that wish to continue with this line of wrestling in
>> oneiric or pangolin you will want to be checking
>> http://wiki.compiz.org/Plugins/Grid , you can grab the source via git
>> and recompile like so;
>>
>> git clone http://cgit.compiz-fusion.org/compiz/plugins/grid/
>>
>> cd grid
>> mkdir build
>> cd build
>> cmake ../
>> make
>> sudo make install
>>
>> But please keep in mind the problems I've iterated above and consider if
>> you really want to go through this yourself.
>>
>> Best of luck.
>>
>
> I think it's probably easier to look at compiz-plugins-main history on
> launchpad
> (http://bazaar.launchpad.net/~compiz-team/compiz-plugins-main/0.9.7/changes
> or one of the others, or maybe
> http://bazaar.launchpad.net/~lbrulet-8/compiz-plugins-main/fix-876591/revision/21),
> find the first offending commit, and revert it in the current package
> source to rebuild the package.
>
> note that i didn't say «easy» i said «easier». But anybody finding the
> time to restore the cycling on left/right (whatever key si configured
> to them) will have my gratitude.

i would really try more to understand this patch if i had more time,
it's the most probable one to be linked to this bug in the set of
patches in the compij-plugins-main source package, alas my c++ foo is
really bad, and i really lack time to dive more into that.
http://bazaar.launchpad.net/~lbrulet-8/compiz-plugins-main/fix-876591/revision/21#debian/patches/fix-862260.patch

Karl Brand (brandk) wrote :
Download full text (5.9 KiB)

Eric, tshirtman,

Really appreciate your sharing your approaches for a work around to keep
this feature in oneiric and perhaps pangolin.

For my level of expertise, i'll remain patient a little longer before
diving in with spanner and wrench :)

Thanks again,

Karl

On Tue, Mar 20, 2012 at 00:45, tshirtman <email address hidden> wrote:

> Le lun. 19 mars 2012 23:57:00 CET, Gabriel Pettier a écrit :
> > Le lun. 19 mars 2012 23:34:55 CET, Eric Bennett a écrit :
> >> Hi Karl,
> >>
> >> I should note in advance that at the end of the day, the fix posted up
> >> there ended up segfaulting my compiz after a few random updates to
> >> oneiric in mainline, I recompiled it a few times and eventually got so
> >> tired of it I just reverted back to natty after trying pangolin (it's
> >> not just broken there but *totally* broken, if I recall correctly the
> >> plugin completely fails to work) and finding it no better.
> >>
> >> I also tried nuking the *entire* compiz distro and all supporting
> >> infrastructure and rebuilding from source, but this is not much of a
> >> better solution either, random segfaults aplenty still.
> >>
> >>
> >> For those that wish to continue with this line of wrestling in
> >> oneiric or pangolin you will want to be checking
> >> http://wiki.compiz.org/Plugins/Grid , you can grab the source via git
> >> and recompile like so;
> >>
> >> git clone http://cgit.compiz-fusion.org/compiz/plugins/grid/
> >>
> >> cd grid
> >> mkdir build
> >> cd build
> >> cmake ../
> >> make
> >> sudo make install
> >>
> >> But please keep in mind the problems I've iterated above and consider if
> >> you really want to go through this yourself.
> >>
> >> Best of luck.
> >>
> >
> > I think it's probably easier to look at compiz-plugins-main history on
> > launchpad
> > (
> http://bazaar.launchpad.net/~compiz-team/compiz-plugins-main/0.9.7/changes
> > or one of the others, or maybe
> >
> http://bazaar.launchpad.net/~lbrulet-8/compiz-plugins-main/fix-876591/revision/21
> ),
> > find the first offending commit, and revert it in the current package
> > source to rebuild the package.
> >
> > note that i didn't say «easy» i said «easier». But anybody finding the
> > time to restore the cycling on left/right (whatever key si configured
> > to them) will have my gratitude.
>
> i would really try more to understand this patch if i had more time,
> it's the most probable one to be linked to this bug in the set of
> patches in the compij-plugins-main source package, alas my c++ foo is
> really bad, and i really lack time to dive more into that.
>
> http://bazaar.launchpad.net/~lbrulet-8/compiz-plugins-main/fix-876591/revision/21#debian/patches/fix-862260.patch
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/878820
>
> Title:
> Window Management, Keyboard shortcut - The grid keybindings are
> behaving inconsistently
>
> Status in Ayatana Design:
> Fix Committed
> Status in Compiz Main Plugins:
> Invalid
> Status in “compiz” package in Ubuntu:
> Fix Released
> Status in “compiz-plugins-main” package in Ubuntu:
> Fix Released
> Status in “compiz” source package in Oneiric:
...

Read more...

Otus (jan-varho) wrote :

If Ctrl+Alt+Num4/6 are going to do nothing and Ctrl+Alt+Num5 is going to Max/Restore instead of position, the keyboard shortcuts overlay should say that. As is, it mentions the numpad shortcuts that work very inconsistently.

Mekk (marcin-kasperski) wrote :

Multi-cycling of window sizes via grid was the single most important compiz feature for me (and still is on computers with 10.04). It is so much more convenient to press shortcut twice to get window in right 1/3 of the screen than to fight with mouse…

Whoever made the design decision to drop this functionality: PLEASE RECONSIDER. It makes grid plugin so much worse.

Eric Williams (eric-canonical) wrote :

I'll just +1 that this behavior is inconsistent and confusing.

Ctrl+Alt+KP* works for everything but left and right, which are the most useful IMHO on widescreen monitors.

Super+L/R would be fine, but Super+Arrow Key presses appear to be misdetected (LP#972330), bringing up the keyboard overlay after a few seconds.

Eric

Eric Williams (eric-canonical) wrote :

After today's update, Super+L/R no longer do anything at all. There is now no way to place windows left or right with the keyboard.

Eric

Daniel van Vugt (vanvugt) wrote :

Eric, today's update changed the key combo to Ctrl+Super+Left/Right, I believe.

Many people disagree no matter what the combo is changed to. You can customize it by running: ccsm

Daniel van Vugt (vanvugt) wrote :

The setting is in the Grid section of ccsm.

Is this going to be fixed in 11.10?

h3 (h3) wrote :

This still doesn't work in 11.10 .. My co-worker made a fresh install of 12.04 final beta and it still doesn't work. However he managed to make it work after fiddling in Compiz Config Manager, it seems at this point it was a key binding conflict.

This issue is really getting painful.

GonzO (gonzo) wrote :

Comment #46 has it 100% right.

I'm starting to really *hate* how Ubuntu/Unity devs are hiding behind some hidden, nebulous idea of "design" whenever they take away or break features people want.

Michael White (mikewhite314) wrote :

Perhaps the Grid plugin should be renamed to FourSquare to reflect its actual functionality.

John Lea (johnlea) wrote :

Reverting to 'Triaged' as this bug is not fixed in the release version of 12.04

Changed in compiz (Ubuntu):
status: Fix Released → Triaged
Changed in compiz-plugins-main (Ubuntu):
status: Fix Released → Triaged
John Lea (johnlea) on 2012-04-26
Changed in compiz-plugins-main:
status: Invalid → Confirmed
Martin Bergman (martin-devsed) wrote :

Please add an option for this in ccsm. Since the change to 50% the plugin has been useless for me, so please allow cycling between sizes for "put left" & "put right".

Also, +1 on what Gonzo wrote.

Leon Matthews (leon-matthews) wrote :

12.04 has been a marvelous upgrade for me -- except for this regression. Rapidly pulling windows side-by-side saved my much time as a software developer on a large monitor. Multiple key presses changing sizes meant that I could quickly give my text editor a little more width, and my terminal a little less.

Breaking the previous ctrl+alt+4/6 behaviour makes the rest of the resizing/moving numberpad shortcuts much less useful too, as the principle of least surprise has been violated pretty badly:

"Use ctrl+alt+numpad to move and resize windows. Up, down, top-right, top-left, bottom-right, bottom-left, and middle. All directions! It's easy!

Except for left or right. In that case you need to use the arrow keys instead. Oh, and don't use the control key anymore, use the super key this time. What's the super key you say? Ah, well..."

Edward Faulkner (ef) wrote :

I would love to see evidence from an actual user test showing that the original behavior was "confusing", because I'm skeptical that any such evidence exists.

Can somebody find even *one* user who was "confused"?

Alfons Maier (am-a6) wrote :

I really hope this gets fixed. In many cases a 50/50 split is not the way to go. Half of the screen may be to little space for e.g. a browser window, but is wasted space for e.g. a terminal window. I use a 66/33 split way more often. While I would prefer separated shortcuts for 50/50 and 66/33 (or even something like Divvy), cycling is better than only having 50/50 BY FAR.

I upgraded from 10.04 to 12.04 yesterday, stumbled upon this bug/feature, and then restored 10.04 backups. Going back to resizing windows with the mouse instead of keyboard shortcuts is a step I don't want to take, it's slower by magnitudes. Please restore this functionality, pretty please with sugar on top.

What fixes/workarounds/alternatives are there at the moment? Compiling upstream grid from source? I tried and failed. Switching distribution? I'm not happy about that idea either.

Edward Faulkner (ef) wrote :

I've hacked back in the old behavior and created a PPA:

https://launchpad.net/~ef/+archive/grid-cycling

At the moment it's waiting in the build queue, and will be for several hours.

If you're adventurous and on amd64, you can try these. They work for me, but that's no guarantee they won't light your computer on fire, etc, etc:

http://dl.dropbox.com/u/239052/compiz-plugins-main_0.9.7.0%7Ebzr19-1custom11_amd64.deb
http://dl.dropbox.com/u/239052/compiz-plugins-main-default_0.9.7.0%7Ebzr19-1custom11_amd64.deb

jadoe (jadoe) wrote :

These work for me. Thank you, Edward.

So we started with a bug saying that ctrl+alt+num behaved inconsistently and ended up with the same problem + different shortcuts?

I don't get why it makes any sense to have 1,2,3,7,8,9 working but not 0,4,5 and 6. It was ok the way it was in 11.10, it made sense. Now it doesn't make sense, and having to change alt to super makes it even more annoying.

Thank you Edward, until now I had no problems whatsoever.

Is there another way to remap the shortcuts then ccsm?

Changed in compiz-grid-plugin:
status: New → Confirmed
Changed in compiz:
status: New → Confirmed
John Lea (johnlea) on 2012-10-12
Changed in compiz:
status: Confirmed → Triaged
Changed in compiz-grid-plugin:
status: Confirmed → Triaged
Changed in compiz-plugins-main:
status: Confirmed → Triaged
Changed in compiz:
importance: Undecided → High
Changed in compiz-grid-plugin:
importance: Undecided → High
Changed in compiz-plugins-main:
importance: Undecided → High
Changed in compiz (Ubuntu):
importance: Undecided → High
no longer affects: compiz (Ubuntu Oneiric)
no longer affects: compiz-plugins-main (Ubuntu Oneiric)
Didier Roche (didrocks) on 2012-10-12
no longer affects: compiz-plugins-main (Ubuntu)
Changed in compiz (Ubuntu):
assignee: Didier Roche (didrocks) → nobody
cako (goldencako) wrote :

Are there any updates on this? We're having the same discussion over at Bug #879218 (https://bugs.launchpad.net/unity/+bug/879218) and everyone there also agrees that the old behaviour is more desirable. The devs don't seem to care though :(

John Lea (johnlea) on 2012-11-22
Changed in compiz-plugins-main (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in compiz:
milestone: none → 0.9.10.0
assignee: nobody → MC Return (mc-return)
status: Triaged → In Progress
MC Return (mc-return) wrote :

This branch follows the Ayatana Design specification in the description and fixes behaviour for top and bottom windows as well
(corner and centered will still cycle):
lp:~mc-return/compiz/compiz.merge-fix1082001-gridded-windows-jump-workspaces

@all: Long term plan is to make behaviour configurable by the user, so everyone will be satisfied.

MC Return (mc-return) wrote :

Cycling through sizes is disabled in my branch for all gridded windows for now, following design specifications in the description of this bug.

MC Return (mc-return) wrote :

Long term plan is finished:

The branch linked here makes the cycling through different grid sizes behaviour fully configurable via CCSM.
CCSM Screenie: http://uppix.net/5/f/4/c21c285ee4ce86b1b9f756e3c17ab.png

:)

TomasHnyk (sup) wrote :

Thanks! That sounds great.

PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:compiz at revision 3650, scheduled for release in compiz, milestone 0.9.10.0

Changed in compiz:
status: In Progress → Fix Committed
TomasHnyk (sup) wrote :

That looks sweet, thanks a lot, cannot wait till saucy :-).

Stephen M. Webb (bregma) on 2013-07-23
Changed in compiz:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :
Download full text (70.8 KiB)

This bug was fixed in the package compiz - 1:0.9.10+13.10.20130822-0ubuntu1

---------------
compiz (1:0.9.10+13.10.20130822-0ubuntu1) saucy; urgency=low

  [ Sam Spilsbury ]
  * Bump version to 0.9.10

  [ Łukasz 'sil2100' Zemczak ]
  * Remove debian/patches/unity_support_test.patch:
    - Running the support test from compiz has bad side effects, from now
      on we run it from Xsession.d
  * Automatic snapshot from revision 3644

  [ Iven Hsu ]
  * Opacify: Only dim the windows above the active window.(LP:
    #1189374). (LP: #1189374)
  * KWD: Fix compile errors with KDE 4.11. The KWin developers made
    kdecorationbridge.h private. See:
    http://lists.freedesktop.org/archives/compiz/2013-March/003479.html
    (LP: #1193792). (LP: #1193792)

  [ Nikolay Martynov ]
  * When static switcher is enabled and has an option to show
    application icon turned on the icons are expected to be ~1/3 of a
    thumbnail (48px). Instead they are displayed in 512px size and
    completely cover everything. This change addresses this issue. See
    LP #1173914. (LP: #1173914, #1186426)

  [ BryanFRitt ]
  * Fixed the non-working Annotate 'Clear' Button. Moved this option's
    CCSM position upwards to keep the button shortcuts together. (LP:
    #1202907). (LP: #1202907)

  [ Mehrdad Afshari ]
  * Added "move window to previous monitor" feature to compiz Put
    plugin. (LP: #1178581)

  [ Hu Kang ]
  * gtk-window-decorator: destroy action menu when any of the (close,
    min, max) buttons on the title bar is pressed. (LP: #1101648)
  * Remove redundant src/logmessage/include/core/logmessage.h (LP:
    #1067246). (LP: #1067246)

  [ Steve Langasek ]
  * Fix for bug #763148 (with added test cases): when the desktop is
    resized, windows should stay on their original workspace. (LP:
    #763148)

  [ Brandon Schaefer ]
  * Unrevert 3728, fix failing tests. Change the behaviour of
    undecorating windows. Previously when a window was undecorated, we
    would shift it back to an appropriate position according to its
    gravity member. That behaviour was problematic because in the
    StaticGravity case the window has to just stay in the same place.
    But then if you had a window with StaticGravity which then did get a
    decoration and later removed it, it would be placed as though it was
    decorated and appear to be in the wrong place. The correct behaviour
    is to place all windows as though they have decorations, and then
    when decorations are removed, to move the window back to the corner
    as indicated in its gravity and then expand its size to cover the
    obscured regions no longer hidden because the decorations went away.
    (LP: #1165343).   1. Completely remove decorOffsetMove and other
    related code from      decor.cpp. Put the logic to handle the
    window->input () - window->border ()      placement offset inside of
    setWindowFrameExtents instead. Now the window      will always be
    offset from its original non-decorated position to the new
         decorated position, rather than having to guess between
    decoration sizes.   2. Make saveGeometry and restoreGeometry work
    relative to window->border ()      a...

Changed in compiz (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.