Re: add libcolorblind as an external dependencie
Hi Richard, I CC'ed the libcolorblind developer, Daniel, since he can say better than me about the libcolorblind stability. But I can say for now that this is not a complex library. What it does is quite simple and we already have cool effects using it in gnome-mag, here are some screenshots: http://www.gnome.org/~carlosd/color-blind-1.png http://www.gnome.org/~carlosd/color-blind-2.png http://www.gnome.org/~carlosd/color-blind-3.png http://www.gnome.org/~carlosd/color-blind-4.png http://www.gnome.org/~carlosd/color-blind-5.png http://www.gnome.org/~carlosd/color-blind-6.png http://www.gnome.org/~carlosd/color-blind-7.png http://www.gnome.org/~carlosd/color-blind-8.png Best regards, Carlos. On Thu, 2007-03-22 at 16:47 +, Richard Hughes wrote: On 22/03/07, Carlos Eduardo R. Diógenes [EMAIL PROTECTED] wrote: http://people.debian.org/~ruoso/colorblind-0.0.1.tar.gz The 0.0.1 version number scares me a little. How stable is libcolorblind? Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bugfix release
On Thu, 2007-03-22 at 18:45 -0600, Elijah Newren wrote: On 3/22/07, Alex Jones [EMAIL PROTECTED] wrote: I remember a while ago some people were talking about how it might be a good idea to dedicate a release cycle to fixing bugs, with a feature freeze in effect. Is there anyone still in support of this idea, or has it been generally discarded? [...] On the other hand, (I'm not sure if such a system might already be in place...) it might be reasonable to say that a given module might want to rally an extra bugfix release on the said current release - if for example an important bugfix was made in the platform after the 2.18.1 release - does that library maintainer have the right to ask for a 2.18.2 to be released to address this ? (and then I suppose the idea would be accepted/rejected by the release team) Or is that all just moot since vendors will go pick up the bugfix regardless of an official gnome release ? Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Desktop sounds in Gnome
Richard Hughes wrote: On 19/03/07, Étienne Bersac [EMAIL PROTECTED] wrote: So, will gnome 2.20 play nice sound when disk is burn, sound volume increased, mail received/sent, new RSS item available, etc. ? Would the system sounds be themable like icons are ? It would be great to theme these like we can icons. gnome-power-manager just needs to play a battery low chime, and linking to gstreamer seems very heavyweight. I love the fact that OS X has just one system beep sound. It makes things super simple from a user perspective. Do we really need, and do users really care about, different sounds for questions, information, battery low, etc. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bugfix release
On 3/23/07, Tristan Van Berkom [EMAIL PROTECTED] wrote: On the other hand, (I'm not sure if such a system might already be in place...) it might be reasonable to say that a given module might want to rally an extra bugfix release on the said current release - if for example an important bugfix was made in the platform after the 2.18.1 release Yes, quoting the tail of the second footnote of my previous email (my emails are too long...someone should file a bug against me): Another alternative for increasing focus on a particular topic is to have individual maintainers choose to follow them for their project. I have basically imposed feature freezes on myself for an entire development cycle for certain modules that I maintained, simply because I felt it was the right focus for my project at the time. - does that library maintainer have the right to ask for a 2.18.2 to be released to address this ? (and then I suppose the idea would be accepted/rejected by the release team) Sure, a maintainer can ask the community to do what we already planned on doing, but I don't see the point. ;-) (A 2.18.2 and 2.18.3 release are already planned on the proposed schedule at http://live.gnome.org/TwoPointNineteen, on May 30 and July 4, respectively. No one has objected to the schedule thus far[1], so it'll be official soon.) Cheers, Elijah [1] http://mail.gnome.org/archives/desktop-devel-list/2007-March/msg00157.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: add libcolorblind as an external dependencie
... Again, this filter is not meant to help usage of gnome applications itself, because gnome is already colorblind-friendly. We're talking here mainly about web content. To show that, I've taken some usefull screenshots using vertical split in gnome-mag [1]. Thanks for the screenshots Daniel, they are by far much better then the ones I have posted :-) daniel [1] http://people.debian.org/~ruoso/colorblind/ ___ Yahoo! Mail - Sempre a melhor opção para você! Experimente já e veja as novidades. http://br.yahoo.com/mailbeta/tudonovo/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: add libcolorblind as an external dependencie
On Fri, 2007-03-23 at 16:14 +, Daniel Ruoso wrote: Sex, 2007-03-23 às 10:14 -0500, Shaun McCance escreveu: Not to be disparaging, but the output on some of those is really pretty grainy, and some of them make the menu text harder to read. Is there really any form of color blindness for which black needs to be transformed to yellow? I've been thinking about this for some time now, and at the end there is two thing I think worth doing in libcolorblind... 1) The first 6 images were from the SELECTIVE_(SATURATE| DESSATURATE)_(RED|GREEN|BLUE). This filter is usefull to differ brown from dark green, light purple from baby blue without changing the entire color pallete. What I want to is to be able to dinamically change the sensitivity level (which would increase or decrease the grain, depending on what is on the screen), I mean, how I decide a color must be saturated or dessaturated. (and No, black doesn't turn into yellow in any filter). 2) Implemente the other three remaining filters, but this filters require the user to choose a base color. The other filters are SELECTIVE_(SATURATE|DESSATURATE), which would allow the user to saturate all colors with the same base as the one he chooses (usefull in a chart). The other is MONOCHROME_OTHERS which would turn monochromatic all colors except the one selected by the user. One thing that must be noted is that the colorblind filter is not supposed to be used all the time, and fortunally, no gnome application actually is colorblind-unfriendly. I would disagree that no Gnome applications are unfriendly to color-blind users. They're generally not outright hostile, but not all of them are friendly. Examples: * All but one of the themes in Five or More are unusable for color-blind users. The shapes theme was added by Callum because I really like Five or More, and I couldn't play it, and he's nice. But since it's not the default, screenshots in documentation don't use it, so our documentation isn't color-blind-friendly. * The colors of the numbers in Mines are hard-coded. It's still playable, because you can still read the numbers. But the colors can help your game if you can distinguish them. (Note that the hard-coded number colors could end up being completely unreadable for users with other sorts of vision problems, such as people using the high contrast inverse theme.) * The colors for the fill bars in the Disk Usage Analyzer are hard-coded. They used to be PNG images, and the red and green were virtually indistinguishable. Now they're custom-drawn, but with hard-coded colors. While the red and green are now distinguishable, the green and yellow are not. That's just off the top of my head. Not show-stopper bugs, but they are mild annoyances for color-blind users. The problem is mainly with web content, when you have charts with colorblind-unfriendly colors. At this time, the user is supposed to just turn the filter on on that moment, choosing which filter fits best on that image, and after reading the image, turn the filter off again. We certainly have great accessibility inside the desktop, and I think it's a great idea to make tools to compensate for the bad accessibility in places we can't control. What worries me, though, is the discoverability of this feature. As a color-blind user, if I encountered some pie chart on the web with crappy colors, it would never occur to me to open the screen magnifier. The technology is cool. Now we need to shake out the user interaction. Again, this filter is not meant to help usage of gnome applications itself, because gnome is already colorblind-friendly. We're talking here mainly about web content. To show that, I've taken some usefull screenshots using vertical split in gnome-mag [1]. daniel [1] http://people.debian.org/~ruoso/colorblind/ I can see the numbers! -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Desktop sounds in Gnome
On Fri, 2007-03-23 at 16:22 +, Thomas Wood wrote: Richard Hughes wrote: On 19/03/07, Étienne Bersac [EMAIL PROTECTED] wrote: So, will gnome 2.20 play nice sound when disk is burn, sound volume increased, mail received/sent, new RSS item available, etc. ? Would the system sounds be themable like icons are ? It would be great to theme these like we can icons. gnome-power-manager just needs to play a battery low chime, and linking to gstreamer seems very heavyweight. I love the fact that OS X has just one system beep sound. It makes things super simple from a user perspective. Do we really need, and do users really care about, different sounds for questions, information, battery low, etc. my personal opinion is no, we don't need all that. So, the question is, are there users that use and like this functionality? -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: add libcolorblind as an external dependencie
On Fri, 2007-03-23 at 12:02 -0500, Shaun McCance wrote: On Fri, 2007-03-23 at 16:14 +, Daniel Ruoso wrote: One thing that must be noted is that the colorblind filter is not supposed to be used all the time, That's an important point - this is something I'd use once in a blue (or maybe purple, but what's the difference) moon. I'd want to be able to quickly switch it on, try the different filters and then quickly switch it off again. Is integrating these filters with gnome-mag the best way to achieve that? (Honest question, it's been a while since I've played with gnome-mag) * The colors for the fill bars in the Disk Usage Analyzer are hard-coded. They used to be PNG images, and the red and green were virtually indistinguishable. Now they're custom-drawn, but with hard-coded colors. While the red and green are now distinguishable, the green and yellow are not. This kind of thing wouldn't bother me. The colours only serve as a subtle extra hint and I, personally, just completely ignore colour hints like that. It's fine to try and figure out better contrasting shades of those colours, but I wouldn't change them outright to different colours since that would surely make the hints a lot less useful to most people. What worries me, though, is the discoverability of this feature. As a color-blind user, if I encountered some pie chart on the web with crappy colors, it would never occur to me to open the screen magnifier. The technology is cool. Now we need to shake out the user interaction. Right. Again, this filter is not meant to help usage of gnome applications itself, because gnome is already colorblind-friendly. We're talking here mainly about web content. To show that, I've taken some usefull screenshots using vertical split in gnome-mag [1]. daniel [1] http://people.debian.org/~ruoso/colorblind/ I can see the numbers! Me too :-) hue-shift-positive seems to work best for me. I wonder is that always true, or just for these pictures? i.e. would I only need to figure out my filter preference once, or would it always be useful to me to try all filters? Cheers, Mark. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Desktop sounds in Gnome
things super simple from a user perspective. Do we really need, and do users really care about, different sounds for questions, information, battery low, etc. my personal opinion is no, we don't need all that. So, the question is, are there users that use and like this functionality? Personally: yes, I like the functionality very much! I have cordless headphones and often walk away from the compy whilst it is doing something which might take a while (CD burning, downloading, updating). I really like being notified audibly, and the different urgency I can assign to it -- a question? I'll wander back. Battery low? Find transformer and run! And that's before even considering accessibility, etc. -- glennji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Battstat-applet and GNOME 2.19.x
Okay, I'm re-opening an old discussion: Can we remove or deprecate battstat-applet for 2.19.x? GNOME Power Manager is being shipped by 99% of the distros, and it's just confusing to have another battery applet in the Add to panel dialog, especially now as they sometimes show different numbers. Seeing as GNOME has a formal external dependency on HAL, I don't see how the argument of g-p-m not running without HAL is still valid. So, let the discussion commence. Thanks, Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Battstat-applet and GNOME 2.19.x
On Sat, 2007-03-24 at 01:35 +0100, Diego Escalante wrote: As I said months ago when this discussion was up, I think that battstat-applet icon is far more informative at one glace than gnome-power-manager icon. Last time I checked at least. Depends. I would argue showing the icon according to the percentage is broken by design also, as 20% might be 7 minutes for one person or 30 minutes for another. It matters more to display the time accurately than the exact percentage level. I think the problem is that the icon has this grey border, like a glass border or something... In any case, a good idea would be to abuse a little more the colors. Sure, but I don't think it's that critical. See above. I think fedora theme the icon with the echo theme, and also ubuntu do with human. Are either of those easier to read at a glance out of interest? Also, right now the tray is already over abused and I would be against having to put yet another thing there. In a classic panel setup this doesn't sound evil but in more customized layouts the story can be different. Hmm. Do you not just show the icon when the battery is discharging? It's not like it's there all the time. Cheers for the comments. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Battstat-applet and GNOME 2.19.x
On Fri, 2007-03-23 at 19:07 -0700, Corey Burger wrote: On 3/23/07, Diego Escalante [EMAIL PROTECTED] wrote: Also, right now the tray is already over abused The simple reality is that all major distros are already shipping gpm and as such, the argument is kind of moot. True, but several people have noted that they'd really prefer that gnome-power-manager came in an applet form (or at least that there was an option for it to be an applet), rather than only a notification area beastie, so they can choose where it ends up on the panel. AfC Sydney 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
