Module semi-proposal: gnome-shell

[Owen Taylor]

Oh, the deadline was *last* Monday? Actually, I knew that, but it snuck
up on me, then it took me a few days to figure out what I wanted to say
here...

This should be read as a semi-proposal: at this point I don't think
gnome-shell is going to be ready to be shipped as a final component on
the 2.30 schedule. But getting it into people's hands is important for
having it be ready for GNOME 3.

So what makes most sense to me is to view 2.30 as a dual release; to
have a set of stable modules that make up the normal GNOME 2 desktop
release and a set of preview modules that can be added on to get a
beta of the GNOME 3 experience. (By beta I mean not a release candidate,
but rather a stabilized version that is suitable for widespread use
and testing but may undergo substantial changes before the final
release.)

Purpose:
 
 GNOME Shell is intended to replace gnome-panel and Metacity in the
 GNOME 3 desktop; it takes on roles such as switching to windows,
 launching applications, and displaying and letting the user interact
 with notification.

Target:

 In GNOME 3, GNOME Shell will be a core part of the GNOME desktop.

Dependencies:

 In addition to standard GNOME platform and desktop modules, GNOME Shell
 currently depends on:

  Clutter: gnome-shell-2.30 will depend on Clutter 1.2 which is
    planned to be finalized around January.

  GJS and SpiderMonkey: Currently gnome-shell is build using the
    GJS bindings to Javascript which work with the Mozilla SpiderMonkey
    Javascript engine. The comparison to seed/JavascriptCore has been
    discussed quite a bit in the past, I don't want to go into in
    detail here; basically the advantages for us are:

     - We have it working right now and don't have to spend time
       converting things over.

     - We get access to a range of nice, but not essential, extensions
       to Javascript that have been added by the Mozilla developers
       based on their needs developing a complex application with JS;
       these include:

       - Destructuring assignments: [x,y] = event.get_coords();
       - let variables with lexical scoping
       - Array.forEach()

    In one sense SpiderMonkey is not a problematic dependency;
    SpiderMonkey is distributed as part of xulrunner, and will be
    present on virtually any computer where GNOME is available.
    GJS is a very small library on top of SpiderMonkey and poses
    few issues in its own. It probably would be a preview desktop
    module in the same category as Mutter and gnome-shell.

    On the other hand: it is conceptually messy for GNOME to depend
    on two Javascript implementations and runtimes and it might be
    a PR problem in presenting GNOME as a project that knows where
    it is going :-)
 
    And SpiderMonkey has another issue; it is distributed only as
    part of xulrunner, and the xulrunner libraries have no binary
    compat guarantees between minor versions, so things linked against
    SpiderMonkey can need a recompile for Firefox security updates.

    My feeling right now is to leave figuring out the Javascript
    engine situation as something to do as time permits, perhaps it
    will get clearer on its own if let sit. But if this is seen
    as a major problem, then we can prioritize to make sure that it is
    done early on.

  Mutter: Mutter is a conversion of Metacity to be a Clutter-based
    window manager and compositing manager. In addition to being used
    in gnome-shell, it is is a core component of Moblin. It's
    maintained jointly by me and Tomas Frydrych.

    (I'm not going to do a separate module proposal for Mutter, read
    this as a proposal for both; I'm not aware of any issues with
    Mutter that aren't a subset of those discussed in this proposal.)

  ? Zeitgeist: I'm a little uncertain about this; we have patches
    around (that I've promised to review, but haven't yet :-() that
    integrate the 0.2  branch of Zeitgeist into gnome-shell in a very
    straightforward way without changing the UI - it's basically used
    as a replacement for .recently-used.xbel.

    This is a reasonable first step to integration, but in itself
    doesn't motivate adding an extra dependency; that needs to be
    motivated by a better understanding of what it will do for users and
    what the user interface will look like for GNOME 3.

    My initial understanding of the Zeitgeist engine was that it was
    a data collection engine to collect a rich view of how the user
    used their computer over time, which would then be used to build
    an OLPC style journal interface; but that understanding fuzzes
    at the edges when people are pressed about this, things like
    deducing related documents from temporal overlaps and tagging
    enter into the picture. This doesn't make me comfortable.

    There are also questions here of the relationship with Tracker. If
    Tracker really lives up to its promise, shouldn't timeline
    information simply be extra metadata added in the Tracker store;
    after all, a timeline really is just an indexed and extended
    view of the classic ctime/mtime/atime metadata?

    If querying the Tracker database for this is a) not sufficiently
    efficient b) too cumbersome to code c) requires expert training
    in RDF, then that, to me, would throw doubt on the whole Tracker
    enterprise.

    What would make us most comfortable would be a comprehensive
    picture of how Tracker, Zeitgeist, and Nautilus work together
    with the shell to allow finding your stuff. Now it is probably
    not completely realistic for me to hang await for this to show
    up in my inbox in finished form, so the first step (from my
    technical perspective) is to get a clear statement of what the
    Zeitgeist engine does, what new user interfaces are enabled by
    that operation, what it does *not* do, and how it relates to
    Tracker.

    If the Zeitgeist people are interested in being in GNOME 2.30,
    perhaps they can provide a similar preview module proposal to this
    and answer that question there.

Resource usage:

 GNOME Shell is the gnome-shell module in GNOME Git, the gnome-shell
 product in bugzilla.gnome.org, gnome-shell-list@..., and
 #gnome-shell on irc.gnome.org.
 
Adoption:

 Packages of GNOME Shell are available for most major operating systems
 and distributions that use GNOME as a desktop either as part of the
 latest versions or from 3rd party sources. Nobody is currently
 using it as the default GUI.

GNOME-ness:

 In addition to the use of GNOME resources as mentioned above;
 GNOME Shell development is being done as close to possible to the
 GNOME community; it has been a major topic of discussion at last
 years and this years Boston GNOME Summit and at GCDS this summer;
 the GNOME art and design community have been extensively
 consulted (we could use more help!), it is translated by the
 GNOME translation teams, and so forth.

License:

 GPL


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

[Brian Cameron]

Owen:

It sounds like GNOME Shell will likely not integrate with GNOME 2.30.

How are users expected to turn on/enable GNOME Shell?  At the Boston
Summit, I remember people suggesting that there should be a checkbox in
the Preferences->Appearance capplet that the user can check it to start
using GNOME Shell.  Is this the plan?

Whatever such interfaces are needed in the base desktop to provide end
users with the ability to "switch" to GNOME Shell, I hope these
interfaces make it into GNOME 2.30.  Ideally, users should just need to
install the new GNOME Shell, mutter, etc. modules and have their desktop
"just work".  Users should be able to enable GNOME Shell without needing
to hack around with gconf-editor, .desktop files, etc.

I think it will cause problems for adoption and testing if users need to
reinstall patched versions of gnome-control-center (or whatever) in
order to turn on GNOME Shell after installing the GNOME Shell packages.

In terms of zeitgeist, there have not been any tarball releases as far
as I can tell.  If we are seriously considering adding zeitgeist into
GNOME, I would think we should be starting to do more formal releases of
the code.  I would think the sooner the better.

Brian

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

[Jamie McCracken-2]

On Mon, 2009-11-02 at 17:12 -0500, Owen Taylor wrote:

