Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
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 RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. Actually I am bit in favor of this approach. Having the window manager and the shell separated has the advantage that they can be used independently. Think about things like Gnome Mobile or Netbooks - probably you want a composited wm here but you don't want GNOME Shell (but probably another shell that is based on a mutter-plugin). Definitely. If the WM and the shell were integrated, it would mean that a severe chunk of functionality would be lost when using other window managers like compiz with GNOME. It's totally possible to separate the shell and the WM and instead abstract calls to the WM with DBUS. That way compiz can have a plugin to support functionality required by gnome-shell. I also like that mutter would only keep that code that is based on clutter. The RENDER stuff is mostly taken care of by compiz and metacity is for non-composited Desktops. All three have their use-cases. Compiz never used RENDER and has always been a traditionally OpenGL compositing manager. While there is support to add a RENDER backend in compiz (it is one of our goals), the likelyhood is that it would not support the majority of our functionality. That said, besides testing from time to time (which is restricted by the state of current open-source api drivers vs. bad performance on my intel-graphik netbook) I am not very involved in gnome-shell development. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Sam Spilsbury ___ 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, 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 paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. Actually I am bit in favor of this approach. Having the window manager and the shell separated has the advantage that they can be used independently. Think about things like Gnome Mobile or Netbooks - probably you want a composited wm here but you don't want GNOME Shell (but probably another shell that is based on a mutter-plugin). In my mind, the Javascript + gobject-introspection approach is the right way to go for all of these use cases. Just use different Javascript. Resource consumption is not significantly higher than with a C-based plugin, and it's much easier to achieve the customization at that level. But that being said, there is current development with Mutter (what Mutter was originally written for) that don't use Javascript and gobject-introspection. Respecting that and not creating a fork is why this option seems like the appropriate choice at the moment. I also like that mutter would only keep that code that is based on clutter. The RENDER stuff is mostly taken care of by compiz and metacity is for non-composited Desktops. All three have their use-cases. (Actually, compiz is GL-based like Mutter/gnome-shell.) - 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 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 control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. Actually I am bit in favor of this approach. Having the window manager and the shell separated has the advantage that they can be used independently. Think about things like Gnome Mobile or Netbooks - probably you want a composited wm here but you don't want GNOME Shell (but probably another shell that is based on a mutter-plugin). Definitely. If the WM and the shell were integrated, it would mean that a severe chunk of functionality would be lost when using other window managers like compiz with GNOME. It's totally possible to separate the shell and the WM and instead abstract calls to the WM with DBUS. That way compiz can have a plugin to support functionality required by gnome-shell. 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 manager/compositor. 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 hard dependencies on gnome-panel now.) - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Games will make 3D mandatory for 2.28
On Mon, Mar 23, 2009 at 06:21:48PM -0500, Jason D. Clinton wrote: This is not a proposal or RFC. This is what is happening; I am merely make it abundantly clear well in advance of it being released to the general public. Games which will require 3D for 2.28: * Gnometris * Lights Off (pending approval of Seed/GJS dependency during proposal period) * Same Gnome (pending approval of Seed/GJS dependency during proposal period) So I assume release team should announce some dependencies earlier if it appears to be a no brainer? Whatever your opinion, remember: these are just games. Don't take this announcement too seriously. I saw you commenting (blog IIRC) about this, this is existing code right that is now used as the only method (scrapping of 2D)? Or totally new code? Assume new for Lights Off and Same Gnome. Anyway, looking forward to the change. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Games will make 3D mandatory for 2.28
On Tue, Mar 24, 2009 at 10:58 AM, Olav Vitters o...@bkor.dhs.org wrote: On Mon, Mar 23, 2009 at 06:21:48PM -0500, Jason D. Clinton wrote: This is not a proposal or RFC. This is what is happening; I am merely make it abundantly clear well in advance of it being released to the general public. Games which will require 3D for 2.28: * Gnometris * Lights Off (pending approval of Seed/GJS dependency during proposal period) * Same Gnome (pending approval of Seed/GJS dependency during proposal period) So I assume release team should announce some dependencies earlier if it appears to be a no brainer? Well, Clutter 1.0 is already in so we're good there. Regarding the JavaScript games, it seems that everyone agrees that JavaScript is going in to Gnome 2.28. GJS seems to have the leg-up as the Gnome-Shell preferred engine. As for which one, Robert Carr has plans to make Seed and GJS run-time compatible (to the extent that the underlying engines have implemented the ECMA specs and same features) by the time the module proposal period opens. I was planning on leaving the proposal up to him due to the requirement that the proposal must be made by the module maintainer. Currently, ScriptCore (as seen in gtkwebkit 1.1, Safari 4 beta, Chrome 2 beta) is about 2x faster than Tracemonkey (as seen in Firefox 3.1 beta) on the Sunspider benchmarks. It seems like allowing both as dependencies is the only way to go forward and since they should be (mostly) run-time compatible, it shouldn't matter, really. The only thing that worries me is Seed/GJS's both depend on the stability of GIR/GOI. But since Owen knows more about the status of that than I do and seems comfortable with the timeline, I do not foresee this really being an issue. Whatever your opinion, remember: these are just games. Don't take this announcement too seriously. I saw you commenting (blog IIRC) about this, this is existing code right that is now used as the only method (scrapping of 2D)? Or totally new code? Assume new for Lights Off and Same Gnome. Anyway, looking forward to the change. Aisleriot is the only game that we are committing to maintaining the old 2D engine on, for now. We're strapped for resources and the thought of doubling our maintenance burden for every game that gets an upgraded engine is not appealing. ___ 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 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 hard dependencies on gnome-panel now.) Yeah, but I can still use gnome-panel in compiz. I understand the reasoning here, and don't have any suggestions or anything, but it's a bit disappointing that the new desktop experience will be so tied to the window manager. Sandy ___ 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, 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 GNOME Shell within the GNOME desktop (just as there are no hard dependencies on gnome-panel now.) Yeah, but I can still use gnome-panel in compiz. I understand the reasoning here, and don't have any suggestions or anything, but it's a bit disappointing that the new desktop experience will be so tied to the window manager. Asking to leave all the compiz goodness will be a tough sell :) ___ 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 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 course remain possible. We have no current plans to create hard dependencies on GNOME Shell within the GNOME desktop (just as there are no hard dependencies on gnome-panel now.) Yeah, but I can still use gnome-panel in compiz. I understand the reasoning here, and don't have any suggestions or anything, but it's a bit disappointing that the new desktop experience will be so tied to the window manager. Asking to leave all the compiz goodness will be a tough sell :) There is nothing good about compiz other than as a spectacle and general proof of concept. It has myriad application compatibility issues and configuring it is a usability nightmare. It tried to be desktop agnostic, so now it has four configuation backends and three window decorators--all of which are half-baked. The community around it very nearly died about a month ago. I would encourage you to try gnome-shell before you lament compiz. You'll see that already it is quite functional and there's lots of bling for those who care about such things. And since it's based on Metacity, all the app. compatibility bugs in compiz are gone. ___ 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, 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 possible. We have no current plans to create hard dependencies on GNOME Shell within the GNOME desktop (just as there are no hard dependencies on gnome-panel now.) Yeah, but I can still use gnome-panel in compiz. I understand the reasoning here, and don't have any suggestions or anything, but it's a bit disappointing that the new desktop experience will be so tied to the window manager. Asking to leave all the compiz goodness will be a tough sell :) What in particular would you miss? We're not looking to take goodness away from you, we are looking to replace it with better goodness (*). - Owen (*) Better here means, in particular, better integrated with GNOME. Hopefully more concentrated on consistent design and usability. Probably not quite as pretty, at least initially. Though there's no inherent reason we can't match Compiz bling for bling; we have access to the same hardware capabilities and a better programming environment. ___ 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, 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 application compatibility issues and configuring it is a usability nightmare. It tried to be desktop agnostic, so now it has four configuation backends and three window decorators--all of which are half-baked. The community around it very nearly died about a month ago. True, but all of this would be implementation details, sort-of. I would encourage you to try gnome-shell before you lament compiz. You'll see that already it is quite functional and there's lots of bling for those who care about such things. And since it's based on Metacity, all the app. compatibility bugs in compiz are gone. The problem isn't just with me - who cares ? After a few linux installs I can reasonably say compiz is addictive for newcomers, and these people don't care about configuration or backends or community behind the product (yet). But I don't want to sound negative or start a flamewar at all. I'll try gnome-shell if it's not too time-consuming, instead of babbling. Thanks, Xav ___ 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 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 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 hard dependencies on gnome-panel now.) Yeah, but I can still use gnome-panel in compiz. I understand the reasoning here, and don't have any suggestions or anything, but it's a bit disappointing that the new desktop experience will be so tied to the window manager. Asking to leave all the compiz goodness will be a tough sell :) What in particular would you miss? We're not looking to take goodness away from you, we are looking to replace it with better goodness (*). - Owen (*) Better here means, in particular, better integrated with GNOME. Hopefully more concentrated on consistent design and usability. Probably not quite as pretty, at least initially. Though there's no inherent reason we can't match Compiz bling for bling; we have access to the same hardware capabilities and a better programming environment. Admittedly I never tried gnome-shell. When I first tried compiz, I found the bling really just that: bling. I used it for a while, then came back to metacity - oh the horror ! Once you're accustomed to wobbly windows and workspaces-on-a-cube, there's no going back. The feeling of a solid desktop, with tangible windows is true usability, not just eye candy. There's more: non-computer-savvy people can't really grasp the workspace concept with metacity, whereas with compiz's cube (or one of its variants) it's obvious to them. Yes, metacity has a compositor. It's better but still far away. Of course I'm open to other ways to map my mind to the multiple applications running on my desktop, like most. But if gnome-shell feels clunky, if it looses the objects-I-can-touch feeling that compiz has, it's gonna be a tough sell. I agree completely with Xav. I have come to rely greatly on the Scale plugin (like Expose in OS X). There are also several animations that are either helpful directly or at least add to that tangibility Xav describes: * Animations on Window open, close, minimize, and maximize * Animations on appearance and disappearance of menus * Animation when moving a window between desktops I have tried switching to Metacity because I do occasionally experience unrecoverable hangs with Compiz's Scale plugin, but I lose too much productivity. I am looking forward to trying out gnome-shell soon so I can give more specific feedback. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GSoc- Nautilus: Add support to Google docs
Hello, I am a postgraduate student of Computer Science Engg. I am planning to work on *Nautilus: Add support to Google docs* topic as Google Summer of Code project. I was thinking of performing following steps. 1). I can use Google Documents List Data API to upload documents to Google Docs user account as well as to list the documents in Google Data API(GData) feeds. 2). Using the same API, the application (Nautilus here) can query the contents in user document. 3). A different libraries *libgdata* and *gdatacopier* *API* also provides Bi-directional copy so i can also use them for downloading, uploading and query Google docs. 4). As native format is concern, i can download/upload in the ODT or DOC format and it will not create any issues. awating suggestions/responce about extending the project and/or missing points. Regards -- Ajay Kr. Gautam Senior Postgraduate Student, Dept. of Computer Science Engg. Institute of Technology - Banaras Hindu University Varanasi-221005, UP INDIA Contact No: +91-9721272721 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
