Re: Two proposals for Gnome-shell

[David Prieto]

Hey Jesse,


> My personal feeling is that there's no easy solution for showing what's in
> different workspaces in a quick and efficient way. The current solution,
> while it certainly isn't perfect, makes the most sense to me, and the large
> thumbnails actually do help me in this case more than icons, because the
> configuration of windows tells me something about what is running there (I
> usually layout different windows differently, in specific patterns, etc). I
> agree that showing icons would make it quicker and easier to find a given
> app. But, the proposed solution is less visually appealing to me and can
> hide more information in the case of the same app running in different
> spaces (also doesn't show the visual layout/structure of the space).
>

I'll be honest here: I don't think the current WS thumbnails do a good job
at showing what is on each workspace. At all. If anything, they show more or
less what each of them would look from far, far away. But windows in them
look mostly the same, and to top that, most windows appear partially or
completely covered from the one on top.

What I think does a superb job at conveying what's in each workspace is the
window picker. It shows windows whole and at a good size, so that you can
recognize them instantly. The only problem with it is that it's difficult to
switch to each space, but that's also partially due to the way the workspace
preview works: you have to open Activities, then move all the way to the
right to bring up the WS thumbnails, then look at the tiny thumbnails and
guess which workspace you're looking for, click it to open its overlay and
then click it again (or the desired window) to close Activities.

I think all of it would be much handier if the workspaces were integrated
into the sidebar and you could do one of these:

   - using the mouse, click Activities, go down to the sidebar and push the
   cursor against the left edge to widen the sidebar. Then hover over each
   workspace to switch to it and see its windows, without having to click. When
   you see the workspace you want, select the desired window either by clicking
   its icon or by clicking the window itself. You get the same effect but only
   clicking once, with less mouse movement, and the window overlay represents
   what's in each workspace much better than a thumbnail could ever do.
   - Using the keyboard, press Super, which should highlight the sidebar
   (more specifically, the active window in the active workspace). From there,
   press left to widen the sidebar (enter the sidebar's "workspace mode") and
   press up / down to switch to another workspace. Or press right to open each
   icon's right-click menu. Admittedly that wouldn't be as handy as using the
   mouse, but it would still let you switch workspaces, apps and windows much
   more easily than having two separate sidebars.

Please give it a minute and try to imagine how that would operate. Wouldn't
you like that?
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: 'gnome-suites-core-3.0' - jhbuild:Error during phase configure of gtk+:

[Sriram Ramkrishna]

On Thu, Mar 10, 2011 at 5:49 PM, Robert Park  wrote:

> I was having a similar problem with a different package.
>
> On Wed, Mar 9, 2011 at 2:44 PM, Andrew Swartz  wrote:
> >checking for GLIB - version >= 2.27.3...
> >*** 'pkg-config --modversion glib-2.0' returned 2.28.3, but GLIB
> (2.29.2)
> >*** was found! If pkg-config was correct, then it is best
> >*** to remove the old version of GLib.
>
> This is the key part of the error message here. Something changed in
> glib and you now have two versions installed, but autotools (or
> whatever) is a little bit confused by the two different versions.
>
> I'm not entirely sure how to remove just glib, so i just turfed my
> entire jhbuild prefix (/opt/gnome) and started over. After that
> everything compiled and installed fine.
>
> Hope this helps!
>
> That's what I did as well.  Worked for me.

sri
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Shutdown and restart

[Allan E. Registos]

*even without reading the design articles, i really think that there are 
things in gnome shell that should go away, like the minimize and 
maximize controls and even the close control because of the whole 
design.  yes, even if our words here will not go through the design 
team, it is still a good thing to talk, as it will relieve the stress of 
testing gnome shell lately.
hiding things that were really needed much by folks outside i believe is 
not really helpful. a minor design issue can be a show stopper to some 
people.  most people here are windows users, and i just want them to use 
linux and gnome with ubuntu* as what i am doing for some workstations. 
ubuntu may provide the shell package in the future, and we have to 
decide of which 'interface' we will be using = unity or the official 
gnome shell, the choice is not according to my feelings, but according 
to the user feedback. i have high hopes for gnome shell, and i hope for 
the major release they will fix the icons in the dash because that will 
be a big issue for me, not necessarily the shutdown/restart hiding since 
that can be easily hacked.


* i can't uppercase, one of my vmware guest suddenly closed by itself.
* we will be using lts 12.04

On Friday, 11 March, 2011 12:02 PM, Justin Edwards wrote:
Hiding things like this will make people think twice about giving 
gnome-shell a try.  If you can't perform simple tasks using obvious 
methods, then the UI is not doing it's job.   I like gnome-shell, but 
I know how people are.


It might not do any good saying anything at this point, but it's such 
a simple thing.



Justin Edwards
Telelanguage Inc


For support, please call 1.888.983.5352 and press 3


On Thu, Mar 10, 2011 at 8:38 PM, Allan E. Registos 
> wrote:




On Thursday, 10 March, 2011 01:36 PM, Sriram Ramkrishna wrote:

The thing is, UI freeze has already passed.  We can't really
make any changes to the UI at this time.  So while we can talk
about it we can't make any change prior to release.

Yes, as I am aware of it. Wanna prove a point further. :)

The change isn't too bad I think.  If we document that we need
to do "press alt" as part of the change then that might work.

It may or might not work for end users(these beings will never
read manuals until being forced to do so). Documentation will
always work for IT people of all sorts because that is part of
what we do.

 Also, distros might decide that they need to add the shutdown
option and might do that on their own.

Yes, its a good thing, being this is a minor design issue, the
design team could go on hiding those buttons.

 But I don't think continuing to talk about it here is going
to contribute to any significant changes prior to release
given our deadlines.

sri


-- 
There must be a computer language that is 100% visual, but runs at

the speed of the C language.

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org 
http://mail.gnome.org/mailman/listinfo/gnome-shell-list




--
There must be a computer language that is 100% visual, but runs at the speed of 
the C language.

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Shutdown and restart

[Allan E. Registos]

On Thursday, 10 March, 2011 01:36 PM, Sriram Ramkrishna wrote:
The thing is, UI freeze has already passed.  We can't really make any 
changes to the UI at this time.  So while we can talk about it we 
can't make any change prior to release.

Yes, as I am aware of it. Wanna prove a point further. :)
The change isn't too bad I think.  If we document that we need to do 
"press alt" as part of the change then that might work.
It may or might not work for end users(these beings will never read 
manuals until being forced to do so). Documentation will always work for 
IT people of all sorts because that is part of what we do.
 Also, distros might decide that they need to add the shutdown option 
