pop-os / shell Goto Github PK
View Code? Open in Web Editor NEWPop!_OS Shell
License: GNU General Public License v3.0
Pop!_OS Shell
License: GNU General Public License v3.0
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.
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?)
That there was a way to restore my shortcuts the way they were before.
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!
The menu key (Fn+RCtrl) does not seem to work at all.
The toggle to activate this might be in the tiling-menu indicator. @maria-komarova is looking at the menu design.
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.
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.
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 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.
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.
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.
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?
Currently, shrinking a window in a direction which would shrink the tree will do nothing.
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.
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.
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.
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?
Design for the default tiling (the logic is open to discussion).
Rules/Steps:
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).
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
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.
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.
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.
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.
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.
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.
Super
+ W
to convert a window to floating and vice versaSuper
+ O
Sometimes it works, sometimes it doesn't.
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.
something
There is a bright pixel in the top-left corner when this extension is enabled and before the overlay is used.
This may require a bit of work
The gap calculations are slightly off. Most noticeable with higher inner gap settings.
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.
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.
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.
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.
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 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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.