Re: desktop schemas review [was: Re: GSettings migration status]

[James Sharpe]

On 3 July 2010 12:58, Vincent Untz  wrote:

> Hi,
>
> Le samedi 03 juillet 2010, à 13:37 +0200, Christian Persch a écrit :
> > Hi;
> >
> > I think we should use the opportunity of converting to gsettings to
> > redesign the desktop schemas, not just do a 1:1 translation from gconf.
> >
> > Let me make some remarks about the gsettings desktop schemas as
> > they right now are in gsettings-desktop-schemas module.
>
> Thanks, it's good that someone takes time to review the schemas! I
> merely converted them so people couldn't use the excuse we don't have
> them yet to not port their code to GSettings ;-)
>
> Might I suggest that you take the opportunity at this point to extend the
schema to at least consider support for multiple desktops / monitors. One of
the difficulties that I found when looking at this in GSOC a few years back
was that there was no way of supporting use of schemas when you had a
dynamic number of items that needed the same configuration (e.g.
background/screen0, background/screen1 etc), If this functionality is still
not available with GSettings shouldn't it be put on the list of things to be
addressed for the future?

James
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: desktop schemas review [was: Re: GSettings migration status]

[Christian Persch]

Hi;

Am Sat, 03 Jul 2010 19:29:13 +0100
schrieb Philip Withnall :
> On Sat, 2010-07-03 at 19:48 +0200, Christian Persch wrote:
> > Am Sat, 03 Jul 2010 17:08:36 +0200
> > schrieb Milan Bouchet-Valat :
> > > If only one string was provided, it would be a pain to find what
> > > a key is supposed to do without reading the full description. And
> > > that's what makes the settings database more useful than a mere
> > > addition of binary values (for example, if we want a « plumbing
> > > tool » to tweak advanced settings, we need it to have short and
> > > useful summaries).
> > 
> > Makes sense. We should at least discourage schema writers from
> > making the description just a reworded summary.
> > 
> > Or, let's only have the one  string, and take the first
> > line (paragraph?) of it as the "summary", and any extra text as
> > detail that will only be displayed in a tooltip, 'detailed info'
> > area, etc.
> > 
> > Like we do for our git commit messages :)
> 
> Isn't that somewhat betraying the idea of XML as a _structured_
> representation of data?

True.

So I'd settle for the style Ryan proposes in the other reply, and
telling schema writers that it's ok to omit  if it would
end up just being a slightly reworded summary. (As is the case in many
current gconf schemas.)

Regards,
Christian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: desktop schemas review [was: Re: GSettings migration status]

[Philip Withnall]

On Sat, 2010-07-03 at 19:48 +0200, Christian Persch wrote:
> Hi;
> 
> Am Sat, 03 Jul 2010 17:08:36 +0200
> schrieb Milan Bouchet-Valat :
> > Le samedi 03 juillet 2010 à 13:37 +0200, Christian Persch a écrit :
> > > Coincidentally, taking a look at all the  and 
> > > strings, it seems to me that once these value enumerations are taken
> > > out, not too much remains that justifies the split between two
> > > strings. IMHO we should consider dropping  from gschema
> > > and only provide for the one  strings.
> > In the case of these schemas, I think you're right, but in general
> > the split is really needed. Consider for example this Metacity key,
> > which is only one example among many others:
> > 
> >   false
> >   Whether to resize with the right button
> >   
> > Set this to true to resize with the right button and show a
> > menu with the middle button while holding down the key given in
> > "mouse-button-modifier"; set it to false to make it work
> > the opposite way around.
> >
> > 
> > 
> > If only one string was provided, it would be a pain to find what a key
> > is supposed to do without reading the full description. And that's
> > what makes the settings database more useful than a mere addition of
> > binary values (for example, if we want a « plumbing tool » to tweak
> > advanced settings, we need it to have short and useful summaries).
> 
> Makes sense. We should at least discourage schema writers from making
> the description just a reworded summary.
> 
> Or, let's only have the one  string, and take the first
> line (paragraph?) of it as the "summary", and any extra text as detail
> that will only be displayed in a tooltip, 'detailed info' area, etc.
> 
> Like we do for our git commit messages :)

Isn't that somewhat betraying the idea of XML as a _structured_
representation of data?