>
>     My initial understanding of the Zeitgeist engine was that it was
>     a data collection engine to collect a rich view of how the user
>     used their computer over time, which would then be used to build
>     an OLPC style journal interface; but that understanding fuzzes
>     at the edges when people are pressed about this, things like
>     deducing related documents from temporal overlaps and tagging
>     enter into the picture. This doesn't make me comfortable.
>
>     There are also questions here of the relationship with Tracker. If
>     Tracker really lives up to its promise, shouldn't timeline
>     information simply be extra metadata added in the Tracker store;
>     after all, a timeline really is just an indexed and extended
>     view of the classic ctime/mtime/atime metadata?
>
>     If querying the Tracker database for this is a) not sufficiently
>     efficient b) too cumbersome to code c) requires expert training
>     in RDF, then that, to me, would throw doubt on the whole Tracker
>     enterprise.
>
>     What would make us most comfortable would be a comprehensive
>     picture of how Tracker, Zeitgeist, and Nautilus work together
>     with the shell to allow finding your stuff. Now it is probably
>     not completely realistic for me to hang await for this to show
>     up in my inbox in finished form, so the first step (from my
>     technical perspective) is to get a clear statement of what the
>     Zeitgeist engine does, what new user interfaces are enabled by
>     that operation, what it does *not* do, and how it relates to
>     Tracker.

I dont want to comment too much on zeitgeist but AFAIK all querying,
tagging and event logging can be done in the tracker DB. A tracker miner
could be created to perform such logging although it seems the zeitgeist
team want to use a python daemon instead.

Tracker has tried not to step on their toes and instead encouraged it to
use tracker as a backend which they are receptive too. (they are far
happier using tracker if it were included in Gnome). AFAIK, all their
queries can be expressed in sparql so tracker should be a good fit

Timeline data is not persistent metadata like title/subject/mtime. Its
what I would call semi-persistent in that you would probably want to
store it for a limited time only (user preference for 3/6/12 month of
history). This could be added to tracker to stop it bloating up over
time. However the main concern I have is how much logging is done.
Zeitgeist, from what I heard,  appears keen to log quite a lot of data
which would quickly bloat up any DB. I personally favour a coarse grain
approach that only logs important stuff like file, application and web
histories.

I personally would like to merge zeitgeist functionality into tracker
but really its up to the zeitgeist team on whether they are willing to
do this (it would mean converting the python code to Vala/Genie or C as
well)

jamie
 

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

[Seif Lotfy]

2009/11/2 Jamie McCracken <jamie.mccrack@...>

On Mon, 2009-11-02 at 17:12 -0500, Owen Taylor wrote:

>
>     My initial understanding of the Zeitgeist engine was that it was
>     a data collection engine to collect a rich view of how the user
>     used their computer over time, which would then be used to build
>     an OLPC style journal interface; but that understanding fuzzes
>     at the edges when people are pressed about this, things like
>     deducing related documents from temporal overlaps and tagging
>     enter into the picture. This doesn't make me comfortable.
>
>     There are also questions here of the relationship with Tracker. If
>     Tracker really lives up to its promise, shouldn't timeline
>     information simply be extra metadata added in the Tracker store;
>     after all, a timeline really is just an indexed and extended
>     view of the classic ctime/mtime/atime metadata?
>
>     If querying the Tracker database for this is a) not sufficiently
>     efficient b) too cumbersome to code c) requires expert training
>     in RDF, then that, to me, would throw doubt on the whole Tracker
>     enterprise.
>
>     What would make us most comfortable would be a comprehensive
>     picture of how Tracker, Zeitgeist, and Nautilus work together
>     with the shell to allow finding your stuff. Now it is probably
>     not completely realistic for me to hang await for this to show
>     up in my inbox in finished form, so the first step (from my
>     technical perspective) is to get a clear statement of what the
>     Zeitgeist engine does, what new user interfaces are enabled by
>     that operation, what it does *not* do, and how it relates to
>     Tracker.

I dont want to comment too much on zeitgeist but AFAIK all querying,
tagging and event logging can be done in the tracker DB. A tracker miner
could be created to perform such logging although it seems the zeitgeist
team want to use a python daemon instead.

Tracker has tried not to step on their toes and instead encouraged it to
use tracker as a backend which they are receptive too. (they are far
happier using tracker if it were included in Gnome). AFAIK, all their
queries can be expressed in sparql so tracker should be a good fit

Timeline data is not persistent metadata like title/subject/mtime. Its
what I would call semi-persistent in that you would probably want to
store it for a limited time only (user preference for 3/6/12 month of
history). This could be added to tracker to stop it bloating up over
time. However the main concern I have is how much logging is done.
Zeitgeist, from what I heard,  appears keen to log quite a lot of data
which would quickly bloat up any DB. I personally favour a coarse grain
approach that only logs important stuff like file, application and web
histories.

I personally would like to merge zeitgeist functionality into tracker
but really its up to the zeitgeist team on whether they are willing to
do this (it would mean converting the python code to Vala/Genie or C as
well)

jamie

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

Hey,
Thanks alot Jamie for actually explaining most of the sutff I wanted to exlpain.
During the course of Zeitgeist development we got into contact with alot of Tracker devs.
To sum it down. Tracker and Zeitgeist are not the same.

Tracker answers question relation the metadata as well as the content of data. "Get me songs from artist A", "Get me all docs with tag B"
Zeitgeist covers how the data is used. "Get me most used applications and documents within a time period", "Which files did I have open while editing X"

It is our plan to actually push our metadata about the items into Tracker keeping the info about the events for ourselves. I patched a dataprovider for Zeitgeist to send events to zeitgeist and the subject of these events to tracker.
But also as discussed with some Tracker devs a total merge makes no sense. However a dependency is possible and also a current option that will be tested during the hackfest.
We also log every focus switch to generate contextual relevancy. This would just bloat the the Tracker storage. We have an extra table to handle this.

I will write a better explanation in a new mail on the tracker ML.
Cheers
Seif


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

[Owen Taylor]

On Mon, 2009-11-02 at 16:28 -0600, Brian Cameron wrote:

> Owen:
>
> It sounds like GNOME Shell will likely not integrate with GNOME 2.30.
>
> How are users expected to turn on/enable GNOME Shell?  At the Boston
> Summit, I remember people suggesting that there should be a checkbox in
> the Preferences->Appearance capplet that the user can check it to start
> using GNOME Shell.  Is this the plan?
>
> Whatever such interfaces are needed in the base desktop to provide end
> users with the ability to "switch" to GNOME Shell, I hope these
> interfaces make it into GNOME 2.30.  Ideally, users should just need to
> install the new GNOME Shell, mutter, etc. modules and have their desktop
> "just work".  Users should be able to enable GNOME Shell without needing
> to hack around with gconf-editor, .desktop files, etc.
>
> I think it will cause problems for adoption and testing if users need to
> reinstall patched versions of gnome-control-center (or whatever) in
> order to turn on GNOME Shell after installing the GNOME Shell packages.

Hey Brian -

Having a standard way to easily switch back and forth is a good idea,
thanks for bringing up the topic. For Fedora we've extended our "Desktop
Effects" capplet to allow changing to GNOME Shell as well as Compiz.

https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00119.html

has a screenshot. It handles like checking for hardware 3D, letting the
user confirm that they still have a working session, and adjusting the
GConf settings for gnome-session to enable the appropriate window
manager and/or panel.

