pop-os / shell Goto Github PK

This will ensure application windows launch on the correct monitor, and that empty monitors can be "focused", by focusing the shell and moving the mouse to them.

This seems like it may be related to #39

If I use Super + Enter to resize a window while in free-float mode, there is a region on the bottom of the screen that I cannot resize the window into with Shift + arrows. I can use the mouse to expand the window into that area, but it's almost like the grid does not extend that far.

The screenshot above shows my monitor setup with an Alacritty window on each display sized as large as I can make it in window management mode. The top display is 4K (100% scaling) and the bottom one is 1080p. The empty area is much larger on the 4K display in terms of pixels, but it seems roughly the same proportionally as the 1080p display.

Also this does not seem to happen with tiling mode activated, so that tiling grid seems to line up with the full area of my displays better.

The menu key (Fn+RCtrl) does not seem to work at all.

When a window is selected with Super+Enter and then Super+/ is selected, the window focus dialog is below the window highlighting from the window having focus.

I see that when launching the window focus dialog first, upon executing Super+Enter, the focus dialog closes (although a bit glitchy).

If I go to set an outer gap value of 3 but hit the enter key more than once, the outer gap gets larger with each key press. The number stays the same in the box though, so maybe something just isn't being reset properly when the outer gap value is updated.

I think this is intentional, but I can't set a gap value that isn't a multiple of 4. If the value entered isn't a multiple of 4, it sets it to the next lowest multiple of 4. This seems pretty reasonable, although I wonder if true rounding would be more user-friendly than rounding down each time. For example, if I enter 7, it sets it to 4. Would 8 be better since it's closer to the number the user entered?

If I set a gap value then open a few windows, the windows will not have a gap between them. If I then re-apply the gap value, the windows I just opened will have gaps again. It seems like whatever applies the gaps doesn't run upon window creation.

Design for the default tiling (the logic is open to discussion).
Rules/Steps:

1. Maximum number of tiles before the system starts splitting windows horizontally:
   • regular format - 2
   • ultrawide - 4
2. The focus shifts to the newly opened window.
3. Open the next window to the right from the one with the focus untill you reach the horizontal split point.
4. When splitting windows horizontally, open the new window at the bottom.
5. Then split the window to the left.
6. After that, open the new window to the left of the one with focus.
   

Menu design that includes:
keyboard shortcuts,
gap setting,
the option to launch windows tiled,
custom layout.
All of the small designs in one window - just to show where the menu will be.

Step by step saving the new custom layout (Click Save Current in the menu - name the layout and click save - confirmation that the layout was saved - new layout added to the list of custom layouts).

Launcher design

Section of the Settings > Desktop & Workspaces page.
The page is part of the upcoming Gnome design: https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/590

When the window focus dialog (Super+/) is launched, locking the screen or letting the system lock itself on powersaving timeout, does not close out of the dialog. From the locked screen I can see what applications are open but cannot interact with this menu.

When I enter either an inner or outer gap of 0, when pressing Enter to apply the change the value in the box disappears.

It also appears that this change of setting either gap to 0 does not apply when pressing Enter.

With two windows opened and tiled vertically, resizing the left window with Super+Enter and then the right direction, eventually the second window gets pushed off of the screen in a way where it is not usable.

The gap calculations are slightly off. Most noticeable with higher inner gap settings.

After entering Tiling mode (Super+Enter), changing workspaces (Super+Ctrl+Down) or entering activities mode(Super) works.

Either these modes should be disabled when in Tiling mode, or upon selecting unexpected keys, tiling mode should cancel/close.

When in window management mode (super+enter), holding Ctrl+ does not change the selected window.

I'm currently on version 6888c7b from master_focal, but I've seen this on the last few rebuild.sh's that I've run.

When launching the Window Focus dialog with Super+/, should the currently open windows be shown by default? Currently you have to search for something before you are shown any results at all?

I feel as though within the last week the behavior of the Window Focus dialog was to show open programs on launch.

The toggle to activate this might be in the tiling-menu indicator. @maria-komarova is looking at the menu design.

• Left and Right shrinks and grows the width
• Up and Down shrink and grow the height

I'm not quite sure what is triggering it but applications sometimes can't be moved between monitors or workspaces. It happens in Pop 19.10 though it seems to correct itself sometimes.

For this bug I have Snap to Grid and Show Window Titles activated.

Maximized windows result in a large empty area at the bottom of the screen, almost like the outer gap gets applied multiple times, but only at the bottom. If I hit Super+M, the gap only appears after I click the top bar, but if I drag the window to the top of the screen, the empty area appears right away. The empty area was proportionally much larger on a 4K display.

When I'm starting with both monitors completely empty with tiling mode enabled, I can open one terminal window and it opens fullscreen as expected. However the next one I open pushes the new window and the one that was already open to my other monitor.

This gif was taken across two 1080p monitors. Having Peek any larger interfered with the bug I was seeing, so I had to make it a bit smaller. Hopefully it's still clear, but basically I opened a terminal on the right monitor, and opening one one more pushed both of them over to the left monitor.

If I open a bunch of tiled windows and close a bunch on one side of the fork, I can make a whole bunch on one side of the fork reorient with the single window on the other side of the fork when I hit Super + O. Is this they way it's supposed to work, or should forks rebalance themselves so not so many windows change with an orientation change?

For navigation we propose two shortcuts for the same action. For the user to customize these, GNOME Settings > Keyboard Shortcuts needs support for multiple shortcuts per action.

something