and might do that on their own.
Yes, its a good thing, being this is a minor design issue, the design 
team could go on hiding those buttons.
 But I don't think continuing to talk about it here is going to 
contribute to any significant changes prior to release given our 
deadlines.


sri



--
There must be a computer language that is 100% visual, but runs at the speed of 
the C language.

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: 'gnome-suites-core-3.0' - jhbuild:Error during phase configure of gtk+:

[Robert Park]

I was having a similar problem with a different package.

On Wed, Mar 9, 2011 at 2:44 PM, Andrew Swartz  wrote:
>    checking for GLIB - version >= 2.27.3...
>    *** 'pkg-config --modversion glib-2.0' returned 2.28.3, but GLIB (2.29.2)
>    *** was found! If pkg-config was correct, then it is best
>    *** to remove the old version of GLib.

This is the key part of the error message here. Something changed in
glib and you now have two versions installed, but autotools (or
whatever) is a little bit confused by the two different versions.

I'm not entirely sure how to remove just glib, so i just turfed my
entire jhbuild prefix (/opt/gnome) and started over. After that
everything compiled and installed fine.

Hope this helps!

-- 
http://exolucere.ca
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Two proposals for Gnome-shell

[Allan E. Registos]

On Friday, 11 March, 2011 01:28 AM, Jesse Hutton wrote:
True, I guess I ignored the fact that running applications aren't 
shown twice between the favorites and the workspace containers in your 
mock-ups.


I can't test the shell, does the current GNOME Shell version will still 
show two icons in the dash when the application has two instances 
running? My last test is that it will show(running two VMware guests), 
and I think it is not good because, the icons in the dash are too small 
when we have many applications running.


As of version 2.91.91, I've seen this:

 * Scale icons rather than using small icons in the overview and