The basic operation of this program is not at all Fedora specific but
there are a couple of things that are tied to the way we do things:

 - We use the 'compiz-gtk' script to launch Compiz
 - We configure Compiz to use the GConf backend and allow setting
   a couple of settings that way.

We could try to make it more flexible to handle the way Compiz works on
other distributions, or even now if /usr/bin/compiz-gtk isn't there (and
it won't be there on any other distribution) then the Compiz option will
simply not be there, but maybe we should strip out the Compiz option
entirely and make it a "GNOME 3 Preview" tool, which would basically
have some explanatory text, a link to read more about GNOME 3, and the
ability to enable or disable.

This could just be shipped right in the gnome-shell module, so it would
be installed if gnome-shell was and not otherwise.

I don't think integrating this into the Appearance capplet really makes
sense - already we have very different things there:

 - Themes (advanced customization)
 - The size of your font (see what you are doing)
 - Change wallpaper (show off a picture of your kid)

Adding another option in there that complete changes the entire way your
desktop works adds a whole extra and much more radical level to this.

I'd be interested in hearing the opinions of different people who are
packaging up gnome-shell on what would be useful for them. The hard part
of the code is written, it's just a question of the details of the UI
and where we put it.

> In terms of zeitgeist, there have not been any tarball releases as far
> as I can tell.  If we are seriously considering adding zeitgeist into
> GNOME, I would think we should be starting to do more formal releases of
> the code.  I would think the sooner the better.

There were a couple of releases this summer:

http://bloc.eurion.net/archives/2009/here-is-zeitgeist-0-2-1/

which Siegfried stepped up to do so there would be a stable base for
GNOME Shell integration while the code was being rewritten in the 0.3
branch. (Apparently another rewrite is planned for the Zeitgeist
hackfest.)

- Owen


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

[Seif Lotfy]

2009/11/3 Owen Taylor <otaylor@...>

On Mon, 2009-11-02 at 16:28 -0600, Brian Cameron wrote:
> Owen:
>
> It sounds like GNOME Shell will likely not integrate with GNOME 2.30.
>
> How are users expected to turn on/enable GNOME Shell?  At the Boston
> Summit, I remember people suggesting that there should be a checkbox in
> the Preferences->Appearance capplet that the user can check it to start
> using GNOME Shell.  Is this the plan?
>
> Whatever such interfaces are needed in the base desktop to provide end
> users with the ability to "switch" to GNOME Shell, I hope these
> interfaces make it into GNOME 2.30.  Ideally, users should just need to
> install the new GNOME Shell, mutter, etc. modules and have their desktop
> "just work".  Users should be able to enable GNOME Shell without needing
> to hack around with gconf-editor, .desktop files, etc.
>
> I think it will cause problems for adoption and testing if users need to
> reinstall patched versions of gnome-control-center (or whatever) in
> order to turn on GNOME Shell after installing the GNOME Shell packages.

Hey Brian -

Having a standard way to easily switch back and forth is a good idea,
thanks for bringing up the topic. For Fedora we've extended our "Desktop
Effects" capplet to allow changing to GNOME Shell as well as Compiz.

https://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00119.html

has a screenshot. It handles like checking for hardware 3D, letting the
user confirm that they still have a working session, and adjusting the
GConf settings for gnome-session to enable the appropriate window
manager and/or panel.

The basic operation of this program is not at all Fedora specific but
there are a couple of things that are tied to the way we do things:

 - We use the 'compiz-gtk' script to launch Compiz
 - We configure Compiz to use the GConf backend and allow setting
  a couple of settings that way.

We could try to make it more flexible to handle the way Compiz works on
other distributions, or even now if /usr/bin/compiz-gtk isn't there (and
it won't be there on any other distribution) then the Compiz option will
simply not be there, but maybe we should strip out the Compiz option
entirely and make it a "GNOME 3 Preview" tool, which would basically
have some explanatory text, a link to read more about GNOME 3, and the
ability to enable or disable.

This could just be shipped right in the gnome-shell module, so it would
be installed if gnome-shell was and not otherwise.

I don't think integrating this into the Appearance capplet really makes
sense - already we have very different things there:

 - Themes (advanced customization)
 - The size of your font (see what you are doing)
 - Change wallpaper (show off a picture of your kid)

Adding another option in there that complete changes the entire way your
desktop works adds a whole extra and much more radical level to this.

I'd be interested in hearing the opinions of different people who are
packaging up gnome-shell on what would be useful for them. The hard part
of the code is written, it's just a question of the details of the UI
and where we put it.

> In terms of zeitgeist, there have not been any tarball releases as far
> as I can tell.  If we are seriously considering adding zeitgeist into
> GNOME, I would think we should be starting to do more formal releases of
> the code.  I would think the sooner the better.

There were a couple of releases this summer:

http://bloc.eurion.net/archives/2009/here-is-zeitgeist-0-2-1/

which Siegfried stepped up to do so there would be a stable base for
GNOME Shell integration while the code was being rewritten in the 0.3
branch. (Apparently another rewrite is planned for the Zeitgeist
hackfest.)

 Correction the 0.3 is the rewrite planned to be done during the hackfest (we r not rewriting all just around 50%). We will release it as a 0.9 though since it will be our last iteration before we actually meet all the services we intended. So a 1.0 is sooner than u think

 

- Owen

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

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

[Willie Walker-2]

Hi Owen:

Many thanks for making this a formal proposal for comments.  I think we
all want to get behind GNOME Shell as a nice whiz-bang feature to make
people want to move to GNOME 3.  With the magnification support going
into GNOME Shell, the accessibility team is also building in a
dependency on the success of GNOME Shell.  So - we want to see it
succeed.

GNOME Shell is currently pretty much inaccessible, however, with the big
deal breakers being keyboard traversal (try to accomplish GNOME Shell
activities without a mouse) and AT-SPI support (try to examine and
interact with GNOME Shell components via accerciser).  Theming is also
another issue, but perhaps not as strong as the other two.

Since accessibility is a core value of GNOME, these things really need
to be addressed before GNOME Shell is fully blessed, IMO.

Thanks!

Will

On Mon, 2009-11-02 at 17:12 -0500, Owen Taylor wrote:

