Re: File Search in Overview

[Siegfried-Angel Gevatter Pujals]

2011/2/26 Lucas David-Roesler :
> That is awesome.  I am curious how that behavior will interact with
> something like my OS upgrade process. I keep my hard drive partitioned into
> a small OS portion and a large File portion.  This allows me to do a fresh
> install of the OS if I want to. I tinker enough that I like to get a fresh
> feel every 6 months.    But this also means that I have many files that I
> want to keep track of but are not being created or copied every 6 months.
>  If my guess for how this is going to work, then those files will not make
> it into the DB until I open them.

Zeitgeist's database is at ~/.local/share/zeitgeist. You can keep it
when you reinstall.

-- 
Siegfried-Angel Gevatter Pujals (RainCT)
Free Software Developer       363DEAE3
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Visual cues

[Sriram Ramkrishna]

On Sat, Feb 26, 2011 at 10:02 AM, Bob Hazard
wrote:

> Balloon tips drive me crazy. I would rather have the Activities button
> glow, bloom or pulsate in some enticing way on first run.
>
>
That would be kind of nifty actually.


>  --
> Sent from my Amiga
>
>
I used to own one long ago.  I think I still have it in my closet
somewhere..
sri
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Gnome Shell Build Error - libmozjs.so

[bsquared]

Gnome-shell doesn't build, Error:

(mutter:19746): mutter-WARNING **: Could not load library
[/usr/src/gnome/gnome-shell/src/libgnome-shell.la (libmozjs.so: cannot
open shared object file: No such file or directory)]

Mozilla:

:~$ jhbuild info mozilla
Name: mozilla
Module Set: gnome-suites-core-deps-3.0
Type: autogen
Install date: 2011-02-24 19:48:53
URL: 
http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.9.2.13/source/xulrunner-1.9.2.13.source.tar.bz2
Version: 1.9.2.12
Tree-ID: 1.9.2.12-d41d8cd98f00b204e9800998ecf8427e
Sourcedir: /usr/src/gnome/mozilla-1.9.2.13
Requires: gtk+, nss, nspr, dbus, gconf, cairo, startup-notification, libnotify
Required by: gjs
Before: libproxy

What am I doing wrong?

-- 
Thank you,
-Brian
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: When UI Enhancements go bad...

[Milan Bouchet-Valat]

On sam., 2011-02-26 at 21:11 +0100, Fabian A. Scherschel wrote:
> On Sat, Feb 26, 2011 at 8:32 PM, Gendre Sebastien 
> wrote:
> 
> 
> If I undestand, Eclipse use pop-up windows instead of simple
> shilde windows?
> 




> 
> If it has always worked in every other DE and Gnome Shell breaks it
> now? To say that is the app's problem would be a bit arrogant, don't
> you think?
No, that's a fair question. The Shell radicalknowly changes the behavior
of dialogs, thus it may unveil small issues in apps that weren't
experienced with other window managers because they behave very
similarly in that regard. It's possible that the windows that don't work
with the new design should be set up differently by Eclipse. Of course,
it may also be a problem with the Shell, but you cannot be sure in
advance.

I think some of the Shell's developers are using Eclipse, so they should
be able to debug this problem. Else, you'll have to provide screenshots
and run 'xprop' on the incriminated dialogs so that they have enough
information. Anyway, a bug report is probably a better place for this
kind of thing.

Regards


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

Re: When UI Enhancements go bad...

[Fabian A. Scherschel]

On Sat, Feb 26, 2011 at 8:32 PM, Gendre Sebastien wrote:

>
> If I undestand, Eclipse use pop-up windows instead of simple shilde
> windows?
>

If it has always worked in every other DE and Gnome Shell breaks it now? To
say that is the app's problem would be a bit arrogant, don't you think?

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

Re: gnome-shell-list@gnome.org

[Gendre Sebastien]

Sorry, the correct place of this message is in the subject: Re: The
logic behind remove "Restart" and hide "Power Off" in User menu.