Alt-Tab [Florian]

Does this changed has anything to do also with the dash's icons? Can 
anyone elaborate of this changed?


--
There must be a computer language that is 100% visual, but runs at the speed of 
the C language.

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: gtk2 theme

[Luke Morton]

On Thu, 2011-03-10 at 01:43 +0100, Stefano Facchini wrote:
> Hi,
> is it possible to use a theme also for the gtk2 applications? 

Yes.

> with the 
> new gnome-settings-daemon running the gtk2 apps have the ugly default 
> win95-like theme. I recently updated all the modules which seemed 
> relevant (gnome-settings-daemon, gsettings-desktop-schemas, 
> gnome-desktop-3, gnome-theme, gnome-theme-standard), am I forgetting 
> something?

I think the current recommended way to try GNOME Shell is using a live
CD/USB drive: http://gnome3.org/tryit.html

If you're trying to upgrade GNOME then it might help to know what distro
you're running.

If you're trying to build it yourself I believe jhbuild should take care
of everything for you but I haven't used it myself.

Luke.

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: gtk2 theme

[Stefano Facchini]

On 10/03/2011 13:05, Mystilleef wrote:

On Wed, Mar 9, 2011 at 7:43 PM, Stefano Facchini
  wrote:

Hi,
is it possible to use a theme also for the gtk2 applications? with the new
gnome-settings-daemon running the gtk2 apps have the ugly default win95-like
theme. I recently updated all the modules which seemed relevant
(gnome-settings-daemon, gsettings-desktop-schemas, gnome-desktop-3,
gnome-theme, gnome-theme-standard), am I forgetting something?

thanks