After a discussion with @maria-komarova , we think we may want to reconsider overriding Ctrl+Super+Left and Right for half-tiling windows left or right on the screen. I'm not certain it will work great in tiling mode, but in the default non-tiling mode, it breaks immersion and takes far more keypresses. What used to be a single hotkey now requires me to enter window management mode, move the window, resize the window, then hit enter. The process seems likely to monopolize the user's attention span, which is detrimental for productivity.

• Added gap settings
• Avoid gap on top-most corner
• Avoid gap on left-most corner
• Avoid gap on right-most corner
• Avoid gap on bottom-most corner
• Gap everything in-between

Context

I wanted to try this to start offering early feedback and to start getting used to what I think is going to be amazing so I asked around and @mmstick got me hooked up right away (thanks!).

I'm on Pop 19.10 and had to do npm install -g typescript (I already had npm set up).
tsc --version now returns Version 3.8.3

This is an Oryx Pro 2019.

Problem

After running the rebuild.sh script, I noticed all my mostly default familiar Pop!_OS shortcuts to move windows around no longer worked. This is obviously expected (that there will be new conflicting shortcuts with a regular Gnome Session), but what was not necessarily expected was that I was going to "lose" my original shortcuts.

Perhaps there's a way to mitigate this (warn users? allow to "save" them?)

Expected

That there was a way to restore my shortcuts the way they were before.

Why am I filing this?

At the request of "shpurk" on mattermost who said: (And I quote):

Maybe you should file an issue about this, the fact that you didn't think to do this/etc, when people upgrade to 20.04, there will probably be a lot more people in the same spot you are in.

Thanks!

When searching "Settings" gnome-control-center does not appear as the application is called gnome-control-center. The search should probably include the name of the desktop application.

When Super+/ is pressed:

After typing the position of the text box on the screen moves, which can be disorienting to the user:

(note the alignment between the input box and "Online Accounts" in the window below)

I think it might be better if the text box stayed in the same place, but the dialog grew downwards to accommodate the results that appear.

Sometimes it works, sometimes it doesn't.

When launching an application with "Launch windows tiled" disabled, Ctrl+Super+Left will tile the program to the left side of the screen. Pressing it again will untile the program. Ctrl+Super+Right does not do anything.

Apparently, this is very possible to do with shell extensions. Changes required should be minimal, as it is mostly adding types to functions and fixing type errors reported by the compiler.

With tiling on by default, on a 1080p display, the fourth window opened (without changing focus of the windows other than by opening the second and third windows) does not follow the window tiling guidelines as defined here: #9.

Screenshot of current behavior:

Screenshot of behavior defined in #9:

I know this is still early, but I discovered the cause of my biggest pain point with pop-shell so far. Somehow Ctrl + Super + Up was assigned to two actions: switch workspace up and restore window. Once I manually reset that hotkey, everything was much better. I did toggle the extension a few times, so maybe that's where the issue came from. I'm also running 20.04, in case that is relevant.

When changing focus to different windows on my 4K non-scaled monitor, I'm finding that it's sometimes hard to follow the mouse cursor around the screen and keep track of which window I currently have focused. If we had an animation or something to indicate which window was becoming active, I think that would make window navigation much quicker and easier.

• Super Q for closing windows (To avoid the destructive action of closing a window when closing browser tabs (CTRL+W) was the intent)
• Rename "Launch Windows Tiled" to "Tile Windows"
  • Change functionality to tile all open windows when activated
  • Give the largest space the browser
• When in tiling mode Super+Enter and then direction keys moves the window to a different tree
• When in tiling mode Super+Enter then Shift+direction keys resizes the tree
• Add Appearance drop down to the extension with Inner Gaps, Outer Gaps, and Show Widow Titles options.
• Adjust gap sizes as the setting is changed (rather than on enter)
• Super + W to convert a window to floating and vice versa
• Change toggle orientation to Super + O
• Add application launching
  • Search via desktop files
  • Command line execution
  • sudo command handling
• Fix resizing issues

It's currently a basic entry, and despite assigning it a purpose as a number entry, this doesn't actually change the behavior of the entry.

Currently, shrinking a window in a direction which would shrink the tree will do nothing.

This may require a bit of work

• Check if a moved window was sized to the dimensions requested
• If the window fails, either revert the changes, or try to compensate
• Compensating could be growing or shrinking a fork, or growing / shrinking a sibling in the fork

Some applications remember their location on the screen when they were last open, and then try to open themselves in the same location after they have been placed by the window manager.

Firefox is really bad about doing this after it has opened.

We should tell windows to sit and stay.

There is a bright pixel in the top-left corner when this extension is enabled and before the overlay is used.

What is the expected behavior of the Window focus dialog (Super+/) when there are no programs open?

Right now the search box appears but there isn't anything that can be done from this list.

If I'm in floating mode and I open the management overlay, there is a good chance a window I select won't line up with the borders of the management overlay. I know the overlay is on a grid, while windows in floating mode are not, but it does look a little strange, and hitting enter without making adjustments will slightly resize the window to the size of the overlay. I'm wondering if the first view of the overlay shouldn't be forced to line up with the window, then return to its grid once adjustments are made?

By default Brave (and other Chrome browsers) have headerbars and enabling it adds a double headerbar though it removes it for other applications.

This is on Pop 20.04 LTS which may void out this bug report which is fine.

gnome-shell --version
GNOME Shell 3.34.3

Just pulled the shell from git a few minutes ago.

With dark mode enabled, launching the window focus dialog Super+/ shows a dark text box with a white dialog around it. The white dialog makes this look very odd. This looks fine in light mode, so I think this is an issue with appropriately theming the dialog in different modes.