Re: UI changes for control-center
Il giorno dom, 23/08/2009 alle 08.44 +0200, Frederic Peters ha scritto: > William Jon McCann wrote: > > > http://bugzilla.gnome.org/show_bug.cgi?id=592759 > > > > So, how about it? I promise they make the user experience better. Are you proposing to remove the Windows preferences capplet now? Isn't better wait for availability of "tweak ui" tool? If you really think it doesn't fit, you could simply hide the launcher. However, I think the proper timing for this kind of changes/removals will be the switch to gnome-shell, keeping the ui that users are accustomed in the meantime. Cheers, Luca ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Prioritisation amidst deprecation
Hallo everybody I'm trying to prioritise some work for the upcoming release, but I'm not 100% familiar with which modules will become deprecated and which will be most worth while to translate. Can anybody give some guidance about which modules might be close to end-of-life, which ones won't be used much anymore, or any similar issues that should affect translators like me who are not yet close to supported status? Thank you for any help. Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/pseudolocalisation-podebug-2 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
Hi, On Sun, Aug 23, 2009 at 6:06 AM, Luca Ferretti wrote: > Il giorno dom, 23/08/2009 alle 08.44 +0200, Frederic Peters ha scritto: >> William Jon McCann wrote: >> >> > http://bugzilla.gnome.org/show_bug.cgi?id=592759 >> > >> > So, how about it? I promise they make the user experience better. > > Are you proposing to remove the Windows preferences capplet now? Isn't > better wait for availability of "tweak ui" tool? If you really think it > doesn't fit, you could simply hide the launcher. Yes, we should remove it now - or years ago actually. There are a number of reasons why I don't think it is right to wait for the availability of a tweak UI tool. * If we don't remove the capplet there is less incentive to create such a tool * We shouldn't assume that such a tool will include this particular set of controls * We should let the demand/market determine whether such a tool is even desired * We shouldn't let these kind of issues hold us back from the providing a good user experience > However, I think the proper timing for this kind of changes/removals > will be the switch to gnome-shell, keeping the ui that users are > accustomed in the meantime. I don't agree at all, obviously. Even in the GNOME 2 panel, this window clutters up our Preferences menu and provides no real value for the overwhelming majority of people. However, since you mention it, one of the very important goals for 2.28 is to be a baseline system for testing the Shell. Keep in mind that the Windows menu is tied to features of the old metacity that may not even be relevant for mutter. And even if they are they are certainly not the type of thing we'd want to show as a toplevel control center feature. I mean, look at the options in that dialog. They are for tweakers. Let's remove it. Thanks, Jon ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
В Вск, 23/08/2009 в 10:40 -0400, William Jon McCann пишет: > Hi, > > On Sun, Aug 23, 2009 at 6:06 AM, Luca Ferretti wrote: > > Il giorno dom, 23/08/2009 alle 08.44 +0200, Frederic Peters ha scritto: > >> William Jon McCann wrote: > >> > >> > http://bugzilla.gnome.org/show_bug.cgi?id=592759 > >> > > >> > So, how about it? I promise they make the user experience better. > > > > Are you proposing to remove the Windows preferences capplet now? Isn't > > better wait for availability of "tweak ui" tool? If you really think it > > doesn't fit, you could simply hide the launcher. > > Yes, we should remove it now - or years ago actually. There are a > number of reasons why I don't think it is right to wait for the > availability of a tweak UI tool. > > * If we don't remove the capplet there is less incentive to create such a > tool > * We shouldn't assume that such a tool will include this particular > set of controls > * We should let the demand/market determine whether such a tool is even > desired > * We shouldn't let these kind of issues hold us back from the > providing a good user experience > > > However, I think the proper timing for this kind of changes/removals > > will be the switch to gnome-shell, keeping the ui that users are > > accustomed in the meantime. > > I don't agree at all, obviously. Even in the GNOME 2 panel, this > window clutters up our Preferences menu and provides no real value for > the overwhelming majority of people. However, since you mention it, > one of the very important goals for 2.28 is to be a baseline system > for testing the Shell. Keep in mind that the Windows menu is tied to > features of the old metacity that may not even be relevant for mutter. > And even if they are they are certainly not the type of thing we'd > want to show as a toplevel control center feature. I mean, look at > the options in that dialog. They are for tweakers. Let's remove it. It looks like it's a wrong mailing list (whatever of those in Cc) to discuss such things. Anyway, I'm strongly against removing this capplet. I need at least two things in it (and I don't think they are 'advanced' settings): focus-follows-mouse checkbox and a modifier key for window manipulations. That's my personal opinion, however. -- Alexey "Ktirf" Rusakov GNOME Project ALT Linux Team signature.asc Description: Эта часть сообщения подписана цифровой подписью ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
New string in orca.desktop file
Hi All: As part of http://bugzilla.gnome.org/show_bug.cgi?id=592741, which was done to meet the GNOME Goal for correct desktop files (see http://live.gnome.org/GnomeGoals/CorrectDesktopFiles), the following string was added to the orca.desktop file: +_GenericName=Screen Reader and Magnifier Thanks again for your hard work, Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
Adding descriptions for the benefit of people who don't want to sift through bugzilla or aren't comfortable reading patches. On Sun, 2009-08-23 at 08:44 +0200, Frederic Peters wrote: > William Jon McCann wrote: > > > There are a few changes we'd like to make to the control center before > > the string freeze. Some of these involve UI changes as well. So, > > according to http://live.gnome.org/TwoPointTwentyseven we need > > approval. > > > > http://bugzilla.gnome.org/show_bug.cgi?id=323323 On the Appearance preferences, adds link "Get more themes online" to the Theme tab, and adds link "Get more backgrounds online" to the Background tab. These point to art.gnome.org. OK by me. > > http://bugzilla.gnome.org/show_bug.cgi?id=591375 Puts a nice decoration on slideshow background images. See the screenshot from Matthias: http://bugzilla-attachments.gnome.org/attachment.cgi?id=140666 I didn't even know we have slideshow backgrounds. The User Guide doesn't even mention these anyway. No reason to block something that makes an already undocumented feature more intuitive. > > http://bugzilla.gnome.org/show_bug.cgi?id=592510 On the Background tab, makes the Add and Remove buttons the same size. I'm not quibbling over these kinds of changes. > > http://bugzilla.gnome.org/show_bug.cgi?id=592756 This proposes removing the Interface tab. This removes from the user the options to show icons in menus, enable editable menu shortcut keys, and change the toolbar button label style. > > http://bugzilla.gnome.org/show_bug.cgi?id=592759 This proposes removing the Window Preferences tool. This removes from the ability to use point-to-focus, change the titlebar double-click action, and change the window movement key. > > So, how about it? I promise they make the user experience better. > > I'll look at them later today (or tomorrow), CC'ing the documentation > list for eventual input, and the translators for possible string > changes. The first three are fine by me. The last two are much more substantive and would require documentation work. On a personal level, I'm not fond of making window shading even more difficult to find. How do you know that these make the user experience better? Do you have any data on how many users use these features? I know of at least one piece of commercial software that uses Alt+click for its own purposes. They have to instruct GNOME users to change the window movement key to use that feature. You'll be making their troubleshooting docs harder. I'm not saying we need to include every configuration option under the sun. But you need some sort of criteria for deciding whether to remove something. And it really seems like people are using "I don't use it" as their sole criterion, which just isn't good enough. -- Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New coordinator for Serbian translations
Hi Milos, Goran, all, Yesterday at 16:11, Goran Rakic wrote: > У уто, 18. 08 2009. у 16:55 +0200, Milos Popovic пише: >> My name is Miloš Popović. I am contributing to GNOME translations for a >> few years now (f-spot, gimp, nautilus, rhythmbox, gvfs, totem, brasero, >> etc.). Recently, Danilo Šergan recommends me to take over Serbian >> translation team, because he and Goran Rakić are quite busy recently, so >> our translations are "on hold". >> >> I hope that Danilo will confirm this change in our team soon. Indeed. I have updated the http://l10n.gnome.org/teams/sr a few months back, and also made Milos the default assignee for new bugs in Bugzilla for l10n/Serbian. FWIW, I fully support Milos' leadership of the Serbian translation team: he's basically been the only major contributor for quite a while already. I hope we can finally move forward with Milos as the Serbian team coordinator. Cheers, Danilo PS. Note that I have lost my mango password, so can't support any requests in there (and my attempts at getting password reset have failed so far: I understand the process is complex, but that doesn't really help with my limited time these days). ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
Hi, On Sun, Aug 23, 2009 at 12:48 PM, Shaun McCance wrote: ... > The first three are fine by me. The last two are much more > substantive and would require documentation work. > > On a personal level, I'm not fond of making window shading > even more difficult to find. > > How do you know that these make the user experience better? > Do you have any data on how many users use these features? You are welcome to do a study to see if people need the options in the window capplet. I know what you'll find if you ask the right people: "What is window shading?" But this isn't the point. The point is figuring out what kind of experience we want to provide - and then executing on it. The way we design our interfaces and the interfaces that we to provide say everything about what we value. If we show options for tweaking window management settings then we are saying that we think tweaking window management settings is something that you *should* do. This is especially true when the tool is a first class preference dialog - on the same level as sound, appearance, displays, etc. The same goes for the Interface tab. It is clearly not the story we want to be telling. Also, as mentioned in another message, the window preferences is strictly a metacity tweak tool. It doesn't apply to other window managers. Perhaps if someone really wants it they can move it to the metacity module as an optional tool. Otherwise, it doesn't belong in control center. > I know of at least one piece of commercial software that > uses Alt+click for its own purposes. They have to instruct > GNOME users to change the window movement key to use that > feature. You'll be making their troubleshooting docs harder. Well, I can't really respond to this without particulars. But it doesn't sound like a good reason to me. > I'm not saying we need to include every configuration option > under the sun. But you need some sort of criteria for deciding > whether to remove something. And it really seems like people > are using "I don't use it" as their sole criterion, which just > isn't good enough. Not at all. What people are you referring to? I don't know anyone who is thinking about this as shallowly as you suggest. My concern isn't about whether I use it or not. As I said above, it is about what story we are trying to tell, the experience we want to provide, and about how we show our values. This capplet and tab are poor design decisions - and need to go. Jon ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Prioritisation amidst deprecation
Ahoj, Am Sonntag, den 23.08.2009, 13:46 +0200 schrieb F Wolff: > Can anybody give some guidance about which modules might be close to > end-of-life, which ones won't be used much anymore, or any similar > issues that should affect translators like me who are not yet close to > supported status? Deprecated modules are listes on the subpages of http://live.gnome.org/TwoPointTwentyseven/ . List of deprecated translatable modules that will be killed for GNOME 3.0 & are part of the official GNOME 2.28 module set: * libbonobo(ui): used by a variety of applications in 2.28 * at-spi: used by several applications (Replacement: at-spi2) * libgnome: used by Evolution and Tomboy in 2.28 * libgnomeui: used by Evolution and gnome-panel in 2.28 * libgnomecanvas: used by Evolution in 2.28 * libgnomeprint(ui): not used anymore by any module in 2.28 * gnome-vfs: not used anymore by any module in 2.28 (For your interest: Unused modules are still shipped in 2.28 as we guarantee API platform stability for the GNOME 2.x series) Furthermore, * gnome-mag will either get killed for 3.0 (if we can have a magnifier in gnome-shell) or will be ported to a D-Bus API * gnome-speech might get killed for 3.0 in favor of speed-dispatcher * gconf *might* get replaced by dconf for 3.0 or 3.2 * gtkhtml *might* get replaced by WebKit for 3.2 Also I'd give Development tools a lower priority as most developers speak english anyway. I have added a "Choosing the last packages to translate" section to http://live.gnome.org/TranslationProject/LocalisationGuide . andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
Il giorno dom, 23/08/2009 alle 10.40 -0400, William Jon McCann ha scritto: > * We should let the demand/market determine whether such a tool is even > desired William, we are not speaking about a feature like "let me change the theme to show my friends how cool is my pc" that anyone expects from a desktop environment. The kind of feature that, if you remove it, people will track you to use tickle torture :D Windows capplet is the perfect example of a tool that exposed (somewhere) in the UI is a way for users to learn what GNOME can do. Asking yourself "What does this ?" is a good starting point to explore the capabilities of GNOME, even if it's something that you will use only once in your lifetime. Rarely used options aren't useless options. Exaggerating and going politically incorrect, we could move all a11y related UI to gconf 'cause there are not so much people that use them. If we stick those stuff in gconf, only GNOME developers, translators and documenters will know that you can, for example, shade a window. As a side note, in my experience with other GNOME users, it seems that a common desire[1] about window management is the ability to close a window double-clicking on the icon in title bar. This case makes me think about: * the demand may be "wrong" * the demand may stay unimplemented > However, since you mention it, > one of the very important goals for 2.28 is to be a baseline system > for testing the Shell. Keep in mind that the Windows menu is tied to > features of the old metacity that may not even be relevant for mutter. If we are planning to "remove" those features moving from metacity to mutter, then another solution could be move the Windows capplet in metacity source tree. [1] desire, maybe non exposed in form of bug reports: users sometimes are lazy in bug reporting, but grumble when they know you are a GNOME contributor :) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
On Sun, 2009-08-23 at 13:23 -0400, William Jon McCann wrote: > Hi, > > On Sun, Aug 23, 2009 at 12:48 PM, Shaun McCance wrote: > ... > > The first three are fine by me. The last two are much more > > substantive and would require documentation work. > > > > On a personal level, I'm not fond of making window shading > > even more difficult to find. > > > > How do you know that these make the user experience better? > > Do you have any data on how many users use these features? > > You are welcome to do a study to see if people need the options in the > window capplet. I know what you'll find if you ask the right people: > "What is window shading?" But this isn't the point. The point is > figuring out what kind of experience we want to provide - and then > executing on it. The way we design our interfaces and the interfaces > that we to provide say everything about what we value. If we show > options for tweaking window management settings then we are saying > that we think tweaking window management settings is something that > you *should* do. This is especially true when the tool is a first > class preference dialog - on the same level as sound, appearance, > displays, etc. It's not always what users *should* do. Sometimes it's just what users *need* to do. Do users need to select whether or not there are icons in menus? Almost certainly not. Do they need to tell the window manager to stop stealing Alt+click? Yes, there are users who need to do this to make effective use of the software they use. And who exactly is "we"? I think maximizing windows is a terrible way to work, and that minimizing is by far inferior to shading. So if I'm allowed to be a part of the "we" that decides what kind of experience "we" want to provide, then yes, I do want to encourage people to use window shading. > The same goes for the Interface tab. It is clearly not the story we > want to be telling. > > Also, as mentioned in another message, the window preferences is > strictly a metacity tweak tool. It doesn't apply to other window > managers. Perhaps if someone really wants it they can move it to the > metacity module as an optional tool. Otherwise, it doesn't belong in > control center. This paragraph doesn't really fit in with the rest of your argument. Throughout the rest of the email you talk about deciding on what experience we want to provide. And yet here you use window manager swapping as an argument. Is swapping out your window manager really an experience we want to promote? > > I know of at least one piece of commercial software that > > uses Alt+click for its own purposes. They have to instruct > > GNOME users to change the window movement key to use that > > feature. You'll be making their troubleshooting docs harder. > > Well, I can't really respond to this without particulars. But it > doesn't sound like a good reason to me. People don't use computers to look at their desktops. If we don't care about the problems people have when running third-party software, well, we have a problem. The program I was referring to is Mathematica, but after a cursory Googling, I've found people having the same issue with a number of other programs. So, OK, tell everybody that the desktop owns Alt+click and those programs are broken, right? Except most of these programs aren't targetting Gnome. Figuring this stuff out as an ISD when your software might be run under $deity-knows-how-many window managers is pretty much impossible. > > I'm not saying we need to include every configuration option > > under the sun. But you need some sort of criteria for deciding > > whether to remove something. And it really seems like people > > are using "I don't use it" as their sole criterion, which just > > isn't good enough. > > Not at all. What people are you referring to? I don't know anyone > who is thinking about this as shallowly as you suggest. My concern > isn't about whether I use it or not. As I said above, it is about > what story we are trying to tell, the experience we want to provide, > and about how we show our values. This capplet and tab are poor > design decisions - and need to go. OK, I apologize for mischaracterizing your argument. I should have asked for your reasoning first. Nonetheless, I don't see that anybody has actually looked into the impact of these changes have on users. Furthermore, we have interface freezes for a reason. These are substantial changes to the user experience that require us to modify the documentation. It's not just a matter of removing content. Since nobody else is looking at the user impact, we'll have to look at each of the options being removed, decide whether we're introducing stumbling blocks for a substantial number of users, and if necessary write considerably more complicated instructions. -- Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
Hey, On Sun, Aug 23, 2009 at 4:52 PM, Shaun McCance wrote: > On Sun, 2009-08-23 at 13:23 -0400, William Jon McCann wrote: >> Hi, >> >> On Sun, Aug 23, 2009 at 12:48 PM, Shaun McCance wrote: >> ... >> > The first three are fine by me. The last two are much more >> > substantive and would require documentation work. >> > >> > On a personal level, I'm not fond of making window shading >> > even more difficult to find. >> > >> > How do you know that these make the user experience better? >> > Do you have any data on how many users use these features? >> >> You are welcome to do a study to see if people need the options in the >> window capplet. I know what you'll find if you ask the right people: >> "What is window shading?" But this isn't the point. The point is >> figuring out what kind of experience we want to provide - and then >> executing on it. The way we design our interfaces and the interfaces >> that we to provide say everything about what we value. If we show >> options for tweaking window management settings then we are saying >> that we think tweaking window management settings is something that >> you *should* do. This is especially true when the tool is a first >> class preference dialog - on the same level as sound, appearance, >> displays, etc. > > It's not always what users *should* do. Sometimes it's just > what users *need* to do. Do users need to select whether or > not there are icons in menus? Almost certainly not. Do they > need to tell the window manager to stop stealing Alt+click? > Yes, there are users who need to do this to make effective > use of the software they use. > > And who exactly is "we"? I think maximizing windows is a > terrible way to work, and that minimizing is by far inferior > to shading. So if I'm allowed to be a part of the "we" that > decides what kind of experience "we" want to provide, then > yes, I do want to encourage people to use window shading. Ok, so we're down to discussing two features in particular. Alt+Click and Window shading. Right? If alt+click is as problematic as you suggest then perhaps we are wrong to rely on that as something that can be owned by the window manager. It is just not acceptable to require that users tweak this shit for that reason. It if exactly because we haven't standardized this kind of thing - and allow customization of basically all hotkeys - that we find ourselves in this situation. We can't tell a story to ISVs. All other platforms that I know of have reserved hotkeys. Also, I don't find it very interesting to try to work around proprietary applications that don't attempt to fit into our platform. And for our part we need to do better to provide a saner platform. Window shading is a really geeky feature. I am asserting that it is not what we want to promote. It is totally fine for you to use it of course. And you may end up being the one motivated to write the tweak UI tool that exposes this functionality graphically. If you feel that we should be promoting window shading then I think the burden of proof is on you. >> The same goes for the Interface tab. It is clearly not the story we >> want to be telling. >> >> Also, as mentioned in another message, the window preferences is >> strictly a metacity tweak tool. It doesn't apply to other window >> managers. Perhaps if someone really wants it they can move it to the >> metacity module as an optional tool. Otherwise, it doesn't belong in >> control center. > > This paragraph doesn't really fit in with the rest of your > argument. Throughout the rest of the email you talk about > deciding on what experience we want to provide. And yet > here you use window manager swapping as an argument. Is > swapping out your window manager really an experience we > want to promote? GNOME Shell is built on mutter. Which is a diverging fork of metacity. For 2.28 (as an alpha/testbed for 3.0) we are going to support switching between metacity and gnome-shell/mutter. Yes. It is an open question if we will continue to support all the crazy options in metacity. >> > I know of at least one piece of commercial software that >> > uses Alt+click for its own purposes. They have to instruct >> > GNOME users to change the window movement key to use that >> > feature. You'll be making their troubleshooting docs harder. >> >> Well, I can't really respond to this without particulars. But it >> doesn't sound like a good reason to me. > > People don't use computers to look at their desktops. > If we don't care about the problems people have when > running third-party software, well, we have a problem. > > The program I was referring to is Mathematica, but > after a cursory Googling, I've found people having > the same issue with a number of other programs. > > So, OK, tell everybody that the desktop owns Alt+click > and those programs are broken, right? Except most of > these programs aren't targetting Gnome. Figuring this > stuff out as an ISD when your software
Re: String additions to 'at-spi.master'
Hi Li Yuan, your commit 22a0d9a3caa235dad52d6cab467d2146bed5dd62 added a translatable string to at-spi master, but at-spi master is string frozen as master is also used for GNOME 2.26. You should retroactively create a gnome-2-26 branch before this commit, plus announce this properly on this mailing list as GNOME 2.27 is in String Announcement period. Note that String *Freeze* for 2.27 starts today as per http://live.gnome.org/Schedule . Am Samstag, den 22.08.2009, 20:09 + schrieb GNOME Status Pages: > This is an automatic notification from status generation scripts on: > http://l10n.gnome.org. > There have been following string additions to module 'at-spi.master': > + "AT SPI Registry Wrapper" andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
On Sun, 2009-08-23 at 17:24 -0400, William Jon McCann wrote: > Hey, > > On Sun, Aug 23, 2009 at 4:52 PM, Shaun McCance wrote: > > On Sun, 2009-08-23 at 13:23 -0400, William Jon McCann wrote: > >> Hi, > >> > >> On Sun, Aug 23, 2009 at 12:48 PM, Shaun McCance wrote: > >> ... > >> > The first three are fine by me. The last two are much more > >> > substantive and would require documentation work. > >> > > >> > On a personal level, I'm not fond of making window shading > >> > even more difficult to find. > >> > > >> > How do you know that these make the user experience better? > >> > Do you have any data on how many users use these features? > >> > >> You are welcome to do a study to see if people need the options in the > >> window capplet. I know what you'll find if you ask the right people: > >> "What is window shading?" But this isn't the point. The point is > >> figuring out what kind of experience we want to provide - and then > >> executing on it. The way we design our interfaces and the interfaces > >> that we to provide say everything about what we value. If we show > >> options for tweaking window management settings then we are saying > >> that we think tweaking window management settings is something that > >> you *should* do. This is especially true when the tool is a first > >> class preference dialog - on the same level as sound, appearance, > >> displays, etc. > > > > It's not always what users *should* do. Sometimes it's just > > what users *need* to do. Do users need to select whether or > > not there are icons in menus? Almost certainly not. Do they > > need to tell the window manager to stop stealing Alt+click? > > Yes, there are users who need to do this to make effective > > use of the software they use. > > > > And who exactly is "we"? I think maximizing windows is a > > terrible way to work, and that minimizing is by far inferior > > to shading. So if I'm allowed to be a part of the "we" that > > decides what kind of experience "we" want to provide, then > > yes, I do want to encourage people to use window shading. > > Ok, so we're down to discussing two features in particular. Alt+Click > and Window shading. Right? Those are the two that I had something to say about. There are people who still love sloppy focus. I'm not necessarily saying we need to design for them. But it's something to take into consideration. > If alt+click is as problematic as you suggest then perhaps we are > wrong to rely on that as something that can be owned by the window > manager. It is just not acceptable to require that users tweak this > shit for that reason. It if exactly because we haven't standardized > this kind of thing - and allow customization of basically all hotkeys > - that we find ourselves in this situation. We can't tell a story to > ISVs. All other platforms that I know of have reserved hotkeys. > Also, I don't find it very interesting to try to work around > proprietary applications that don't attempt to fit into our platform. > And for our part we need to do better to provide a saner platform. So, yeah, I totally agree we're in a sucky situation here. Windows and Mac both reserve certain things for the desktop, and ISDs know that and deal with it. The tight spot we find ourselves in is that most ISDs aren't going to target Gnome or KDE or XFCE. We're lucky when they target the Linux desktop at all. And because Gnome and KDE each reserve different things for the desktop, those ISDs find themselves pretty much SOL. It's a hard situation. I'm not putting the blame on us, and I'm not putting the blame on ISDs. It's just one of the many difficulties that we've all inherited. And if we can solve that difficulty once and for all, frickin' awesome. But if we can't (or we just haven't yet), then workarounds are just a fact of life. > Window shading is a really geeky feature. I am asserting that it is > not what we want to promote. It is totally fine for you to use it of > course. And you may end up being the one motivated to write the tweak > UI tool that exposes this functionality graphically. If you feel that > we should be promoting window shading then I think the burden of proof > is on you. It's only a geeky feature because we've relegated it to the dark geeks-only shadows. There's nothing about minimizing that's inherently more intuitive than shading. It's just what people are used to because Microsoft Windows has 90+% of the desktop market share. Before OS X, Mac used window shading. And I don't think Mac is a particularly geeky desktop. > >> The same goes for the Interface tab. It is clearly not the story we > >> want to be telling. > >> > >> Also, as mentioned in another message, the window preferences is > >> strictly a metacity tweak tool. It doesn't apply to other window > >> managers. Perhaps if someone really wants it they can move it to the > >> metacity module as an optional tool. Otherwise, it doesn't belong in > >> control center. >
string addition in gnome-util
Hi,
A string has been added to gnome-util in
http://bugzilla.gnome.org/show_bug.cgi?id=592372
_("Screenshot taken"))
Thanks,
Jon
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Little help with string for gnome-disk-utility
As I'm going though the very extensive gnome-disk-utility strings I came across this one: #. Translators: Shown in the "Self-tests" item in the status table #: ../src/gdu-gtk/gdu-ata-smart-dialog.c:2611 #, fuzzy msgid "Last self-test FAILED (Servo)" I was wondering if anyone can tell me the meaning of Servo? Thanks in advance, -- Og B. Maciel omac...@foresightlinux.org ogmac...@gnome.org ogmac...@ubuntu.com GPG Keys: D5CFC202 http://www.ogmaciel.com (en_US) http://blog.ogmaciel.com (pt_BR) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
New string in at-spi
Hi, To fix http://bugzilla.gnome.org/show_bug.cgi?id=578334 , we added a desktop file for at-spi-registryd to let gnome-session manage it. A new string was added to the desktop file: _Name=AT SPI Registry Wrapper Thanks very much, Li ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[at-spi] created branch gnome-2-26
Hi, We just created a branch for gnome-2-26: d3538c26be2db7ea3b751f2f6538d00e90d1fa93 Updated Irish translation Thanks, Li ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'at-spi.master'
Hi Andre Klapper, Thanks for the notification. I forgot to create gnome-2-26 branch I think. Li On Mon, 2009-08-24 at 00:02 +0200, Andre Klapper wrote: > Hi Li Yuan, > > your commit 22a0d9a3caa235dad52d6cab467d2146bed5dd62 added a > translatable string to at-spi master, but at-spi master is string frozen > as master is also used for GNOME 2.26. > You should retroactively create a gnome-2-26 branch before this commit, > plus announce this properly on this mailing list as GNOME 2.27 is in > String Announcement period. Note that String *Freeze* for 2.27 starts > today as per http://live.gnome.org/Schedule . > > Am Samstag, den 22.08.2009, 20:09 + schrieb GNOME Status Pages: > > This is an automatic notification from status generation scripts on: > > http://l10n.gnome.org. > > There have been following string additions to module 'at-spi.master': > > + "AT SPI Registry Wrapper" > > > andre ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: UI changes for control-center
On Sun, Aug 23, 2009 at 6:07 PM, Shaun McCance wrote: > >> I agree that these proprietary applications are going to have to >> change their docs. And we will have to change some docs in GNOME too. >> Which docs in particular do you think need to be changed? If this is >> going to be a problem then I'll update the docs too. Is that >> necessary? > > For starters, the relevant sections in the User Guide. > And then other material needs to be audited. And we > have to analyze the user impact to see if we need to > add troubleshooting docs. > > I can't just tell you exactly what needs to be edited, > because that's the hard part. Typing words is a pretty > small part of writing. Deciding what needs to be written > is where the real work is. Looking over the user guide, there are sections Configuring Your Desktop > Look and Feel > Appearance Preferences > Interface Preferences and Configuring Your Desktop > Look and Feel > Windows Preferences which will have to be axed along with the UI they describe. And then there is this sentence: You can also press-and-hold Alt and drag any part of the window. in the section Desktop Overview > Windows > Manipulating Windows. Worth pointing out that it is already a half-truth, since the current UI makes the modifier configurable, which should be mentioned here. My suggestion for Alt-click is to turn it off by default, since it seems to cause problems for some apps, and the functionality is available via the window menu anyway. Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Little help with string for gnome-disk-utility
Hi Og, El dom, 23-08-2009 a las 22:48 -0400, Og Maciel escribió: > As I'm going though the very extensive gnome-disk-utility strings I > came across this one: > > #. Translators: Shown in the "Self-tests" item in the status table > #: ../src/gdu-gtk/gdu-ata-smart-dialog.c:2611 > #, fuzzy > msgid "Last self-test FAILED (Servo)" > > I was wondering if anyone can tell me the meaning of Servo? Not 100% sure, but I guess it refers to a servomechanism: http://en.wikipedia.org/wiki/Servomechanism > > Thanks in advance, Cheers. -- Jorge González González Weblog: http://aloriel.no-ip.org Fotolog: http://www.flickr.com/photos/aloriel ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
