Re: GNOME Development suite (was: Re: Glade 3.0 stable branched)
Naba Kumar wrote: Hi guys, [starting a new thread] [...] The website is kind of outdated, but I believe we can revive it and make some real effort this time. A mailing list was also setup for the group called gnome-devtools(@)gnome.org. I guess it is still used by some people (e.g. devhelp). So, in addition to coming up with plans, release system and other necessary stuffs for meta distribution, I would also like to see collaborations among the development tools in terms of integration and consistency. Yes ! this is a great start - I think that alot of the time we will bring things up on our own private mailing lists and irc channels when it might concern the whole developer suite - in these cases we should all start to CC the gnome-devtools ML (its alot easier than being subscribed to each ML for each component). Michael R. Head wrote: I just added my own comments there re: Eclipsifying GNOME as a broad target for a development suite. My argument is that if it's really easy to checkout, hack, and submit patches to any GNOME module, then there would be an increase in the numbers of fresh developers. Very good point - maybe someone could work on a garnome/jhbuild type of plugin for Anjuta to that end ? Now - I'm sure that there are all kinds of great ideas about developer tool integration etc - lets bring them up on the gnome-devtools ML ! But while we're here - lets not lose sight of an original initiative that is going to hold us all together in the future... a release schedule. Who can tell us simple minded module maintainers what they need us to do in order to participate in an initial kick-start release cycle of the gnome developer tools suite ? Maybe we need to setup a page that looks more like http://live.gnome.org/TwoPointFifteen/Desktop ? Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Proposal: NetworkManager for GNOME 2.18.
Let's try this again. I'd like to start the discussion on getting NetworkManager--more explicitly, its GNOME-based applet, nm-applet--into GNOME 2.18. Tell me about NetworkManager without using big words. NetworkManager is the future of Linux networking. Red Hat, SUSE, and others have adopted NetworkManager as their networking solution. NetworkManager supports Ethernet, PPP, and all sorts of wireless network connections. It also supports VPNs. The addition of NetworkManager to GNOME will improve the user experience and overall desktop usability. There is both a daemon and a client? Explain. The daemon is desktop-agnostic. It requires glib, HAL, and DBUS. It runs as root, at the system-level, and enforces no policy, stores no settings, and maintains no state across sessions. The client, conversely, is policy-rich. It provides a user interface, allowing user control. There are currently two clients: nm-applet, GNOME's client, and KNetworkManager, KDE's client. There is also plans for a command-line client. You are asking to merge just nm-applet? Yes, I think that makes the most sense. In the same way we have GNOME Volume Manager in the Desktop, and HAL as an implicit requirement, I propose putting nm-applet in the Desktop and have NetworkManager (or anything else implementing its DBUS API) as an implicit requirement. What else does this so-called nm-applet require? Outside of DBUS, it has no hard requirements of libraries not in GNOME. It requires gtk, glib, and gnome-keyring. Optionally, it can utilize libnotify and gcrypt. Is the DBUS API stable? It is within each branch; e.g., the stable release has a stable DBUS API for both NetworkManager and the VPN interface. What release are you proposing for 2.18? The stable branch, 0.6.x. Who maintains NetworkManager? Myself and Dan Williams of Red Hat. Dan is the real star, though, a regular Carry Grant. Where can an inquiring mind obtain more information? I like your gumption! Check out the NetworkManager homepage: http://www.gnome.org/projects/NetworkManager/ Our mailing list: http://mail.gnome.org/mailman/listinfo/networkmanager-list And my GUADEC talk, Managing Networks Since the Summer of Aught Four: http://rlove.org/talks/guadec_rlove_nm_2006.odp Go Gator Football, Robert Love ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: NetworkManager for GNOME 2.18.
On Tue, 2006-10-03 at 11:40 -0400, Robert Love wrote: Let's try this again. I'd like to start the discussion on getting NetworkManager--more explicitly, its GNOME-based applet, nm-applet--into GNOME 2.18. Tell me about NetworkManager without using big words. NetworkManager is the future of Linux networking. Red Hat, SUSE, and others have adopted NetworkManager as their networking solution. NetworkManager supports Ethernet, PPP, and all sorts of wireless network connections. It also supports VPNs. The addition of NetworkManager to GNOME will improve the user experience and overall desktop usability. There is both a daemon and a client? Explain. The daemon is desktop-agnostic. It requires glib, HAL, and DBUS. It runs as root, at the system-level, and enforces no policy, stores no settings, and maintains no state across sessions. The client, conversely, is policy-rich. It provides a user interface, allowing user control. There are currently two clients: nm-applet, GNOME's client, and KNetworkManager, KDE's client. There is also plans for a command-line client. You are asking to merge just nm-applet? Yes, I think that makes the most sense. In the same way we have GNOME Volume Manager in the Desktop, and HAL as an implicit requirement, I propose putting nm-applet in the Desktop and have NetworkManager (or anything else implementing its DBUS API) as an implicit requirement. Are you then proposing three separate tarball releases? Would you then split NM into three separate CVS modules? Where would each of those modules live? (I can't imagine KDE being excited about KNetworkManager being hosted on Gnome CVS.) If the daemon is to live somewhere neutral, like fd.o, does it have translatable strings that we'll need to worry about? On another note, I'd very much appreciate if either you or Dan could send some detailed information to the docs list (gnome-doc-list@gnome.org) about how it works, how users interact with it, under what conditions users might have problems, etc. Pointers to existing documentation from Red Hat or Novell would be great, if any exists. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
On Mon, 2006-10-02 at 23:00 -0400, Dan Winship wrote: Toby Smithe wrote: On Sun, 2006-10-01 at 01:33 +0200, Marco Cabizza wrote: So, can the metacity compositor link against something else - i.e. a compiz backend? - or is it just stalled ? Well, I know nothing of how it currently works, but I do believe that the best solution would be to incorporate support for Compiz/Beryl plugins such that Metacity compositing could be up to standard, with all the effects and what-not. Compiz plugins aren't like xscreensaver hacks or something like that where they're completely self-contained and could in theory be run by anybody. They are utterly dependent on various random bits of compiz's internal architecture. Metacity could never run compiz plugins unless it essentially became compiz. I had a feeling this would be the case, and I doubted inclusion as soon as I sent off the e-mail. I don't want a Compiz clone, so I probably think that doing something new is the better approach. It's just that there is a working infrastructure there, and it's a pity to waste it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
On 10/3/06, Rob Adams [EMAIL PROTECTED] wrote: On Tue, 2006-10-03 at 21:18 +0100, Toby Smithe wrote: I had a feeling this would be the case, and I doubted inclusion as soon as I sent off the e-mail. I don't want a Compiz clone, so I probably think that doing something new is the better approach. It's just that there is a working infrastructure there, and it's a pity to waste it. Compiz is really more of a technology demo than a seriously credible contender as a main window manager for either the GNOME or the KDE projects. It has lots of pretty eye candy (though for me it's beyond painfully slow), but it's not a particularly good window manager. You don't have to use it for very long before you notice lots of little details about being a window manager that it gets wrong. It would be nice if you could back up these claims with examples of such missing details. Or even better, file bugs so we can get them fixed. There is a component for compiz in the freedesktop.org bugzilla: https://bugs.freedesktop.org/enter_bug.cgi?product=xorgcomponent=App/compiz thanks, Kristian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
On Tue, 2006-10-03 at 17:25 -0400, Kristian Høgsberg wrote: It would be nice if you could back up these claims with examples of such missing details. Or even better, file bugs so we can get them fixed. There is a component for compiz in the freedesktop.org bugzilla: https://bugs.freedesktop.org/enter_bug.cgi?product=xorgcomponent=App/compiz Why bother when both the GNOME and KDE projects already have excellent window managers? I don't understand this idea of writing a whole new window manager just to add eye candy. There's nothing about compositing that requires a complete rewrite of the window manager. The effort would be far better spend simply extending the existing support for compositors in metacity and KWin. Realistically, compiz is unlikely ever to be accepted by either project, because it's a chimera. So why are we dumping so much effort into it? -Rob ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
On Tue, 2006-10-03 at 14:34 -0700, Rob Adams wrote: On Tue, 2006-10-03 at 17:25 -0400, Kristian Høgsberg wrote: It would be nice if you could back up these claims with examples of such missing details. Or even better, file bugs so we can get them fixed. There is a component for compiz in the freedesktop.org bugzilla: https://bugs.freedesktop.org/enter_bug.cgi?product=xorgcomponent=App/compiz Why bother when both the GNOME and KDE projects already have excellent window managers? I don't understand this idea of writing a whole new window manager just to add eye candy. There's nothing about compositing that requires a complete rewrite of the window manager. The effort would be far better spend simply extending the existing support for compositors in metacity and KWin. Realistically, compiz is unlikely ever to be accepted by either project, because it's a chimera. So why are we dumping so much effort into it? Perhaps because there's plenty of demand for it. People want eye-candy, Compiz got written and it kinda took off. Metacity and KWin just stalled, as the code and momentum didn't really come together at the same time. People aren't going to stop Compiz now; just look at the fork, Beryl, in such a short space of time! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: NetworkManager for GNOME 2.18.
quote who=Robert Love Right now both the applet and daemon live in GNOME CVS and are released together. (I don't think it's important for them to be split, unless you forsee the combination having an impact on adherence to the GNOME release schedule.) I think the crucial thing we need to do when considering new basic tech like NetworkManager is grok the integration points. Which modules throughout the (official) stack can benefit from integration with NetworkManager? This will result in great examples for third party developers and the exercise of use cases (possibly) beyond the original scope. Perhaps the most interesting (in the Chinese sense) is gnome-system-tools. Not just because of the static configuration issue, but how we integrate configuration in general. But there are lots of other places this integration matters throughout the stack, from Epiphany to applets. Thanks, - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ People keep asking me why we aren't married, and he says, 'Every time I am about to ask you, you do something annoying'. - Kate Beckinsale ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: NetworkManager for GNOME 2.18.
On Tue, 2006-10-03 at 14:44 -0400, Jeff Waugh wrote: quote who=Robert Love Right now both the applet and daemon live in GNOME CVS and are released together. (I don't think it's important for them to be split, unless you forsee the combination having an impact on adherence to the GNOME release schedule.) I think the crucial thing we need to do when considering new basic tech like NetworkManager is grok the integration points. Which modules throughout the (official) stack can benefit from integration with NetworkManager? This will result in great examples for third party developers and the exercise of use cases (possibly) beyond the original scope. Perhaps the most interesting (in the Chinese sense) is gnome-system-tools. Not just because of the static configuration issue, but how we integrate configuration in general. But there are lots of other places this integration matters throughout the stack, from Epiphany to applets. One of the nice things about NM is knowing when you are connected and when you are not. Some apps already have patches to utilize this for say offline modes. As for static configuration issues, it is on the NetworkManager development map though I am not sure how far they have gotten or how much longer they think it will take. My guess is it is not very soon. I know at Red Hat at least, one of the goals when starting NM was to replace the if* stack so we didn't have to maintain two networking systems. Unfortunately, dynamic networks is still a big mountain to climb. Anyway as part of the release team +1 for NM-applet being in the release and gnome apps starting to (optionally) rely on the extra info NM can give them. -- John (J5) Palmieri [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
On 10/3/06, Rob Adams [EMAIL PROTECTED] wrote: Why bother when both the GNOME and KDE projects already have excellent window managers? I don't understand this idea of writing a whole new window manager just to add eye candy. There's nothing about compositing that requires a complete rewrite of the window manager. The effort would be far better spend simply extending the existing support for compositors in metacity and KWin. Why would the effort be better spent writing duplicate code? There is nothing platform specific about the compositing, neither is there really anything platform specific about general window manager behaviour. Code from Metacity can be re-used in Compiz plugins and even now it does almost everything I could ask from it. Realistically, compiz is unlikely ever to be accepted by either project, because it's a chimera. So why are we dumping so much effort into it? Why is it a chimera, because the GNOME dependent modules are optional? That makes no sense to me. I rather see this as Compiz' biggest strength, since it encourages code sharing and cooperation (as well as experimentation). Is there really any objective reason why Compiz shouldn't be at least considered as a potential successor to Metacity? Daniel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: NetworkManager for GNOME 2.18.
On Tue, 2006-10-03 at 12:30 -0400, Robert Love wrote: On Tue, 2006-10-03 at 11:24 -0500, Shaun McCance wrote: Are you then proposing three separate tarball releases? Would you then split NM into three separate CVS modules? Where would each of those modules live? (I can't imagine KDE being excited about KNetworkManager being hosted on Gnome CVS.) I don't think separate tarball releases are necessary, although that is something we can discuss if its a requirement for GNOME merging. (KNetworkManager is already a separate release.) Right now both the applet and daemon live in GNOME CVS and are released together. That's fine by me, but that's not the impression I got from your original proposal. You said you're asking to merge just nm-applet, and making the daemon an external dependency. To me, that implies that they're separate packages. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
On Wed, 2006-10-04 at 00:36 +0200, Daniel Borgmann wrote: On 10/3/06, Rob Adams [EMAIL PROTECTED] wrote: Realistically, compiz is unlikely ever to be accepted by either project, because it's a chimera. So why are we dumping so much effort into it? Why is it a chimera, because the GNOME dependent modules are optional? That makes no sense to me. I rather see this as Compiz' biggest strength, since it encourages code sharing and cooperation (as well as experimentation). Is there really any objective reason why Compiz shouldn't be at least considered as a potential successor to Metacity? 1) Metacity has, over the years, accumulated a lot of details about how windows are managed. These were designed to address our users' and developers' needs. Any replacement would have to dedicate quite a lot of time to get these details right. 2) Metacity's theme format is stable. Dropping in a replacement that can't use existing themes creates massive churn. 3) Even if all other things were compatible, having a different binary name creates some churn that we have yet to solve well. (See the recent difficulties with changing Gnopernicus to Orca, and how we didn't really get it right despite a lot of discussion.) Why don't we just add the required features to Metacity? -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
On Wed, 2006-10-04 at 00:36 +0200, Daniel Borgmann wrote: Why is it a chimera, because the GNOME dependent modules are optional? That makes no sense to me. I rather see this as Compiz' biggest strength, since it encourages code sharing and cooperation (as well as experimentation). Is there really any objective reason why Compiz shouldn't be at least considered as a potential successor to Metacity? The effort required to add eye candy effects to metacity is much smaller, in my opinion, than the effort required to make compiz a good, usable window manager. Most of the effects code is likely to be reusable in metacity and KWin; compiz makes for a good experimental platform, but in the end, that's all it is. In that regard, it is perhaps similar to the luminosity project. It's a great technology demonstrator. It shows us what is possible with this new architecture, and we can afford to add crack to it and see how it well it plays out without making our end-users the subjects of any misguided experiments along the way. Whether it makes sense to add compiz-style plugins to metacity remains to be seen, though at least in the case of accessibility tools it seems that there are advantages to this approach. Certainly the incredibly bewildering adventure that is getting compiz running and configured isn't what we want as far as a GNOME window manager experience goes, though compiz's problems aren't limited to configuration. -Rob ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
quote who=Daniel Borgmann Is there really any objective reason why Compiz shouldn't be at least considered as a potential successor to Metacity? Because it does not benefit from a long history of development, testing and fixes for crucial window management behaviour, and gives everyone terrible, vomitous flashbacks to Sawfish configuration (those who don't feel ill have not learned from history, and are doomed to repeat it). It definitely seems like a useful testing platform for cool effects, but it doesn't seem like a step forward for GNOME in general. It would be great if we could figure out a way to take well-tested effects and improvements from Compiz and deliver them to Metacity... - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ From my observation, when it comes to porting Linux to a particular device, a point doesn't appear to be necessary. - mpt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
On Tue, 2006-10-03 at 14:34 -0700, Rob Adams wrote: On Tue, 2006-10-03 at 17:25 -0400, Kristian Høgsberg wrote: It would be nice if you could back up these claims with examples of such missing details. Or even better, file bugs so we can get them fixed. There is a component for compiz in the freedesktop.org bugzilla: https://bugs.freedesktop.org/enter_bug.cgi?product=xorgcomponent=App/compiz Why bother when both the GNOME and KDE projects already have excellent window managers? I don't understand this idea of writing a whole new window manager just to add eye candy. There's nothing about compositing that requires a complete rewrite of the window manager. The effort would be far better spend simply extending the existing support for compositors in metacity and KWin. Realistically, compiz is unlikely ever to be accepted by either project, because it's a chimera. So why are we dumping so much effort into it? In fact David R. tried the compositing in metacity approach and ran into technical difficulties (and in fact I believe that Kristian and Soeren eventually bumped into the same limitations). -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
On Tue, 2006-10-03 at 17:48 -0500, Shaun McCance wrote: On Wed, 2006-10-04 at 00:36 +0200, Daniel Borgmann wrote: On 10/3/06, Rob Adams [EMAIL PROTECTED] wrote: Realistically, compiz is unlikely ever to be accepted by either project, because it's a chimera. So why are we dumping so much effort into it? Why is it a chimera, because the GNOME dependent modules are optional? That makes no sense to me. I rather see this as Compiz' biggest strength, since it encourages code sharing and cooperation (as well as experimentation). Is there really any objective reason why Compiz shouldn't be at least considered as a potential successor to Metacity? 1) Metacity has, over the years, accumulated a lot of details about how windows are managed. These were designed to address our users' and developers' needs. Any replacement would have to dedicate quite a lot of time to get these details right. compiz took much of metacity's window placement code. 2) Metacity's theme format is stable. Dropping in a replacement that can't use existing themes creates massive churn. compiz 0.2.0 has metacity theme support in the window decorator. 3) Even if all other things were compatible, having a different binary name creates some churn that we have yet to solve well. (See the recent difficulties with changing Gnopernicus to Orca, and how we didn't really get it right despite a lot of discussion.)x Why don't we just add the required features to Metacity? See my other mail about technical difficulties. -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
On Tue, 2006-10-03 at 18:53 -0400, Jeff Waugh wrote: quote who=Daniel Borgmann Is there really any objective reason why Compiz shouldn't be at least considered as a potential successor to Metacity? Because it does not benefit from a long history of development, testing and fixes for crucial window management behaviour, and gives everyone terrible, vomitous flashbacks to Sawfish configuration (those who don't feel ill have not learned from history, and are doomed to repeat it). I'm not sure how lisp like configuration equates with something that exposes all its settings in gconf and has a dbus plugin for remote control. gnome-xgl is a settings gui that is fairly generic (except for enabling Xgl on suse), although it could use a little UI love. -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
This is very much not a detail, but the last time I tried compiz (which was on ubuntu dapper), it lacked *ALL* of the keybindings to maximize, minimize, etc windows. Certainly not a minor detail. On Tue, 3 Oct 2006, [UTF-8] Kristian Høgsberg wrote: On 10/3/06, Rob Adams [EMAIL PROTECTED] wrote: On Tue, 2006-10-03 at 21:18 +0100, Toby Smithe wrote: I had a feeling this would be the case, and I doubted inclusion as soon as I sent off the e-mail. I don't want a Compiz clone, so I probably think that doing something new is the better approach. It's just that there is a working infrastructure there, and it's a pity to waste it. Compiz is really more of a technology demo than a seriously credible contender as a main window manager for either the GNOME or the KDE projects. It has lots of pretty eye candy (though for me it's beyond painfully slow), but it's not a particularly good window manager. You don't have to use it for very long before you notice lots of little details about being a window manager that it gets wrong. It would be nice if you could back up these claims with examples of such missing details. Or even better, file bugs so we can get them fixed. There is a component for compiz in the freedesktop.org bugzilla: https://bugs.freedesktop.org/enter_bug.cgi?product=xorgcomponent=App/compiz thanks, Kristian kr, Chipzz AKA Jan Van Buggenhout -- UNIX isn't dead - It just smells funny [EMAIL PROTECTED] Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'.___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: NetworkManager for GNOME 2.18.
On Tue, 2006-10-03 at 18:23 -0400, John (J5) Palmieri wrote: On Tue, 2006-10-03 at 14:44 -0400, Jeff Waugh wrote: quote who=Robert Love Right now both the applet and daemon live in GNOME CVS and are released together. (I don't think it's important for them to be split, unless you forsee the combination having an impact on adherence to the GNOME release schedule.) I think the crucial thing we need to do when considering new basic tech like NetworkManager is grok the integration points. Which modules throughout the (official) stack can benefit from integration with NetworkManager? This will result in great examples for third party developers and the exercise of use cases (possibly) beyond the original scope. Perhaps the most interesting (in the Chinese sense) is gnome-system-tools. Not just because of the static configuration issue, but how we integrate configuration in general. But there are lots of other places this integration matters throughout the stack, from Epiphany to applets. One of the nice things about NM is knowing when you are connected and when you are not. Some apps already have patches to utilize this for say offline modes. As for static configuration issues, it is on the NetworkManager development map though I am not sure how far they have gotten or how much longer they think it will take. My guess is it is not very soon. I know at Red Hat at least, one of the goals when starting NM was to replace the if* stack so we didn't have to maintain two networking systems. Unfortunately, dynamic networks is still a big mountain to climb. The basic daemon capabilities are there, you can set static IP's via sysconfig on opensuse/sled. Anyway as part of the release team +1 for NM-applet being in the release and gnome apps starting to (optionally) rely on the extra info NM can give them. Online/offline information should really be a platform API. -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
Rob Adams wrote: Why bother when both the GNOME and KDE projects already have excellent window managers? I don't understand this idea of writing a whole new window manager just to add eye candy. There's nothing about compositing that requires a complete rewrite of the window manager. The effort would be far better spend simply extending the existing support for compositors in metacity and KWin. Realistically, compiz is unlikely ever to be accepted by either project, because it's a chimera. So why are we dumping so much effort into it? Because that's where the innovation is happening. Metacity advertises itself as the boring window manager for the adult in you (from its README file). Things like compiz's water plugin don't really fit with that. You can say yeah, but the water plugin is crack, and maybe you're right, but I don't think anyone can really say that for sure now. Once upon a time people thought that virtual workspaces were crack too. Our usability team was experimenting with using the water effect, colored drop shadows, and various other bits of compiz bling to call the user's attention to modal dialogs to make it more clear why they can't interact with the application. Maybe that's crack, maybe it will turn out to be really useful. We can't know unless we try. To quote again from the metacity README, Metacity is firmly in the choose good defaults camp rather than the offer 6 equally broken ways to do it, and let the user pick one camp. But of course, it can only manage to be in the good defaults camp because it was possible to look through all the various window managers out there and see what worked well and what didn't. No one knows what the good defaults for a compositing manager will be. Is the compiz spinning cube a good default? Our hope was that it would be more intuitive for users than the traditional switch-instantaneously-from-one-workspace-to-another aka I clicked on the pager and all of my windows disappeared! model. But Kristian's plane plugin provides a slightly different interface. Will that turn out to be better than the cube? Maybe. It's too early to tell. Some day we'll want the boring compositing manager for the adult in you, and that may very well turn out to be the metacity compositor. But we can't have that until we've played around enough to know what sort of compositing effects the adult in you has use for. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
On Tue, 2006-10-03 at 18:33 -0500, Travis Watkins wrote: Does compiz work without a 3D card? If not it's worthless as anything but a power user addon. Very few desktop cards don't have 3D capabilities, but yes its a possible issue. There are ways to address it like better software fallbacks though. Based on reaction to Xgl/Compiz from users and in trade press, it is definitely more than a power user add on. -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
Em Qua, 2006-10-04 às 01:29 +0200, Chipzz escreveu: This is very much not a detail, but the last time I tried compiz (which was on ubuntu dapper), it lacked *ALL* of the keybindings to maximize, minimize, etc windows. Certainly not a minor detail. It's quite possible that you tried an early version of the beryl fork, not compiz. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
On Tue, 2006-10-03 at 19:54 -0400, Jeff Waugh wrote: quote who=JP Rosevear I'm not sure how lisp like configuration equates with something that exposes all its settings in gconf and has a dbus plugin for remote control. gnome-xgl is a settings gui that is fairly generic (except for enabling Xgl on suse), although it could use a little UI love. Compiz may not be programmable, but it contains almost as many settings as the rest of GNOME combined [1]. Do we really want to bring that kind of thing upon ourselves again? Plugins changing behaviour so fundamentally is pretty scary, too (in terms of supportability, combinatorial brainfuckage, etc). Certainly we have to move forward on integration of a compositing manager and useful (and pretty) effects, but Compiz in its current state seems like a backwards step in many ways. New and cool technologies don't have to mean we forget what we've learned over the last six years. You don't have to expose everything in the main user facing UI, we do this all the time in GNOME. Support of cracktastic plugins not included in the basic compiz could be an issue, but I'm not sure its worth sacrificing the flexibility of the plugin system for, especially if there is a good way to detect non-standard plugins when the bug is reported. -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
JP Rosevear wrote: On Tue, 2006-10-03 at 18:33 -0500, Travis Watkins wrote: Does compiz work without a 3D card? If not it's worthless as anything but a power user addon. Very few desktop cards don't have 3D capabilities, More than you think: OLPC, thin clients, old machines, etc. Maybe not in the business world that Novell and al. are targetting, but surely in the other world. Including that run on platform (recycled) whose card vendor refuse to support (think nVidia on PowerPC), etc. There are plenty of reasons why 3D support should NOT be a requirement. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
Ciao, Il giorno mar, 03/10/2006 alle 18.33 -0500, Travis Watkins ha scritto: Does compiz work without a 3D card? If not it's worthless as anything but a power user addon. This is exactly something I was thinking of a couple hours ago. Maybe compiz should be able to work EVEN WITHOUT the composite extension so that it may act just like the boring window manager for the adult in you. Still with all the effort put in compiz and everything else ( AIGLX, X11 in general... ) the result is that you may now get to install some random Linux distribution and have a good chance to see those thingies work out of the box, with the usual xorg.conf hacking. And you *might* even not miss what you used to do with metacity. I used to have 12 workspaces and left-hand-only keybindings to select them, which is the thing I'm missing *right now* as well as some wnck-applet integration - compiz's GNOME integration in general sucks *right now* - and random stuff. My opinion is that compiz is a perfectly working toy in my box, which means that becoming some window manager that should work basically fine might take some time, but if we get to a point where one sees that he just doesn't notice the difference in configuring metacity or compiz PLUS all the shinycrazybubblegum and yummygummycube effects ( that one might even ( want to ) get rid of ), well, I guess that stabilising everything will be just a matter of time! Oh, thanks everyone for the replies on metacity, I wasn't really sure of what was going on :) Ciao ~marco signature.asc Description: Questa parte del messaggio è firmata ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
On 10/3/06, Travis Watkins [EMAIL PROTECTED] wrote: Does compiz work without a 3D card? If not it's worthless as anything but a power user addon. This is orthogonal to the compiz vs. metacity discussion. Both compositors have exactly the same requirements to the underlying stack (X.org and Mesa) and have the same limitations imposed on them by the shortcomings in the drivers (direct rendering Open GL and Xv not working). Wether or not we want a composited desktop is a different topic, but I think the general consensus is that we do, as long as there's an option to fall back to a legacy desktop (that is, a non-composited desktop). Kristian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
On Tue, 2006-10-03 at 21:30 -0400, Hubert Figuiere wrote: JP Rosevear wrote: On Tue, 2006-10-03 at 18:33 -0500, Travis Watkins wrote: Does compiz work without a 3D card? If not it's worthless as anything but a power user addon. Very few desktop cards don't have 3D capabilities, More than you think: OLPC, thin clients, old machines, etc. Maybe not in the business world that Novell and al. are targetting, but surely in the other world. Including that run on platform (recycled) whose card vendor refuse to support (think nVidia on PowerPC), etc. Well, I'm pretty sure there aren't a lot of thin clients in people's houses either so this is not a novell's corporate market thing. Thin clients have 3D cards as well in some cases, many old machines have them (depending on the definition of old I suppose), although there could be be quality of driver issues there. Its also not clear to me the OLPC people (and it would seem definitely not the maemo people) want to use metacity or compiz either so its hard to tell how much consideration to give it. There are plenty of reasons why 3D support should NOT be a requirement. Probably so, but I take issue with it being simplified down to a power user addon when millions of machines can use it and many non-power users love the experience. -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
On 10/3/06, Kristian Høgsberg [EMAIL PROTECTED] wrote: Wether or not we want a composited desktop is a different topic, but I think the general consensus is that we do, as long as there's an option to fall back to a legacy desktop (that is, a non-composited desktop). So does this mean support will be added to compiz to do basic window management without requiring 3D support? Or are you suggesting we support two window managers: compiz for bling and metacity as the legacy desktop? -- Travis Watkins http://www.realistanew.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