Le samedi 26 février 2011 à 20:37 +0100, Gendre Sebastien a écrit :
> Le samedi 26 février 2011 à 12:27 -0500, William Jon McCann a écrit :
> > This seems to be a very common misconception of how inhibit works.
> > The reason I chose the word inhibit was to differentiate it from
> > "block".  Inhibiting suspend does not block suspend.  An inhibit
> > informs the system proactively of a certain condition.  For example,
> > inhibiting idleness doesn't mean the system won't honor an explicit
> > user request to lock the screen (go idle).  It informs the system that
> > despite other indications of idleness (lack of mouse and keyboard
> > activity), there is something still going on (say, watching a video).
> > This information is used to inform automatic behaviors of the system.
> > So, in this case, the screen won't lock or power off automatically
> > while the inhibiting activity exists.
> > 
> > Inhibiting automatic suspend works in a similar way.  It doesn't block
> > the human initiated request to suspend.  It only informs the system
> > that automatic suspend shouldn't occur for some specific reason.
> > 
> > So, inhibit is closer to inform than mandate.  And we respect humans
> > more than apps.  But the nice thing about apps is they don't have any
> > feelings to hurt (yet).
> 
> Sorry, but I lack the vocabulary in English to have understood: Do you
> say I have true or false?
> 
> > > And the choice to have Suspend but not Power Off in the User menu
> > > encourages them to waste energy.
> > 
> > I'm usually inclined to ignore claims like this that don't provide any
> > supporting evidence.
> 
> Thistsentence is really arrogant. Before becoming a programmer, I worked
> several years in the installation and repair of electronic (TV, Hi-Fi,
> etc) and I have acquired some experience in this field. I stop that
> there is 4 years old but I do not think the mentality of people have
> changed so much in such a bit of time.
> 
> Some people, who use their computer one or two hours per day, abuse to
> standby. But if you hide the option "Power Off", those who make the
> effort to turn off their computers no longer want to do.
> 
> We are not all computer passionate, some people use them one or two
> hours per day or less.
> 
> Regards
> ___
> gnome-shell-list mailing list
> gnome-shell-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list



signature.asc
Description: This is a digitally signed message part
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

gnome-shell-list@gnome.org

[Gendre Sebastien]

Le samedi 26 février 2011 à 12:27 -0500, William Jon McCann a écrit :
> This seems to be a very common misconception of how inhibit works.
> The reason I chose the word inhibit was to differentiate it from
> "block".  Inhibiting suspend does not block suspend.  An inhibit
> informs the system proactively of a certain condition.  For example,
> inhibiting idleness doesn't mean the system won't honor an explicit
> user request to lock the screen (go idle).  It informs the system that
> despite other indications of idleness (lack of mouse and keyboard
> activity), there is something still going on (say, watching a video).
> This information is used to inform automatic behaviors of the system.
> So, in this case, the screen won't lock or power off automatically
> while the inhibiting activity exists.
> 
> Inhibiting automatic suspend works in a similar way.  It doesn't block
> the human initiated request to suspend.  It only informs the system
> that automatic suspend shouldn't occur for some specific reason.
> 
> So, inhibit is closer to inform than mandate.  And we respect humans
> more than apps.  But the nice thing about apps is they don't have any
> feelings to hurt (yet).

Sorry, but I lack the vocabulary in English to have understood: Do you
say I have true or false?

> > And the choice to have Suspend but not Power Off in the User menu
> > encourages them to waste energy.
> 
> I'm usually inclined to ignore claims like this that don't provide any
> supporting evidence.

Thistsentence is really arrogant. Before becoming a programmer, I worked
several years in the installation and repair of electronic (TV, Hi-Fi,
etc) and I have acquired some experience in this field. I stop that
there is 4 years old but I do not think the mentality of people have
changed so much in such a bit of time.

Some people, who use their computer one or two hours per day, abuse to
standby. But if you hide the option "Power Off", those who make the
effort to turn off their computers no longer want to do.

We are not all computer passionate, some people use them one or two
hours per day or less.

Regards


signature.asc
Description: This is a digitally signed message part
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: When UI Enhancements go bad...

[Gendre Sebastien]

Le vendredi 25 février 2011 à 18:49 -0500, Cliff Resnick a écrit :
> I've been using Gnome-Shell for perhaps a year now. For the most part 
> it's been an ideal window manager for me, and I appreciate all the 
> thought and effort that has gone into it.
> 
> However, today, for the first time, I've been forced to "shell-out" in 
> order to perform some work. I use eclipse for java development, and 
> eclipse likes to use transitional pop-up windows as part of its flow, 
> often with one begetting another. These windows are resizable and 
> eclipse remembers their last-use size. Gnome-shell for the past couple 
> of months has pinned these windows as a modal stack. I found this 
> annoying, but workable, that is, until today when I discovered I am no 
> longer "allowed" to resize the top window. Unfortunately the text entry 
> portion of this window was collapsed upon, "sized-out", so I had no 
> choice but to restart my session in an earlier version of shell and 
> finish my work.
> 
> I have to admit I am dismayed at how some of Gnome-shell's more recent 
> enhancements have become more restrictive. I have noticed some of the 
> look-and-feel ideas seem to be borrowed from OS X, the modal pinning 
> almost an aping of same feature on the Mac. As I said, I go along with 
> these because I appreciate the product as a whole, and all the imposed 
> artistic licence that entails, but hey, there are reasons I prefer a 
> Linux GUI environment to Mac, namely among them freedom to do as I please.
> 
> As it stands, I will revert to the Ubuntu 10.10 apt version of 
> Gnome-Shell and check back to see what the future holds.
> 
> Thanks,
> Cliff

