Re: Google Summer of Code 2010 Call for Ideas
On Tue, 2010-03-09 at 18:34 -0800, Sandy Armstrong wrote: On Tue, Mar 9, 2010 at 5:20 PM, Brian Cameron brian.came...@sun.com wrote: Ruben: At the GNOME Usability Hackfest, it was discussed that there is a real need to develop some free software to help the GNOME Usability team better collaborate. Máirín Duffy discusses this in some detail in her blog: http://mairin.wordpress.com/2010/03/01/the-one-where-the-designers-ask-for-a-pony/ Could this project be a part of the Google Summer of Code project? That would be a great project, as long as somebody is willing to mentor it. ;-) That's usually the only limiting factor, as long as it's GNOME-related. It was already on my plans to draw-up a plan for it, along with some technical data. I've also added a few of the ideas from the UX hackfest to http://live.gnome.org/SummerOfCode2010/Ideas Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder : do NOT hardcode deprecation flags in tarball / new tarballs NEEDED
Le 12/01/2010 18:50, Frederic Crozat a écrit : Hi everyone, just a quick reminder about deprecation flags and tarball release : please avoid at all cost to hardcode deprecation flags in compilation flags, when a module is built from a tarball (it is ok to have such flags when building from gi checkout). Why, you may ask ? Well, I'm currently strugling with smoketesting GNOME 2.29.5 release and there are some tarballs no longer building because new G_SEAL deprecation were added in yesterday GTK+ 2.19.3 release and some modules were not fixed for this. Current guilty modules : - vte (bedhad is cooking a new release) - gnome-utils In a similar idea, try to avoid releasing tarballs which depends on other unreleased tarball module version. Since I'm the release team member taking care of 2.29.92 release, I'm going to rant again against modules which are hardcoding deprecation flags in their configure.in (or Makefile.am), even when building from tarballs. Please, avoid that, it is killing us, since many released modules are not building with latest gtk+ 2.19.7 (new deprecated added). If you want to use deprecation flags, check in configure.in if you are in a git checkout and enable them in that case, but do not enable them by default in tarballs. Current guilty modules, which needs a new release NOW (this is blocking GNOME 2.29.92 release): -gnome-python-desktop (doesn't build with latest totem-pl-parser, it seems) -clutter-gtk -evince -gconf-editor -gucharmap -gnome-mag -gnome-terminal Thanks you for you attention. -- Frederic Crozat Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder : do NOT hardcode deprecation flags in tarball / new tarballs NEEDED
On 10/03/10 19:05, Frederic Crozat wrote: Since I'm the release team member taking care of 2.29.92 release, I'm going to rant again against modules which are hardcoding deprecation flags in their configure.in (or Makefile.am), even when building from tarballs. Please, avoid that, it is killing us, since many released modules are not building with latest gtk+ 2.19.7 (new deprecated added). If you want to use deprecation flags, check in configure.in if you are in a git checkout and enable them in that case, but do not enable them by default in tarballs. This is also harmful to distributors as it means some packages will start to FTBFS when updating a different one (e.g. because it adds new deprecations). So full ACK. Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder : do NOT hardcode deprecation flags in tarball / new tarballs NEEDED
On Wed, 2010-03-10 at 19:05 +0100, Frederic Crozat wrote: Since I'm the release team member taking care of 2.29.92 release, I'm going to rant again against modules which are hardcoding deprecation flags in their configure.in (or Makefile.am), even when building from tarballs. Please, avoid that, it is killing us, since many released modules are not building with latest gtk+ 2.19.7 (new deprecated added). If you want to use deprecation flags, check in configure.in if you are in a git checkout and enable them in that case, but do not enable them by default in tarballs. In the gtkmm world, thanks to Daniel Elstner, we have long had a configure.ac macro that uses the autotools idea of maintainer-mode, so we can use certain build options when using autogen.sh or when doing distcheck, without affecting tarballs builds. The latest version is the MM_ARG_ENABLE_WARNINGS() macro, which is used in this example project: http://git.gnome.org/browse/mm-common/tree/skeletonmm/configure.ac#n55 It has some documentation here: http://git.gnome.org/browse/mm-common/tree/macros/mm-warnings.m4#n35 In Glom I use the older DK_ARG_ENABLE_WARNINGS() macro and you can see where I've mentioned deprecations: http://git.gnome.org/browse/glom/tree/configure.ac#n189 I've seen some talk of putting this in gnome-common, which seems like a good idea. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal for 3.0: Déjà Dup Backup Tool
On Wed, Mar 3, 2010 at 2:56 PM, Michael Terry m...@mterry.name wrote: In the interests of JFDI, I added deja-dup and its external dependency duplicity to jhbuild's 2.30 moduleset for ease of testing. Déjà Dup will also shortly land in Fedora rawhide, thanks to Rahul Sundaram! Indeed, it has landed now, and while we are considering whether to include it in the desktop spin or not, Jon and I went over the UI and interactions a bit, and came away with the following ideas for improvement. Don't be scared by this long list, it is mostly UI details... - Could have a better first-time screen than just two big buttons. Maybe just ask the user what he wants to backup if no locations have been configured yet... The entire question of initial setup and assisting the user with setting up a reasonable backup configuration is an interesting one that seems to be left out so far. - With a UI consisting just of two big buttons, the main window should not be resizable, since huge buttons look odd. In the same vein, the assistant windows should probably not be resizable. - The main window should not pop in and out as the two assistants are shown. - The button labels should probably have ellipses to indicate that there is a dialog coming up. Otherwise, people might be scared to click the Restore button, thinking that it might directly start a possibly destructive action. - When the restore is actually happening, it should warn me about overwriting files. It should also tell me what locations will be restored, before starting it, and ideally allow me to selectively restore. - The nautilus extension should only offer to restore files that are actually present in the backup - When restoring a single file (in nautilus), the success message at the end should not talk about 'files' - ngettext... - It would be good if the nautilus extension also allowed to add a location to the set of backup locations. - Identifying backups by date is ok, but it would be nice to make that a little less detailed. If there is only one backup from March 10, it would suffice to identify it as 'Today' or 'March 10', not the full 'Wed 10 Mar 2010 03:26:55 PM EST - If the 'Include from:' list in the Backup assistant is long enough to break over several lines, the window has size issues, the 'Except for:' line gets cut off. In the same dialog, an empty 'Except for:' line should probably just be hidden. - The Details expander in the progress page needs to enlarge the window to a reasonable size. It is somewhat tricky to get that right, but I have code to do it somewhere... Hope this helps, Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome-panel Improvement?
Hello, My name is Reda Lazri, I have an idea that needs some attention: It's the ability to change the icons in the notification area, you might understand in you just saw the mockup: http://0rax0.deviantart.com/art/Gnome-panel-improved-156723192 I really need someone to think about this, and whether or not it should/could be implemented. Cheers. -- - ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome-panel Improvement?
On 10/03/10 05:02 PM, rAX wrote: http://0rax0.deviantart.com/art/Gnome-panel-improved-156723192 I really need someone to think about this, and whether or not it should/could be implemented. Seems to me that would severely complicate theming. If the custom icon was saved in ~/.icons, it would be saved for a specific theme only. There isn't much preventing the user from doing this without a UI right now, I think. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GtkNotebook scrolling usability
So, right now GtkNotebook allows you to change tabs by using the mouse wheel. Once I noticed this and the more I thought about it, it really seems like a terrible feature and one that may be detrimental to usability. I talked to Matthias briefly on irc, and he seemed to agree. He suggested that maybe there's a use for it in the case that you have a ton of notebook tabs open, but I'm not quite convinced. Just wanted to post on the lists and see if people have thoughts on this, otherwise I'm probably going to file a patch to either rip the feature out or at the very least make it so we can disable it. :) / Cody ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GtkNotebook scrolling usability
Hi! I talked to Matthias briefly on irc, and he seemed to agree. He suggested that maybe there's a use for it in the case that you have a ton of notebook tabs open, but I'm not quite convinced. Just wanted to post on the lists and see if people have thoughts on this, otherwise I'm probably going to file a patch to either rip the feature out or at the very least make it so we can disable it. :) I always found if rather annoying. When you want to scroll in a text and hit the border of the notebook it changes tabs which you probably almost never want. Just my 2 cents... Regards, Johannes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GtkNotebook scrolling usability
On Wed, Mar 10, 2010 at 4:50 PM, Cody Russell brats...@gnome.org wrote: He suggested that maybe there's a use for it in the case that you have a ton of notebook tabs open, but I'm not quite convinced. Just wanted to post on the lists and see if people have thoughts on this, otherwise I'm probably going to file a patch to either rip the feature out or at the very least make it so we can disable it. :) I don't recall where but I'm fairly sure I saw someone using that to flip through open tabs in Epiphany. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GtkNotebook scrolling usability
On Wed, 2010-03-10 at 17:25 -0600, Jason D. Clinton wrote: On Wed, Mar 10, 2010 at 4:50 PM, Cody Russell brats...@gnome.org wrote: He suggested that maybe there's a use for it in the case that you have a ton of notebook tabs open, but I'm not quite convinced. Just wanted to post on the lists and see if people have thoughts on this, otherwise I'm probably going to file a patch to either rip the feature out or at the very least make it so we can disable it. :) I don't recall where but I'm fairly sure I saw someone using that to flip through open tabs in Epiphany. You might have been watching me. I do it all the time. But I don't think I ever do it in preference dialogs or other places where there's a static set of tabs. I'm sure there are people who trigger this accidentally, and it's very annoying for them. And I'm sure there are people who love this feature. So, you know, trade-off. -- Shaun McCance http://syllogist.net/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GtkNotebook scrolling usability
On 11/03/10 00:25, Jason D. Clinton wrote: On Wed, Mar 10, 2010 at 4:50 PM, Cody Russell brats...@gnome.org wrote: He suggested that maybe there's a use for it in the case that you have a ton of notebook tabs open, but I'm not quite convinced. Just wanted to post on the lists and see if people have thoughts on this, otherwise I'm probably going to file a patch to either rip the feature out or at the very least make it so we can disable it. :) I don't recall where but I'm fairly sure I saw someone using that to flip through open tabs in Epiphany. I like that feature, and use it in Epiphany too (and Liferea and probably everywhere there's a GtkNotebook). Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal for 3.0: Déjà Dup Backup Tool
Comments below. On 10 March 2010 15:49, Matthias Clasen matthias.cla...@gmail.com wrote: Jon and I went over the UI and interactions a bit, and came away with the following ideas for improvement. Don't be scared by this long list, it is mostly UI details... ::snip:: Hope this helps, Yes, it does, thanks! One of the things I wanted to eventually take advantage of is the GNOME usability team, but these are all valid usability issues. I haven't replied to each one because largely I agree and the particular details of why things are the way they are now aren't important. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GtkNotebook scrolling usability
On 03/11/2010 12:35 AM, Shaun McCance wrote: I do it all the time. But I don't think I ever do it in preference dialogs or other places where there's a static set of tabs. I'm sure there are people who trigger this accidentally, and it's very annoying for them. And I'm sure there are people who love this feature. So, you know, trade-off. In this case probably Safety vs. Efficency. http://mpt.net.nz/archive/2008/08/11/usability - Andreas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GtkNotebook scrolling usability
Il giorno mer, 10/03/2010 alle 16.50 -0600, Cody Russell ha scritto: Just wanted to post on the lists and see if people have thoughts on this, otherwise I'm probably going to file a patch to either rip the feature out or at the very least make it so we can disable it. :) I'm a big fan of this feature, it allows me to quickly switch between tabs without move the pointer. It's really useful when I don't know/remember which tab I actually need or want to activate. It helps you to be more streamlined, so I can't understand why it should be an issue for novice users... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GtkNotebook scrolling usability
On Wed, Mar 10, 2010 at 4:20 PM, Luca Ferretti elle@libero.it wrote: Il giorno mer, 10/03/2010 alle 16.50 -0600, Cody Russell ha scritto: Just wanted to post on the lists and see if people have thoughts on this, otherwise I'm probably going to file a patch to either rip the feature out or at the very least make it so we can disable it. :) I'm a big fan of this feature, it allows me to quickly switch between tabs without move the pointer. It's really useful when I don't know/remember which tab I actually need or want to activate. It helps you to be more streamlined, so I can't understand why it should be an issue for novice users... I also happen to be a fan of this feature. I use it in my web browser of choice, in gnome-terminal, in gedit, and similar applications. I don't find it as handy in preferences dialogs. If there ends up being a bug report about this, please share the bug number. And hopefully we can get some usability nerds involved in this decision. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
