Tweak Tool in Workstation?

Wed May 13 08:28:08 UTC 2015

----- Original Message -----
> On Tue, 2015-05-12 at 13:58 -0400, Bastien Nocera wrote:
> > 
> > ----- Original Message -----
> > > On Tue, 2015-05-12 at 06:02 -0400, Bastien Nocera wrote:
> > > > > * Shell extensions: As long as we're going to offer them, we
> > > > > shouldn't
> > > > > relegate them to Tweak Tool. Perhaps gnome-software would be a
> > > > > better
> > > > > location than gnome-control-center, but either would be better
> > > > > than
> > > > > Tweak Tool. (But the gnome-shell browser plugin is very crashy
> > > > > at
> > > > > worst and unreliable at best, so we should fix that first.)
> > > > 
> > > > Extensions is what happens when designers and developers don't
> > > > agree.
> > > > If you know you want extensions, installing gnome-tweak-tool is
> > > > only
> > > > a
> > > > step away. If people want to integrate that better, they can add
> > > > support
> > > > to the gnome-shell web browser plugin to show whether or not
> > > > gnome
> > > > -tweak-tool
> > > > is installed, and launch Software to install it through the
> > > > browser
> > > > if not.
> > > > 
> > > 
> > > At the same time, I think it would be very useful to poll GNOME
> > > users
> > > for what extensions they are using (if any). I think you'll find
> > > that
> > > it's very likely that more users have installed (for example) the
> > > Alternate Tab extension than are using the default behavior (and it
> > > would also be interesting to know whether those using the default
> > > behavior know about the extension).
> > > 
> > > Some other extensions that I personally know a great many people
> > > cannot
> > > live without:
> > > 
> > > * Topicons: I understand that systray icons are not the way the
> > > GNOME
> > > designers want things to work, but FAR too much software exists
> > > today
> > > that relies on these icons. Shunting them to the message tray (pre
> > > -3.16) or into a tiny little expansion box (post-3.16) or hiding
> > > them
> > > entirely (Wayland) are not valid solutions for this software. Call
> > > it
> > > legacy software if you wish, but not having a sensible
> > > compatibility
> > > layer is harmful to users.
> > 
> > The sensible compatibility layer is what you see. We don't want to
> > encourage using a functionality that we've been trying to wean
> > ourselves
> > off for a number of years already.
> > 
> > We can't keep on indulging applications that are designed like Winamp
> > and ICQ circa 1998.
> > 
> > There are alternative ways:
> > https://wiki.gnome.org/Design/OS/MessageTray/Compatibility
> > 
> 
> 
> That is all well and good if we have access to the sources for these
> tools. How about the endless supply of third-party software that we
> don't and can't control? Dropbox, Steam, Chrome Hangouts... are just a
> few. Without the topicons extension, these tools are difficult to
> access.

They get relegated to the corner... A good experiment would be to see if
changes in the status icon could be transformed into notifications through
an extension.

And contact your app provider to tell them that the GNOME integration is bad...

> > > * Window List: For many users attempting to locate the window they
> > > want
> > > across a number of workstations, having the window list at the
> > > bottom
> > > of the screen provides a very quick way to see what is on every
> > > workspace. It's far easier to process a short line of information
> > > than
> > > to 1) go into the Overview. 2) start paging through each workspace.
> > > 3)
> > > scan the entire screen for the window that matches what you want.
> > 
> > 1) Go into the overview
> > 2) type the name of the app followed by enter
> > or
> > 2) click on the app's icon in the dock
> > 
> > Maybe GNOME Classic is a better option for this site?
> > 
> 
> Neither of these options is sufficient if you have more than one window
> for a particular application. Some simple examples:
> 
> * I have several browser windows open on different workspaces to match
> what I'm doing in those spaces.

You should try using Epiphany's Webapps. I have separate apps for Webmail,
web RSS reader and my NAS' "UI in a web browser".

> * I opened an email composition window and moved it to another
> workspace in order to easily reference something
> 
> Neither of those cases work with the above response.