> Oh, the deadline was *last* Monday? Actually, I knew that, but it snuck
> up on me, then it took me a few days to figure out what I wanted to say
> here...
>
> This should be read as a semi-proposal: at this point I don't think
> gnome-shell is going to be ready to be shipped as a final component on
> the 2.30 schedule. But getting it into people's hands is important for
> having it be ready for GNOME 3.
>
> So what makes most sense to me is to view 2.30 as a dual release; to
> have a set of stable modules that make up the normal GNOME 2 desktop
> release and a set of preview modules that can be added on to get a
> beta of the GNOME 3 experience. (By beta I mean not a release candidate,
> but rather a stabilized version that is suitable for widespread use
> and testing but may undergo substantial changes before the final
> release.)
>
> Purpose:
>  
>  GNOME Shell is intended to replace gnome-panel and Metacity in the
>  GNOME 3 desktop; it takes on roles such as switching to windows,
>  launching applications, and displaying and letting the user interact
>  with notification.
>
> Target:
>
>  In GNOME 3, GNOME Shell will be a core part of the GNOME desktop.
>
> Dependencies:
>
>  In addition to standard GNOME platform and desktop modules, GNOME Shell
>  currently depends on:
>
>   Clutter: gnome-shell-2.30 will depend on Clutter 1.2 which is
>     planned to be finalized around January.
>
>   GJS and SpiderMonkey: Currently gnome-shell is build using the
>     GJS bindings to Javascript which work with the Mozilla SpiderMonkey
>     Javascript engine. The comparison to seed/JavascriptCore has been
>     discussed quite a bit in the past, I don't want to go into in
>     detail here; basically the advantages for us are:
>
>      - We have it working right now and don't have to spend time
>        converting things over.
>
>      - We get access to a range of nice, but not essential, extensions
>        to Javascript that have been added by the Mozilla developers
>        based on their needs developing a complex application with JS;
>        these include:
>
>        - Destructuring assignments: [x,y] = event.get_coords();
>        - let variables with lexical scoping
>        - Array.forEach()
>
>     In one sense SpiderMonkey is not a problematic dependency;
>     SpiderMonkey is distributed as part of xulrunner, and will be
>     present on virtually any computer where GNOME is available.
>     GJS is a very small library on top of SpiderMonkey and poses
>     few issues in its own. It probably would be a preview desktop
>     module in the same category as Mutter and gnome-shell.
>
>     On the other hand: it is conceptually messy for GNOME to depend
>     on two Javascript implementations and runtimes and it might be
>     a PR problem in presenting GNOME as a project that knows where
>     it is going :-)
>  
>     And SpiderMonkey has another issue; it is distributed only as
>     part of xulrunner, and the xulrunner libraries have no binary
>     compat guarantees between minor versions, so things linked against
>     SpiderMonkey can need a recompile for Firefox security updates.
>
>     My feeling right now is to leave figuring out the Javascript
>     engine situation as something to do as time permits, perhaps it
>     will get clearer on its own if let sit. But if this is seen
>     as a major problem, then we can prioritize to make sure that it is
>     done early on.
>
>   Mutter: Mutter is a conversion of Metacity to be a Clutter-based
>     window manager and compositing manager. In addition to being used
>     in gnome-shell, it is is a core component of Moblin. It's
>     maintained jointly by me and Tomas Frydrych.
>
>     (I'm not going to do a separate module proposal for Mutter, read
>     this as a proposal for both; I'm not aware of any issues with
>     Mutter that aren't a subset of those discussed in this proposal.)
>
>   ? Zeitgeist: I'm a little uncertain about this; we have patches
>     around (that I've promised to review, but haven't yet :-() that
>     integrate the 0.2  branch of Zeitgeist into gnome-shell in a very
>     straightforward way without changing the UI - it's basically used
>     as a replacement for .recently-used.xbel.
>
>     This is a reasonable first step to integration, but in itself
>     doesn't motivate adding an extra dependency; that needs to be
>     motivated by a better understanding of what it will do for users and
>     what the user interface will look like for GNOME 3.
>
>     My initial understanding of the Zeitgeist engine was that it was
>     a data collection engine to collect a rich view of how the user
>     used their computer over time, which would then be used to build
>     an OLPC style journal interface; but that understanding fuzzes
>     at the edges when people are pressed about this, things like
>     deducing related documents from temporal overlaps and tagging
>     enter into the picture. This doesn't make me comfortable.
>
>     There are also questions here of the relationship with Tracker. If
>     Tracker really lives up to its promise, shouldn't timeline
>     information simply be extra metadata added in the Tracker store;
>     after all, a timeline really is just an indexed and extended
>     view of the classic ctime/mtime/atime metadata?
>
>     If querying the Tracker database for this is a) not sufficiently
>     efficient b) too cumbersome to code c) requires expert training
>     in RDF, then that, to me, would throw doubt on the whole Tracker
>     enterprise.
>
>     What would make us most comfortable would be a comprehensive
>     picture of how Tracker, Zeitgeist, and Nautilus work together
>     with the shell to allow finding your stuff. Now it is probably
>     not completely realistic for me to hang await for this to show
>     up in my inbox in finished form, so the first step (from my
>     technical perspective) is to get a clear statement of what the
>     Zeitgeist engine does, what new user interfaces are enabled by
>     that operation, what it does *not* do, and how it relates to
>     Tracker.
>
>     If the Zeitgeist people are interested in being in GNOME 2.30,
>     perhaps they can provide a similar preview module proposal to this
>     and answer that question there.
>
> Resource usage:
>
>  GNOME Shell is the gnome-shell module in GNOME Git, the gnome-shell
>  product in bugzilla.gnome.org, gnome-shell-list@..., and
>  #gnome-shell on irc.gnome.org.
>  
> Adoption:
>
>  Packages of GNOME Shell are available for most major operating systems
>  and distributions that use GNOME as a desktop either as part of the
>  latest versions or from 3rd party sources. Nobody is currently
>  using it as the default GUI.
>
> GNOME-ness:
>
>  In addition to the use of GNOME resources as mentioned above;
>  GNOME Shell development is being done as close to possible to the
>  GNOME community; it has been a major topic of discussion at last
>  years and this years Boston GNOME Summit and at GCDS this summer;
>  the GNOME art and design community have been extensively
>  consulted (we could use more help!), it is translated by the
>  GNOME translation teams, and so forth.
>
> License:
>
>  GPL
>
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list@...
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Martyn Russell-4]

On 02/11/09 22:59, Jamie McCracken wrote:
> On Mon, 2009-11-02 at 17:12 -0500, Owen Taylor wrote:
> I personally would like to merge zeitgeist functionality into tracker
> but really its up to the zeitgeist team on whether they are willing to
> do this (it would mean converting the python code to Vala/Genie or C as
> well)

Why is that necessary? It should work with Python AFAIK.

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

[Gustavo Noronha Silva-5]

On Tue, 2009-11-03 at 00:11 +0100, Seif Lotfy wrote:
> >     Zeitgeist engine does, what new user interfaces are enabled by
> >     that operation, what it does *not* do, and how it relates to
> >     Tracker.

> I will write a better explanation in a new mail on the tracker ML.

I am also missing the simple description of what Zeitgeist does, and
what it does not do. I think something like this would help a lot:

"Zeitgeist watches accesses to files using the following sources: x, y,
z. It provides a D-Bus interface (link to a doc or service definition
file) that applications can query like this: one simple example.
Zeitgeist does not: 1) change file metadata 2) store file metadata 3)
copy, move or delete files 4) send emails" =)

See you,

--
Gustavo Noronha Silva <gns@...>
GNOME

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

[Mikkel Kamstrup Erlandsen-2]

2009/11/3 Gustavo Noronha Silva <gns@...>:

> On Tue, 2009-11-03 at 00:11 +0100, Seif Lotfy wrote:
>> >     Zeitgeist engine does, what new user interfaces are enabled by
>> >     that operation, what it does *not* do, and how it relates to
>> >     Tracker.
>
>> I will write a better explanation in a new mail on the tracker ML.
>
> I am also missing the simple description of what Zeitgeist does, and
> what it does not do. I think something like this would help a lot:
>
> "Zeitgeist watches accesses to files using the following sources: x, y,
> z. It provides a D-Bus interface (link to a doc or service definition
> file) that applications can query like this: one simple example.
> Zeitgeist does not: 1) change file metadata 2) store file metadata 3)
> copy, move or delete files 4) send emails" =)

Indeed we are working on such a document for Zeitgeist, we hope to
send it about this evening.

--
Cheers,
Mikkel
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Christian Neumair-2]