If I undestand, Eclipse use pop-up windows instead of simple shilde
windows?

If yes, this is not Eclipse that have a problem?


Regards 

-- 
Gendre Sebastien 


signature.asc
Description: This is a digitally signed message part
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: gnome shell intuitive application removal idea

[Gendre Sebastien]

Le samedi 26 février 2011 à 13:04 +0200, Dave a écrit :
> Hello all.
> 
> When one is viewing applications by type it becomes immediately
> apparent that (in my case) I have a number of unwanted applications
> installed.
> 
> It would be cool if an app icon could be dragged onto an area of the
> desktop for removal/purging.
> A confirmation menu with a "yes/no" dialog could pop up and upon
> providing root password the application could be purged or removed on
> the spot.

You talk about uninstall applications or just remove icon from
Gnome-Shell ?


-- 
Gendre Sebastien 


signature.asc
Description: This is a digitally signed message part
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: File Search in Overview

[Lucas David-Roesler]

Awesome.  I will definitely do that.  Thank you.

~Lucas David-Roesler

On Sat, Feb 26, 2011 at 1:42 PM, Siegfried-Angel Gevatter Pujals <
siegfr...@gevatter.com> wrote
>
>
> Zeitgeist's database is at ~/.local/share/zeitgeist. You can keep it
> when you reinstall.
>
>
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: File Search in Overview

[Florian Müllner]

On Sat, 2011-02-26 at 18:28 +, Patrick Michael Niedzielski wrote:
> File search is a must before the release.  If this patch could be
> reviewed before the feature-freeze (unless that has already happened),
> GNOME Shell would be far better off.

It won't be reviewed before feature-freeze, as we are past UI freeze
already (which means that it won't make it into 3.0, even if reviewed
today). So for now there will only the existing file search based on
GtkRecent(*).

Florian

(*) Due to a change in GTK+ with regard to the handling of recent files,
only files from applications using GTK+-3 or GTK+-2 > 2.24 will show up
in GNOME Shell - neither is shipped with current stable distributions,
but the situation will obviously be different when GNOME 3 is shipped by
distributions

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

Re: The logic behind remove "Restart" and hide "Power Off" in User menu.

[Marcus Husar]

Hi,

I didn't think this way before. Nevertheless your thoughts are
reasonable. I’ll try to adapt my behaviour to use software suspend
more often.

But people still may have a problem with „holding down a modifier key“
to switch between suspend/shutdown modes. It’s fine with me. I (now)
know that I have to hold down the alt key.

How do you want to teach people to hold down a modifier key, when they
can’t find the shutdown menu item in gnome shell? Without help they
perhaps never will discover this possibility. Everybody wants to
shutdown his/her computer sometimes.

The mockups in 
https://live.gnome.org/GnomeShell/Design/Whiteboards/SystemStopRestart
show a menu item called „Install Updates & Restart...". In my language
(German) it is „Installiere Updates und starte [das System] neu..."
(without „das System“ it sounds odd). That’s quite long and won’t fit
in the menu. I even think it is the wrong place. What about a
notification with an okay button?

What If people want/have to restart their computer manually? They have
to click „Power off..." to restart. That’s quide odd. It’s the same in
Gnome 2.xx (Shutdown -> Restart).

A solution like that would be fine:

normal:
Suspend

holding down modifier key:
Restart
Power off

Regards,
Marcus

2011/2/26 William Jon McCann :
> Hi,
>
> On Sat, Feb 26, 2011 at 11:39 AM, Gendre Sebastien  wrote:
>> ...
>> And the choice to have Suspend but not Power Off in the User menu
>> encourages them to waste energy.
>
> I'm usually inclined to ignore claims like this that don't provide any
> supporting evidence.  But since you're probably going to keep on
> saying it anyway...
>
> Encouraging the use of suspend will very likely result in a dramatic
> power savings for many people.  If you only have the options: a)
> continue to run at full power b) stop everything you're doing, save
> all your work, close all your apps, lose all your state, wait for the
> system to power off; you have a problem.  In this case, your selfish
> motivations are in opposition to low power consumption.  That's not
> going to turn out well.  And no amount of preaching will change that.
>
> What you need is something that doesn't have to make that trade.
> Maybe something that doesn't force me to abruptly and jarringly
> interrupt my activities and efficiently uses power at the same time.
> Do we have such a thing?
>
> It is also worth pointing out that you can't really measure waste in
> absolute terms anyway.  Waste is subjective: it means to use
> carelessly or without value.  I think it is pretty clear that, for
> many, there is value in suspending instead of stopping activities.
> So, we're spending a tiny tiny bit of energy here in the suspend case
> in order that we may save a tremendous amount of energy in others.
> That isn't waste - that is investment.
>
> We'll achieve even more impressive power savings when we enable
> suspend on system idleness.  Which for portable systems will result in
> much improved battery run times.  There's that win-win again.
>
> Jon
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: File Search in Overview