This may or may not work for you. But I had to change the
metacity theme in Gconf to "Adwaita" for GNOME shell to use
the new gtk3 theme on my system.
I tried to change /apps/metacity/general/theme to "Adwaita" but didn't 
work :-(

You might also want to take
a look at the new tweak tool Jon Stowers is working on.
Search the mailing list for it. It helped me adjust fonts and I think
you can also change themes with it.
I'd like to try this but it requires pygobject, which I can't compile 
because at configuration stage it complains about a conflict regarding 
glib version:


checking for GLIB - version >= 2.24.0...
*** 'pkg-config --modversion glib-2.0' returned 2.28.3, but GLIB (2.29.0)
*** was found!
error


Stefano
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: No minimise/maximise (again)

[Sriram Ramkrishna]

On Thu, Mar 10, 2011 at 6:36 AM, Jesse Hutton wrote:

> Right-click -> minimize. Done. I'm sure you'll be able to bind a key
> combination for ultra fast minimizing, too (even faster than shooting for
> that minimize button with your mouse pointer).
>
>
> For me it is IRC, I don't want to be caught talking with you guys.  bad
mojo.

sri
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: telepathy-glib git repo changed?

[Jasper St. Pierre]

Was already updated:

http://git.gnome.org/browse/gnome-shell/commit/?id=edabafc0fcb49315fda8e792faa50d8dac890742

But jhbuild isn't smart enough to update the repo remote for you, you have to:

 git remote set-url origin
git://anongit.freedesktop.org/telepathy/telepathy-glib

On Tue, Mar 8, 2011 at 3:32 PM, Cliff Resnick  wrote:
> Jhbuild failed for me because it could not clone from the repo configured in
> gnome-shell.modules:
>
> I searched and found:
>
> http://blogs.gnome.org/danni/2011/02/26/telepathy-git-repositories-move-to-freedesktop-org/
>
> Looks like the collabora repo is now decommissioned?
>
> Anyway, as a temporary work-around I downloaded and reconfigured
> gnome-shell.modules with the freedesktop repo and build successfully with
> that.
>
> -Cliff
> ___
> gnome-shell-list mailing list
> gnome-shell-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

telepathy-glib git repo changed?

[Cliff Resnick]

Jhbuild failed for me because it could not clone from the repo 
configured in gnome-shell.modules:


I searched and found:

http://blogs.gnome.org/danni/2011/02/26/telepathy-git-repositories-move-to-freedesktop-org/

Looks like the collabora repo is now decommissioned?

Anyway, as a temporary work-around I downloaded and reconfigured 
gnome-shell.modules with the freedesktop repo and build successfully 
with that.


-Cliff
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Two proposals for Gnome-shell

[Jesse Hutton]

True, I guess I ignored the fact that running applications aren't shown
twice between the favorites and the workspace containers in your mock-ups.
And, if an one is only shown in the most recently accessed workspace, that
would prevent the scaling issue*. However, doesn't that behavior pose a
problem if the goal is to show what's in each workspace?

My personal feeling is that there's no easy solution for showing what's in
different workspaces in a quick and efficient way. The current solution,
while it certainly isn't perfect, makes the most sense to me, and the large
thumbnails actually do help me in this case more than icons, because the
configuration of windows tells me something about what is running there (I
usually layout different windows differently, in specific patterns, etc). I
agree that showing icons would make it quicker and easier to find a given
app. But, the proposed solution is less visually appealing to me and can
hide more information in the case of the same app running in different
spaces (also doesn't show the visual layout/structure of the space).

Jesse

* Disclaimer: not being able to use GNOME Shell yet, I could be making
faulty assumptions about the dash's behavior.

On Thu, Mar 10, 2011 at 10:20 AM, David Prieto wrote:

> Jesse,
>
> I think it's a problem of scaling and an aesthetic judgement. Showing the
>> icons in all workspaces won't scale well with many apps and many
>> workspaces. What if somebody had 7 favorites on the dash and apps open on 4
>> different workspaces, for example? How would there be room for workspace
>> widgets?
>
>
> That's a good question. There would NEVER be more icons than we have now.
> If that person had seven favourites, they would only appear at the top as
> long as they were not running. If one of them was running, it would appear
> ONLY in the corresponding workspace (so there would only be six at the top).
> If another was running on more than one workspace, it would appear ONLY in
> the most recent workspace.
>
> As for room for workspace widgets, I'm not sure what you mean by that. The
> boxes themselves wouldn't take any vertical space (I did the mockups based
> on an actual dash, and didn't have to alter separation between the icons)
> and the extra horizontal space would only appear on demand.
>
>
>> And, to me, it looks cluttered and less elegant than the current solution
>> even in the mock-ups you posted.
>>
>
> It looks definitely cleaner to me, but I guess it's a matter of taste. I'd
> like to know what the rest of you guys think, does it look more cluttered?
>
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Two proposals for Gnome-shell

[David Prieto]

Hey Florian,

I was referring to the case where you have e.g. both a favorite and a
> non-favorite running on the first workspace, and another favorite
> running on the second workspace - you'll end up with the non-favorite
> mixed up with the running favorites.
>

 Let's suppose you have:

   - Totem (favourite).
   - Banshee (non-favourite).
   - Nautilus (favourite).

Let's suppose Totem and Nautilus are running on the first WS, and Nautilus
is open on the second. The dash would have:

   - zero icons at the favourites area.
   - Totem, Banshee at the WS1 area.
   - Nautilus at the WS2 area.

Is that what you mean? That Totem and Banshee would appear together, even
though Totem is a favourite and Banshee isn't?

If so, would that be different from the current situation? I fail to see how
that would be a problem :-?
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Two proposals for Gnome-shell

[Florian Müllner]

On Thu, 2011-03-10 at 16:02 +0100, David Prieto wrote:
> I may not have myself clear there: the top part would show only
> non-running favourites, and the workspace would show any type of
> running app (either favourite or non-favourite). Therefore,
> non-running favourites would never mix. They would always be apart.

Seems like I have not been that clear myself :)

I was referring to the case where you have e.g. both a favorite and a
non-favorite running on the first workspace, and another favorite
running on the second workspace - you'll end up with the non-favorite
mixed up with the running favorites.

Florian


___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Two proposals for Gnome-shell

[David Prieto]

Jesse,

I think it's a problem of scaling and an aesthetic judgement. Showing the
> icons in all workspaces won't scale well with many apps and many
> workspaces. What if somebody had 7 favorites on the dash and apps open on 4
> different workspaces, for example? How would there be room for workspace
> widgets?


That's a good question. There would NEVER be more icons than we have now. If
that person had seven favourites, they would only appear at the top as long
as they were not running. If one of them was running, it would appear ONLY
in the corresponding workspace (so there would only be six at the top). If
another was running on more than one workspace, it would appear ONLY in the
most recent workspace.

As for room for workspace widgets, I'm not sure what you mean by that. The
boxes themselves wouldn't take any vertical space (I did the mockups based
on an actual dash, and didn't have to alter separation between the icons)
and the extra horizontal space would only appear on demand.


> And, to me, it looks cluttered and less elegant than the current solution
> even in the mock-ups you posted.
>

It looks definitely cleaner to me, but I guess it's a matter of taste. I'd
like to know what the rest of you guys think, does it look more cluttered?
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Two proposals for Gnome-shell

[David Prieto]

Hi Florian, thanks for your anser,

Not entirely correct - the workspace separation of both icons and
> thumbnails only covers "on the current workspace" / "on another
> workspace".
>

True, I have to give you that.


> I can only guess, but I'd say that one major point is to make the dash
> more stable - the alt-tab switcher is at least stable during each
> invocation (there may be a workspace switch when leaving the switcher,
> but never while it's up), but applying the same logic in the dash would
> not only mean that the icon order changes between overview invocations,
> but also while the overview is up.
>

You also have a point there. Applications with windows on several workspaces
would have to change place every time a different workspace were selected.


> In my opinion there would also be some issues with the dash displaying
> not only running applications, but favorites as well - favorites being
> listed first in a user specified order, followed by non-favorite running
> apps. Bringing workspaces in would necessarily require mixing favorites
> and running apps (and breaking the order defined by the user).
>

I may not have myself clear there: the top part would show only non-running
favourites, and the workspace would show any type of running app (either
favourite or non-favourite). Therefore, non-running favourites would never
mix. They would always be apart.


> Adding thumbnails to running applications would double the functionality
> of the window picker (which should be the primary mean of selecting a
> specific window in the overview) - using the right-click menu to select
> a window gives another selection method, in case the previews are not
> distinct enough to pick the right one.
>

Two things I'd like to say about that:

First, it would "kinda" double the picker's functionality. You use the
picker to select any window from a given workspace, regardless of its app.
You would use the dash to select any window from a given app, regardless of
its workspace. That's two different usercases: in the first you're looking
for a window you have more or less in front of you, in the second you're
looking for a Firefox window but you don't quite remember where you put it.

Second, I don't think the thumbnails should appear right away. I think
having them appear on right-click (or maybe pressing right if you're using
the keyboard) should be enough. So, basically the same we have now, only
showing previews instead of a list.

You brought very good points to the table, thanks a lot :-)
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: No minimise/maximise (again)

[Jesse Hutton]

Right-click -> minimize. Done. I'm sure you'll be able to bind a key
combination for ultra fast minimizing, too (even faster than shooting for
that minimize button with your mouse pointer).

Jesse

On Thu, Mar 10, 2011 at 9:00 AM,  wrote:

> I know this has been discussed to death... but I'm going to say it anyways
>
> I can understand removing the maximise button because you can just drag the
> window up to maximise it. But the Minimise
> button is a very useful feature and should not be removed for 2 reasons
>
>
> 1) Quite often when your working with open windows, you want to make the
> current window disappear "without closing the program" to quickly go back to
> your Desktop. You assume
> that people will want to switch to another application all the time by
> using "alt tab" But you cannot switch back to your Desktop with alt tab. The
> only way you can really go about it now is
> too Zoom out, point to an empty workspace and click into it. This is 3
> steps to switch to your Desktop over 1 click of the minimise button. Very
> Very Annoying
>
>
> 2) Don't you guys surf the net for porn C'mo. Do you know how
> hard it is now to hide a webpage quickly when somebody walks into the
> room Don't deny it. You guys watch porn too ;)
> now you ruined everything. haha :)
> ___
> gnome-shell-list mailing list
> gnome-shell-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
>
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: No minimise/maximise (again)