[orignally and accidentally just sent to Owen Taylor in private]

Dear Owen,

2009/11/2 Owen Taylor <otaylor@...>:
>  GJS and SpiderMonkey: Currently gnome-shell is build using the
>    GJS bindings to Javascript which work with the Mozilla SpiderMonkey
>    Javascript engine. The comparison to seed/JavascriptCore has been
>    discussed quite a bit in the past, I don't want to go into in
>    detail here; basically the advantages for us are:

I have not been following the GNOME shell discussions, but I wonder
why we JavaScript is needed at all. Now that some of the core modules
exhibit Python, suddently JavaScript is discussed. I have always
considered programming and script languages as interchangeable
(besides syntactic and refactoring sugar), so we need a good argument
for adding new ones that just make the dependency stack larger and
larger. I'd really strongly opt for "C + Mono + one scripting
language" or "C + Mono" or "C + one scripting language" when we talk
about the core desktop. I see no advantage whatsoever in a Babylonian
approach -- unless you convince me with good arguments.

>    In one sense SpiderMonkey is not a problematic dependency;
>    SpiderMonkey is distributed as part of xulrunner, and will be
>    present on virtually any computer where GNOME is available.

Now that both the Epiphany web browser and Yelp [1] moved away  from
Gecko to WebKit, it seems to be very odd that we suddently introduce a
XULrunner dependency again. Is this a political decision due to the
collaboration of the GNOME foundation and the Mozilla foundation that
was once announced?

Ay

best regards,
 Christian Neumair

[1]
http://git.gnome.org/cgit/yelp/commit/?h=yelp-3-0&id=3da814fdf5c3dd8d209574fdeb99cc2cf6cbdfb4

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

[Christian Neumair-2]

[orignally and accidentally just sent to Owen Taylor in private]

Dear Owen,

2009/11/2 Owen Taylor <otaylor@...>:
> This should be read as a semi-proposal: at this point I don't think
> gnome-shell is going to be ready to be shipped as a final component on
> the 2.30 schedule. But getting it into people's hands is important for
> having it be ready for GNOME 3.

Reading some of the responses, major concerns wrt accessibility,
theming and some other topics regarding "quality control" have been
raised. I'd like to add another one: All the current desktop
components (including the panel) have undergone usability studies from
major companies (Sun etc.) and many individuals. Maybe you could point
out similar usability studies for the shell? A proper investigation of
usability is a prerequisite for not making GNOME 3.0 worse than GNOME
2.30. Most developers just seem to say "try it out" when they are
faced with concerns about replacing a well thought-out system with one
that doesn't seem to be, but didn't we drop this naive kind of
development since the arrival of GNOME 2.0? I have serious concerns
when we introduce a new desktop component with rave and fanboyism, but
without any good arguments.

We have enough polished UIs that do not improve productivity -- just
try out KDE 4! We don't want no other KDE 4!

Another concern:

What happens if GNOME shell does not match the desired quality by the
time of GNOME 3.0, i.e. what is the plan B? Do we delay it? Do we ship
unfinished software that ruins our image of shipping good software?

Finally:

I am not trying to be rude. I am rather trying to explicitly state
some concerns that seem to be under the hood of your very own email. I
am not against changes. I also had some unpublished sketches and
concepts regarding "the desktop I want" [which IMO should work like a
personal life planner, i..e datebook + ..., where ... includes files,
notes, photos, associations with other datebook entries]. It pretty
much seems to be what you mention with the "Zeitgeist (data colletion)
engine to collect a rich view of how the user used their computer over
time". I don't see this kind of data-centric desktop in the GNOME
shell, so I don't see any new concepts but "just" lots of
application-centric UI polish. I just want to see good arguments for a
move to GNOME shell.

best regards,
 Christian Neumair


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

[Colin Walters]

On Wed, Nov 4, 2009 at 1:24 AM, Christian Neumair <cneumair@...> wrote:
>
> Reading some of the responses, major concerns wrt accessibility,
> theming and some other topics regarding "quality control" have been
> raised. I'd like to add another one: All the current desktop
> components (including the panel) have undergone usability studies from
> major companies (Sun etc.) and many individuals. Maybe you could point
> out similar usability studies for the shell?

None yet, but it's increasingly high priority.  We are still missing a
good chunk of the design as it is now to be implemented though.

> A proper investigation of
> usability is a prerequisite for not making GNOME 3.0 worse than GNOME
> 2.30.

I agree.

> What happens if GNOME shell does not match the desired quality by the
> time of GNOME 3.0, i.e. what is the plan B? Do we delay it? Do we ship
> unfinished software that ruins our image of shipping good software?

We delay it.

> I am not trying to be rude. I am rather trying to explicitly state
> some concerns that seem to be under the hood of your very own email. I
> am not against changes. I also had some unpublished sketches and
> concepts regarding "the desktop I want" [which IMO should work like a
> personal life planner, i..e datebook + ..., where ... includes files,
> notes, photos, associations with other datebook entries]. It pretty
> much seems to be what you mention with the "Zeitgeist (data colletion)
> engine to collect a rich view of how the user used their computer over
> time". I don't see this kind of data-centric desktop in the GNOME
> shell, so I don't see any new concepts but "just" lots of
> application-centric UI polish.

Well, we have a little bit of the infrastructure for this; the shell
actively tracks and records application usage data, for example.
We're not (at present) using this data in the UI but I have a plan to.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Colin Walters]

On Wed, Nov 4, 2009 at 1:23 AM, Christian Neumair <cneumair@...> wrote:

> I have not been following the GNOME shell discussions, but I wonder
> why we JavaScript is needed at all. Now that some of the core modules
> exhibit Python, suddently JavaScript is discussed. I have always
> considered programming and script languages as interchangeable
> (besides syntactic and refactoring sugar), so we need a good argument
> for adding new ones that just make the dependency stack larger and
> larger. I'd really strongly opt for "C + Mono + one scripting
> language" or "C + Mono" or "C + one scripting language" when we talk
> about the core desktop. I see no advantage whatsoever in a Babylonian
> approach -- unless you convince me with good arguments.

This is a large topic, but basically I think we should be conservative
for the "core desktop", and liberal for apps.  My definition of "core
desktop" is "what you need to launch applications and select windows",
not "desktop module set" which includes all kinds of applications,
applets, etc.

The specific argument for JavaScript for the core desktop is twofold:

1) It's not a platform in itself, it is supposed to be embedded in a
host platform.  In our case, the GNOME/GObject libraries are the host
platform.  No conflicts in fundamental things like threading,
mainloop, http libraries etc.
2) It's used on the web, which is by far the biggest crossplatform
application system for desktop computing.  We get the benefit of all
of the innovation going into JS from browser vendors.

On the other hand, I do think we need to be liberal for applications,
and that's the goal of GObject Introspection; make the platform
by-default more scriptable for all of the other runtimes/platforms out
there.

>
> Now that both the Epiphany web browser and Yelp [1] moved away  from
> Gecko to WebKit, it seems to be very odd that we suddently introduce a
> XULrunner dependency again. Is this a political decision due to the
> collaboration of the GNOME foundation and the Mozilla foundation that
> was once announced?

<snuffs out his cigar and waves away a bit of the smoke from the backroom>

There is no conspiracy...


