Personally, we should cede the desktop to other projects like XFCE
that work very well with minimal hardware requirements. I've noticed
a lot of projects in GNOMEFiles with goals to write lightweight
panels and what not. 10 years is a reasonable amount of time to
expect hardware
Will the 3d shell work well on OpenMoko?
On Tue, Mar 31, 2009 at 11:10 AM, Owen Taylor otay...@redhat.com wrote:
And the same applies to virtualized desktops, but more so. Don't put the
effort into avoiding 3D. Put the effort into making 3D work.
- Owen
--
Andy Tai, a...@atai.org
On Mon, 2009-04-06 at 16:52 -0700, Andy Tai wrote:
Will the 3d shell work well on OpenMoko?
1. OpenMoko is the name of the company; do you mean on the GTA02?
2. why should a UI oriented towards the desktop work on a 3.5 display?
3. the GTA02 does not have a GPU. and it barely runs 2D frameworks.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tomas Frydrych a écrit :
Josselin Mouette wrote:
I don’t think maintaining a few more packages (especially packages that
already exist today) is a big effort. But it stills bother me if we are
going to propose two entirely different user
On Sat, 2009-04-11 at 14:24 +0200, Dodji Seketeli wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tomas Frydrych a écrit :
Josselin Mouette wrote:
I don’t think maintaining a few more packages (especially packages that
already exist today) is a big effort. But it stills bother me
Personally, we should cede the desktop to other projects like XFCE that
work very well with minimal hardware requirements. I've noticed a lot of
projects in GNOMEFiles with goals to write lightweight panels and what
not. 10 years is a reasonable amount of time to expect hardware
requirements to
On Tue, 2009-04-07 at 07:09 +0800, Sam Spilsbury wrote:
A bit of work needs to be put into separating the code out (i.e
separating clutter contexts, etc)
with my Clutter maintainer hat on:
Clutter currently, and for the foreseeable future, assumes that it will
be the one library creating the
Calum Benson a écrit :
I guess the other category here is the current generation of thin
clients... not 'legacy hardware' by any means, they just aren't really
designed for this sort of thing.
Then why not just run the current metacity + gnome applet combinations of today
on that hardware ?
Le samedi 04 avril 2009 à 15:33 +0200, Dodji Seketeli a écrit :
Then why not just run the current metacity + gnome applet combinations of
today
on that hardware ? Assuming metacity + current gnome applets are not going to
vanish all of a sudden.
Of course, that would result in more work
Josselin Mouette wrote:
I don’t think maintaining a few more packages (especially packages that
already exist today) is a big effort. But it stills bother me if we are
going to propose two entirely different user experiences with two
different configurations. For the end user, it will just
2009/4/6 Jason D. Clinton m...@jasonclinton.com:
On Mon, Apr 6, 2009 at 10:34 AM, Tomas Frydrych t...@linux.intel.com wrote:
mainstream user. There are good reasons to provide legacy support, and
it's great to be able to run GNOME on a machine that is 5 years old, but
it must be seen for what
On Mon, Apr 6, 2009 at 11:37 AM, Alberto Ruiz ar...@gnome.org wrote:
You are missing the remote desktop scenario here. This is not only a
matter of working on old hardware, being able to run gnome smoothly on
a thin client solution through XDM, or VNC, or whatever is also
needed.
VNC is not
On Mon, 2009-04-06 at 17:37 +0100, Alberto Ruiz wrote:
2009/4/6 Jason D. Clinton m...@jasonclinton.com:
On Mon, Apr 6, 2009 at 10:34 AM, Tomas Frydrych t...@linux.intel.com
wrote:
mainstream user. There are good reasons to provide legacy support, and
it's great to be able to run GNOME on
On Tue, Apr 7, 2009 at 5:23 AM, Owen Taylor otay...@redhat.com wrote:
On Mon, 2009-04-06 at 17:37 +0100, Alberto Ruiz wrote:
2009/4/6 Jason D. Clinton m...@jasonclinton.com:
On Mon, Apr 6, 2009 at 10:34 AM, Tomas Frydrych t...@linux.intel.com
wrote:
mainstream user. There are good reasons
Le mardi 31 mars 2009 à 14:10 -0400, Owen Taylor a écrit :
I just don't think it makes sense to code GNOME Shell to the limitations
of other pieces of the software stack. The effort to fix the other
pieces of the stack - to create free software ways of doing thin clients
with a composited
Il giorno mer, 01/04/2009 alle 19.34 +0200, Josselin Mouette ha scritto:
I understand the rationale for going “full 3D” for GNOME Shell, but the
overall result is that we will have to maintain the gnome-panel +
metacity solution separately, for ever. This will not be a big burden,
but the real
Le lundi 30 mars 2009 à 15:20 -0500, Ted Gould a écrit :
Swappable Window Managers isn't important. Being able to have graceful
degradation down to non-composited environments is.
I totally agree with this. There is way too much hardware for which
acceleration is not supported under Linux,
Hi everyone,
Sam Spilsbury wrote:
I don't get why that statement is true. For a GNOME Shell project to
be successful, it hast to be freakin good.
Mac OS X and Windows XP are way far more successful desktop
environments than GNOME or KDE are, and they don't even have the
notion of swappable
On Mon, 2009-03-30 at 15:20 -0500, Ted Gould wrote:
On Mon, 2009-03-30 at 20:23 +0100, Alberto Ruiz wrote:
2009/3/30 Ted Gould t...@gould.cx:
On Wed, 2009-03-25 at 12:07 -0400, Owen Taylor wrote:
So, basically, no I don't see a way that GNOME Shell coexists with
Compiz other than as
Owen:
I just don't think it makes sense to code GNOME Shell to the limitations
of other pieces of the software stack. The effort to fix the other
pieces of the stack - to create free software ways of doing thin clients
with a composited snazzy desktop - is going to be comparable or less
then
On Wed, 2009-03-25 at 12:07 -0400, Owen Taylor wrote:
So, basically, no I don't see a way that GNOME Shell coexists with
Compiz other than as two separate shells for the GNOME desktop.
And I think that coexistence is part of the problem with GNOME Shell
becoming the default GNOME interface.
2009/3/30 Ted Gould t...@gould.cx:
On Wed, 2009-03-25 at 12:07 -0400, Owen Taylor wrote:
So, basically, no I don't see a way that GNOME Shell coexists with
Compiz other than as two separate shells for the GNOME desktop.
And I think that coexistence is part of the problem with GNOME Shell
On Mon, 2009-03-30 at 20:23 +0100, Alberto Ruiz wrote:
2009/3/30 Ted Gould t...@gould.cx:
On Wed, 2009-03-25 at 12:07 -0400, Owen Taylor wrote:
So, basically, no I don't see a way that GNOME Shell coexists with
Compiz other than as two separate shells for the GNOME desktop.
And I think
On Mon, 2009-03-30 at 20:23 +0100, Alberto Ruiz wrote:
2009/3/30 Ted Gould t...@gould.cx:
On Wed, 2009-03-25 at 12:07 -0400, Owen Taylor wrote:
So, basically, no I don't see a way that GNOME Shell coexists with
Compiz other than as two separate shells for the GNOME desktop.
And I think
On Tue, Mar 31, 2009 at 3:23 AM, Alberto Ruiz ar...@gnome.org wrote:
2009/3/30 Ted Gould t...@gould.cx:
On Wed, 2009-03-25 at 12:07 -0400, Owen Taylor wrote:
So, basically, no I don't see a way that GNOME Shell coexists with
Compiz other than as two separate shells for the GNOME desktop.
And
On Mon, 2009-03-23 at 17:11 -0400, Owen Taylor wrote:
On Mon, 2009-03-23 at 17:02 -0400, Colin Walters wrote:
On Mon, Mar 23, 2009 at 4:41 PM, Owen Taylor otay...@redhat.com wrote:
2) Mutter could be renamed as a project to mutter (binary, GConf schemas,
etc. Presumably, the internals
On Tue, 2009-03-24 at 19:42 +0100, Xavier Bestel wrote:
Eh, for now compiz is working and is the reference WM for linux (and
more)
Interesting point of view.
I thought that the reference window manager for GNOME was Metacity, what
with it being the only window manager which is in the GNOME
On Wed, Mar 25, 2009 at 12:47 AM, Owen Taylor otay...@redhat.com wrote:
On Tue, 2009-03-24 at 16:17 +0900, Sam Spilsbury wrote:
On Tue, Mar 24, 2009 at 8:18 AM, Johannes Schmid j...@jsschmid.de wrote:
Hi!
2) Mutter could be renamed as a project to mutter (binary, GConf schemas,
etc.
Hi!
To try and make GNOME Shell integrate with multiple window managers
would either greatly constrain the user interface vision or greatly
increase the amount of work involved. The power of the GNOME shell
approach is that we are working within the desktop scene graph of the
window
On Wed, 2009-03-25 at 20:54 +0900, Sam Spilsbury wrote:
On Wed, Mar 25, 2009 at 12:47 AM, Owen Taylor otay...@redhat.com wrote:
On Tue, 2009-03-24 at 16:17 +0900, Sam Spilsbury wrote:
On Tue, Mar 24, 2009 at 8:18 AM, Johannes Schmid j...@jsschmid.de wrote:
Hi!
2) Mutter could be
Owen Taylor wrote:
So, basically, no I don't see a way that GNOME Shell coexists with
Compiz other than as two separate shells for the GNOME desktop.
IMHO, rather than looking for gnome-shell to work with compiz or another
VM, one should rather try and make a way for applets to work on
On Thu, Mar 26, 2009 at 12:29 AM, Johannes Schmid j...@jsschmid.de wrote:
Hi!
To try and make GNOME Shell integrate with multiple window managers
would either greatly constrain the user interface vision or greatly
increase the amount of work involved. The power of the GNOME shell
approach is
On Thu, Mar 26, 2009 at 1:07 AM, Owen Taylor otay...@redhat.com wrote:
On Wed, 2009-03-25 at 20:54 +0900, Sam Spilsbury wrote:
On Wed, Mar 25, 2009 at 12:47 AM, Owen Taylor otay...@redhat.com wrote:
On Tue, 2009-03-24 at 16:17 +0900, Sam Spilsbury wrote:
On Tue, Mar 24, 2009 at 8:18 AM,
On Tue, Mar 24, 2009 at 8:18 AM, Johannes Schmid j...@jsschmid.de wrote:
Hi!
2) Mutter could be renamed as a project to mutter (binary, GConf schemas,
etc. Presumably, the internals would stay Meta*) and imported into GNOME
version control independently of metacity. The uncomposited and
On Tue, 2009-03-24 at 00:18 +0100, Johannes Schmid wrote:
Hi!
2) Mutter could be renamed as a project to mutter (binary, GConf schemas,
etc. Presumably, the internals would stay Meta*) and imported into GNOME
version control independently of metacity. The uncomposited and RENDER
code
On Tue, 2009-03-24 at 16:17 +0900, Sam Spilsbury wrote:
On Tue, Mar 24, 2009 at 8:18 AM, Johannes Schmid j...@jsschmid.de wrote:
Hi!
2) Mutter could be renamed as a project to mutter (binary, GConf schemas,
etc. Presumably, the internals would stay Meta*) and imported into GNOME
version
On 03/24/2009 08:47 AM, Owen Taylor wrote:
Using Compiz to create a GNOME desktop using GNOME applications, the
GNOME control-center, and so forth will of course remain possible. We
have no current plans to create hard dependencies on GNOME Shell within
the GNOME desktop (just as there are no
On Tue, 2009-03-24 at 10:28 -0700, Sandy Armstrong wrote:
On 03/24/2009 08:47 AM, Owen Taylor wrote:
Using Compiz to create a GNOME desktop using GNOME applications, the
GNOME control-center, and so forth will of course remain possible. We
have no current plans to create hard dependencies
On Tue, Mar 24, 2009 at 12:33 PM, Xavier Bestel xavier.bes...@free.fr wrote:
On Tue, 2009-03-24 at 10:28 -0700, Sandy Armstrong wrote:
On 03/24/2009 08:47 AM, Owen Taylor wrote:
Using Compiz to create a GNOME desktop using GNOME applications, the
GNOME control-center, and so forth will of
On Tue, 2009-03-24 at 18:33 +0100, Xavier Bestel wrote:
On Tue, 2009-03-24 at 10:28 -0700, Sandy Armstrong wrote:
On 03/24/2009 08:47 AM, Owen Taylor wrote:
Using Compiz to create a GNOME desktop using GNOME applications, the
GNOME control-center, and so forth will of course remain
On Tue, 2009-03-24 at 12:46 -0500, Jason D. Clinton wrote:
There is nothing good about compiz other than as a spectacle and
general proof of concept.
Eh, for now compiz is working and is the reference WM for linux (and
more). gnome-shell would be the proof of concept :)
It has myriad
On 03/24/2009 11:30 AM, Xavier Bestel wrote:
On Tue, 2009-03-24 at 13:53 -0400, Owen Taylor wrote:
On Tue, 2009-03-24 at 18:33 +0100, Xavier Bestel wrote:
On Tue, 2009-03-24 at 10:28 -0700, Sandy Armstrong wrote:
On 03/24/2009 08:47 AM, Owen Taylor wrote:
Using Compiz to create a GNOME
Now that the GNOME-2.27 cycle is beginning, I'd like to come up with
a definitive plan for how we are going to be developing the Metacity
codebase in the context of Mutter and gnome-shell.
To review the current situation:
- Metacity is developed in GNOME svn by Thomas Thurman and others.
On Mon, Mar 23, 2009 at 4:41 PM, Owen Taylor otay...@redhat.com wrote:
2) Mutter could be renamed as a project to mutter (binary, GConf schemas,
etc. Presumably, the internals would stay Meta*) and imported into GNOME
version control independently of metacity. The uncomposited and RENDER
code
On Mon, 2009-03-23 at 17:02 -0400, Colin Walters wrote:
On Mon, Mar 23, 2009 at 4:41 PM, Owen Taylor otay...@redhat.com wrote:
2) Mutter could be renamed as a project to mutter (binary, GConf schemas,
etc. Presumably, the internals would stay Meta*) and imported into GNOME
version control
On Mon, Mar 23, 2009 at 5:11 PM, Owen Taylor otay...@redhat.com wrote:
But it could also be confusing, and unless you are going to keep on
merging Metacity wholesale into mutter, there's not a big advantage in
having them in the same repository. 'git cherry-pick' has no special
intelligence
On Mon, 2009-03-23 at 17:23 -0400, Colin Walters wrote:
On Mon, Mar 23, 2009 at 5:11 PM, Owen Taylor otay...@redhat.com wrote:
But it could also be confusing, and unless you are going to keep on
merging Metacity wholesale into mutter, there's not a big advantage in
having them in the same
Hi!
2) Mutter could be renamed as a project to mutter (binary, GConf schemas,
etc. Presumably, the internals would stay Meta*) and imported into GNOME
version control independently of metacity. The uncomposited and RENDER
code paths would gradually be removed leaving just a Clutter based
48 matches
Mail list logo