Philip

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

Re: desktop schemas review [was: Re: GSettings migration status]

[Christian Persch]

Hi;

Am Sat, 03 Jul 2010 17:08:36 +0200
schrieb Milan Bouchet-Valat :
> Le samedi 03 juillet 2010 à 13:37 +0200, Christian Persch a écrit :
> > Coincidentally, taking a look at all the  and 
> > strings, it seems to me that once these value enumerations are taken
> > out, not too much remains that justifies the split between two
> > strings. IMHO we should consider dropping  from gschema
> > and only provide for the one  strings.
> In the case of these schemas, I think you're right, but in general
> the split is really needed. Consider for example this Metacity key,
> which is only one example among many others:
> 
>   false
>   Whether to resize with the right button
>   
> Set this to true to resize with the right button and show a
> menu with the middle button while holding down the key given in
> "mouse-button-modifier"; set it to false to make it work
> the opposite way around.
>
> 
> 
> If only one string was provided, it would be a pain to find what a key
> is supposed to do without reading the full description. And that's
> what makes the settings database more useful than a mere addition of
> binary values (for example, if we want a « plumbing tool » to tweak
> advanced settings, we need it to have short and useful summaries).

Makes sense. We should at least discourage schema writers from making
the description just a reworded summary.

Or, let's only have the one  string, and take the first
line (paragraph?) of it as the "summary", and any extra text as detail
that will only be displayed in a tooltip, 'detailed info' area, etc.

Like we do for our git commit messages :)

> > Looks like this should use a settings list, with a base schema
> > containing "exec", "needs-term" (should be "needs-terminal" as
> > below) keys, and an extended schema for the browser settings adding
> > the "nremote" key.
> I've considered this too when reading the file, but in the end I was
> really not sure we gain anything with a list. GSettingsList is
> intended for schemas that will be extended at runtime, while here we
> have a list that is mostly set in stone. Apps only look for a known
> schema, and will never want to get the list of all registered
> applications, nor add an application to the list.
> 
> So I don't think that's worth the complexity it would add

I don't think it adds complexity, but reduces it. You only need to
write the schema once, and then can just reference it and override its
values (this is not in gsettings yet, but I think it's going to land
soon?).

Regards,
Christian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: desktop schemas review [was: Re: GSettings migration status]

[Ryan Lortie]

On Sat, 2010-07-03 at 13:37 +0200, Christian Persch wrote:
> Coincidentally, taking a look at all the  and 
> strings, it seems to me that once these value enumerations are taken
> out, not too much remains that justifies the split between two
> strings.
> IMHO we should consider dropping  from gschema and only
> provide for the one  strings.
> 
I'm of a mixed mind on this.

On one hand I'm sort of sick of coming up with 3 strings (of slightly
increasing verbosity) to describe my GObject properties and the same
sort of logic comes into play here.

On the other hand, I notice that the typical format for git commit
messages is actually extremely helpful.  Just because we presently don't
have any tools that take advantage of the summary (ie: by showing it
somewhere that the full description is not showing) doesn't mean that
it's pointless as a concept.

One thing I'd like to point to:

   https://bugzilla.gnome.org/show_bug.cgi?id=620562

The intention is that everything that interacts with the description
will do whitespace handling similar to the way Owen described in the
bug.

As implemented, in intltool for example:


  This is a description.

  Woo.  Multiple paragraphs.


will end up as "This is a description.\n\nWoo. Multiple paragraphs."
which should end up being shown reasonably well in UIs.

((note the folding of the spaces between "Woo." and "Multiple"))

So as a matter of style, I recommend writing summary and description
like so:


  This is a short summary (50 char rule, anyone?)
  
Even short one-paragraph descriptions should be done like this.
Wrap at 72, please.
  



Since we're discussing style, I'll also mention that I'm a fan of
vertical whitespace and that each key should probably have a newline
between:

 ...
   

   
 ...

and schemas definitely.  Maybe even two newlines there.


Cheers

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

Re: desktop schemas review [was: Re: GSettings migration status]

[Christian Persch]

Hi;