[William Jon McCann]

Hey,

On Thu, Mar 10, 2011 at 9:37 AM, Florian Müllner  wrote:
> On Thu, 2011-03-10 at 14:00 +, kaddy...@gmail.com wrote:
>> 2) Don't you guys surf the net for porn C'mo. Do you know
>> how hard it is now to hide a webpage quickly when somebody walks into
>> the room Don't deny it. You guys watch porn too ;)
>> now you ruined everything. haha :)
>
> Uhm - so basically you post to a public mailing list that you'd like to
> keep your porn-browsing habits private?

Well at least he or she didn't describe the type of porn.

Sounds like a good case for a porn workspace.  When someone walks up
behind you at work, zip it up and switch workspaces.  Another option
is to use the keyboard shortcuts if that's where your hands are
(doubtful).  You may even want to configure a special keybinding if
getting caught in the act is a common part of your workflow.
Otherwise you can use the overview to switch away.   Your porn-space
is mostly hidden off the right side of the screen in the overview.

But let's try to use work-safe examples here in the future please.

Best of luck,
Jon
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: No minimise/maximise (again)

[Florian Müllner]

On Thu, 2011-03-10 at 14:00 +, kaddy...@gmail.com wrote:
> 2) Don't you guys surf the net for porn C'mo. Do you know
> how hard it is now to hide a webpage quickly when somebody walks into
> the room Don't deny it. You guys watch porn too ;)
> now you ruined everything. haha :)