Worth filing a bug about, with this information. It's kind of weird that
we don't search through opened windows when in the overview, in some way.

> > > Don't get me wrong: the GNOME designers have made many excellent
> > > choices: I wouldn't be running the GNOME environment if I thought
> > > otherwise. But some choices have fallen well into the realm of
> > > "perfect
> > > is the enemy of good". It doesn't matter how "clean" an experience
> > > feels on paper if people trying to use it get frustrated. There are
> > > many extensions out there to alleviate some of these pains, but
> > > there
> > > are two problems:
> > > 
> > > 1) Extensions aren't common knowledge. Most people assume that
> > > GNOME is
> > > immutable and limited to only the few choices allowed by gnome
> > > -settings. Related to the above: no matter how easy it might be to
> > > install GNOME Tweak Tool, it's not *discoverable*. There are no
> > > hints
> > > anywhere that you might want or need it. There are no links from
> > > Fedora
> > > to popular extension pages, etc.
> > > 
> > > 2) Extensions aren't (and as I understand it, cannot be) stable
> > > API. So
> > > even when someone has discovered an extension that they really
> > > cannot
> > > survive without, there's no guarantee that it won't be broken on
> > > the
> > > next update. This problem isn't solvable by GNOME, but it can be
> > > solvable by Fedora: we could identify a set of high-value
> > > extensions
> > > and work with their authors to have them ready before we release
> > > new
> > > versions of Workstation.
> > 
> > High-value extensions should be in the core of gnome-shell. Support
> 
> 
> This is absolutely something I would like to see. Some of them are: the
> ones attached to GNOME Classic. So that's definitely a step in the
> right direction.
> 
> 
> > for
> > non-Gregorian calendars for example:
> > https://bugzilla.gnome.org/show_bug.cgi?id=624959
> > 
> > Or support for media player controls, or builtin weather.
> > 
> > I made a list of those for the gnome-shell developers, but cannot for
> > the
> > life of me find them anywhere anymore.
> > 
> 
> ...
> 
> > Everything in gnome-settings-daemon and the gnome-control-center is
> > designed
> > in such a way that "close the lid" means "put the machine to sleep if
> > it's
> > stand-alone, turn off the screen if it's plugged in to a
> > dock/external monitor".
> > 
> > As such, any option that might exist changing that behaviour is
> > provided
> > as-is, YMMV, you-get-to-keep-both-pieces.
> > 
> 
> OK, that's reasonable (and a pretty decent default as well). Thank you
> for explaining.
> 
> 
> > > > > * Top bar: Maybe show date in clock could live in the Date &
> > > > > Time
> > > > > panel, where the 12/24 hour setting is.
> > > > 
> > > > We already show it inside the menu, is that not enough?
> > > > 
> > > 
> > > When someone wants to know the date, it's usually because they need
> > > to
> > > use it for something (like signing a check, etc.) right now.
> > > Needing
> > > more than a quick glance to the top of the screen is wasteful,
> > > particularly since the GNOME design policy is to have none of that
> > > space used for anything else. This is one of those cases where I
> > > cannot
> > > figure out why the default doesn't simply include the date. I can
> > > understand having seconds or week numbers in the tweak tool; those
> > > are
> > > far less interesting.
> > 
> > The full date (compared to the week day and time) would also distract
> > from
> > the more important parts. Do we need the year in the full date? Do we
> > need the
> > month? Feel free to file a bug about that, the default and/or having
> > a visible
> > configuration option can be discussed in its own bug.
> > 
> 
> 
> In this case, I was actually just talking about having the default
> behavior match the "enabled" value of the checkbox in Tweak Tool. Right
> now, on my system that results in the menu bar reading:
> 
> Tue 12 May, 15:25
> 
> I think this is probably sane and reasonable in general, though I'll
> admit that others might prefer a different representation of the date.

Could you file a bug against gnome-shell about it (upstream)? We'll discuss
it there and see whether gnome-desktop and gnome-control-center about it.

Cheers