Re: Bump minimum version of poppler to 0.12.0
Le jeudi 10 septembre 2009, à 11:06 +0200, Carlos Garcia Campos a écrit : Poppler 0.12 is the new stable release. Although it doesn't add any new API and evince builds with earlier versions, I suggest to bump the minimum version because this release includes a lot of important rendering and performance improvements, specially in the cairo backend: blend modes, linear/radial patterns, tiling patterns performance, ... Ok? My understanding is that we already require 0.11, and that 0.12 is the stable version of 0.11. Is that right? If yes, then +1. 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
Danger: older bugs are getting squashed with NEEDINFO
Guys, Im sorry I missed the memo if there was one, I woke up this morning to a full page of bugmail, deleting valid bugs from the buglist and throwing them into a NEEDINFO state. Javier pointed me to a blog post[0] which describes a new policy to mark bugs as NEEDINFO after one year. I'm raising the flag here on d-d-l because it concerns us all and I think every maintainer needs to know this policy is currently in effect. I know the guys mean well, and I cannot express my gratitude enough for the efficiency that the bugsquad has for closing some crash bugs that really do need info. Suffice it to say; I really need to know this policy is going to stop, or at least not effect Glade bugs. Thank you, -Tristan [0]http://blogs.gnome.org/aklapper/2009/08/10/gnome-bugsquad-policy-changes/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Sound system - user perspective
I spotted an area in which Gnome desktop can offer better user experience. Imagine I use VoIP (skype, empathy or anything like that) and some music player (Banshee, Rhythmbox etc.). I listen to some music or a podcast when someone ring. I have to stop the music and answer the phone. However I guess that music/podcast should actually be paused (i.e. state in application should be stopped) instead of being just volume down. I'm not sure if current architecture would allow such integration and probably it would require changes to few packages (music player and empathy at least) I prefer to post the idea here firstly. Regards 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
Autostart programs made easy
Sorry for posting two posts one after another. I do so as they are on different topics. If I should do it in one post - please just say so I'll do it such way in future. I always found adding new startup programs a bit tricky. I need to fill several fields to create new .desktop file. However most of the time what I really want is create an starup for existing application. The only problems I see is: 1. Most of programs I'd like to see in minimised view (either minimized or hidden in tray). I don't know how it is with gnome-shell but I just don't want them on front view. It can be treated with gnome-shell or wm/gs integration or parameters to application. In the last case it may require some changes to .desktop format. 2. Probably the best would be softlinks to original .desktop files. In case when such file is missing: - Search with similar naming (lower/upper case etc.) - Ask user what to do Regards 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: Would this be a break?
On Sat, 12.09.09 17:01, Nirbheek Chauhan (nirbh...@gentoo.org) wrote: On Sat, Sep 12, 2009 at 4:45 PM, Philippe Rouquier rouquie...@wanadoo.fr wrote: I just got a patch today that add a minor feature to brasero (see https://bugzilla.gnome.org/show_bug.cgi?id=594954). Once applied the patch allow brasero to emit a sound. the code is quite small but I was wondering if it would be considered as a break for any of the freezes. This won't break UI Freeze + String Freeze if there's no option in the menu(s) to disable it (is it supposed to be there? Or is it supposed to be globally controlled? Lennart should know this.) With very few exceptions event sounds should be controlled globally in the sound capplet. There you can globally disable/enable event sounds or choose a different sound theme that disables or enables specific sounds. I think it would be bad UI if all apps had seperate checkboxes for enabling event sounds. (BTW, the very few exceptions I mentioned above are probably IM and email notifications. Many people receive such a high volume of emails/IMs that it is probably a good idea to allow them to disable these sounds in the application) Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound system - user perspective
On Sun, 13.09.09 19:18, Maciej Piechotka (uzytkown...@gmail.com) wrote: I spotted an area in which Gnome desktop can offer better user experience. Imagine I use VoIP (skype, empathy or anything like that) and some music player (Banshee, Rhythmbox etc.). I listen to some music or a podcast when someone ring. I have to stop the music and answer the phone. However I guess that music/podcast should actually be paused (i.e. state in application should be stopped) instead of being just volume down. I'm not sure if current architecture would allow such integration and probably it would require changes to few packages (music player and empathy at least) I prefer to post the idea here firstly. This logic is actually already supported in PulseAudio and activated by default. This all depends on that applications properly tag their audio streams, i.e. so that it is clear which stream is telephony, which one is event sounds, and which one is music. Some apps have now started to do this properly. In fact the next beta of Skype will do this too. And if your favourite telephony or music app still doesn't then please complain and file a bug and ask them to read this: http://0pointer.de/blog/projects/tagging-audio.html and this: http://pulseaudio.org/wiki/ApplicationProperties The logic in PA will mute every stream tagged as music as soon as a stream tagged as phone is active. It will also send an asynchronous event to each music playing client requesting that it should pause its playback. If the phone stream goes away the music streams will be unmuted again and the apps notified that it is a good idea to unpause playback again. Unfortunately GStreamer does not have a nice API for tagging streams yet (this limitation can be circumvented via using environment variables which PA will pick up, but that's not a very nice solution). Also, GStreamer does not actually forward the pause request message to the applications and hence you'll effectively only see the muting taking happen, not the pause/unpause in current media players. To make this all work nicely jut a little bit glue code needs to be written for Gst and some minor patches be prepared for the various telephony apps/media players. If someone wants to pick this up and push this through this would be really great! Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound system - user perspective
On Sun, 2009-09-13 at 20:11 +0200, Lennart Poettering wrote: On Sun, 13.09.09 19:18, Maciej Piechotka (uzytkown...@gmail.com) wrote: I spotted an area in which Gnome desktop can offer better user experience. Imagine I use VoIP (skype, empathy or anything like that) and some music player (Banshee, Rhythmbox etc.). I listen to some music or a podcast when someone ring. I have to stop the music and answer the phone. However I guess that music/podcast should actually be paused (i.e. state in application should be stopped) instead of being just volume down. I'm not sure if current architecture would allow such integration and probably it would require changes to few packages (music player and empathy at least) I prefer to post the idea here firstly. This logic is actually already supported in PulseAudio and activated by default. This all depends on that applications properly tag their audio streams, i.e. so that it is clear which stream is telephony, which one is event sounds, and which one is music. Some apps have now started to do this properly. In fact the next beta of Skype will do this too. And if your favourite telephony or music app still doesn't then please complain and file a bug and ask them to read this: http://0pointer.de/blog/projects/tagging-audio.html and this: http://pulseaudio.org/wiki/ApplicationProperties The logic in PA will mute every stream tagged as music as soon as a stream tagged as phone is active. It will also send an asynchronous event to each music playing client requesting that it should pause its playback. If the phone stream goes away the music streams will be unmuted again and the apps notified that it is a good idea to unpause playback again. I heard about tagging but I haven't heard (till your mail) about sending event. Unfortunately GStreamer does not have a nice API for tagging streams yet (this limitation can be circumvented via using environment variables which PA will pick up, but that's not a very nice solution). Also, GStreamer does not actually forward the pause request message to the applications and hence you'll effectively only see the muting taking happen, not the pause/unpause in current media players. To make this all work nicely jut a little bit glue code needs to be written for Gst and some minor patches be prepared for the various telephony apps/media players. If someone wants to pick this up and push this through this would be really great! Lennart Ok. Since the problem is in gstreamer I'll try to fill bugs against it (or CC existing). Regards 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: Request for removing clutter in current form
On Mon, 2009-08-17 at 07:43 +0100, Emmanuele Bassi wrote: On Mon, 2009-08-17 at 08:03 +0200, Xavier Bestel wrote: Le dimanche 16 août 2009 à 23:55 +0100, Emmanuele Bassi a écrit : the majority of GPUs, nowadays, work fine on Linux with open source drivers[1], and provide the basic functionality that Clutter requires[2]. Except for some Intel cards, that's not true by a long shot. Only very old ATI cards are supported, you can't buy a card retail (current radeon HD4000 or even HD3000 or HD2000) that works in a current distribution or even in the next batch of distribs (they are in alpha state already and the drivers don't exist yet). NVIDIA are of course not supported at all by OSS drivers (nouveau is progressing slowly). Things are changing, but it'll be something like a full year before end-users see all working on their desktop for ATi cards and more for NVIDIA. so you're saying that only old GPUs work, and Maciej is saying that old GPUs do not work. it would be interesting to have a single place where the hardware support matrix was stored -- maybe on live.gnome.org or on freedesktop.org's wiki -- and updated. ciao, Emmanuele. I talked with the people from #radeon and freedesktop bugzilla. The problems with GL I had was due to composition enabled in metacity (or in fact any composition - it's not metacity bug - kwin/compiz would do the same). The solution is KMS/DRI2, which for radeon just landed as highly experimental in kernel (and AFAIK are not released yet as drivers for xorg but will be soon). Here's starts the steps. In KMS-enabled system as many GTK+ apps redraw frequently there are many flushes to kernel. As a result it is unusable on xorg-server 1.6 on my, older, system. gnome-terminal cannot be scrolled and glxgears have 7-11 FPS instead of normal 200-220 FPS. I was advised to use xorg-server 1.7 if I'm 'feeling tester-like'. It was pointed out by someone that on KMS (s)he is using xfce-theme as more lightweight. As for sure KMS will improve before 2.6.32 I still feel that introducing OGL know is a bit too early. Hopefully it is just one kernel release too early. Regards 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: Sound system - user perspective
Lennart Poettering schrieb: On Sun, 13.09.09 19:18, Maciej Piechotka (uzytkown...@gmail.com) wrote: I spotted an area in which Gnome desktop can offer better user experience. Imagine I use VoIP (skype, empathy or anything like that) and some music player (Banshee, Rhythmbox etc.). I listen to some music or a podcast when someone ring. I have to stop the music and answer the phone. However I guess that music/podcast should actually be paused (i.e. state in application should be stopped) instead of being just volume down. I'm not sure if current architecture would allow such integration and probably it would require changes to few packages (music player and empathy at least) I prefer to post the idea here firstly. This logic is actually already supported in PulseAudio and activated by default. This all depends on that applications properly tag their audio streams, i.e. so that it is clear which stream is telephony, which one is event sounds, and which one is music. Some apps have now started to do this properly. In fact the next beta of Skype will do this too. And if your favourite telephony or music app still doesn't then please complain and file a bug and ask them to read this: http://0pointer.de/blog/projects/tagging-audio.html and this: http://pulseaudio.org/wiki/ApplicationProperties The logic in PA will mute every stream tagged as music as soon as a stream tagged as phone is active. It will also send an asynchronous event to each music playing client requesting that it should pause its playback. If the phone stream goes away the music streams will be unmuted again and the apps notified that it is a good idea to unpause playback again. Unfortunately GStreamer does not have a nice API for tagging streams yet (this limitation can be circumvented via using environment variables which PA will pick up, but that's not a very nice solution). Also, GStreamer does not actually forward the pause request message to the applications and hence you'll effectively only see the muting taking happen, not the pause/unpause in current media players. To make this all work nicely jut a little bit glue code needs to be written for Gst and some minor patches be prepared for the various telephony apps/media players. If someone wants to pick this up and push this through this would be really great! THis is the one about tagging the stream, right https://bugzilla.gnome.org/show_bug.cgi?id=567656 It would be easy to implement. The reason its stalled is that as gstreamer is abstracting various technologies, we neeed to study where this could apply and if it's generic enough. Lennart, is there is ticket about the pause? I still wonder how it should be done (just forwarding to the app so that it will pause the pipeline). Also wonder if simmilar features could be mapped to other technologies. Finally we ned to figure how to merge such events, as e.g. a video editor might get this for a recording source and the playback sink (despite that a phone call should not interruppt a recoding session, but there is a category for that too). Stefan Lennart ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