Uhm - so basically you post to a public mailing list that you'd like to
keep your porn-browsing habits private?

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Two proposals for Gnome-shell

[Jesse Hutton]

David,

I think it's a problem of scaling and an aesthetic judgement. Showing the
icons in all workspaces won't scale well with many apps and many
workspaces. What if somebody had 7 favorites on the dash and apps open on 4
different workspaces, for example? How would there be room for workspace
widgets? And, to me, it looks cluttered and less elegant than the current
solution even in the mock-ups you posted.

Jesse

On Thu, Mar 10, 2011 at 7:51 AM, David Prieto wrote:

> So, considering that the Switcher has two rows or layers:
>
>- An top layer that shows open applications, using their icons to
>represent them, and separating them according to the workspace they're in.
>- A bottom layer for multi-window apps, that represents the different
>windows belonging to the same application by means of a thumbnail.
>
> And considering that the Dash only has one layer, using icons to represent
> applications; but it doesn't separate them according to workspace, and
> doesn't show thumbnails to represent each app's open windows.
>
> I have to wonder: where's the difference? Why does this logic, which seems
> valid for the Switcher, not apply to the Dash? If you think about it, that's
> basically what I was proposing in my first mail.
>
> ___
> gnome-shell-list mailing list
> gnome-shell-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
>
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Two proposals for Gnome-shell

[Florian Müllner]

Hey.

Disclaimer: I'm a developer, not a designer - so my reply should in no
way be considered authorative on the matter :)

On Thu, 2011-03-10 at 13:51 +0100, David Prieto wrote:
> So, considering that the Switcher has two rows or layers:
>   * An top layer that shows open applications, using their icons
> to represent them, and separating them according to the
> workspace they're in.

Not entirely correct - the workspace separation of both icons and
thumbnails only covers "on the current workspace" / "on another
workspace".


> And considering that the Dash only has one layer, using icons to
> represent applications; but it doesn't separate them according to
> workspace, and doesn't show thumbnails to represent each app's open
> windows.

I can only guess, but I'd say that one major point is to make the dash
more stable - the alt-tab switcher is at least stable during each
invocation (there may be a workspace switch when leaving the switcher,
but never while it's up), but applying the same logic in the dash would
not only mean that the icon order changes between overview invocations,
but also while the overview is up.

In my opinion there would also be some issues with the dash displaying
not only running applications, but favorites as well - favorites being
listed first in a user specified order, followed by non-favorite running
apps. Bringing workspaces in would necessarily require mixing favorites
and running apps (and breaking the order defined by the user).

Adding thumbnails to running applications would double the functionality
of the window picker (which should be the primary mean of selecting a
specific window in the overview) - using the right-click menu to select
a window gives another selection method, in case the previews are not
distinct enough to pick the right one.

I'm not saying that your suggestions should not be considered, just that
I think that it's a lot less straightforward than you make it sound.


> I have to wonder: where's the difference? Why does this logic, which
> seems valid for the Switcher, not apply to the Dash? If you think
> about it, that's basically what I was proposing in my first mail.

Both are application based, but they are not the same (if they were, one
of them would not be needed and could be removed).

Florian

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: No minimise/maximise (again)

[David Prieto]

About both points:

1) Quite often when your working with open windows, you want to make the
> current window disappear "without closing the program" to quickly go back to
> your Desktop. You assume
> that people will want to switch to another application all the time by
> using "alt tab" But you cannot switch back to your Desktop with alt tab. The
> only way you can really go about it now is too Zoom out, point to an empty
> workspace and click into it. This is 3 steps to switch to your Desktop over
> 1 click of the minimise button. Very Very Annoying
>