[Lucas David-Roesler]

On Sat, Feb 26, 2011 at 1:20 PM, Seif Lotfy  wrote:

> Zeitgeist will soon be able to log when a file has been created or copied
> around allowing you to find files that you have not yet interacted with
>
>
That is awesome.  I am curious how that behavior will interact with
something like my OS upgrade process. I keep my hard drive partitioned into
a small OS portion and a large File portion.  This allows me to do a fresh
install of the OS if I want to. I tinker enough that I like to get a fresh
feel every 6 months.But this also means that I have many files that I
want to keep track of but are not being created or copied every 6 months.
 If my guess for how this is going to work, then those files will not make
it into the DB until I open them.

~Lucas David-Roesler
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: File Search in Overview

[Jasper St. Pierre]

I've been the ones reviewing the patches. I've pretty much told them
to go to the designers to push to get this approved. At this point,
we're past UI freeze for gnome-shell, so I don't think we'll be seeing
this in 3.0 as well.

The dashboard isn't on that ticket, I believe that's somewhere else.

On Sat, Feb 26, 2011 at 1:28 PM, Patrick Michael Niedzielski
 wrote:
> On sab, 2011-02-26 at 19:20 +0100, Seif Lotfy wrote:
>> Zeitgeist will soon be able to log when a file has been created or copied
>> around allowing you to find files that you have not yet interacted with
>
> Speaking of Zeitgeist, how is the integration going?  On this bug report
> [1], only one of the proposed patches has been reviewed, and the last
> activity was over two weeks ago.
>
> File search is a must before the release.  If this patch could be
> reviewed before the feature-freeze (unless that has already happened),
> GNOME Shell would be far better off.
>
> That, or Zeitgeist could be an extension to the shell, and not part of
> it.  Either way, the shell needs something like this.
>
> Cheers,
> Patrick Niedzielski
>
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=640659
>
> --
> Humm and Strumm , a Free Software 3D
> adventure game for both Windows and *NIX.
>
> freeSoftwareHacker(); , a blog
> about Free Software, music, and law.
>
> ___
> 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: File Search in Overview

[Seif Lotfy]

We took some time off after the hackfest. Starting Monday we will continue
the integration work.

On Sat, Feb 26, 2011 at 7:28 PM, Patrick Michael Niedzielski <
patrickniedziel...@gmail.com> wrote:

> On sab, 2011-02-26 at 19:20 +0100, Seif Lotfy wrote:
> > Zeitgeist will soon be able to log when a file has been created or copied
> > around allowing you to find files that you have not yet interacted with
>
> Speaking of Zeitgeist, how is the integration going?  On this bug report
> [1], only one of the proposed patches has been reviewed, and the last
> activity was over two weeks ago.
>
> File search is a must before the release.  If this patch could be
> reviewed before the feature-freeze (unless that has already happened),
> GNOME Shell would be far better off.
>
> That, or Zeitgeist could be an extension to the shell, and not part of
> it.  Either way, the shell needs something like this.
>
> Cheers,
> Patrick Niedzielski
>
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=640659
>
> --
> Humm and Strumm , a Free Software 3D
> adventure game for both Windows and *NIX.
>
> freeSoftwareHacker(); , a blog
> about Free Software, music, and law.
>
>


-- 
This is me doing some advertisement for my blog http://seilo.geekyogre.com
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: File Search in Overview

[Patrick Michael Niedzielski]

On sab, 2011-02-26 at 19:20 +0100, Seif Lotfy wrote:
> Zeitgeist will soon be able to log when a file has been created or copied
> around allowing you to find files that you have not yet interacted with

Speaking of Zeitgeist, how is the integration going?  On this bug report
[1], only one of the proposed patches has been reviewed, and the last
activity was over two weeks ago.

File search is a must before the release.  If this patch could be
reviewed before the feature-freeze (unless that has already happened),
GNOME Shell would be far better off.

That, or Zeitgeist could be an extension to the shell, and not part of
it.  Either way, the shell needs something like this.

Cheers,
Patrick Niedzielski

[1] https://bugzilla.gnome.org/show_bug.cgi?id=640659

-- 
Humm and Strumm , a Free Software 3D
adventure game for both Windows and *NIX.

freeSoftwareHacker(); , a blog
about Free Software, music, and law.

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

gnome shell intuitive application removal idea

[Dave]

Hello all.