Am Sat, 03 Jul 2010 13:22:16 -0400
schrieb Ryan Lortie :
> On Sat, 2010-07-03 at 13:37 +0200, Christian Persch wrote:
> > 
> > Finally, I'd like to suggest that gsettings-desktop-schemas install
> > a header file containing #define's for each schema ID, schema, path
> > and all the key names.
> > 
> I tried to discuss this on IRC because I believe it's a good idea.
> It's nice to have the compiler yell at you because you typed
> G_DESKTOP_BACKROUND instead of silently allowing
> "org.gnome.desktop.backround".

Exactly. So let's do this :)

> I was even considering one step farther, defining macros like:
> 
> #define g_desktop_background_settings_new()  -> g_setting_new("...")
> 
> That then leads to g_desktop_background_settings_get_style() macros
> and such.  That might be going too far.

'Too far' would be anything that makes this into a library instead of
just a set of .h files. Anything less goes, as far as I'm concerned.

Regards,
Christian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: desktop schemas review [was: Re: GSettings migration status]

[Ryan Lortie]

On Sat, 2010-07-03 at 13:37 +0200, Christian Persch wrote:
> This is a common error. Filenames need to be stored as "ay" and *NOT*
> "s" (since "s" is UTF-8). (I think this needs some enhancement in
> glib-compile-schemas to be able to still put a string in .)

I'm not sure I buy into your hardline stance on this one.

I think it's not unreasonable to require that all filenames specified in
the settings be in a valid encoding (whatever that encoding is) on their
own filesystem (where "in a valid encoding" means "converts correctly to
and from unicode").  In that case, utf8 is appropriate here.

Cheers

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

Re: desktop schemas review [was: Re: GSettings migration status]

[Ryan Lortie]

On Sat, 2010-07-03 at 13:37 +0200, Christian Persch wrote:
> 
> Finally, I'd like to suggest that gsettings-desktop-schemas install a
> header file containing #define's for each schema ID, schema, path and
> all the key names.
> 
I tried to discuss this on IRC because I believe it's a good idea.  It's
nice to have the compiler yell at you because you typed
G_DESKTOP_BACKROUND instead of silently allowing
"org.gnome.desktop.backround".

I was even considering one step farther, defining macros like:


#define g_desktop_background_settings_new()  -> g_setting_new("...")

That then leads to g_desktop_background_settings_get_style() macros and
such.  That might be going too far.

Opinions?

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

Re: desktop schemas review [was: Re: GSettings migration status]

[Milan Bouchet-Valat]

Le samedi 03 juillet 2010 à 13:37 +0200, Christian Persch a écrit :
> Hi;
> 
> I think we should use the opportunity of converting to gsettings to
> redesign the desktop schemas, not just do a 1:1 translation from gconf.
> 
> Let me make some remarks about the gsettings desktop schemas as
> they right now are in gsettings-desktop-schemas module.
I agree with most of your suggestions too. Just two remarks.


> Coincidentally, taking a look at all the  and 
> strings, it seems to me that once these value enumerations are taken
> out, not too much remains that justifies the split between two strings.
> IMHO we should consider dropping  from gschema and only
> provide for the one  strings.
In the case of these schemas, I think you're right, but in general
the split is really needed. Consider for example this Metacity key,
which is only one example among many others:

  false
  Whether to resize with the right button
  
Set this to true to resize with the right button and show a menu
with the middle button while holding down the key given in
"mouse-button-modifier"; set it to false to make it work
the opposite way around.
   


If only one string was provided, it would be a pain to find what a key
is supposed to do without reading the full description. And that's what
makes the settings database more useful than a mere addition of binary
values (for example, if we want a « plumbing tool » to tweak advanced
settings, we need it to have short and useful summaries).

> Looks like this should use a settings list, with a base schema
> containing "exec", "needs-term" (should be "needs-terminal" as below)
> keys, and an extended schema for the browser settings adding the
> "nremote" key.
I've considered this too when reading the file, but in the end I was
really not sure we gain anything with a list. GSettingsList is intended
for schemas that will be extended at runtime, while here we have a list
that is mostly set in stone. Apps only look for a known schema, and will
never want to get the list of all registered applications, nor add an
application to the list.

So I don't think that's worth the complexity it would add


Regards


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

Re: desktop schemas review [was: Re: GSettings migration status]

[Vincent Untz]

Hi,

Le samedi 03 juillet 2010, à 13:37 +0200, Christian Persch a écrit :
> Hi;
> 
> I think we should use the opportunity of converting to gsettings to
> redesign the desktop schemas, not just do a 1:1 translation from gconf.
> 
> Let me make some remarks about the gsettings desktop schemas as
> they right now are in gsettings-desktop-schemas module.

Thanks, it's good that someone takes time to review the schemas! I
merely converted them so people couldn't use the excuse we don't have
them yet to not port their code to GSettings ;-)