For what it's worth, I think the desktop is going to lose all purpose on
Gnome3, except for showing a pretty picture. No more folders on it, no
launchers... so I guess reaching the desktop quickly won't be much of a
priority.

2) Don't you guys surf the net for porn C'mo. Do you know how
> hard it is now to hide a webpage quickly when somebody walks into the
> room Don't deny it. You guys watch porn too ;)
>

I don't remember having ever done that, but a
friendasked me to tell you
guys to let him "tag" specific folders so that their
files won't show thumbnails in the history or search results, since you
brought that up.
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

No minimise/maximise (again)

[kaddy080]

I know this has been discussed to death... but I'm going to say it anyways

I can understand removing the maximise button because you can just drag the  
window up to maximise it. But the Minimise

button is a very useful feature and should not be removed for 2 reasons


1) Quite often when your working with open windows, you want to make the  
current window disappear "without closing the program" to quickly go back  
to your Desktop. You assume
that people will want to switch to another application all the time by  
using "alt tab" But you cannot switch back to your Desktop with alt tab.  
The only way you can really go about it now is
too Zoom out, point to an empty workspace and click into it. This is 3  
steps to switch to your Desktop over 1 click of the minimise button. Very  
Very Annoying



2) Don't you guys surf the net for porn C'mo. Do you know how  
hard it is now to hide a webpage quickly when somebody walks into the  
room Don't deny it. You guys watch porn too ;)

now you ruined everything. haha :)
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Two proposals for Gnome-shell

[David Prieto]

So, considering that the Switcher has two rows or layers:

   - An top layer that shows open applications, using their icons to
   represent them, and separating them according to the workspace they're in.
   - A bottom layer for multi-window apps, that represents the different
   windows belonging to the same application by means of a thumbnail.

And considering that the Dash only has one layer, using icons to represent
applications; but it doesn't separate them according to workspace, and
doesn't show thumbnails to represent each app's open windows.

I have to wonder: where's the difference? Why does this logic, which seems
valid for the Switcher, not apply to the Dash? If you think about it, that's
basically what I was proposing in my first mail.
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Two proposals for Gnome-shell

[Florian Müllner]

On Thu, 2011-03-10 at 11:25 +, Rui Tiago Cação Matos wrote:
> >>> There should be a default for switch_group in GNOME Shell
> >>
> >> Alt+KeyAboveTab (e.g. Alt-` for US keyboard layout)
> >
> > This there a way to make that layout independent? I wouldn't want to have to
> > reconfigure loads of hotkeys because I'm using the Neo layout...
> 
> It is.

That is, the "key above tab" part is, not the "alt-`" :)

Florian

___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Two proposals for Gnome-shell

[Rui Tiago Cação Matos]

On 10 March 2011 11:15, Marcel  wrote:
> Am 10.03.2011 07:45, schrieb Florian Müllner:
>>
>> On Wed, 2011-03-09 at 22:20 -0500, Jesse Hutton wrote:
>>>
>>> There should be a default for switch_group in GNOME Shell
>>
>> Alt+KeyAboveTab (e.g. Alt-` for US keyboard layout)
>
> This there a way to make that layout independent? I wouldn't want to have to
> reconfigure loads of hotkeys because I'm using the Neo layout...

It is.

Rui
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Two proposals for Gnome-shell

[Marcel]

Am 10.03.2011 07:45, schrieb Florian Müllner:

On Wed, 2011-03-09 at 22:20 -0500, Jesse Hutton wrote:

There should be a default for switch_group in GNOME Shell


Alt+KeyAboveTab (e.g. Alt-` for US keyboard layout)


This there a way to make that layout independent? I wouldn't want to 
have to reconfigure loads of hotkeys because I'm using the Neo layout...


Marcel
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list