More seriously...yes, it's a problem.  Roughly what I'd like to say
here is that we encourage convergence on ECMAScript 5 at a code level;
maybe the JS engine then becomes pluggable through something like
alex's GScript prototype.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Sriram Ramkrishna-5]

On Tue, Nov 3, 2009 at 5:23 PM, Christian Neumair <cneumair@...> wrote:

[orignally and accidentally just sent to Owen Taylor in private]

Dear Owen,

2009/11/2 Owen Taylor <otaylor@...>:

>  GJS and SpiderMonkey: Currently gnome-shell is build using the
>    GJS bindings to Javascript which work with the Mozilla SpiderMonkey
>    Javascript engine. The comparison to seed/JavascriptCore has been
>    discussed quite a bit in the past, I don't want to go into in
>    detail here; basically the advantages for us are:

I have not been following the GNOME shell discussions, but I wonder
why we JavaScript is needed at all. Now that some of the core modules
exhibit Python, suddently JavaScript is discussed. I have always
considered programming and script languages as interchangeable
(besides syntactic and refactoring sugar), so we need a good argument
for adding new ones that just make the dependency stack larger and
larger. I'd really strongly opt for "C + Mono + one scripting
language" or "C + Mono" or "C + one scripting language" when we talk
about the core desktop. I see no advantage whatsoever in a Babylonian
approach -- unless you convince me with good arguments.

So I was checking to see how popular javascript is compared to the others.  Javascript is much more popular than our other bindings except for C and Java according to this website:
 http://langpop.com/

This seems to me that it might be a good investment in having javascript if it means that we can build momentum from a popular language and have more people from other OSes be able to take advantage of GNOME technologies.   My two cents.

sri

