This is a great way to lose track of what is open and running and let RAM and CPU resources climb unchecked.
Many of us have good reasons for wanting to retain full user control of the desktop rather than letting it automate us out of the equation.
2 Likes
One super cool feature that I found about not too long ago for Gnome (and I think it also exists on XFCE) is that you can hold Super and then you can just click anywhere on a window and drag it around. With right-click instead, you can resize windows instead.
These seems small, but not having to click exactly on the toolbar or exactly at the edge of the window is such a massive relief. That has also made me use the minimize buttons less often than before (although I still like having them around and use them occasionally).
2 Likes
I absolutely do not get your point here. How does a keyboard focussed workflow make you lose track of what is open and running? How does a keyboard focussed workflow let resources climb unchecked? How would a keyboard focussed workflow take control away from you? There is nothing more or let automatic about it than mouse focussed workflow.
Very good points. I stand corrected. In the manner you describe in this post, it does not.
Rather, I meant that if a user is faced with open windows stacked onto each other that they are not minimizing or closing with no controls to allow them to do so, then they can lose track of what is open. Indeed, I do see this all the time. Especially when I approach someones computer and see their browser loaded up with 1,242,987 tabs open.
You can also witness this on Mobile devices - they lack a close button and users often end up with many processes stacked and running.
I misunderstood that by your workflow, you are managing those open windows with keyboard controls, rather than just stacking them.
The workflow you just described in the quoted post sounds well within your direction and control.
3 Likes
Now I understand, and I totally agree.
I am actually guilty of doing that, not windows, I keep only those that are needed, but certainly browser tabs. I think some of my tabs are two years old. Not proud of it. 
Had to teach myself how to overcome the Browser Tab phenomenon. Now, I monitor that I do not go above seven open tabs for any period longer than a few minutes at a time. If any are still open (Such as clearing out threads on this forum), I close them. If needed, I can just relaunch them from history anyway.
Some links on tabs that I find important, I save in a .txt file in Documents Directory.
Me also, I can't stand having more than a few tabs opened. I even tweaked my Firefox UI to shrink the number of visible tabs:
I can still scroll horizontally if I open a bunch, but this helps a lot to keep things nice and concise.
I'm happy with the current workspaces and Workpace Indicator which has only one small, numbered icon.
This is antithetic to GnuLinux and FOSS - software being integrated, not modular. It does not keep it simple, it does not do one thing and do it well and it restricts user access.
Gnome. 
The more integrated software is, the less it can be forked. GNome Devs claim that users can just fork and modify if they do not like what the GNome Devs are doing; then they pull stunts like this to prevent the users from doing just that.
It's an excellent example of "Just listen to our claims but do not test them."
4 Likes
Yeah, no idea why they'd do this... I mean, obviously it's a simple utility that can be easily replaced but I don't see the improvement either.
Is anyone else having this gap between window and taskbar when advanced tiling windows is enabled? You can see here on the left that the terminal window has an extra bit of room left.
Also, after running an update the zorin-os-feedback shortcut has been removed. I guess stable release is coming?
This already works, although only if you've previously loaded that image preview with the normal file manager. This is a bug for GNOME to fix, most likely
As a matter of fact, GNOME-Screenshot is no longer a seperate utility. You can still install it if you wish (e.g sudo apt install gnome-screenshot) although the included Screenshot tool is completely integrated into gnome-shell.
What you're thinking of is the UNIX Philosophy, neither GNU/Linux or FOSS in of themselves.
That is a side-effect of the Terminal having a fixed size, not Advanced Tiling. Try floating the window and resizing it, you'll notice that it adjusts it's size only to the grid of characters.
Neither is included, at least not the GUI for GNOME-Extensions. Note that Zorin wouldn't work without extensions.
I would personally recommend Extension Manager from Flathub anyways
1 Like
Yes, you are correct that the statement I gave is grounded in UNIX Philosophy.
Write programs that do one thing and do it well.
However, I stand by my comments in light of the Gnu Philosphy:
https://www.gnu.org/philosophy/greve-clown.en.html
Therefore, accessibility of source code is a necessary condition for free software. Obfuscated “source code” is not real source code and does not count as source code.
https://en.wikibooks.org/wiki/FOSS_A_General_Introduction/Introduction
Reduced duplication of effort
By releasing programs early and granting users the right to modify and redistribute the source code, FOSS developers reuse the work produced by compatriots. The economies of scale can be enormous. Instead of five software developers in 10 companies writing a single networking application, there is the potential for the combined efforts of 50 developers. The reduced duplication of effort allows FOSS development to scale to massive, unheard of levels involving thousands of developers around the world.
Integrating software into the Gnome Shell adheres that software to the Gnome D.E. and Shell.
It is not modular, cannot be easily distributed and is obfuscated by the surrounding shell code.
I am not alone in thinking this: So have the Gnome Devs:
On numerous occasions, actually, Gnome Devs including Tobias Bernard floated leaving GPL due to it "restricting their mission and desires for Gnome."
4 Likes
It seems to be only the gnome-terminal though, other terminals like Kitty and even Tilix, which is based on gnome-terminal, don't have this issue. Other windows have similar small glitches but less noticeable. Not a huge deal for me, just found it interesting and something to improve upon for later point releases perhaps.
As for the screenshot tool, I don't really think it's an improvement to integrate it like that. It's really nice looking and gives that feeling of cohesion, but it does hurt extensibility and customization.
Yeah, because GNOME-Terminal is programmed to fit to the grid. The issue isn't the desktop, it is GNOME-Terminal.
Integrating it (in of itself) doesn't hurt it - you can now customize the screenshot tool using Extensions after all. The issue stems from the fact that the GNOME Developers that worked on this feature either forgot, or deliberately didn't add in the timer feature.
On other Desktop Environments, the Window Manager is responsible for this. Gnomes Mutter doesn't fully manage these aspects because Gnome Developers really want to push as much development onto the individual application makers, and make them do their development for them, as possible. Some App makers are on board with this, as they would love nothing better than to take control of these facets that are their Brand Image (the appearance of the app) and lock out the user from making changes.
So, it really is the desktop environment, just as much as it is Gnome terminal.
This is one of my chief complaints about trying to theme Gnome; it is so non-standardized that different applications take on different dimensions, widget sizes, widgets overlap or do not line up with each other creating gaps.
The general solution to this is to stick with Flat and Monochromatic themes - since these hide all those unpolished edges by blending them together with no gradients to show the breakages, no color changes to show how poorly it all lines up.
Gnome is as polish-able as pumice.
That would explain why even forks of gnome-terminal don't have that same behavior.
With little research your claims of things that the GNOME developers are supposedly trying to do are quickly proven false and aren't based on facts but rather on beliefs that you have built up out of a dislike of how GNOME handles things.
For example, Kitty also allows resizing in this way, regardless of Window Manager, because this is something that X11 APIs allow.
This completely derails your claim that "Gnome Developers really want to push as much development onto the individual application makers" because in reality this just shows that GNOME decided not to arbitrarily override X11 APIs in the position of a Window Manager and Compositor.
Time and time again I have seen that your opinions regarding how GNOME does things come from a place of dislike or possibly even hatred, but not of research of how the features that you're criticizing work. This is in stark contrast to how thoroughly you often research other topics regarding how GNOME runs things in terms of Ideology or Governance over the project.
GNOME-Terminal was programmed to (by default) use X11 APIs to adjust the window size in steps according to the grid that the Terminal window has. This was a conscious decision by GNOME-Terminal developers and has nothing to do with Mutter.
Please note that Tilix isn't based on Gnome-Terminal, it only uses GNOME's Terminal library that happens to also be used in Gnome-Terminal. (see: VTE)
If you look at the Source-Code and official website you will soon notice that it is mentioned nowhere that Tilix is supposedly a Gnome-Terminal fork.
There is no logic in suggesting that because Applications allow window resizing, that this somehow falsifies my statements. It does not. It is essential that apps allow resizing, just as it is that the Window manager works in conjunction with this, rather than skipping it.
Read here:
https://trac.transmissionbt.com/ticket/3685
And here:
The issue is that Gnome devs built Mutter around its own display manager (Mutter is from Clutter and Metacity) in order to remove large elements of window management (In preference of CSD's) in which at that time, only Gnome was doing this. The result was that modular apps, such as ones that are desktop agnostic, had no issues with their API's on any desktop - except for Gnome. Gnome's response was to try to push those other developers into adjusting their API's or to perform all the API work, instead of Gnome.
In the links above, you can read all of this.
I think at this point that I must remind you that I code in GTK and work with Gnome Developed applications and GDK. Your assertion that I lack research on the topic falls down completely with that point.
This is because there is no stark contrast. I am relaying how the applications and the desktops work.
But if research is something you want, I can provide more of it:
https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/
https://blogs.gnome.org/shell-dev/
Modules are loaded differently than scripts, and some statements — namely
importandexport— are only valid in modules. That means that trying to import a module with the legacy system will result in a syntax error if the module uses one of those statements (about as likely as a pope being Catholic).
As you can see, my statements are not only not "proven false" (Proofs only exist in mathematics, by the way) by your assertion, they are supported by the statements directly made by Gnome dev including Tobias Bernard.
In fact, a great deal of my information about Gnome developments and ideology is due to following Bernards direct statements.
Which links to the blog where you can find even more ideology.
It also links to this beautiful gem:
Note this disclaimer:
Note: Even though some of us are Foundation members or work on GNOME, these are our personal views as individuals, and not those of the GNOME Project, the GNOME Foundation, or our employers.
If you read the signatures, the vast majority of signors are Gnome Developers.
The Gnome devs wrote an open letter, to themselves, under the pretense of being general app developers of the public. Now, this did get noticed and they did get called out on this behavior. So they later added that disclaimer above saying, "Ok, yeah... we are the Gnome devs, but in signing this letter we will point to any other non-gnome projects and assign ourselves as those developers for the sake of this letter."
You are correct: I dislike what the Gnome Developers do and are doing. I dislike their direction and how they apply their direction on the users with force (LibAdwaita).
Or with the use of Deception (You can fork our apps, except that we integrate them into the shell; we are suddenly not Gnome Devs to write an Open Letter to Gnome and then go back to being Gnome Devs after signing the document with other project titles).
I did not start out disliking Gnomes direction. This developed over time due to Gnomes behavior. So if you want to defend Gnomes decisions based on my dislike, you might want to check which came first.
For those of us who have to code around Gnomes development by making one exception after another for things to work on Gnome that otherwise work fine on every other desktop; for those of us that must do this constantly and then reel in the bug reports for the things in Gnome we missed (Because I do not use Gnome daily anymore and what I write must be done on a test rig); Yes... We absolutely have loads of research under our belt - not only from having to follow Gnomes declarations of intent, but from having to constantly fix Gnome Exceptions.
Yes, Gnome Devs state outright that they want to eliminate the Modular aspects of GnuLinux in Gnome. That they believe Gnome Extensions are a "niche thing" that will not last (Wow!) and that they wish to do away with Gnome Extensions and have users instead, be beholden to Contributing Directly to Gnome Shell Code if they want to help improve Gnome, not make extensions for Gnome (Which is actually a way of barring the door).
3 Likes
The release of Zorin 17 is upcoming, and the adoption of Gnome is inevitable. Discussing Gnome itself in this thread is not useful feedback.
1 Like