When one is viewing applications by type it becomes immediately
apparent that (in my case) I have a number of unwanted applications
installed.

It would be cool if an app icon could be dragged onto an area of the
desktop for removal/purging.
A confirmation menu with a "yes/no" dialog could pop up and upon
providing root password the application could be purged or removed on
the spot.

Hope I'm not wasting anyone's time with this idea.

All the best and thank you - I'm loving gnome-shell.

Dave Jones
-- 
http://www.empirecafe.co.za
http://www.google.com/profiles/squilla.dave
http://twitter.com/Muizenberg
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Missing the Gnome-shell experience

[Onyeibo Oku]

On Sat, 2011-02-26 at 05:42 +0100, Onyeibo Oku wrote:
> On Tue, 2011-02-15 at 16:50 +0800, Yu Chen wrote:
> > 
> > 
> > 2011/2/15 
> > Its been about a week or more since I ran Gnome-shell. The
> > reason being that I cannot get it to compile along with the
> > rest of gnome3. Please, does anyone know how to get all of
> > gnome3 and gnome-shell to compile with Jhbuild?
> > 
> > 
> > http://library.gnome.org/devel/jhbuild/2.32/jhbuild-and-gnome.html.en
> > 
> > 
> > -- 
> > Yu
> > 
> Gave this compilation another try.
> Result:
> 
> 
> make[3]: Entering directory
> `/home/t2hot/Source/gnome-world-3.0/source/gtk-doc/tests/gobject/src'
>   CC gobject.lo
> gobject.c:49:18: fatal error: glib.h: No such file or directory
> compilation terminated.
> 
> 
> I don't get it.  This is a fresh jhbuild!
> 
> 

*$ jhbuild sanitycheck*
says automake-1.8 and 1.9 is missing.

I have done a *jhbuild bootstrap --ignore-system*
automake for those versions where built.  Yet a sanity check still lists
them as missing.  Could this be contributing to the build problem? 

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

When UI Enhancements go bad...

[Cliff Resnick]

I've been using Gnome-Shell for perhaps a year now. For the most part 
it's been an ideal window manager for me, and I appreciate all the 
thought and effort that has gone into it.


However, today, for the first time, I've been forced to "shell-out" in 
order to perform some work. I use eclipse for java development, and 
eclipse likes to use transitional pop-up windows as part of its flow, 
often with one begetting another. These windows are resizable and 
eclipse remembers their last-use size. Gnome-shell for the past couple 
of months has pinned these windows as a modal stack. I found this 
annoying, but workable, that is, until today when I discovered I am no 
longer "allowed" to resize the top window. Unfortunately the text entry 
portion of this window was collapsed upon, "sized-out", so I had no 
choice but to restart my session in an earlier version of shell and 
finish my work.


I have to admit I am dismayed at how some of Gnome-shell's more recent 
enhancements have become more restrictive. I have noticed some of the 
look-and-feel ideas seem to be borrowed from OS X, the modal pinning 
almost an aping of same feature on the Mac. As I said, I go along with 
these because I appreciate the product as a whole, and all the imposed 
artistic licence that entails, but hey, there are reasons I prefer a 
Linux GUI environment to Mac, namely among them freedom to do as I please.


As it stands, I will revert to the Ubuntu 10.10 apt version of 
Gnome-Shell and check back to see what the future holds.


Thanks,
Cliff

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

Re: File Search in Overview

[Seif Lotfy]

Zeitgeist will soon be able to log when a file has been created or copied
around allowing you to find files that you have not yet interacted with

On Sat, Feb 26, 2011 at 7:18 PM, Lucas David-Roesler <
roesler.lu...@gmail.com> wrote:

> Does anyone know if file searching will eventually be implemented from the
> overview?  I know that there has been some development to add a zeitgeist
> search, but it does not really seem to be doing anything at the moment.
> Also, zeitgeist and a general file search are slightly different things
> because I have to interact with a file first before it gets into the
> zeitgeist DB.  Right now actually getting to my files is the slowest
> activity in Gnome-Shell. I am in no way suggesting that a file search should
> replace Nautilus.  I still find Nautilus important, but when I know exactly
> which file I want a search tool like Gnome-Do or Synapse gets me there
> faster.  It seems natural (to me) to have this in the overview.  I would
> personally prefer a full-text search tool like tracker be integrated because
> I am a research mathematician and have tons of articles to sort through, but
> I would definitely settle for a simple file name search.
>
> ~Lucas David-Roesler
>
> ___
> gnome-shell-list mailing list
> gnome-shell-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
>


-- 
This is me doing some advertisement for my blog http://seilo.geekyogre.com
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

File Search in Overview

[Lucas David-Roesler]

Does anyone know if file searching will eventually be implemented from the
overview?  I know that there has been some development to add a zeitgeist
search, but it does not really seem to be doing anything at the moment.
Also, zeitgeist and a general file search are slightly different things
because I have to interact with a file first before it gets into the
zeitgeist DB.  Right now actually getting to my files is the slowest
activity in Gnome-Shell. I am in no way suggesting that a file search should
replace Nautilus.  I still find Nautilus important, but when I know exactly
which file I want a search tool like Gnome-Do or Synapse gets me there
faster.  It seems natural (to me) to have this in the overview.  I would
personally prefer a full-text search tool like tracker be integrated because
I am a research mathematician and have tons of articles to sort through, but
I would definitely settle for a simple file name search.

~Lucas David-Roesler
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Visual cues

[Bob Hazard]

Balloon tips drive me crazy. I would rather have the Activities button
glow, bloom or pulsate in some enticing way on first run.

-- 
Sent from my Amiga
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: The logic behind remove "Restart" and hide "Power Off" in User menu.

[Milan Bouchet-Valat]

Le samedi 26 février 2011 à 12:27 -0500, William Jon McCann a écrit :
> It is also worth pointing out that you can't really measure waste in
> absolute terms anyway.  Waste is subjective: it means to use
> carelessly or without value.  I think it is pretty clear that, for
> many, there is value in suspending instead of stopping activities.
> So, we're spending a tiny tiny bit of energy here in the suspend case
> in order that we may save a tremendous amount of energy in others.
> That isn't waste - that is investment.
This reasoning is only true if users care less about power consumption
than about restoring their work. Which in turn supposes :

1) That people will leave their computers on if they can't suspend.
This is yet to be proved, and from a purely environmental point of view,
is determinant. People may as well choose to restore manually their
tasks. This leads us to the second assumption:

2) That people have things to restore
Most of my friends I observe only need to restart e-mail and Web
browser, which is done by session management anyway, and is only one
click away. They close all of their tasks anyway when they're done, even
when they suspend/hibernate (maybe silly, but that's how it is).
Depending on users, suspend may or may not be considered useful.

3) That hibernate doesn't work as well as suspend
Which is of course true in many cases due to hardware, but not always;
often, when hibernate fails, suspend fails too. By hiding this option,
you incite users to use suspend instead of hibernate even when they know
they won't use their computer for the whole night.


> We'll achieve even more impressive power savings when we enable
> suspend on system idleness.  Which for portable systems will result in
> much improved battery run times.  There's that win-win again.
I fully agree, but to me it's absolutely unrelated, if not opposite, to
the decision of hiding the power off/hibernate options. Re-adding just
one item allowing users to run a dialog with those choices doesn't go
against any of your arguments.


You knew this was going to be one of the nicest GNOME 3 flamewars,
didn't you? ;-)


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

Re: The logic behind remove "Restart" and hide "Power Off" in User menu.

[William Jon McCann]

Hi,

On Sat, Feb 26, 2011 at 11:39 AM, Gendre Sebastien  wrote:
> Le samedi 26 février 2011 à 09:02 +0100, Johannes Schmid a écrit :
>> There is absolutely no information about why suspend is the default
>> apart
>> from telling that this is what happens when you close the lid on a
>> laptop.
>> I think you can argue that it might be a reasonable default for
>> laptops
>> but it is not at all a reasonable default for a desktop PC. And this
>> is
>> not discussed at all in the linked page.
>
> About suspend when close the lid, it's juste a change of logic.
>
> Before, you need to change yourself the parameter depending to the
> situation. In some cases, you need to keep the laptop in activity (ex:
> download files) when you close the lid. But in other cases, it's not
> necessary.
>
> Instead of require a constant change of the parameter like before (in
> Gnome 2.XX), Gnome 3 change it automatcaly. So, by default, Gnome 3
> suspend the laptop when you clode the lid and when a software should not
> be stopped it interrupts the proceedings of standby.
>
> This solution has some advantages. Ex: You start a long transcoding of a
> HD video and you want to go sleep. You just close the lid and go to bed.
> The laptop don't go to standby and continue to transcode. When it
> finish, it turn to standby.

This seems to be a very common misconception of how inhibit works.
The reason I chose the word inhibit was to differentiate it from
"block".  Inhibiting suspend does not block suspend.  An inhibit
informs the system proactively of a certain condition.  For example,
inhibiting idleness doesn't mean the system won't honor an explicit
user request to lock the screen (go idle).  It informs the system that
despite other indications of idleness (lack of mouse and keyboard
activity), there is something still going on (say, watching a video).
This information is used to inform automatic behaviors of the system.
So, in this case, the screen won't lock or power off automatically
while the inhibiting activity exists.

Inhibiting automatic suspend works in a similar way.  It doesn't block
the human initiated request to suspend.  It only informs the system
that automatic suspend shouldn't occur for some specific reason.

So, inhibit is closer to inform than mandate.  And we respect humans
more than apps.  But the nice thing about apps is they don't have any
feelings to hurt (yet).

...
> And the choice to have Suspend but not Power Off in the User menu
> encourages them to waste energy.

I'm usually inclined to ignore claims like this that don't provide any
supporting evidence.  But since you're probably going to keep on
saying it anyway...

Encouraging the use of suspend will very likely result in a dramatic
power savings for many people.  If you only have the options: a)
continue to run at full power b) stop everything you're doing, save
all your work, close all your apps, lose all your state, wait for the
system to power off; you have a problem.  In this case, your selfish
motivations are in opposition to low power consumption.  That's not
going to turn out well.  And no amount of preaching will change that.

What you need is something that doesn't have to make that trade.
Maybe something that doesn't force me to abruptly and jarringly
interrupt my activities and efficiently uses power at the same time.
Do we have such a thing?

It is also worth pointing out that you can't really measure waste in
absolute terms anyway.  Waste is subjective: it means to use
carelessly or without value.  I think it is pretty clear that, for
many, there is value in suspending instead of stopping activities.
So, we're spending a tiny tiny bit of energy here in the suspend case
in order that we may save a tremendous amount of energy in others.
That isn't waste - that is investment.

We'll achieve even more impressive power savings when we enable
suspend on system idleness.  Which for portable systems will result in
much improved battery run times.  There's that win-win again.

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

Re: The logic behind remove "Restart" and hide "Power Off" in User menu.

[Gendre Sebastien]

Le samedi 26 février 2011 à 09:02 +0100, Johannes Schmid a écrit :
> There is absolutely no information about why suspend is the default
> apart
> from telling that this is what happens when you close the lid on a
> laptop.
> I think you can argue that it might be a reasonable default for
> laptops
> but it is not at all a reasonable default for a desktop PC. And this
> is
> not discussed at all in the linked page. 

About suspend when close the lid, it's juste a change of logic.

Before, you need to change yourself the parameter depending to the
situation. In some cases, you need to keep the laptop in activity (ex:
download files) when you close the lid. But in other cases, it's not
necessary. 

Instead of require a constant change of the parameter like before (in
Gnome 2.XX), Gnome 3 change it automatcaly. So, by default, Gnome 3
suspend the laptop when you clode the lid and when a software should not
be stopped it interrupts the proceedings of standby. 

This solution has some advantages. Ex: You start a long transcoding of a
HD video and you want to go sleep. You just close the lid and go to bed.
The laptop don't go to standby and continue to transcode. When it
finish, it turn to standby.

Note: I think the Gnome 3 dev and designers team need to explain their
choices in a faq if they don't want to have questions about it in
continue.

And about:
http://live.gnome.org/GnomeShell/Design/Whiteboards/SystemStopRestart

The line "Install update and restart" in the User menu it's a bad idea.
Exemple: in french, you have "Installer les mises à jours et
redémarrer". It's to long. I think it's in better place in messaging
tray. And this message is not true because update are already installed.
The correct message is "Restart for use updates of the system core".

And the choice to have Suspend but not Power Off in the User menu
encourages them to waste energy.

PS: And if we stay logic, all entries about the system are in wrong
place in the User menu and we need a System menu.


Regards.

-- 
Gendre Sebastien 


signature.asc
Description: This is a digitally signed message part
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

Re: Visual cues

[Jeffery Olson]

I'd like the idea of, maybe, having a "balloon menu" widget or
whatever (like when you click on your username and it displays
activity status, lock screen, etc) be displayed below the activities
button saying something like "click Activities to see an overview your
available applications, blah blah etc".

The above idea could be expanded to a generlized concept of having
"tooltips", balloon-messages or whatever (what's the proper term for
those widgets? they're the same ones that appears as tray
notifications, right?) appearing at regular intervals (or after some
period of user inactivity, indicating confusion?) giving some short,
informative cues about key points of UI integration. I guess the
specifics of what this should look like are a design concern.

Another nice visual cue might be to "buttonize" the word 'Activites'
as it appears in the upper-left, as that would be a nice visual cue
for new users to click on it to make something happan . As it stands
right now, it just appears to be a label.. granted OSX users don't
have buttonized menus on their panel-bar, but they also have a
consistent, cross-app experience (the top panel bar changes which each
focused app, cueing the user that there is some experience to be
explored by clicking the words) and not to mention the inertia
supporting that paradigm. In gnome-shell, the word "Activities" is,
basically, bolded and styled in the same way as the focused app's
title, which appears immediately to its right.

Bottom line: all I'm saying is that if a new user isn't familiar with
the gnome-shell UI (watching videos, website, etc), then they don't
have a lot to go on (as Akshay rightly observes above).

Cheers,
Jeff

On Fri, Feb 25, 2011 at 3:12 PM, Akshay Dua  wrote:
>> Yes, I also think we need a Welcome message at the first login for all
>> new users accounts.
>>
>> A welcome message look like:
>>
>> Welcome on Gnome 3.0
>> → See a short presentation video.
>> → See manual.
>> → Begin to Use.
>>
>
> This is a great idea!
>
> -- Akshay
> ___
> 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

Workspace switching, and other UI tweaks

[Elia Cogodi]

I fall broadly into the "power user" cathegory of Gnome 2, and I'm
trying to adapt my workflow to the gnome shell paradigms. I appreciate
the effort into designing something that is clear and immediate for
the mainstream user - efforts that led to what I consider very nice
results - and I know that power tools are expected to appear as
extensions. Still, I think that there's space for some improvements in
an expert user's experience with GS, in ways that don't compromize its
design. A few ideas

1) When I use key navigation to switch workspaces (in my case bound to
ctrl+alt+arrows) I get this abstract, centered grey overlay with
rounded spaces and arrows showing my navigation.
Why exactly, when we have a perfectly good representation of
workspaces and their selection in the overview mode?
Proposal 1: ditch the abstract overlay, have the overview version of
the workspace list show in its usual (right edge) position instead,
with the selection box movement and everything, then slide or fade
away quickly.
Pros:
- if a beginner stumbles upon the key navigation by mistake,
consistency can guide and reassure him ("Uhm, what did just happen? My
windows flew up offscreen, but that thing that appeared on the right
is that thing I don't use in the "Activities" screen, let me go there
and see if I can fix it")
- if a power user wants to use the quick key navigation, the overview
version of the workspace list is much more expressive, showing their
actual content.
Corollary proposal 1.1: have icon overlays of the applications
superimposed over the workspace thumbnails, so that I can quickly find
out at a glance "now, in what workspace did I put the email client?".
Windows are not distinguishable enough at the scale of the workspace
list, and the dynamic nature of the list wreaks havoc to estabilished
patterns based on absolute numbers ("workspace 1 for editor and
browser, workspace 2 for compiler terminals, workspace 3 for email and
messaging...")

Another smallish peeve
2) since the super/windows key is by default associated with the
activities overview and thus with GS's management activities, wouldnt
it make sense to bind by default the workspace switching to something
like super+arrows? What about super+scrollwheel?

A more "out there" idea, given previous discussions and the current roadmap
3) again, since the super key is the entrance point to GS's features
and I am among those users that find jumping in and out of overview
mode _very_ distracting, couldn't we have so that if it is kept
pressed for over a time threshold, it instantly brings the favourite
apps/dock from the left and the workspace list from the right without
actually going in overview mode? Release the key and they are gone,
again instantly or with a tenth of a second fade.
Pros:
- the transition to overview takes a good half second, and both time
and animation are only a bother if what I want is to open a new
application window or to check if one of my docked apps is already
running and in which workspace.
- plus, if this "temporary tools" mode existed, we could ditch the
artificial divide between window management internal to a workspace (
done in normal mode) and window management between workspaces ( done
in overview ), because we could have direct drag and drop of windows
in and out of the workspaces.

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

Re: The logic behind remove "Restart" and hide "Power Off" in User menu.

[Johannes Schmid]

Hi Jon!

>> https://bugzilla.gnome.org/show_bug.cgi?id=636680
>
> No, that bug was about the menu item and the resulting dialog being out of
> sync.

Well, I can file a new bug if you like but still it doesn't seem that
there is a good place to discuss this regarding the usual ignorance of
mailing list posts on this topic which I can understand due to the bad
signal/noise ratio.

> There is some information about what we're trying to achieve with the
> system stop options here:
> http://live.gnome.org/GnomeShell/Design/Whiteboards/SystemStopRestart

There is absolutely no information about why suspend is the default apart
from telling that this is what happens when you close the lid on a laptop.
I think you can argue that it might be a reasonable default for laptops
but it is not at all a reasonable default for a desktop PC. And this is
not discussed at all in the linked page.

On a desktop for me there are the following links

* I'am done with it for now (= I go home/out now) -> power off
* I'am done with it currently (= lunchbreak) -> suspend
* I want to install an update (= Restart)

I never changed batteries in my desktop nor do I usually disconnect the
power cord (though I switch it off to save the standby power of the
ATX-Power-Supply and the monitor, which badly kills suspend-to-ram). Maybe
German's are more energy aware than other people in the world but this is
definitely common in Germany. And companies generally require employees to
shutdown their desktop when they go home.

Thanks and regards,
Johannes

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