Re: New modules in 2.14
On Sun, 2006-01-22 at 22:04, Richard Hughes wrote: gnome-screensaver is just that, a screensaver with a defined dbus interface. gnome-power-manager does all the policy decisions, which include what to notify on suspend, resume etc. Similarly, why does gnome-screensaver need to ask gnome-power-manager to power down the screen? Isn't this a simple X call that it could do itself? It used to (I'm not sure what mode is enabled in cvs g-s), but it was not seen proper for a screensaver daemon to control the low level power management of a screen. Logically why should it? I know XScreenSaver had this feature, but that's all legacy stuff now. If you go this way, g-s shouldn't even have a notion of timeouts. All settings should be in g-p-m (maybe mirrored in g-s) and g-s should just sit and wait for request to start and stop (and maybe use a low-power hack). Xav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
I propose the following: if there's an API/ABI break after the GNOME API freeze deadline (which only applies for gnome devel platform modules, of course), then desktop library maintainers are strongly advised to notify bindings authors by sending an email to the language-bindings list. This should be enough, I think I think it might be better to notify desktop-devel-list too, since other desktop modules depend on non platform ABI as well. This sort of thing broke some a11y functionality some time back too, and it was very late in the game (during the RC phase, IIRC). Fixing it turned out to be nontrivial, so making ABI changes to exported symbols late in the release cycle seems like a problem. At the time, it was suggested that non-platform modules should also obey API freeze. My suggestion, which was a compromise, was to make desktop ABI freeze come somewhat later than the platform ABI freeze, but to have a freeze nonetheless. There's a logic in making such a freeze no later than, feature freeze, since features and external ABIs are sometimes interdependent. Bill ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
David Zeuthen wrote: On Thu, 2006-01-19 at 14:19 +0800, James Henstridge wrote: Richard Hughes wrote: Of course, this wonderful system does not exist. Again, gnome-power-manager is the best offering we have at this time. Thanks! Making g-p-m very closely tied to other GNOME stuff allows it and other programs to play nice, e.g. g-p-m telling g-s to lock the screen after hibernating, all via a nice DBUS interface. g-s can also use g-p-m to blank the screen using DPMS. This always seemed a bit weird to me. Is there any reason to choose this form of integration. Wouldn't it have been better to make gnome-screensaver listen for the HAL power management events directly, and lock the screen/throttle the screensaver where appropriate? Similarly, why does gnome-screensaver need to ask gnome-power-manager to power down the screen? Isn't this a simple X call that it could do itself? Separation by functionality. So I think gnome-power-manager should manage the power of the system (includes the display) and gnome-screensaver should manage putting up a screen savers and locking the screen. Either should have fall-backs if the other is not available of course. How each depend on the other seems like an implementation detail and can probably be changed. Is it interesting? I guess the main thing I found weird was that g-p-m was signalling gnome-screensaver directly rather than gnome-screensaver listening to a general power management event broadcast (which could either be from HAL or g-p-m). I guess the main question is: why would an app use the gnome-power-manager interfaces to respond to power management events rather than HAL's notifications? I think this is sorta covered in these mails http://lists.freedesktop.org/archives/hal/2006-January/004256.html http://lists.freedesktop.org/archives/hal/2006-January/004239.html Basically preparing the desktop before suspending is a) a somewhat complicated process if you want to do it right [1] b) something that varies with the reason for the suspend [2] c) notifications / prompts for the user under certain circumstances [3] d) something apps may want to stall [4] There's just a lot of corner cases and I do think these justify g-p-m if we want the right user experience. All this is about policy and thus don't belong in HAL. Btw, is it now more clear that we need the policy piece in the desktop session and not on a system-level? Okay, it does sound like some per-user program is necessary to handle these parts of the power management system. The fact that the g-p-m contains special knowledge of gnome-screensaver still seems a weird way of doing things, and won't scale as more apps become aware of power management events. As an example, say the Totem developers decide it would be nice to disable the video pipeline when the laptop's lid is closed to conserve power. It would be much easier to do this by making totem listen for a broadcast, rather than modifying g-p-m to send a special notification to Totem. James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Sun, 2006-01-22 at 19:26 +0800, James Henstridge wrote: There's just a lot of corner cases and I do think these justify g-p-m if we want the right user experience. All this is about policy and thus don't belong in HAL. Btw, is it now more clear that we need the policy piece in the desktop session and not on a system-level? Okay, it does sound like some per-user program is necessary to handle these parts of the power management system. The fact that the g-p-m contains special knowledge of gnome-screensaver still seems a weird way of doing things, and won't scale as more apps become aware of power management events. Ohh yes, there is talk of g-p-m having a session DBUS interface for programs to register for, like gnome-screensaver and Network Manager. At the moment, you are right, and these are hardcoded. As an example, say the Totem developers decide it would be nice to disable the video pipeline when the laptop's lid is closed to conserve power. It would be much easier to do this by making totem listen for a broadcast, rather than modifying g-p-m to send a special notification to Totem. Ohh yes, I totally agree. We've got bugs open trying to hash out the details, and we're actively working on the issues at the moment. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Thu, 2006-01-19 at 14:19 +0800, James Henstridge wrote: snip This always seemed a bit weird to me. Is there any reason to choose this form of integration. Wouldn't it have been better to make gnome-screensaver listen for the HAL power management events directly, and lock the screen/throttle the screensaver where appropriate? gnome-screensaver is just that, a screensaver with a defined dbus interface. gnome-power-manager does all the policy decisions, which include what to notify on suspend, resume etc. Similarly, why does gnome-screensaver need to ask gnome-power-manager to power down the screen? Isn't this a simple X call that it could do itself? It used to (I'm not sure what mode is enabled in cvs g-s), but it was not seen proper for a screensaver daemon to control the low level power management of a screen. Logically why should it? I know XScreenSaver had this feature, but that's all legacy stuff now. I guess the main question is: why would an app use the gnome-power-manager interfaces to respond to power management events rather than HAL's notifications? Not quite sure what you mean? You mean about the registering for notification stuff? That part is in heavy discussion at the moment from lots of developers, and nothing is in CVS yet. Currently g-p-m hardcodes the events that happen on suspend, such as notifying NetworkManager and g-s over dbus. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On 1/21/06, Vincent Untz [EMAIL PROTECTED] wrote: Le vendredi 20 janvier 2006 à 22:52 +, Gustavo J. A. M. Carneiro a écrit : I propose the following: if there's an API/ABI break after the GNOME API freeze deadline (which only applies for gnome devel platform modules, of course), then desktop library maintainers are strongly advised to notify bindings authors by sending an email to the language-bindings list. This should be enough, I think. Actually, the mail should probably also be sent to d-d-l (or maybe devel-announce-list?) since other modules depending on the library might need a change. It was (http://mail.gnome.org/archives/desktop-devel-list/2006-January/msg00418.html). ;-) But, given the length of the thread, if we really want it proposed, we should probably have it sent as the beginning of a new thread so that those who have already stopped paying attention to this one hopefully still notice the proposal. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Le samedi 21 janvier 2006 à 07:32 -0700, Elijah Newren a écrit : On 1/21/06, Vincent Untz [EMAIL PROTECTED] wrote: Le vendredi 20 janvier 2006 à 22:52 +, Gustavo J. A. M. Carneiro a écrit : I propose the following: if there's an API/ABI break after the GNOME API freeze deadline (which only applies for gnome devel platform modules, of course), then desktop library maintainers are strongly advised to notify bindings authors by sending an email to the language-bindings list. This should be enough, I think. Actually, the mail should probably also be sent to d-d-l (or maybe devel-announce-list?) since other modules depending on the library might need a change. It was (http://mail.gnome.org/archives/desktop-devel-list/2006-January/msg00418.html). ;-) Err... What I wanted to say is that if a desktop library maintainer break API/ABI, he should send a mail to language-bindings and d-d-l :-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
fre, 20,.01.2006 kl. 09.39 +0800, skrev Davyd Madeley: Quoting Elijah Newren [EMAIL PROTECTED]: On 1/18/06, Davyd Madeley [EMAIL PROTECTED] wrote: I'm with Ryan on this. I think we should give vendors a choice for the time being. It looks like the vendors have already jumped on and chosen g-p-m. Once again, I ask the question, what about our non-Linux vendors? Status quo? Or they can start working on creating the same kind of interfaces that g-p-m or the mythical PowerManager can use on the platforms where HAL doesn't work? Having it must work on all platforms as a criteria for inclusion is not going to work when we're talking about stuff that is this close to the hardware IMO. At least not in the near future. As for creating another ESD I don't know what all the fuss is about. I think the problems caused by us using ESD are greatly exaggerated, both in techical terms and wrt maintainability. The package has needed close to zero work the last few years and I don't see a lot of people complaining about it in bugzilla at least. What they do in the various forums is a different issue, but some people will disagree no matter what choices we make. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Quoting Kjartan Maraas [EMAIL PROTECTED]: As for creating another ESD I don't know what all the fuss is about. I think the problems caused by us using ESD are greatly exaggerated, both in techical terms and wrt maintainability. The package has needed close to zero work the last few years and I don't see a lot of people complaining about it in bugzilla at least. What they do in the various forums is a different issue, but some people will disagree no matter what choices we make. The point I was trying to make is that we would have been better off without any sort of hard dependance on ESD. Of course, at the time GStreamer was not available to us, but my point was more that soft dependence allows us to be more modular with what vendors want to do. --d ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Fri, Jan 20, 2006 at 09:39:12AM +0800, Davyd Madeley wrote: Quoting Elijah Newren [EMAIL PROTECTED]: It looks like the vendors have already jumped on and chosen g-p-m. Once again, I ask the question, what about our non-Linux vendors? I think crippling functionality because Hal hasn't been ported to some OSs yet is unreasonable. The alternative would be to provide a myriad of small daemons that need to be individually ported, and that time could be better spent on providing hal and giving us some consistency between hardware access on different platforms. -- Matthew Garrett | [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Fri, 2006-01-20 at 09:11 +, Matthew Garrett wrote: I think crippling functionality because Hal hasn't been ported to some OSs yet is unreasonable. The alternative would be to provide a myriad of small daemons that need to be individually ported, and that time could be better spent on providing hal and giving us some consistency between hardware access on different platforms. I'm not talking about crippling functionality; or saying that people can't use it. I'm saying let's not commit to it in Desktop at this point. Is there absolutely any reason it *must* be in Desktop? Should we include NetworkManager is Desktop also? --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Gwe, 2006-01-20 at 09:05 +, Matthew Garrett wrote: currently has no mechanism for making a distinction between background users and the user that currently 'controls' the machine. I don't think hal's the right layer to make that distinction. I'm working on implementing it at the dbus level. I question the existance of such a distinction. Take an HP box with four monitor heads and four keyboards. Who is in control. Or consider a tape monkey in the server room. Sometimes it is clear and useful - many desktops, most laptops but not something you can implement blindly. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Jan 20, 2006, at 7:43 AM, Alan Cox wrote: On Gwe, 2006-01-20 at 09:05 +, Matthew Garrett wrote: currently has no mechanism for making a distinction between background users and the user that currently 'controls' the machine. I don't think hal's the right layer to make that distinction. I'm working on implementing it at the dbus level. I question the existance of such a distinction. Take an HP box with four monitor heads and four keyboards. Who is in control. In this case you'd have four copies of g-p-m, one for each console. Only one copy obtains the right to manage the system power, this happens through the PolicyManager as described here http://blog.fubar.dk/?p=63 ... e.g. the call ClaimPolicyService() will return FALSE for everyone but the first one to ask. Thus, It is up to g-p-m to ensure that only the copy with the right to manage system power actually does - this does include the losing copies to somehow communicate to the winning copy that their display is idle and they're ready to suspend caused by inactivity. The winning copy will thus invoke the suspend, due to inactivity, if and only if all sessions have said they are inactive. How g-p-m does this is up to g-p-m.. I don't see the need to provide a framework for things like this.. All copies of g-p-m will still manage devices specific to the console, e.g. the display via DPMS on X. This probably also includes devices we know are specific to consoles (say, a subtree of all USB devices.. we can do this) but right now there's no good answer on run-time power management on Linux at least so it's not something that HAL or g-p-m currently does. It's definitely something we can and will do in the future. Waiting on kernel people. Yes.. someone needs to code up the support I rambled about plus add it to g-p-m (and make sure the g-p-m maintainer agrees so to :-). Right now it's just ideas to support various not-so-interesting-but-still-important scenarios. For non-corner cases I think g-p-m is doing pretty well and we can all thank Richard for that. Or consider a tape monkey in the server room. It's busy attempting to write Shakespeare on a good old fashioned type writer? :-) ... no, seriously, care to clarify? David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On 1/20/06, Johan Dahlin [EMAIL PROTECTED] wrote: Well, no library in the desktop can be relied upon to remain API or ABI stable; that's the reason they are in the desktop. The difference with this lib, _if_ I remember correctly, is that those other libs in the desktop were meant to be used by whoever wanted to use them, whereas libmetacity-private was expected to not be used by anything other than control-center (with the implication that if we make any changes that breaks anything other than the control center, we just don't care and won't consider it a bug). Is it not similar to wnck, which mostly the panel uses? Similar, but not the same. Havoc intended libwnck to be used by other apps besides just the panel. And other apps do use it. From the README: libwnck isn't supported in the devel platform, which means OS vendors won't guarantee the API/ABI long-term, but authors of open source apps should feel free to use libwnck as users can always recompile against a new version. (And the API/ABI has historically changed very little, I'm not changing it gratuitously or without soname increments.) While libwnck doesn't have API/ABI requirements from the release set it is in, we agreed a release cycle or two back to not break API/ABI after feature freeze. Also, when making API/ABI changes that breaks something, or adding API to libwnck that certain modules need to use, I make a best effort (which is sometimes lacking, in particular I just realized I've always forgotten to notify the bindings people -- which is perhaps why you see it as no different) to at least notify apps that I know are affected and often also provide patches. I wouldn't bother notifying anyone if I broke ABI of libmetacity-private (other than control-center), even if it was during a micro point release during the stable cycle. However... To me the name metacity-private is just another way of saying it's an unstable library and don't complain to us if we break your application. If you're fine with that, feel free to go ahead. :) I do have to say that it does sound like a very cool use you have for libmetacity-private. And, you're probably unlikely to get any breakage since no one (least of all me) seems to be interested in working on anything theme related in Metacity right now. It's just that we're not going to make any guarantees. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Fri, 2006-01-20 at 08:18 -0500, David Zeuthen wrote: Yes.. someone needs to code up the support I rambled about plus add it to g-p-m (and make sure the g-p-m maintainer agrees so to :-). Right now it's just ideas to support various not-so-interesting-but-still-important scenarios. For non-corner cases I think g-p-m is doing pretty well and we can all thank Richard for that. Thanks David. I think your DBUS API suggested could be used by a whole lot more than g-p-m, but g-v-m, and other session stuff too. As soon as the design has fleshed out, I'm all for adding code to g-p-m to support this extended mode of operation. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On 1/20/06, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: Sex, 2006-01-20 às 09:10 -0700, Elijah Newren escreveu: I make a best effort (which is sometimes lacking, in particular I just realized I've always forgotten to notify the bindings people -- which is perhaps why you see it as no different) to at least notify apps that I know are affected and often also provide patches. Note the above parenthetical comment... I wouldn't bother notifying anyone if I broke ABI of libmetacity-private (other than control-center), even if it was during a micro point release during the stable cycle. This already happened once with wnck, with nasty results: http://www.daa.com.au/pipermail/pygtk/2006-January/011660.html But we understand the limitations of API guarantees and live with it. Yup, this was an example of where I sucked as mentioned in the previous comment. I probably should have notified bindings in the past of wnck API/ABI changes. Would it make sense to do so in the future? Would a mail to language-bindings@ be sufficient for that purpose? So I've finally released the split g-p-e/g-p-d packages, leaving metacity in g-p-e and untouched. I almost thought about renaming to you mean g-p-d? ;) metacity.private, but it's ugly, and I thought this discussion had died out with no much concern. At the time I received this email, I had already uploaded the packages. I hope this will not cause much concern, but I guess renaming the module or issuing a warning during import is still a viable option. Nah, don't worry about the renaming or giving a warning. As you've pointed out, this really is not different for you than how you've had to deal with wnck in the past; since you're fine with that, I don't see any problems. Cheers, Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Fri, 2006-01-20 at 13:35 -0700, Elijah Newren wrote: On 1/20/06, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: Sex, 2006-01-20 às 09:10 -0700, Elijah Newren escreveu: I make a best effort (which is sometimes lacking, in particular I just realized I've always forgotten to notify the bindings people -- which is perhaps why you see it as no different) to at least notify apps that I know are affected and often also provide patches. Note the above parenthetical comment... I wouldn't bother notifying anyone if I broke ABI of libmetacity-private (other than control-center), even if it was during a micro point release during the stable cycle. This already happened once with wnck, with nasty results: http://www.daa.com.au/pipermail/pygtk/2006-January/011660.html But we understand the limitations of API guarantees and live with it. Yup, this was an example of where I sucked as mentioned in the previous comment. I probably should have notified bindings in the past of wnck API/ABI changes. Would it make sense to do so in the future? Would a mail to language-bindings@ be sufficient for that purpose? I think that API/ABI changes will be noticed after a while and fixed. But if library authors change API/ABI very near the GNOME release date, the errors could go unnoticed until too late. I propose the following: if there's an API/ABI break after the GNOME API freeze deadline (which only applies for gnome devel platform modules, of course), then desktop library maintainers are strongly advised to notify bindings authors by sending an email to the language-bindings list. This should be enough, I think. So I've finally released the split g-p-e/g-p-d packages, leaving metacity in g-p-e and untouched. I almost thought about renaming to you mean g-p-d? ;) Yes, of course. Sorry. :) metacity.private, but it's ugly, and I thought this discussion had died out with no much concern. At the time I received this email, I had already uploaded the packages. I hope this will not cause much concern, but I guess renaming the module or issuing a warning during import is still a viable option. Nah, don't worry about the renaming or giving a warning. As you've pointed out, this really is not different for you than how you've had to deal with wnck in the past; since you're fine with that, I don't see any problems. Thanks. Regards, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic 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: New modules in 2.14
On Wed, 2006-18-01 at 23:14 +0800, Davyd Madeley wrote: pragmatism, before we commit to path that none of our vendors or any other desktops want to share. In all fairness, I know that at least Ubuntu Dapper is using g-p-m. No idea about Edgy. Cheers. 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: New modules in 2.14
On Wed, 2006-18-01 at 10:32 -0500, William Jon McCann wrote: How is a system daemon more secure than a user session daemon? A system daemon runs as root (or some other 'special' user) and can be given special abilities without giving them to the user. A system daemon is also immune to user tampering. g-p-m doesn't require any additional privileges. HAL is doing most of the work. This is exactly the problem. In order for g-p-m to do its stuff we have to add to HAL the ability for any user to say suspend the system now (since g-p-m needs to do this and it's just running as a normal user). If any user can say suspend now then I can be logged in as a background user and play nasty tricks on the console user. HAL currently has no mechanism for making a distinction between background users and the user that currently 'controls' the machine. When you add additional privileges to HAL you also increase the chance that someone is able to exploit a security hole in HAL itself. Martin Pitt, for example, has ranted about this at length because it's not a good idea (and even found some security problems to validate his concerns). Can you please provide some reasons why g-p-m is very Gnome-centric? It uses the system tray standard and provides a DBUS interface that any application can use. This DBUS interface could be standardized with freedesktop.org once we figure out what works for us. Yes, it has GNOME in its name and uses Gconf and GTK+. You provided my reasons for me. You could say that all Gnome applications are sufficiently cross-desktop because they connect to the X server through the standard protocol. They do not, however, have the Qt look and feel so they stick out like a sore thumb. KDE users are also not interested in having Gconf and GTK+ installed. For this reason, you can't honestly expect KDE to use g-p-m. Adding an application to the Desktop release doesn't make too many guarantees about its API availability. We talked about this in #gnome-hackers a bit before I wrote my mail listing my concerns. Jeff (I think!) brought up the example of esd and said that it's very hard to remove something once it's included. Once apps start to depend on it it -does- become difficult to remove. Another issue is that right now some distributions are using power management systems that are vastly different from how g-p-m works. If we include g-p-m we are encouraging people to depend on it and making life difficult for those distributions that do not want to ship it. I think it is the interface that counts. As long as the DBUS interface is sane then you should be able to plug whatever you want in to provide that service. g-p-m is a session daemon. It uses the D-BUS session bus and does not listen on the system bus. Most distributions have power management systems that run at the system level. It's difficult for things not running as part of the user's session to connect to the user's session bus (in fact, the default policy is to reject non-user connections - even those from root). You also have to somehow 'snoop' the bus location out of the environment of another process. You also assume they use D-BUS for their systems at all (or want to). The question comes down to: is there sufficient reason not to use the best solution we have in favor of one that hasn't been spec'd, reviewed, or developed in the community or at all? For what it's worth, Davyd Madeley spec'd this imaginary system out a long time ago. Of course, nobody has coded on it. A lot of your argument has been along the lines of including g-p-m now doesn't limit the choice of distributors or our future choices. Based on what I've been told, I think that in a very real way it limits both of these things. This makes sense -- if Gnome applications start to use g-p-m then it becomes hard to remove (both for distributions and for us in the future). This is really the crux of the argument and honestly I'm not in a position to really comment on if it's true or not since I've not been around on the Gnome scene for very long. Cheers. 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: New modules in 2.14
On Wed, 2006-18-01 at 17:16 +0100, Mark Rosenstand wrote: Without actually using the stuff, I think this sounds pretty much like what HAL does (and g-p-m uses.) Definitely not. HAL is incapable of acting on its own (ie: making policy decisions). This is exactly the part that needs to be pushed down into being a system daemon. Cheers 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: New modules in 2.14
On Wed, 2006-01-18 at 10:17 -0500, Ryan Lortie wrote: On Wed, 2006-18-01 at 23:14 +0800, Davyd Madeley wrote: pragmatism, before we commit to path that none of our vendors or any other desktops want to share. In all fairness, I know that at least Ubuntu Dapper is using g-p-m. No idea about Edgy. I know Fedora Core 5 will include g-p-m by default, as it's in the current rawhide, and in all the latest test releases. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Wed, 2006-01-18 at 10:17 -0500, Ryan Lortie wrote: On Wed, 2006-18-01 at 23:14 +0800, Davyd Madeley wrote: pragmatism, before we commit to path that none of our vendors or any other desktops want to share. In all fairness, I know that at least Ubuntu Dapper is using g-p-m. No idea about Edgy. suse is also shipping it -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Wed, 2006-01-18 at 10:58 -0500, Ryan Lortie wrote: The question comes down to: is there sufficient reason not to use the best solution we have in favor of one that hasn't been spec'd, reviewed, or developed in the community or at all? For what it's worth, Davyd Madeley spec'd this imaginary system out a long time ago. Of course, nobody has coded on it. The specs Ryan refers to are documented here: http://live.gnome.org/PowerManager Some of the contents contained here are not strictly true or useful any more (when Ryan and I started discussing this, HAL had no support for power management devices, nor did it have callable functions, so we were going to have to implement that in our layer). In the end, after beginning the design phase I ran out of time to devote to the project and so it stopped. Richard has done some great work in extending HAL to the point where it now implements a large amount of the functionality that was required in PowerManager. If we were going to implement PowerManager today, it would be significantly easier. Using the existing capplets from g-p-m and the HAL interfaces, we would then be able to write a monitoring/policy daemon that handled the core of what PowerManager would do. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Tue, 2006-01-17 at 22:37 -0500, Ryan Lortie wrote: This would make the system more secure as a normal user process wouldn't be given the ability to 'suspend now' as g-p-m (and any system which makes policy decisions at user privilege) currently requires we provide it with. This (and other privileges that g-p-m need to be provided with) have serious security implications. g-p-m runs completely unprivileged; what you are worried about are the methods on HAL? You know, sane distros lock this down to only allowing console user or certain group membership. Paranoid distros use things like SELinux to only allow the /usr/bin/gnome-power-manager process to invoke the Suspend() method on HAL. (please also specify concrete attack vectors) Having a system daemon would also mean that the policy system runs when the user is not logged in without resorting to hacks like gdm invoking a private copy of g-p-m. Strong disagreement, see http://blog.fubar.dk/?p=63 for some ramblings why this is exactly what one wants to do. Yes, you need to answer how the system daemon is configured when no user is logged in (don't tell me some UNIX-y scheme with a file in /etc please). 2. More platform-neutral approach. The technologies on which g-p-m is based have seen wide acceptance from other desktops. We should try and create a power management system that has the same acceptance. g-p-m is very Gnome-centric. With a faceless system daemon doing all the real hard work we could have multiple configuration front-ends (Gnome, Qt, etc). What is the point here? Most distributions nowadays either support only GNOME or KDE; sure, they ship the other, but focus on just one of them. Personally I think that is fine.. We'll get kick-ass GNOME distros and kick-ass KDE distros. Also.. do you really think the GNOME and KDE people can agree on a settings format for said system daemon? I think it would be a mistake. Also, from a more pragmatic point of view... Is it worth splitting e.g. g-p-m into two daemons simply to feed settings from gconf from one to the other? I think the answer to this question is no. The answer is that the approach that I outlined (which you call a hack; offends me a bit actually) allows us to 1) leverage and unlock the full power of gconf; e.g. g-p-m when running in the no user logged in case reads from gconf, this might stem from LDAP some day 2) It gives us an easy way to say set these settings as system default 3) Simplified code, e.g. keep everything in a single process just like with g-p-m today 4) Not having to fight about feature parity of the system daemon with projects that have another approach to what is configurable. Hope this helps. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On 1/18/06, Davyd Madeley [EMAIL PROTECTED] wrote: I'm with Ryan on this. I think we should give vendors a choice for the time being. It looks like the vendors have already jumped on and chosen g-p-m. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Wed, 2006-01-18 at 10:58 -0500, Ryan Lortie wrote: This is exactly the problem. In order for g-p-m to do its stuff we have to add to HAL the ability for any user to say suspend the system now (since g-p-m needs to do this and it's just running as a normal user). If any user can say suspend now then I can be logged in as a background user and play nasty tricks on the console user. Tell me how the desktop piece that talks to the system daemon in your proposal isn't vulnerable in this case? Because you need this to e.g. tell the system daemon that your session is idle and it's time to suspend to save battery... You know... A smart guy once told me that once you can run code on a victims machine you've already won. In this case we limit this to being able to suspend the machine. Also, if you use SELinux you can even limit this since you'll only allow /usr/bin/gnome-power-manager to do this. Don't you think there are far worse destructive things you could do if you could run code in a console session? Like.. silently just log key-strokes? HAL currently has no mechanism for making a distinction between background users and the user that currently 'controls' the machine. This is a missing feature in D-BUS. See my proposal about ConsoleTracker at http://blog.fubar.dk/?p=63 and on the D-BUS mailing list on how to deal with this. Someone just needs to write the code. Oh, it's also a corner case. When you add additional privileges to HAL you also increase the chance that someone is able to exploit a security hole in HAL itself. Martin Pitt, for example, has ranted about this at length because it's not a good idea (and even found some security problems to validate his concerns). Don't forget to say that Martin and I agree what needs to be done to make us both feel comfortable about this. Oh, btw, I can assure you that HAL will grow more functional and provide more and more methods to make things easier (next up is providing Format() and PartitionDisk() methods). It's just stupid to create a system daemon for every conceivable case where you need privileges. We have a simple and secure framework to easily do this in HAL. Saying it's not a good idea is.. well.. let's just say I disagree :-) David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Iau, 2006-01-19 at 17:09 -0500, David Zeuthen wrote: Strong disagreement, see http://blog.fubar.dk/?p=63 for some ramblings why this is exactly what one wants to do. Yes, you need to answer how the system daemon is configured when no user is logged in (don't tell me some UNIX-y scheme with a file in /etc please). Oh well that rules out gconf. Pity because a 'gconf' database for the nobody logged in case would be nice and clean. But hey it uses that nasty unix /etc directory too! 1) leverage and unlock the full power of gconf; e.g. g-p-m when running in the no user logged in case reads from gconf, this might stem from LDAP some day Well you are contradicting yourself now but I believe this is the right answer.. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
tor, 19,.01.2006 kl. 15.19 -0700, skrev Elijah Newren: On 1/18/06, Davyd Madeley [EMAIL PROTECTED] wrote: I'm with Ryan on this. I think we should give vendors a choice for the time being. It looks like the vendors have already jumped on and chosen g-p-m. I'm in favour of this too. Most of the main distros already use it and I think going back to the design stage for the ultimate power manager will just serve to drag this issue out. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Quoting David Zeuthen [EMAIL PROTECTED]: What is the point here? Most distributions nowadays either support only GNOME or KDE; sure, they ship the other, but focus on just one of them. Personally I think that is fine.. We'll get kick-ass GNOME distros and kick-ass KDE distros. Also.. do you really think the GNOME and KDE people can agree on a settings format for said system daemon? I think it would be a mistake. Also, from a more pragmatic point of view... Is it worth splitting e.g. g-p-m into two daemons simply to feed settings from gconf from one to the other? I think the answer to this question is no. Personally, I always imagined a system that functioned more like NetworkManager. Which brings me to another point. NetworkManager is not part of Desktop. We leave it up to vendors to decide whether or not NetworkManager should be shipped, or should be shipped by default. Additionally, while we have heard that Ubuntu, SuSE and Fedora will be shipping g-p-m in their next distribution, have we heard anything from our other non-Linux, non-HAL-enabled brethren? Having hard dependancies on something like g-p-m, which has hard dependancies on HAL, which in turn doesn't (yet) work on Solaris (I think) sounds like a world of pain it would be really nice to avoid. Then there is AIX, HP-UX, IRIX, and every other UNIX someone is building GNOME for... --d ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Quoting Joe Marcus Clarke [EMAIL PROTECTED]: I'm not sure about the KDE side of the house, but they seem to be more multi-OS (i.e. non-Linux) friendly out-of-the-box. I think this is simply a matter of technology. For a long time in GNOME all of that OS specific code was being replicated over and over and over and the developers would make the same mistakes and the porters would keep sending them the same patches. So then you decide to standardize on one place where everything can be nicely abstracted into a consistant interface. Yay, the porters no longer have to send a million and one little patches, unfortunately they now have to port HAL, which I understand is a massive undertaking. I guess in some regards, you just can't win either way. --d ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Wed, 2006-01-18 at 23:14 +0800, Davyd Madeley wrote: I'm with Ryan on this. I think we should give vendors a choice for the time being. He also raises excellent points about what gnome-power-manager is (that is, it is very GNOME centric). When I first envisioned something like this, I named it PowerManager and like its namesake NetworkManager it was to be largely platform independant. Ideally it would offer perhaps a capplet and some manner of system for notifications, but other than that would not be intrusive on a GNOME desktop. This is unfortunately not how it works. So, looking again at http://live.gnome.org/PowerManager would you agree that the only difference to gnome-power-manager is that 1) everything is handled in a single process (so we don't need to pass preferences from the session to the system daemon); and 2) gconf is utilized for reading settings (so we don't have to invent yet another configuration system)? Because I really can't figure out exactly how one is more intrusive than the other in the context of a GNOME desktop. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Thu, 2006-01-19 at 14:19 +0800, James Henstridge wrote: Richard Hughes wrote: Of course, this wonderful system does not exist. Again, gnome-power-manager is the best offering we have at this time. Thanks! Making g-p-m very closely tied to other GNOME stuff allows it and other programs to play nice, e.g. g-p-m telling g-s to lock the screen after hibernating, all via a nice DBUS interface. g-s can also use g-p-m to blank the screen using DPMS. This always seemed a bit weird to me. Is there any reason to choose this form of integration. Wouldn't it have been better to make gnome-screensaver listen for the HAL power management events directly, and lock the screen/throttle the screensaver where appropriate? Similarly, why does gnome-screensaver need to ask gnome-power-manager to power down the screen? Isn't this a simple X call that it could do itself? Separation by functionality. So I think gnome-power-manager should manage the power of the system (includes the display) and gnome-screensaver should manage putting up a screen savers and locking the screen. Either should have fall-backs if the other is not available of course. How each depend on the other seems like an implementation detail and can probably be changed. Is it interesting? I guess the main question is: why would an app use the gnome-power-manager interfaces to respond to power management events rather than HAL's notifications? I think this is sorta covered in these mails http://lists.freedesktop.org/archives/hal/2006-January/004256.html http://lists.freedesktop.org/archives/hal/2006-January/004239.html Basically preparing the desktop before suspending is a) a somewhat complicated process if you want to do it right [1] b) something that varies with the reason for the suspend [2] c) notifications / prompts for the user under certain circumstances [3] d) something apps may want to stall [4] There's just a lot of corner cases and I do think these justify g-p-m if we want the right user experience. All this is about policy and thus don't belong in HAL. Btw, is it now more clear that we need the policy piece in the desktop session and not on a system-level? David [1] : you want to prepare apps in the right order, e.g. make gedit save the document to the networking share on the corporate network *before* nm-applet tears down the VPN tunnel and the network. HAL provides no such framework. [2] : HAL would never know why someone invoked Suspend() or Hibernate(). g-p-m knows as g-p-m is the power manager. [3] : never prompt/notify on lid close (user won't see it!), but probably OK to bother the user if the reason for suspend stems from a press of dedicated sleep button or invoked from the menu option of g-p-m applet. [4] : e.g. nautilus wants to stall standby when copying files from remote sites or n-c-b when burning discs. Otherwise these user-initiated operations fails. Whether g-p-m honors this depends on why g-p-m wants to suspend. E.g. common sense would say don't honor on lid close [5] but do honor if g-p-m wants to suspend due to session inactivity. [5] : then the user just made a mistake and it's too late to prompt him; he will realize when he opens the laptop.. maybe we can even tell him that though someone would probably think it would be patronizing to put up a dialog saying you just created a another coaster ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Hello. On Mon, 2006-16-01 at 19:13 -0700, Elijah Newren wrote: Ok, here's what I'm guessing is the rough module consensus after having re-read or skimmed a ton of emails: In: - gnome-power-manager I don't think it's appropriate to include gnome-power-manager at this point. There are a number of reasons for this. First, I don't think that g-p-m itself and the technologies that it depend on are mature enough that we should standardise on any particular solution yet. g-p-m is one way of cracking the power management egg and I think there are a lot of better possibilities. Certainly, at the current time, it appears to be the best offering. However, after discussing this at length at Ubuntu Below Zero, I believe, that we'd be better served by a system with the two following key properties: 1. Based on system daemon. This would make the system more secure as a normal user process wouldn't be given the ability to 'suspend now' as g-p-m (and any system which makes policy decisions at user privilege) currently requires we provide it with. This (and other privileges that g-p-m need to be provided with) have serious security implications. Having a system daemon would also mean that the policy system runs when the user is not logged in without resorting to hacks like gdm invoking a private copy of g-p-m. 2. More platform-neutral approach. The technologies on which g-p-m is based have seen wide acceptance from other desktops. We should try and create a power management system that has the same acceptance. g-p-m is very Gnome-centric. With a faceless system daemon doing all the real hard work we could have multiple configuration front-ends (Gnome, Qt, etc). Of course, this wonderful system does not exist. Again, gnome-power-manager is the best offering we have at this time. This does not mean, however, that we should put include it in Gnome proper. Once things are in, they have a tendency to stay around forever. Applications form hard dependencies on them. If we are going to standardise on a solution it should be the best possible solution -- not just the best thing that we have right now. If we aren't sure that the thing we have now is the best possible solution then it's appropriate to wait. Another issue is that right now some distributions are using power management systems that are vastly different from how g-p-m works. If we include g-p-m we are encouraging people to depend on it and making life difficult for those distributions that do not want to ship it. Essentially, I think that (a) we should not rush into this and (b) we should, at the current time, leave this up to distributions to decide. We do them no harm by not including it since they can include it anyway. I'm not subscribed to the list so please cc: me on any replies. Cheers. 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: New modules in 2.14
On 1/17/06, Davyd Madeley [EMAIL PROTECTED] wrote: On Tue, 2006-01-17 at 22:56 +, Gustavo J. A. M. Carneiro wrote: So, I'm going a bit off-topic here, but I'm curious: what are these metacity python bindings for? They wrap libmetacity-private. I think Johan wants to draw windows inside a scrolled window in Gazpacho GUI builder, and that library supposedly allows one to use metacity's rendering engine to immitate metacity frames. But I gues you already know this better than me :) That's all I know about the bindings and the library, I'm afraid. I hope this is not a problem?.. libmetacity-private is a library installed by a desktop module, hence it belongs in gnome-python-desktop, I think. These bindings were added before API/feature freeze. And I do expect to keep full control in the future of which bindings are added to gnome-python-desktop as long as they wrap libraries of desktop modules. Given the name libmetacity-private, I don't think it's a good idea to be shipping public bindings to it. I don't think you could rely on this library to remain API stable. Well, no library in the desktop can be relied upon to remain API or ABI stable; that's the reason they are in the desktop. The difference with this lib, _if_ I remember correctly, is that those other libs in the desktop were meant to be used by whoever wanted to use them, whereas libmetacity-private was expected to not be used by anything other than control-center (with the implication that if we make any changes that breaks anything other than the control center, we just don't care and won't consider it a bug). Of course, Elijah would have a better idea of this. Perhaps the solution is to create a libmetacity that use functions people may need to use, and a libmetacity-private to do whatever it is doing now. Actually, it'd be Havoc who'd probably need to comment here, as I'm not certain I'm recalling correctly, I've never touched that lib, and he'd need to be the one to say whether he's willing to support wider use of it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Hello Ryan, You have some interesting comments about power management. I too have been thinking about this recently and I have a few questions and comments. Ryan Lortie wrote: [snip] Certainly, at the current time, it appears to be the best offering. However, after discussing this at length at Ubuntu Below Zero, I believe, that we'd be better served by a system with the two following key properties: 1. Based on system daemon. This would make the system more secure as a normal user process wouldn't be given the ability to 'suspend now' as g-p-m (and any system which makes policy decisions at user privilege) currently requires we provide it with. This (and other privileges that g-p-m need to be provided with) have serious security implications. Having a system daemon would also mean that the policy system runs when the user is not logged in without resorting to hacks like gdm invoking a private copy of g-p-m. Can you provide some reasons why you think g-p-m has serious security implications? How is a system daemon more secure than a user session daemon? g-p-m doesn't require any additional privileges. HAL is doing most of the work. I think the whole on-console issue is a complicated one and one that certainly isn't limited to power management. It seems to me that most of your arguments apply equally to gnome-volume-manager or any of the other session daemons. 2. More platform-neutral approach. The technologies on which g-p-m is based have seen wide acceptance from other desktops. We should try and create a power management system that has the same acceptance. g-p-m is very Gnome-centric. With a faceless system daemon doing all the real hard work we could have multiple configuration front-ends (Gnome, Qt, etc). Can you please provide some reasons why g-p-m is very Gnome-centric? It uses the system tray standard and provides a DBUS interface that any application can use. This DBUS interface could be standardized with freedesktop.org once we figure out what works for us. Yes, it has GNOME in its name and uses Gconf and GTK+. Of course, this wonderful system does not exist. Again, gnome-power-manager is the best offering we have at this time. Great. This does not mean, however, that we should put include it in Gnome proper. Once things are in, they have a tendency to stay around forever. Applications form hard dependencies on them. If we are going to standardise on a solution it should be the best possible solution -- not just the best thing that we have right now. If we aren't sure that the thing we have now is the best possible solution then it's appropriate to wait. Adding an application to the Desktop release doesn't make too many guarantees about its API availability. Another issue is that right now some distributions are using power management systems that are vastly different from how g-p-m works. If we include g-p-m we are encouraging people to depend on it and making life difficult for those distributions that do not want to ship it. I think it is the interface that counts. As long as the DBUS interface is sane then you should be able to plug whatever you want in to provide that service. Essentially, I think that (a) we should not rush into this and (b) we should, at the current time, leave this up to distributions to decide. We do them no harm by not including it since they can include it anyway. Historically, distributions have always been able to make their own choices regardless of what was in the Desktop and I think this can still be true. The question comes down to: is there sufficient reason not to use the best solution we have in favor of one that hasn't been spec'd, reviewed, or developed in the community or at all? Thanks, Jon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Tue, 2006-01-17 at 22:37 -0500, Ryan Lortie wrote: First, I don't think that g-p-m itself and the technologies that it depend on are mature enough that we should standardise on any particular solution yet. g-p-m is one way of cracking the power management egg and I think there are a lot of better possibilities. Certainly, at the current time, it appears to be the best offering. However, after discussing this at length at Ubuntu Below Zero, I believe, that we'd be better served by a system with the two following key properties: 1. Based on system daemon. This would make the system more secure as a normal user process wouldn't be given the ability to 'suspend now' as g-p-m (and any system which makes policy decisions at user privilege) currently requires we provide it with. This (and other privileges that g-p-m need to be provided with) have serious security implications. Having a system daemon would also mean that the policy system runs when the user is not logged in without resorting to hacks like gdm invoking a private copy of g-p-m. 2. More platform-neutral approach. The technologies on which g-p-m is based have seen wide acceptance from other desktops. We should try and create a power management system that has the same acceptance. g-p-m is very Gnome-centric. With a faceless system daemon doing all the real hard work we could have multiple configuration front-ends (Gnome, Qt, etc). Of course, this wonderful system does not exist. Again, gnome-power-manager is the best offering we have at this time. Without actually using the stuff, I think this sounds pretty much like what HAL does (and g-p-m uses.) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Hi Ryan, I should point out that I can't speak for Richard, or David and these are merely my interpretations of their work. Ryan Lortie wrote: On Wed, 2006-18-01 at 10:32 -0500, William Jon McCann wrote: How is a system daemon more secure than a user session daemon? A system daemon runs as root (or some other 'special' user) and can be given special abilities without giving them to the user. A system daemon is also immune to user tampering. User tampering? You mean like pulling the power cord? This is pretty silly. Clearly, in a system that requires strict lockdown you won't be using user controlled power management. Using an out-of-session daemon has a number of disadvantages: * I think it is harder to write securely. * Policy would still have to be defined in the session. * You also need to provide a mechanism for the user session to communicate policy. * You still have to figure out which session is on console in order to arbitrate policy choices. * You have to determine which session is allowed to invoke actions. * Something in the user session still has to trigger a shutdown, suspend, or hibernate. * Need a way to communicate feedback, notifications, etc to the user. So, in the end, the session still has the ability to perform power management actions and the who's on console issue is not solved. I think the who's in control of the console issue is larger than g-p-m. g-p-m doesn't require any additional privileges. HAL is doing most of the work. This is exactly the problem. In order for g-p-m to do its stuff we have to add to HAL the ability for any user to say suspend the system now (since g-p-m needs to do this and it's just running as a normal user). If any user can say suspend now then I can be logged in as a background user and play nasty tricks on the console user. HAL currently has no mechanism for making a distinction between background users and the user that currently 'controls' the machine. When you add additional privileges to HAL you also increase the chance that someone is able to exploit a security hole in HAL itself. Martin Pitt, for example, has ranted about this at length because it's not a good idea (and even found some security problems to validate his concerns). This seems like a general argument against HAL and not g-p-m in particular. Can you please provide some reasons why g-p-m is very Gnome-centric? It uses the system tray standard and provides a DBUS interface that any application can use. This DBUS interface could be standardized with freedesktop.org once we figure out what works for us. Yes, it has GNOME in its name and uses Gconf and GTK+. You provided my reasons for me. You could say that all Gnome applications are sufficiently cross-desktop because they connect to the X server through the standard protocol. They do not, however, have the Qt look and feel so they stick out like a sore thumb. KDE users are also not interested in having Gconf and GTK+ installed. For this reason, you can't honestly expect KDE to use g-p-m. Oh, come on. So, you're referring to the preferences dialog only? I think there are two equally simple ways to solve this (if you care). Write a policy abstraction that can get from either GConf or the KDE equivalent and make a preferences dialog in Qt, or write a kde-power-manager that uses the same DBUS interface. Adding an application to the Desktop release doesn't make too many guarantees about its API availability. We talked about this in #gnome-hackers a bit before I wrote my mail listing my concerns. Jeff (I think!) brought up the example of esd and said that it's very hard to remove something once it's included. Once apps start to depend on it it -does- become difficult to remove. That doesn't mean it must always be the case. Again, the application is not nearly as important as the DBUS API. Another issue is that right now some distributions are using power management systems that are vastly different from how g-p-m works. If we include g-p-m we are encouraging people to depend on it and making life difficult for those distributions that do not want to ship it. I think it is the interface that counts. As long as the DBUS interface is sane then you should be able to plug whatever you want in to provide that service. g-p-m is a session daemon. It uses the D-BUS session bus and does not listen on the system bus. Most distributions have power management systems that run at the system level. It's difficult for things not running as part of the user's session to connect to the user's session bus (in fact, the default policy is to reject non-user connections - even those from root). You also have to somehow 'snoop' the bus location out of the environment of another process. You also assume they use D-BUS for their systems at all (or want to). I don't understand your reasoning here. Are you assuming that the system isn't using HAL? The question comes
Re: New modules in 2.14
Mark Rosenstand wrote: Without actually using the stuff, I think this sounds pretty much like what HAL does (and g-p-m uses.) HAL avoids doing policy. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Richard Hughes wrote: Of course, this wonderful system does not exist. Again, gnome-power-manager is the best offering we have at this time. Thanks! Making g-p-m very closely tied to other GNOME stuff allows it and other programs to play nice, e.g. g-p-m telling g-s to lock the screen after hibernating, all via a nice DBUS interface. g-s can also use g-p-m to blank the screen using DPMS. This always seemed a bit weird to me. Is there any reason to choose this form of integration. Wouldn't it have been better to make gnome-screensaver listen for the HAL power management events directly, and lock the screen/throttle the screensaver where appropriate? Similarly, why does gnome-screensaver need to ask gnome-power-manager to power down the screen? Isn't this a simple X call that it could do itself? I guess the main question is: why would an app use the gnome-power-manager interfaces to respond to power management events rather than HAL's notifications? James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Le lundi 16 janvier 2006 à 19:13 -0700, Elijah Newren a écrit : Ok, here's what I'm guessing is the rough module consensus after having re-read or skimmed a ton of emails: In: - pyorbit (bindings suite) - deskbar-applet - fast-user-switch-applet (though this should be integrated in the panel later) - gnome-power-manager - gnome-screensaver - pessulus (new admin suite[2]) - sabayon[1] (also in new admin suite) - libnotify notification-daemon[3] - gnome-python-desktop[4] (_desktop_ suite) Out: - atomix[5] - nautilus-actions - anything else (if there be any) that might have been proposed but apparently wasn't important enough for anyone to bring up in the recent trying-to-reach-consensus thread ;-) Does that sound right? Sounds right to me. The only thing I fear is that a lot of apps will use notification bubbles without good reasons. I'd like to see some HIG recommandations for this. Also, it's not clear whether apps should use notification bubbles or the notification area. And sometimes they use both... Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Le lundi 16 janvier 2006 à 19:13 -0700, Elijah Newren a écrit : Ok, here's what I'm guessing is the rough module consensus after having re-read or skimmed a ton of emails: In: [...] - libnotify notification-daemon[3] [...] Does that sound right? Sounds right to me. The only thing I fear is that a lot of apps will use notification bubbles without good reasons. I'd like to see some HIG recommandations for this. Also, it's not clear whether apps should use notification bubbles or the notification area. And sometimes they use both... Vincent Hi, libnotify lets applications set a urgency level for notifications among low, normal and critical. Maybe notify-daemon can fileter them, showing only notifications above or equal a user selected urgency level, maybe with a very small and simple UI to store a GConf key with that value and able to send notify-daemon a command via dbus. This should work, at least until applications will start marking all their nofitications as critical :) Anyway a HIG annex will be more than welcome. Luca (I'm the one who proposed libnotify and notify-daemon :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Mon, 2006-01-16 at 19:13 -0700, Elijah Newren wrote: Ok, here's what I'm guessing is the rough module consensus after having re-read or skimmed a ton of emails: In: - pyorbit (bindings suite) - deskbar-applet - fast-user-switch-applet (though this should be integrated in the panel later) - gnome-power-manager - gnome-screensaver - pessulus (new admin suite[2]) - sabayon[1] (also in new admin suite) - libnotify notification-daemon[3] - gnome-python-desktop[4] (_desktop_ suite) Out: - atomix[5] - nautilus-actions what was the reason for refusing the inclusion of n-a? -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Seg, 2006-01-16 às 19:13 -0700, Elijah Newren escreveu: [4] gnome-python-desktop hasn't yet been split from gnome-python-extras but it was a very recent proposal (caused by requirements of other modules), so it may be a few more days yet before Gustavo is able to make the split. I would have done it already if some caring gnome cvs admin would have found time to answer my cvs surgery request[1].. :-) Regards. [1] Your message about CVS surgery request for gnome-python-extras/gnome-python-desktop split has been received and assigned a ticket ID [gnome.org #863]. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. signature.asc Description: Esta é uma parte de mensagem assinada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Em Ter, 2006-01-17 às 13:24 +, Gustavo J. A. M. Carneiro escreveu: I would have done it already if some caring gnome cvs admin would have found time to answer my cvs surgery request[1].. :-) The Sysadmin Team cares, believe me. Sorry for the delay, looking at it now. Yours, Guilherme de S. Pastore The GNOME Sysadmin Team ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Ter, 2006-01-17 às 11:43 -0200, Guilherme de S. Pastore escreveu: Em Ter, 2006-01-17 às 13:24 +, Gustavo J. A. M. Carneiro escreveu: I would have done it already if some caring gnome cvs admin would have found time to answer my cvs surgery request[1].. :-) The Sysadmin Team cares, believe me. Sorry for the delay, looking at it now. Yeah, I know, I don't mean to criticize; I asked for it on a saturday, so I shouldn't expect it so soon... :P PS: please add 'metacity' to the list of subdirs to copy into gnome-python-desktop. Thanks! Yours, Guilherme de S. Pastore The GNOME Sysadmin Team ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. signature.asc Description: Esta é uma parte de mensagem assinada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Tue, 2006-01-17 at 09:58 +0100, Vincent Untz wrote: Sounds right to me. The only thing I fear is that a lot of apps will use notification bubbles without good reasons. I'd like to see some HIG recommandations for this. Also, it's not clear whether apps should use notification bubbles or the notification area. And sometimes they use both... Yeah, I've already put in some placeholders for this sort of stuff, but haven't had time to flesh them out yet: http://developer.gnome.org/projects/gup/hig/draft_hig_new/desktop-notification-area.html#desktop-notification-balloon Suggestions for sane guidelines always welcome... Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Group http://ie.sun.com +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Tue, 2006-01-17 at 14:04 +, Calum Benson wrote: On Tue, 2006-01-17 at 09:58 +0100, Vincent Untz wrote: Sounds right to me. The only thing I fear is that a lot of apps will use notification bubbles without good reasons. I'd like to see some HIG recommandations for this. Also, it's not clear whether apps should use notification bubbles or the notification area. And sometimes they use both... Yeah, I've already put in some placeholders for this sort of stuff, but haven't had time to flesh them out yet: http://developer.gnome.org/projects/gup/hig/draft_hig_new/desktop-notification-area.html#desktop-notification-balloon Suggestions for sane guidelines always welcome... (Especially as I'm not really all that familiar with what the whole notification framework allows... is it written up anywhere?) Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Group http://ie.sun.com +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Tue, 2006-01-17 at 14:09 +, Calum Benson wrote: On Tue, 2006-01-17 at 14:04 +, Calum Benson wrote: On Tue, 2006-01-17 at 09:58 +0100, Vincent Untz wrote: Sounds right to me. The only thing I fear is that a lot of apps will use notification bubbles without good reasons. I'd like to see some HIG recommandations for this. Also, it's not clear whether apps should use notification bubbles or the notification area. And sometimes they use both... Yeah, I've already put in some placeholders for this sort of stuff, but haven't had time to flesh them out yet: http://developer.gnome.org/projects/gup/hig/draft_hig_new/desktop-notification-area.html#desktop-notification-balloon Suggestions for sane guidelines always welcome... (Especially as I'm not really all that familiar with what the whole notification framework allows... is it written up anywhere?) http://galago-project.org/specs/notification/index.php not sure if it's up-to-date, but should give you a broad view of how it works. -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On 1/17/06, Rodrigo Moya [EMAIL PROTECTED] wrote: On Mon, 2006-01-16 at 19:13 -0700, Elijah Newren wrote: Ok, here's what I'm guessing is the rough module consensus after having re-read or skimmed a ton of emails: In: - pyorbit (bindings suite) - deskbar-applet - fast-user-switch-applet (though this should be integrated in the panel later) - gnome-power-manager - gnome-screensaver - pessulus (new admin suite[2]) - sabayon[1] (also in new admin suite) - libnotify notification-daemon[3] - gnome-python-desktop[4] (_desktop_ suite) Out: - atomix[5] - nautilus-actions what was the reason for refusing the inclusion of n-a? Just a lack of consensus to include it. Vincent pointed out in his recent email that there didn't appear to yet be consensus about nautilus-actions with extra issues (possible integration into nautilus and perhaps instead being part of a power tool release suite that never got off the ground) making things a bit harder to understand. The remainder of the emails in the thread didn't seem to clarify much either (if it had only been your email about it, I would have considered it clarified, but there were other emails later that brought up more integration issues) -- but even more important than that, there were also a number of objections posted against its inclusion (in fact, more of them than I saw who seemed to be in favor). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Tue, 2006-01-17 at 22:56 +, Gustavo J. A. M. Carneiro wrote: So, I'm going a bit off-topic here, but I'm curious: what are these metacity python bindings for? They wrap libmetacity-private. I think Johan wants to draw windows inside a scrolled window in Gazpacho GUI builder, and that library supposedly allows one to use metacity's rendering engine to immitate metacity frames. But I gues you already know this better than me :) That's all I know about the bindings and the library, I'm afraid. I hope this is not a problem?.. libmetacity-private is a library installed by a desktop module, hence it belongs in gnome-python-desktop, I think. These bindings were added before API/feature freeze. And I do expect to keep full control in the future of which bindings are added to gnome-python-desktop as long as they wrap libraries of desktop modules. Given the name libmetacity-private, I don't think it's a good idea to be shipping public bindings to it. I don't think you could rely on this library to remain API stable. Of course, Elijah would have a better idea of this. Perhaps the solution is to create a libmetacity that use functions people may need to use, and a libmetacity-private to do whatever it is doing now. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Quoting Elijah Newren [EMAIL PROTECTED]: - pessulus (new admin suite[2]) - sabayon[1] (also in new admin suite) I think these should only be part of a GNOME Admin Suite. We shouldn't ship them with the Desktop release. These will only serve to clutter the menus of those who don't know how to use them. If we pimp our admin suite enough, people who need these tools will still be able to get them by grabbing the appropriate meta-packages from their distro. --d ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Mon, 2006-01-16 at 19:13 -0700, Elijah Newren wrote: [1] gnome-power-manager and sabayon have not been having recent and regular releases, which would be easy to fix, but could be a cause of worry if not done soon for the upcoming releases. I've been waiting for HAL 0.5.6 to be released for the last few weeks, as this hal has important fixes that 0.5.5.1 does not. Seeing as http://freedesktop.org/~david/dist/hal-0.5.6.tar.gz was released just last night [ http://freedesktop.org/~david/dist/hal-0.5.6.tar.gz ] there will be a release today. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