On a general note: I think you should feel free to commit most of your
proposed changes.

> 
> 
> org.gnome.desktop.background.gschema.xml.in:
> 
>  enum="org.gnome.desktop.GDesktopBackgroundStyle">
> 'zoom' Picture Options
>   Determines how the image set by wallpaper_filename
> is rendered.  Possible values are "none", "wallpaper", "centered",
> "scaled", "stretched", "zoom", "spanned". 
> 
> I don't think we need to enumerate all choices in the 
> here. With gsettings, the valid values are stored in the schema via the
> enum, so this is unnecessary work for translators, and superflous.

Agree.

> Coincidentally, taking a look at all the  and 
> strings, it seems to me that once these value enumerations are taken
> out, not too much remains that justifies the split between two strings.
> IMHO we should consider dropping  from gschema and only
> provide for the one  strings.

Hrm, I don't know; I can't think of any major objection right now,
except that we're used to this way ;-) Ryan, what's your opinion?

> 
>   
> '@datadir@/pixmaps/backgrounds/gnome/background-default.jpg'
>   Picture Filename
>   File to use for the background image.
> 
> 
> This is a common error. Filenames need to be stored as "ay" and *NOT*
> "s" (since "s" is UTF-8). (I think this needs some enhancement in
> glib-compile-schemas to be able to still put a string in .)

Ryan?

> 
>   
>   100
>   Picture Opacity
>   Opacity with which to draw the background
> picture. 
> 
> IMHO, should be a "d" with  instead.

Works for me.

> Also, I wonder if all the picture-* keys should be inside a child schema
> here.

They probably should, indeed.

> ---
> 
> org.gnome.desktop.default-applications.gschema.xml:
> 
> Looks like this should use a settings list, with a base schema
> containing "exec", "needs-term" (should be "needs-terminal" as below)
> keys, and an extended schema for the browser settings adding the
> "nremote" key.
> 
> 
>   'mozilla'
>   Default browser
>   Default browser for all URLs.
> 
> 
> I wonder if we should support "as" as argv here, instead.

IMHO, the sane thing to do here is to store .desktop filenames instead
of what we do right now.

> Also, whether this should be "ay" (or "aay") since technically,
> programme names need not be UTF-8.
> 
> ---
> 
> org.gnome.desktop.interface.gschema.xml: 
> 
> Looks ok, but maybe the keys could be named more consistently.
> 
> ---
> 
> org.gnome.desktop.lockdown.gschema.xml:
> 
> I wonder if this schema should simply contain a flag setting, instead
> of several boolean lockdown settings?

Does it really make things easier?

> --
> 
> org.gnome.desktop.url-handlers.gschema.xml: 
> 
> This should be a settings list, with a base schema for the "enabled",
> "exec" and "needs-terminal" keys; actually the same base schema as the
> default-applications schemas above.

Nod.

> ---
> 
> org.gnome.system.proxy.gschema.xml: 
> 
> Should use a settings list for the various (http/https/ftp/socks)
> proxies.

Nod.

> Maybe the developers working on GIO proxy support could look at this
> schema and see if it maps nicely to what their code supports ?
> 
> 
>   ''
>   HTTP proxy host name
>   The machine name to proxy HTTP through.
> 
> 
>   
>   8080
>   HTTP proxy port
>   The port on the machine defined by
> "/system/proxy/http/host" that you proxy through.
> 
> 
> IMHO this is _one_ setting that belongs together, as a "(sq)" tuple
> (string, uint16).

Works for me.

> -
> 
> Finally, I'd like to suggest that gsettings-desktop-schemas install a
> header file containing #define's for each schema ID, schema, path and
> all the key names.

There's already a header file in git. I don't think Ryan put all those
defines. If not, feel free to do it :-)