--
-- Sriram Ramkrishna (sriram.ramkrishna_@@_@.gmail.com (remove _@@_)



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

[Owen Taylor]

On Wed, 2009-11-04 at 02:23 +0100, Christian Neumair wrote:

> 2009/11/2 Owen Taylor <otaylor@...>:
> >  GJS and SpiderMonkey: Currently gnome-shell is build using the
> >    GJS bindings to Javascript which work with the Mozilla SpiderMonkey
> >    Javascript engine. The comparison to seed/JavascriptCore has been
> >    discussed quite a bit in the past, I don't want to go into in
> >    detail here; basically the advantages for us are:
>
> I have not been following the GNOME shell discussions, but I wonder
> why we JavaScript is needed at all. Now that some of the core modules
> exhibit Python, suddently JavaScript is discussed. I have always
> considered programming and script languages as interchangeable
> (besides syntactic and refactoring sugar), so we need a good argument
> for adding new ones that just make the dependency stack larger and
> larger. I'd really strongly opt for "C + Mono + one scripting
> language" or "C + Mono" or "C + one scripting language" when we talk
> about the core desktop. I see no advantage whatsoever in a Babylonian
> approach -- unless you convince me with good arguments.

The most fundamental and core reason for the use of Javascript is
that it gives us a clean platform; the experience with Javascript is
that you get a very pure experience with the GNOME libraries - to do IO,
you use GIO, and so forth. There are other languages where this
would be the case (Lua for example), but it's not the case with
Python, Mono, etc which have large standard libraries that overlap
with the GNOME libraries in complicated ways.

There are a number of secondary reasons, among them:

 - Familiarity - Python is certainly widely known, but not as
   widely as Javascript, Javascript provides an opportunity to
   get more people involved with GNOME.

 - Performance; JIT compilation is more advanced and widely
   deployed for Javascript than for Python, there's a lot of
   competition going on currently on performance for open-source
   Javascript engines.

 - Sandboxing - not a huge concern at the moment; we're more
   interested in extensions that have unrestricted access to
   the shell and platform than constrained widgets, but there
   are possibilities opened up by the ability to have an
   interpreter running in a restricted context, something that
   there's a lot more experience with with Javascript than
   any other language.

In terms of "C + Mono" - well, that's certainly a discussion I don't
want to get into, but practically speaking, for whatever, reason, there
is is no use of Mono in the core of the GNOME desktop, though there
are several applications built with Mono as part of the release sets.

> >    In one sense SpiderMonkey is not a problematic dependency;
> >    SpiderMonkey is distributed as part of xulrunner, and will be
> >    present on virtually any computer where GNOME is available.
>
> Now that both the Epiphany web browser and Yelp [1] moved away  from
> Gecko to WebKit, it seems to be very odd that we suddently introduce a
> XULrunner dependency again. Is this a political decision due to the
> collaboration of the GNOME foundation and the Mozilla foundation that
> was once announced?

The reason that we went with GJS (and thus SpiderMonkey) when we
started was that at point it was more mature than Seed and maintained by
people that we knew better (like Havoc and Johan). Seed quickly made
progress and surpassed GJS in the feature set, and we got to know Rob
and Tim well too, but there's never been a choice where making a switch
from one to the other has seemed like a good use of resources.

There are ways that SpiderMonkey is better technically aligned with what
we are doing with the Shell ... after all, its being used as the core of
a large hybrid native/Javascript application, instead of just inside web
pages. So, there's more control over garbage collection, and more of a
willingness to add language extensions. There's very little interest
from the WebKit to add language extensions because they aren't usable
from web pages, which are by definition cross-browser.

But the main thing is just history and priorities.

I would emphasize that the choice of Javascript engine is largely just
not that important. We don't have any code written directly to the
SpiderMonkey C apis; everything is intermediated through
gbject-introspection. The syntax for imports and for using GObjects is
the same between GJS and Seed. We do use a number of SpiderMonkey
extensions extensively, but removing the use would be straightforward
and mechanical. If switching makes sense, we can switch at any point.

- Owen


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

[Jamie McCracken-2]

JS, whilst a good glue language, is nevertheless problematic in this it
appears impotent (no native dbus support nor subclassing). I would only
recommend it for scripting that does not need dbus. Currently a lot of
code needs to be written in C to make up for these shortfalls in
Gnome-Shell so I dont think its a particular good choice. I dont however
see it as a blocker to gnome-shell acceptance

A much better alternative to any VM out there is Vala which sports two
languages (Genie being a python/Delphi as well as Vala's c#/java syntax)
and which gives C like performance and is moulded to fit gobject and our
platform perfectly with better Dbus integration

jamie


On Wed, 2009-11-04 at 13:04 -0500, Owen Taylor wrote:

> On Wed, 2009-11-04 at 02:23 +0100, Christian Neumair wrote:
>
> > 2009/11/2 Owen Taylor <otaylor@...>:
> > >  GJS and SpiderMonkey: Currently gnome-shell is build using the
> > >    GJS bindings to Javascript which work with the Mozilla SpiderMonkey
> > >    Javascript engine. The comparison to seed/JavascriptCore has been
> > >    discussed quite a bit in the past, I don't want to go into in
> > >    detail here; basically the advantages for us are:
> >
> > I have not been following the GNOME shell discussions, but I wonder
> > why we JavaScript is needed at all. Now that some of the core modules
> > exhibit Python, suddently JavaScript is discussed. I have always
> > considered programming and script languages as interchangeable
> > (besides syntactic and refactoring sugar), so we need a good argument
> > for adding new ones that just make the dependency stack larger and
> > larger. I'd really strongly opt for "C + Mono + one scripting
> > language" or "C + Mono" or "C + one scripting language" when we talk
> > about the core desktop. I see no advantage whatsoever in a Babylonian
> > approach -- unless you convince me with good arguments.
>
> The most fundamental and core reason for the use of Javascript is
> that it gives us a clean platform; the experience with Javascript is
> that you get a very pure experience with the GNOME libraries - to do IO,
> you use GIO, and so forth. There are other languages where this
> would be the case (Lua for example), but it's not the case with
> Python, Mono, etc which have large standard libraries that overlap
> with the GNOME libraries in complicated ways.
>
> There are a number of secondary reasons, among them:
>
>  - Familiarity - Python is certainly widely known, but not as
>    widely as Javascript, Javascript provides an opportunity to
>    get more people involved with GNOME.
>
>  - Performance; JIT compilation is more advanced and widely
>    deployed for Javascript than for Python, there's a lot of
>    competition going on currently on performance for open-source
>    Javascript engines.
>
>  - Sandboxing - not a huge concern at the moment; we're more
>    interested in extensions that have unrestricted access to
>    the shell and platform than constrained widgets, but there
>    are possibilities opened up by the ability to have an
>    interpreter running in a restricted context, something that
>    there's a lot more experience with with Javascript than
>    any other language.
>
> In terms of "C + Mono" - well, that's certainly a discussion I don't
> want to get into, but practically speaking, for whatever, reason, there
> is is no use of Mono in the core of the GNOME desktop, though there
> are several applications built with Mono as part of the release sets.
>
> > >    In one sense SpiderMonkey is not a problematic dependency;
> > >    SpiderMonkey is distributed as part of xulrunner, and will be
> > >    present on virtually any computer where GNOME is available.
> >
> > Now that both the Epiphany web browser and Yelp [1] moved away  from
> > Gecko to WebKit, it seems to be very odd that we suddently introduce a
> > XULrunner dependency again. Is this a political decision due to the
> > collaboration of the GNOME foundation and the Mozilla foundation that
> > was once announced?
>
> The reason that we went with GJS (and thus SpiderMonkey) when we
> started was that at point it was more mature than Seed and maintained by
> people that we knew better (like Havoc and Johan). Seed quickly made
> progress and surpassed GJS in the feature set, and we got to know Rob
> and Tim well too, but there's never been a choice where making a switch
> from one to the other has seemed like a good use of resources.
>
> There are ways that SpiderMonkey is better technically aligned with what
> we are doing with the Shell ... after all, its being used as the core of
> a large hybrid native/Javascript application, instead of just inside web
> pages. So, there's more control over garbage collection, and more of a
> willingness to add language extensions. There's very little interest
> from the WebKit to add language extensions because they aren't usable
> from web pages, which are by definition cross-browser.
>
> But the main thing is just history and priorities.
>
> I would emphasize that the choice of Javascript engine is largely just
> not that important. We don't have any code written directly to the
> SpiderMonkey C apis; everything is intermediated through
> gbject-introspection. The syntax for imports and for using GObjects is
> the same between GJS and Seed. We do use a number of SpiderMonkey
> extensions extensively, but removing the use would be straightforward
> and mechanical. If switching makes sense, we can switch at any point.
>
> - Owen
>
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list@...
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Jason D. Clinton]

On Wed, Nov 4, 2009 at 12:22 PM, Jamie McCracken <jamie.mccrack@...> wrote:

JS, whilst a good glue language, is nevertheless problematic in this it
appears impotent (no native dbus support nor subclassing). I would only
recommend it for scripting that does not need dbus. Currently a lot of
code needs to be written in C to make up for these shortfalls in
Gnome-Shell so I dont think its a particular good choice. I dont however
see it as a blocker to gnome-shell acceptance

Regarding DBUS, there was a session about that and I blogged about it[1]. DBUS bindings will move in to in Glib/GIO, and by extension, br accessible via GObject Introspection, and thus any language--including JavaScript--will have first-class DBUS support for free. So the language is completely orthogonal to DBUS this-or-that. But we're straying from the point of this thread.

I would much rather see a discussion about the experience we would like our users to have when GNOME 3.0 comes out and how Shell will get us there.

[1] http://jasondclinton.livejournal.com/76020.html

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

[Willie Walker-2]

I also forgot to mention the issue with applets, which was raised in a
private e-mail to me.  As I understand it, the existing applets will all
need to be rewritten for GNOME Shell.  If this is the case, then we have
some issues where some accessibility applets (e.g., the MouseTweaks
dwell click applet and the {Sticky/Slow}Keys feedback keyboard applet)
would need to be ported.

Will

On Mon, 2009-11-02 at 20:15 -0500, Willie Walker wrote:

> Hi Owen:
>
> Many thanks for making this a formal proposal for comments.  I think we
> all want to get behind GNOME Shell as a nice whiz-bang feature to make
> people want to move to GNOME 3.  With the magnification support going
> into GNOME Shell, the accessibility team is also building in a
> dependency on the success of GNOME Shell.  So - we want to see it
> succeed.
>
> GNOME Shell is currently pretty much inaccessible, however, with the big
> deal breakers being keyboard traversal (try to accomplish GNOME Shell
> activities without a mouse) and AT-SPI support (try to examine and
> interact with GNOME Shell components via accerciser).  Theming is also
> another issue, but perhaps not as strong as the other two.
>
> Since accessibility is a core value of GNOME, these things really need
> to be addressed before GNOME Shell is fully blessed, IMO.
>
> Thanks!
>
> Will
>
> On Mon, 2009-11-02 at 17:12 -0500, Owen Taylor wrote:
> > Oh, the deadline was *last* Monday? Actually, I knew that, but it snuck
> > up on me, then it took me a few days to figure out what I wanted to say
> > here...
> >
> > This should be read as a semi-proposal: at this point I don't think
> > gnome-shell is going to be ready to be shipped as a final component on
> > the 2.30 schedule. But getting it into people's hands is important for
> > having it be ready for GNOME 3.
> >
> > So what makes most sense to me is to view 2.30 as a dual release; to
> > have a set of stable modules that make up the normal GNOME 2 desktop
> > release and a set of preview modules that can be added on to get a
> > beta of the GNOME 3 experience. (By beta I mean not a release candidate,
> > but rather a stabilized version that is suitable for widespread use
> > and testing but may undergo substantial changes before the final
> > release.)
> >
> > Purpose:
> >  
> >  GNOME Shell is intended to replace gnome-panel and Metacity in the
> >  GNOME 3 desktop; it takes on roles such as switching to windows,
> >  launching applications, and displaying and letting the user interact
> >  with notification.
> >
> > Target:
> >
> >  In GNOME 3, GNOME Shell will be a core part of the GNOME desktop.
> >
> > Dependencies:
> >
> >  In addition to standard GNOME platform and desktop modules, GNOME Shell
> >  currently depends on:
> >
> >   Clutter: gnome-shell-2.30 will depend on Clutter 1.2 which is
> >     planned to be finalized around January.
> >
> >   GJS and SpiderMonkey: Currently gnome-shell is build using the
> >     GJS bindings to Javascript which work with the Mozilla SpiderMonkey
> >     Javascript engine. The comparison to seed/JavascriptCore has been
> >     discussed quite a bit in the past, I don't want to go into in
> >     detail here; basically the advantages for us are:
> >
> >      - We have it working right now and don't have to spend time
> >        converting things over.
> >
> >      - We get access to a range of nice, but not essential, extensions
> >        to Javascript that have been added by the Mozilla developers
> >        based on their needs developing a complex application with JS;
> >        these include:
> >
> >        - Destructuring assignments: [x,y] = event.get_coords();
> >        - let variables with lexical scoping
> >        - Array.forEach()
> >
> >     In one sense SpiderMonkey is not a problematic dependency;
> >     SpiderMonkey is distributed as part of xulrunner, and will be
> >     present on virtually any computer where GNOME is available.
> >     GJS is a very small library on top of SpiderMonkey and poses
> >     few issues in its own. It probably would be a preview desktop
> >     module in the same category as Mutter and gnome-shell.
> >
> >     On the other hand: it is conceptually messy for GNOME to depend
> >     on two Javascript implementations and runtimes and it might be
> >     a PR problem in presenting GNOME as a project that knows where
> >     it is going :-)
> >  
> >     And SpiderMonkey has another issue; it is distributed only as
> >     part of xulrunner, and the xulrunner libraries have no binary
> >     compat guarantees between minor versions, so things linked against
> >     SpiderMonkey can need a recompile for Firefox security updates.
> >
> >     My feeling right now is to leave figuring out the Javascript
> >     engine situation as something to do as time permits, perhaps it
> >     will get clearer on its own if let sit. But if this is seen
> >     as a major problem, then we can prioritize to make sure that it is
> >     done early on.
> >
> >   Mutter: Mutter is a conversion of Metacity to be a Clutter-based
> >     window manager and compositing manager. In addition to being used
> >     in gnome-shell, it is is a core component of Moblin. It's
> >     maintained jointly by me and Tomas Frydrych.
> >
> >     (I'm not going to do a separate module proposal for Mutter, read
> >     this as a proposal for both; I'm not aware of any issues with
> >     Mutter that aren't a subset of those discussed in this proposal.)
> >
> >   ? Zeitgeist: I'm a little uncertain about this; we have patches
> >     around (that I've promised to review, but haven't yet :-() that
> >     integrate the 0.2  branch of Zeitgeist into gnome-shell in a very
> >     straightforward way without changing the UI - it's basically used
> >     as a replacement for .recently-used.xbel.
> >
> >     This is a reasonable first step to integration, but in itself
> >     doesn't motivate adding an extra dependency; that needs to be
> >     motivated by a better understanding of what it will do for users and
> >     what the user interface will look like for GNOME 3.
> >
> >     My initial understanding of the Zeitgeist engine was that it was
> >     a data collection engine to collect a rich view of how the user
> >     used their computer over time, which would then be used to build
> >     an OLPC style journal interface; but that understanding fuzzes
> >     at the edges when people are pressed about this, things like
> >     deducing related documents from temporal overlaps and tagging
> >     enter into the picture. This doesn't make me comfortable.
> >
> >     There are also questions here of the relationship with Tracker. If
> >     Tracker really lives up to its promise, shouldn't timeline
> >     information simply be extra metadata added in the Tracker store;
> >     after all, a timeline really is just an indexed and extended
> >     view of the classic ctime/mtime/atime metadata?
> >
> >     If querying the Tracker database for this is a) not sufficiently
> >     efficient b) too cumbersome to code c) requires expert training
> >     in RDF, then that, to me, would throw doubt on the whole Tracker
> >     enterprise.
> >
> >     What would make us most comfortable would be a comprehensive
> >     picture of how Tracker, Zeitgeist, and Nautilus work together
> >     with the shell to allow finding your stuff. Now it is probably
> >     not completely realistic for me to hang await for this to show
> >     up in my inbox in finished form, so the first step (from my
> >     technical perspective) is to get a clear statement of what the
> >     Zeitgeist engine does, what new user interfaces are enabled by
> >     that operation, what it does *not* do, and how it relates to
> >     Tracker.
> >
> >     If the Zeitgeist people are interested in being in GNOME 2.30,
> >     perhaps they can provide a similar preview module proposal to this
> >     and answer that question there.
> >
> > Resource usage:
> >
> >  GNOME Shell is the gnome-shell module in GNOME Git, the gnome-shell
> >  product in bugzilla.gnome.org, gnome-shell-list@..., and
> >  #gnome-shell on irc.gnome.org.
> >  
> > Adoption:
> >
> >  Packages of GNOME Shell are available for most major operating systems
> >  and distributions that use GNOME as a desktop either as part of the
> >  latest versions or from 3rd party sources. Nobody is currently
> >  using it as the default GUI.
> >
> > GNOME-ness:
> >
> >  In addition to the use of GNOME resources as mentioned above;
> >  GNOME Shell development is being done as close to possible to the
> >  GNOME community; it has been a major topic of discussion at last
> >  years and this years Boston GNOME Summit and at GCDS this summer;
> >  the GNOME art and design community have been extensively
> >  consulted (we could use more help!), it is translated by the
> >  GNOME translation teams, and so forth.
> >
> > License:
> >
> >  GPL
> >
> >
> > _______________________________________________
> > desktop-devel-list mailing list
> > desktop-devel-list@...
> > http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Owen Taylor]

