Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
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. Distributions need something that can gracefully decline between a composited and a non-composited environment. Not saying that Compiz can do that today, but we effectively get that with the combination of metacity and Compiz and lots of nasty hacks. But, overall it works. For a GNOME Shell like project to be successful it will need to have either two backends or some sort of architecture that would allow for GNOME Shell features to be integrated in other less featureful shell-like tools. While I love many of the concepts being explored and have suggested ideas for some of them, I just simply can't see the currently incarnation of GNOME Shell being the default for GNOME. --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
2009/3/30 Ted Gould : > 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. Distributions need something that > can gracefully decline between a composited and a non-composited > environment. Not saying that Compiz can do that today, but we > effectively get that with the combination of metacity and Compiz and > lots of nasty hacks. But, overall it works. > > For a GNOME Shell like project to be successful it will need to have > either two backends or some sort of architecture that would allow for > GNOME Shell features to be integrated in other less featureful > shell-like tools. 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 windows managers, and if they do, none uses them. So what's your point here? > While I love many of the concepts being explored and have suggested > ideas for some of them, I just simply can't see the currently > incarnation of GNOME Shell being the default for GNOME. > > --Ted > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, 2009-03-30 at 20:23 +0100, Alberto Ruiz wrote: > 2009/3/30 Ted Gould : > > 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. Distributions need something that > > can gracefully decline between a composited and a non-composited > > environment. Not saying that Compiz can do that today, but we > > effectively get that with the combination of metacity and Compiz and > > lots of nasty hacks. But, overall it works. > > > > For a GNOME Shell like project to be successful it will need to have > > either two backends or some sort of architecture that would allow for > > GNOME Shell features to be integrated in other less featureful > > shell-like tools. > > I don't get why that statement is true. For a GNOME Shell project to > be successful, it hast to be freakin good. I could not have said this better. :-) - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, 2009-03-30 at 20:23 +0100, Alberto Ruiz wrote: > 2009/3/30 Ted Gould : > > 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. Distributions need something that > > can gracefully decline between a composited and a non-composited > > environment. Not saying that Compiz can do that today, but we > > effectively get that with the combination of metacity and Compiz and > > lots of nasty hacks. But, overall it works. > > > > For a GNOME Shell like project to be successful it will need to have > > either two backends or some sort of architecture that would allow for > > GNOME Shell features to be integrated in other less featureful > > shell-like tools. > > 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 windows managers, and if they do, none uses them. > > So what's your point here? Swappable Window Managers isn't important. Being able to have graceful degradation down to non-composited environments is. To be entirely honest, some of these are problems of our own situation. Neither Mac nor Windows have to worry about shipping binary nvidia drivers either. I'm not a fan of the situation, but we've solved this problem in the past with swapping window managers. I don't think that's the only way to do it, but it's definitely the easiest today. I'm not sure of all of the demo CDs out there, but I don't think that almost all of them come up in non-composited environments on the vast majority of hardware. Having the demo be entirely different than what you get when install seems like a really bad idea. --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Tue, Mar 31, 2009 at 3:23 AM, Alberto Ruiz wrote: > 2009/3/30 Ted Gould : >> 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. Distributions need something that >> can gracefully decline between a composited and a non-composited >> environment. Not saying that Compiz can do that today, but we >> effectively get that with the combination of metacity and Compiz and >> lots of nasty hacks. But, overall it works. It can, see compiz 0.9.x (admittedly this is the new development branch and won't be stable for a while but it _can_ do it, if the opengl or composite plugins can't initialize for whatever reason compiz just falls back to being a normal WM and all the bling plugins aren't loaded. >> >> For a GNOME Shell like project to be successful it will need to have >> either two backends or some sort of architecture that would allow for >> GNOME Shell features to be integrated in other less featureful >> shell-like tools. > > 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 windows managers, and if they do, none uses them. > > So what's your point here? See KDE. They've abstracted a lot of their stuff and made special efforts so that it works with other composite window managers. > >> While I love many of the concepts being explored and have suggested >> ideas for some of them, I just simply can't see the currently >> incarnation of GNOME Shell being the default for GNOME. >> >> --Ted >> >> >> To be frank in the end, unless we see some kind of co-operation we are going to have to take a really bad route, which is forking shell so that compiz users aren't unfairly locked out of half of their desktop functionality when using future GNOME versions - I'd really hate it to come down to this. >From what I can see with the code, I know so far that gnome-shell is really just a plugin to gnome, making the job of abstracting it about 100 times easier. I don't think there needs to be a specific dependency on Mutter's scene graph - the shell isn't really transformed in any way, so it can just use the GL context and spawn another clutter context in which it draws on top. The idea would be to make your plugin a wrapper to the lib, so that the lib doesn't depend on mutter and the plugin is linked to the lib. We can do something similar in compiz as can a lot of other window managers. I was told however, that there were some javascript bits and bobs in the code which would make the task harder - but I couldn't find them in the source. Could anybody point me to these? ___ >> desktop-devel-list mailing list >> desktop-devel-list@gnome.org >> http://mail.gnome.org/mailman/listinfo/desktop-devel-list >> > > > > -- > Un saludo, > Alberto Ruiz > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > Kind Regards, -- Sam Spilsbury ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
logout desktop session,process is not kill?
I design a program.it's always loop until.
for example
#include
#include
int main(int argc,char** argv)
{
while(1)
sleep(1);
return 0;
}
User logout desktop session,again login desktop session,this process still
exists but look like not run.
When logout desktop session,which signal will be send to all process?
--
View this message in context:
http://www.nabble.com/logout-desktop-session%2Cprocess-is-not-kill--tp22797310p22797310.html
Sent from the Gnome - Desktop - Dev mailing list archive at Nabble.com.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
logout desktop session,process is not kill?
I design a program.it's always loop until.
for example
#include
#include
int main(int argc,char** argv)
{
while(1)
sleep(1);
return 0;
}
User logout desktop session,again login desktop session,this process still
exists but look like not run.
When logout desktop session,system will send which signal to all process?
--
View this message in context:
http://www.nabble.com/logout-desktop-session%2Cprocess-is-not-kill--tp22797279p22797279.html
Sent from the Gnome - Desktop - Dev mailing list archive at Nabble.com.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