(and you can win a maintainer hat for this module by just adding your
name in MAINTAINERS and the .doap ;-))

Cheers,

Vincent

-- 
Les gens heureux ne sont pas pressés.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/d

GSettings schema writing guidance [was: dconf/GSettings namespace]

[Christian Persch]

Hi;

I think we should provide a more in-depth guide on how to write schemas
for gsettings, convering e.g.:

- schema names: tld.foo.FooApp vs. tld.foo.foo-app vs ...

- paths: /tld/foo/foo-app/ vs /apps/foo-app/ vs ...

- what key names to use

- how the  and  should differ and what they
  should (and should not) contain.
  (E.g. IMHO for enum and flags settings, the GConf schemas used to
  contain a complete enumeration of the valid values. Since these are
  stored in the schema itself for gsettings, I think the description
  need not do this anymore.) [Actually I wonder if we should just drop
  the summary altogether and only provide the description?]

- how to store some common data types:

  * colours: should they be stored as "s" ('rrggbb' or '#rrggbb' or
'#bbb' or ...) or "(yyy)" (tuple of 3 bytes) or
"(nnn)" (tuple of 3 int16's) ? And should it always contain also
the alpha component?

  * remind the programmer that filenames need to be "ay" not "s" (and
advise to just use URIs instead which can be stored as "s" ?)

  * command lines as one line ("s" / "ay"), or argv ("as" / "aay")

  * enums, flags should use the built-in gsettings support for them

  * (host, port) pairs (e.g. in the proxy settings): separate keys for
host and port, or an "(si)" tuple ?

  * window sizes, should they be two "i" settings for width and height,
or an "(ii)" tuple? same for window positions

  * generalising the two above, when to use several individual settings,
and when to just one setting containing an tuple

  * etc.

- when to use child schemas

- when to use settings lists

Regards,
Christian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Statistics on each release

[Jonh Wendell]

Em Qui, 2010-07-01 às 19:04 -0400, Shaun McCance escreveu:
> On Thu, 2010-07-01 at 14:35 -0700, Germán Póo-Caamaño wrote:
> > On Thu, 2010-07-01 at 14:21 -0300, Jonh Wendell wrote:
> > > Hello guys, I just read a xorg release announcement and found quite
> > > interesting their statistics not only about people but also about
> > > companies behind committers:
> > > http://lists.x.org/archives/xorg-devel/2010-July/010706.html
> > > 
> > > Wouldn't be nice to have this in GNOME releases? :)
> > 
> > Indeed.  But there are some differences and it requires a bit more work.
> > 
> > It is easier to run gitdm against Linux or Xorg or Python or OOo or
> > whatever because there is *one* 'module' involved.  But in GNOME we have
> > dozens of modules involved, so it is required to consolidate the data.
> 
> Which is what Blip (née Pulse) does:
> 
> http://people.gnome.org/~shaunm/pulse/web/
> 
> It could easily generate reports like these. I know it feels
> kind of like vaporware, given how long I've been working on
> it without a deployment. But the code is pretty solid. It
> wouldn't take too much to get it running.
> 
> --
> Shaun
> 

Can we (me, Shaun, German, Dave and others interested) talk about this
at GUADEC?

Cheers,
-- 
Jonh Wendell
http://www.bani.com.br

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

desktop schemas review [was: Re: GSettings migration status]

[Christian Persch]

Hi;

I think we should use the opportunity of converting to gsettings to
redesign the desktop schemas, not just do a 1:1 translation from gconf.

Let me make some remarks about the gsettings desktop schemas as
they right now are in gsettings-desktop-schemas module.



org.gnome.desktop.background.gschema.xml.in:


'zoom' Picture Options
  Determines how the image set by wallpaper_filename
is rendered.  Possible values are "none", "wallpaper", "centered",
"scaled", "stretched", "zoom", "spanned". 

I don't think we need to enumerate all choices in the 
here. With gsettings, the valid values are stored in the schema via the
enum, so this is unnecessary work for translators, and superflous.

Coincidentally, taking a look at all the  and 
strings, it seems to me that once these value enumerations are taken
out, not too much remains that justifies the split between two strings.
IMHO we should consider dropping  from gschema and only
provide for the one  strings.


  
'@datadir@/pixmaps/backgrounds/gnome/background-default.jpg'
  Picture Filename
  File to use for the background image.


This is a common error. Filenames need to be stored as "ay" and *NOT*
"s" (since "s" is UTF-8). (I think this needs some enhancement in
glib-compile-schemas to be able to still put a string in .)


  
  100
  Picture Opacity
  Opacity with which to draw the background
picture. 

IMHO, should be a "d" with  instead.

Also, I wonder if all the picture-* keys should be inside a child schema
here.

---

org.gnome.desktop.default-applications.gschema.xml:

Looks like this should use a settings list, with a base schema
containing "exec", "needs-term" (should be "needs-terminal" as below)
keys, and an extended schema for the browser settings adding the
"nremote" key.


  'mozilla'
  Default browser
  Default browser for all URLs.


I wonder if we should support "as" as argv here, instead. Also, whether
this should be "ay" (or "aay") since technically, programme names need
not be UTF-8.

---

org.gnome.desktop.interface.gschema.xml: 

Looks ok, but maybe the keys could be named more consistently.

---

org.gnome.desktop.lockdown.gschema.xml:

I wonder if this schema should simply contain a flag setting, instead
of several boolean lockdown settings?

--

org.gnome.desktop.url-handlers.gschema.xml: 

This should be a settings list, with a base schema for the "enabled",
"exec" and "needs-terminal" keys; actually the same base schema as the
default-applications schemas above.

---

org.gnome.system.proxy.gschema.xml: 

Should use a settings list for the various (http/https/ftp/socks)
proxies.

Maybe the developers working on GIO proxy support could look at this
schema and see if it maps nicely to what their code supports ?


  ''
  HTTP proxy host name
  The machine name to proxy HTTP through.


  
  8080
  HTTP proxy port
  The port on the machine defined by
"/system/proxy/http/host" that you proxy through.


IMHO this is _one_ setting that belongs together, as a "(sq)" tuple
(string, uint16).

-

Finally, I'd like to suggest that gsettings-desktop-schemas install a
header file containing #define's for each schema ID, schema, path and
all the key names.

Regards,
Christian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Gnome-shell and usability (from user perspective)

[Maciej Piechotka]

First of all I'd like to say that I'm not usability specialist (I'm not
event 'normal' user - I'm closer to power user). However after some time
of using the gnome-shell (from about GNOME 2.27.x)  I noted a few problems -
and they are more the minor problems (I believe) in design rather that 'bugs' so
I decided to post it here.

I know that GNOME 3.0 is near but I guess it should be somewhere
addressed (possibly in GNOME 3.2)

- Application-based navigation in gnome-shell may be nice idea but in
some cases it has no high usability. If someone have more than one
document it can be hard to navigate - all I have is white boxes with
some text.

The fade-out provides little clue where should I find an application.
There *are* names and I can use recent items but there are some problems
with this approach:

  1. It does not work for terminals as they are not documents.
  2. Recent items can get spammed by some applications - for example
seeing 160 photos from camera destroys the whole list

Anyway the problem is not that it is not impossible. The problem is that
it is harder.

- Working with workspace is harder. When I had gnome-panel I had about 8
workspaces constantly opened and I had 1:1 relationship between tasks
and workspaces. Now I use one workspace.

The problem is the change from 'array' approach to 'linked list'
approach. Also I cannot rearrange them or insert workspace in the
middle.

I also cannot rearrange freely the workspaces. I had the set up where
all programming tasks was next to each other etc.

- It is less about me but the notes about redesign nautilus. All
'normal' users I know do not use toolbars and keyboard shortcuts. If
they want to save they go to File|Save even if disk is on toolbar. If
they want to print they go to File|Print even if printer icon is on
toolbar (some if they want to exit goes to File|Save and then File|
Close).

While getting rid of menus may be argued as simpler etc. it may be
perceived as harder for users which have some experience with computers
but do not understand how does it work (and they have some
superstitions).

(On the other hand simplifying menus seems a good idea).



I understand that gnome-shell is probably targeted at users who are not
necessary familiar with computers. However after some time of using
gnome-shell I find it *less* task-based and harder to use using my work
flow.

Regards
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list