On Wed, 2009-11-04 at 02:24 +0100, Christian Neumair wrote:

> 2009/11/2 Owen Taylor <otaylor@...>:
> > This should be read as a semi-proposal: at this point I don't think
> > gnome-shell is going to be ready to be shipped as a final component on
> > the 2.30 schedule. But getting it into people's hands is important for
> > having it be ready for GNOME 3.
>
> Reading some of the responses, major concerns wrt accessibility,
> theming and some other topics regarding "quality control" have been
> raised. I'd like to add another one: All the current desktop
> components (including the panel) have undergone usability studies from
> major companies (Sun etc.) and many individuals. Maybe you could point
> out similar usability studies for the shell?

We haven't done much testing yet, because there's not a whole lot of
point in spending a lot of time and effort to find out things you
already know; a certain level of completion is a necessary prerequisite.

On the other hand, we've done a lot of talking to users, looking at how
users use computers, looking at how other systems interact with users,
etc. These are generally more productive ways to drive innovative design
than detailed usability studies, which mostly give you negative results,
and show you what doesn't work.

We're getting to the point now where we *can* do direct testing of the
shell meaningfully, and I definitely would hope we'll have some initial
results by the end of the year.

> What happens if GNOME shell does not match the desired quality by the
> time of GNOME 3.0, i.e. what is the plan B? Do we delay it? Do we ship
> unfinished software that ruins our image of shipping good software?

We have a range of options, including among other things.

 - Delay further
 - Relabel what we are releasing in a way that sets appropriate
   expectations.
 - Restrict the scope and remove components to make sure that
   we can deliver the quality we desire

The exact course will have to be picked if and when the situation
arises; I don't think it's possible to plan that out now.

> I am not against changes. I also had some unpublished sketches and
> concepts regarding "the desktop I want" [which IMO should work like a
> personal life planner, i..e datebook + ..., where ... includes files,
> notes, photos, associations with other datebook entries]. It pretty
> much seems to be what you mention with the "Zeitgeist (data colletion)
> engine to collect a rich view of how the user used their computer over
> time". I don't see this kind of data-centric desktop in the GNOME
> shell, so I don't see any new concepts but "just" lots of
> application-centric UI polish. I just want to see good arguments for a
> move to GNOME shell.

There's not much I can say to this but that we really like people
getting involved in design, so publish your unpublished sketches!

- Owen


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