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: Splash screen + desktop background + gdm theme for 2.14
If we're still using splash screens in 20 years, then $DIETY help me... -- dobey On Sun, 2006-01-22 at 04:44 +0100, Tino Meinen wrote: In 20 years we can organize contests during GUADEC to match the images with the numbers! Wheee! Tino ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GStreamer version for 2.14
Hi, Without any of this, people will just switch back to totem-xine or other, non-GNOME apps like always, or just continue self-confirming that Linux sucks. Very disappointing after my hard work to make GStreamer not totally suck from an end user's point of view. Basically a total year wasted. As Christian is saying, you're painting a too bleak picture. We've all invested in 0.8, both us as community members and some of us as employees of Fluendo. So have you, both in your spare time as well as paid by Fluendo. None of your work is wasted - all of it is already being used already or waiting to be ported over. Every single element that gets ported to 0.10 gets started from the 0.8 version. Also, let's not overstate the problems in 0.10. It's pretty clear that a lot of formats are easier to fix in 0.10. With Julien's fixing on Totem this weekend as well as some other fixes all over, I've been able to play .avi files, divx files, mpeg-4 video files (apparently a bunch of quicktime fixes went in), and all of them have a lot better and more responsive seeking than the 0.8 versions ever had. Also, 0.10 handles aspect ratio better than 0.8 did - try playing starwars.mkv in the 0.8 and 0.10 version, it's a particularly hairy file to test with. Unless Nathalie Portman is in fact so stick thin that she needs to go see a psychiatrist for her eating disorder, this is just one of the cases where the 0.10 version is simply better than 0.8 All of the file tests I did were done with only the GStreamer modules, no Fluendo-specific modules in there. The only major formats that I have files for that do not work at all yet are .asf and .wmv files. And the only real issues I had with current files were with some .vob files (not all of them) - which also seem a lot better with the freely available Fluendo MPEG demuxer. I hope people will try out the 0.10 version of totem and give us some feedback on what works. If you haven't seen the seeking yet, you should - it's zippy. Scrub that drag handle to and fro. You know you want to ! Happy hacking, Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ -*- thomas (dot) apestaart (dot) org -*- I've got ladyfingers baby I've got kidgloves baby I got heart -*- thomas (at) apestaart (dot) org -*- URGent, best radio on the net - 24/7 ! - http://urgent.fm/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
