Re: GNOME Goal Proposal: Port to GMenu
On Thu, 2012-04-26 at 13:55 +0100, Allan Day wrote: It would be great if we could improve on the current situation and ensure that all our applications present an appropriate set of items in their GMenu. Is there a reference application doing this right? I ask this because Epiphany¹ has no menu, but does and a funky button over on the right that, upon investigation, turns out to be a menu has useful things like add bookmark ... but not preferences! Which, eventually and quite by accident, I discovered was in the global GMenu thing up top. Oh. Presumably that's not quite what you're aiming for. Perhaps you can suggest a current GNOME app that *is* doing precisely what it is you want us all to do? AfC Sydney ¹ Please, for the love of all that's holy, can we please just rename it from Web back to Epiphany? I thought we gave up that generic no-name application thing in about GNOME 2.10. No one tried to rename Firefox. And if you type Web into Shell's Overview, you get... Firefox. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Mon, May 7, 2012 at 7:15 AM, Andrew Cowie and...@operationaldynamics.com wrote: On Thu, 2012-04-26 at 13:55 +0100, Allan Day wrote: It would be great if we could improve on the current situation and ensure that all our applications present an appropriate set of items in their GMenu. Is there a reference application doing this right? There are two paths available to applications - (1) replace the menu bar entirely, or (2) move some items to the app menu. For (1), the calculator [1] is a good example. For (2), I'd recommend checking out Nautilus [2]. I'm happy to give design advise on any specific examples. Just file a bug and cc me. I ask this because Epiphany¹ has no menu, but does and a funky button over on the right that, upon investigation, turns out to be a menu has useful things like add bookmark ... but not preferences! Which, eventually and quite by accident, I discovered was in the global GMenu thing up top. Oh. ... Epiphany is a slightly unusual case, since it's in the process of transitioning to Web. (The gear button menu isn't in the Web mockups.) The best way to prevent those 'oh' moments is to be consistent in the placement of menu items like preferences (that item should always be in the app menu). The sooner we can get every application looking and behaving the same way, the better. Allan [1] https://bugzilla.gnome.org/show_bug.cgi?id=674529 [2] https://bugzilla.gnome.org/show_bug.cgi?id=674532 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
Il giorno lun, 07/05/2012 alle 16.15 +1000, Andrew Cowie ha scritto: I ask this because Epiphany¹ has no menu, but does and a funky button over on the right that, upon investigation, turns out to be a menu has useful things like add bookmark ... but not preferences! Which, eventually and quite by accident, I discovered was in the global GMenu thing up top. Oh. On this note, I have to say it was quite difficult for me at first to figure out there was a menu hidden under the activity title you see on the Shell bar. Back in 3.0 and 3.2 days, it contained only a Exit item for all apps I can remember of, and even then, I only discovered it by mistake - I did not think it was clickable, only a visual current-application title. Add to this that most applications present already with a menu bar inside their window, and it really is hard for a user to figure out there is a menu *outside* the window. Maybe it's only me (I always found the Mac OS X approach counter-intuitive too), but having to search menus in two places isn't ideal. Also, if I have two apps side-by-side, I need to change the current focus to click on the GMenu. So, some consistency is needed, I'd say. Or else instead than one place for menus, we end up with two places for menus. And with apps like Evolution, that have a lot of menu items, I am not entirely sure it is feasible to move them under the upper GMenu. By the way, and slightly unrelated: F10 allows me to pop up the first menu, and ALT+letter to open a specific one by accelerator. What is the corresponding shortcut for the upper menu? Finally, a design question: why GMenu (and some related classes, come to think of that) are in GIO and not in Gtk+? This is just to understand the rationale behind the choice. When I looked at the documentation, I expected at first to find it in Gtk+. Thanks! -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d--(-) s+: a- C+++ UL+++ P+ L$ E+ W+++ N+ o? w--- O M- V- PS++ PE- Y+++ PGP+++ t++ 5 X- R+ !tv b+++ DI++ D++ G++ e++ h+ r++ y+ --END GEEK CODE BLOCK-- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Please check your sources for strings not marked for translation before release
Hallo developers. Since the release of GNOME 3.4 we have received a steady stream of emails saying This is not a string freeze break, we just forgot to mark the strings for translation. So much so, that the statistics e.g. for my language (which has not been touched since release) now counts 63* untranslated or fuzzy strings in a source that was at 0 at release time, three weeks ago. I understand the reason for not counting marking existing strings as a string freeze break. But please understand that even though you are in your right to fix things like this post release, and even though it off course makes sense to do it, it does not mean that it is not annoying and a burden for translators. The reason for this is that we concentrate large amounts of work in the period just before release (where string changes are relatively quiet), so therefore it is also an advantage for us if we can finish as much of it as possible in that period (of course also because a lot of us has an extra hat as distribution translators for distributions that follow within a month or so of the gnome release). On top of that, small updates are uncharacteristically expensive in a work/string-sense because they involve the same amount of emails back and forth for proofreading and git work. So please... If you could make a bit more of an effort of checking your sources for non-internationalized strings before release that would be great. IMHO 63 is just a bit on the high side of where this number should be Regards Kenneth * These 63 off course also include genuinely new strings due e.g. to bug fixes. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Please check your sources for strings not marked for translation before release
Den 07-05-2012 14:04, Jorge González skrev: Hello, On Mon, May 7, 2012 at 1:59 PM, Kenneth Nielsenk.nielse...@gmail.com wrote: Hallo developers. Since the release of GNOME 3.4 we have received a steady stream of emails saying This is not a string freeze break, we just forgot to mark the strings for translation. So much so, that the statistics e.g. for my language (which has not been touched since release) now counts 63* untranslated or fuzzy strings in a source that was at 0 at release time, three weeks ago. I understand the reason for not counting marking existing strings as a string freeze break. But please understand that even though you are in your right to fix things like this post release, and even though it off course makes sense to do it, it does not mean that it is not annoying and a burden for translators. The reason for this is that we concentrate large amounts of work in the period just before release (where string changes are relatively quiet), so therefore it is also an advantage for us if we can finish as much of it as possible in that period (of course also because a lot of us has an extra hat as distribution translators for distributions that follow within a month or so of the gnome release). On top of that, small updates are uncharacteristically expensive in a work/string-sense because they involve the same amount of emails back and forth for proofreading and git work. So please... If you could make a bit more of an effort of checking your sources for non-internationalized strings before release that would be great. IMHO 63 is just a bit on the high side of where this number should be Can't this be half-automatized? like with a bash script that checks the strings, which are marked and which not? It could be helpful. I guess it may depend on the syntax of the language. But I guess for most languages it should be doable[1] to make a script the output all the strings that has not been marked. It might of course contain false positives in the form of strings purposely not marked for translation, but I guess it should be easier to review this output than the entire source. The pseudo translation approach as mentioned by Friedel is of course also an options, I'm just not sure if it is as easy for developers to exercise the application as suggested in the wiki page. Regards Kenneth [1] By someone with an appropriate level of reg-exp-fu Regards Kenneth Kind regards. * These 63 off course also include genuinely new strings due e.g. to bug fixes. ___ gnome-i18n mailing list gnome-i...@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Please check your sources for strings not marked for translation before release
On Mon, May 7, 2012 at 7:59 AM, Kenneth Nielsen k.nielse...@gmail.com wrote: So please... If you could make a bit more of an effort of checking your sources for non-internationalized strings before release that would be great. IMHO 63 is just a bit on the high side of where this number should be Of course, we should try to avoid these less-than-perfect appearances in .0 releases. What would help enormously is if we had more testing in non-English locales, to find these things. Actually, we just need more testing in general, period. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Mon, May 7, 2012 at 1:28 PM, Allan Day allanp...@gmail.com wrote: On Mon, May 7, 2012 at 7:15 AM, Andrew Cowie Is there a reference application doing this right? There are two paths available to applications - (1) replace the menu bar entirely, or (2) move some items to the app menu. For (1), the calculator [1] is a good example. For (2), I'd recommend checking out Nautilus [2]. For [2] there are actually two paths as well: a) keep the existing menus, but add an additional application menu; the tricky part is to make sure that the app menu is not shown in non-gnome environments (as windows would end up with *two* menubars), and hide items already in the app menu from regular menus when running in gnome b) port *all* menus to GMenu, and use gtk_application_set_menubar() to set the in-window menubar; in environments that do not support the app menu, GTK+ will display it as first item in the menubar *automagically* So for a transitional period, option [2]a is OK, but long term application should really go with [1] or [2]b. Regards, Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Mon, May 7, 2012 at 1:41 PM, Matteo Settenvini matteo...@member.fsf.orgwrote: By the way, and slightly unrelated: F10 allows me to pop up the first menu, and ALT+letter to open a specific one by accelerator. What is the corresponding shortcut for the upper menu? SuperF10 to open, arrow keys to navigate (I'm not saying that ALT+letter would be a bad idea, but at least for now we don't support that in any shell menu, so the app menu is consistent here) Regards, Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Sharing widgets between GNOME 3 applications
The newly designed (or redesigned) GNOME 3 applications have some common UI elements. For example, if you look at the following designs, you will notice that the main toolbar, selection toolbar, main icon view, etc. are quite similar: + https://live.gnome.org/Design/Apps/Boxes + https://live.gnome.org/Design/Apps/Documents + https://live.gnome.org/Design/Apps/Photos We may benefit from having a way to share these widgets among the applications. Currently, what I have been doing, for gnome-photos, is to copy-paste the *.c/*.h files from the gnome-documents tree. One downside of doing this is that the gnome-photos binary has some dead code which will never be executed. For example the code path that implements the list view for Documents, which is not necessary for Photos. So all the classes implementing it need to be copied over into the gnome-photos tree to avoid maintaining a fork of the GdMainView widget. Currently it is not so much of a practical problem, but I am curious to know if people have better ideas about this. Happy hacking, Debarshi -- Give a man ssh access, he'll still need a computer. Give him a computer, he'll give ssh access to you. -- Ashish Shukla pgpeAbZEigTlR.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Mon, May 7, 2012 at 12:41 PM, Matteo Settenvini matteo...@member.fsf.org wrote: Il giorno lun, 07/05/2012 alle 16.15 +1000, Andrew Cowie ha scritto: I ask this because Epiphany¹ has no menu, but does and a funky button over on the right that, upon investigation, turns out to be a menu has useful things like add bookmark ... but not preferences! Which, eventually and quite by accident, I discovered was in the global GMenu thing up top. Oh. On this note, I have to say it was quite difficult for me at first to figure out there was a menu hidden under the activity title you see on the Shell bar. Back in 3.0 and 3.2 days, it contained only a Exit item for all apps I can remember of, and even then, I only discovered it by mistake - I did not think it was clickable, only a visual current-application title. Right, so this is another reason why it is important for us to ensure that the app menu is always populated. As this functionality becomes universal people will discover it more quickly and we can do more to advertise it to users. Add to this that most applications present already with a menu bar inside their window, and it really is hard for a user to figure out there is a menu *outside* the window. Maybe it's only me (I always found the Mac OS X approach counter-intuitive too), but having to search menus in two places isn't ideal. I think that all of this can be overcome with consistency. Users just need to learn the new structure. Also, if I have two apps side-by-side, I need to change the current focus to click on the GMenu. Is that so terrible? So, some consistency is needed, I'd say. Or else instead than one place for menus, we end up with two places for menus. And with apps like Evolution, that have a lot of menu items, I am not entirely sure it is feasible to move them under the upper GMenu. ... It's ok to have items in two places, provided we do it in a predictable way. Having app menus that are located in the top bar is fantastic with the new app designs. On average size displays and below, they are superb with a maximised window that has had its titlebar removed. They also mean that everything in the window can be context bound, with the toolbar adjusting to the content that is below. As more of the new apps start coming through, these advantages should start to be readily apparent, and it's encouraging to see new apps like Clocks, Photos and Videos starting to emerge. We can't redesign all our apps all at once. What we can do is concentrate on new core apps now and update existing ones to be consistent where possible. In the future I would hope that we can get all our apps to the stage where they more strongly benefit from new parts of the UX like the app menus. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sharing widgets between GNOME 3 applications
Hey Debarshi, On Mon, 2012-05-07 at 13:45 +, Debarshi Ray wrote: We may benefit from having a way to share these widgets among the applications. Currently, what I have been doing, for gnome-photos, is to copy-paste the *.c/*.h files from the gnome-documents tree. One downside of doing this is that the gnome-photos binary has some dead code which will never be executed. For example the code path that implements the list view for Documents, which is not necessary for Photos. So all the classes implementing it need to be copied over into the gnome-photos tree to avoid maintaining a fork of the GdMainView widget. Currently it is not so much of a practical problem, but I am curious to know if people have better ideas about this. Yeah, I agree we could do better. I don't think another shared library would be the best solution though; maybe a better approach could be splitting these common bits in a separate git module and have projects import it using git submodule [1] (or git subtree? [2]). This way, maintenance of the common bits could still be managed in a single place, and different projects could even depend on different revisions of the shared code if they want (I believe if we use git subtree this could go as far as even maintaining an additional patchset on top of the shared tree). What do you think? [1] http://git-scm.com/book/en/Git-Tools-Submodules [2] http://git-scm.com/book/en/Git-Tools-Subtree-Merging ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sharing widgets between GNOME 3 applications
Hi, On Mon, May 7, 2012 at 3:45 PM, Debarshi Ray rishi...@lostca.se wrote: The newly designed (or redesigned) GNOME 3 applications have some common UI elements. For example, if you look at the following designs, you will notice that the main toolbar, selection toolbar, main icon view, etc. are quite similar: Sorry for being so naive but why couldn't this be part of GTK+? -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sharing widgets between GNOME 3 applications
The newly designed (or redesigned) GNOME 3 applications have some common UI elements. For example, if you look at the following designs, you will notice that the main toolbar, selection toolbar, main icon view, etc. are quite similar: Sorry for being so naive but why couldn't this be part of GTK+? The applications are young, the designs are young, which means they are still evolving. Putting them in GTK+ is risky because of API/ABI guarantees. Happy hacking, Debarshi -- Give a man ssh access, he'll still need a computer. Give him a computer, he'll give ssh access to you. -- Ashish Shukla pgpT4TQPcZFpf.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Mon, May 7, 2012 at 8:15 AM, Andrew Cowie and...@operationaldynamics.com wrote: Is there a reference application doing this right? I ask this because Epiphany¹ has no menu, but does and a funky button over on the right that, upon investigation, turns out to be a menu has useful things like add bookmark ... but not preferences! Which, eventually and quite by accident, I discovered was in the global GMenu thing up top. Oh. The way it was designed is that things related to the application as a whole go in the application menu, things related to the particular window you are in go in the gear thing. I'm not sure about what you mean exactly with Epiphany has no menu in any case. Presumably that's not quite what you're aiming for. Perhaps you can suggest a current GNOME app that *is* doing precisely what it is you want us all to do? The design we have is not exactly like what it's implemented, since there's a few things in the gear menu that should not be there. The fact that there's a global app menu and a window specific menu is implemented as designed, though. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sharing widgets between GNOME 3 applications
The way I see it, is that we need to provide some widgets to do the stuff following the guldelines of the new Gnome Design As Allan says here [1], there's a new kind of toolbar, which have some stuff in common, and it will be worthy to look into the possibility of make a specific widget for it, and the sames goes for those new kinds of iconviews, and for the selection patterns as well. [1](http://afaikblog.wordpress.com/2012/02/10/a-new-approach-to-gnome-application-design/) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Mon, May 7, 2012 at 12:51 PM, Xan Lopez x...@gnome.org wrote: On Mon, May 7, 2012 at 8:15 AM, Andrew Cowie and...@operationaldynamics.com wrote: Is there a reference application doing this right? I ask this because Epiphany¹ has no menu, but does and a funky button over on the right that, upon investigation, turns out to be a menu has useful things like add bookmark ... but not preferences! Which, eventually and quite by accident, I discovered was in the global GMenu thing up top. Oh. The way it was designed is that things related to the application as a whole go in the application menu, things related to the particular window you are in go in the gear thing. I'm not sure about what you mean exactly with Epiphany has no menu in any case. Presumably that's not quite what you're aiming for. Perhaps you can suggest a current GNOME app that *is* doing precisely what it is you want us all to do? The design we have is not exactly like what it's implemented, since there's a few things in the gear menu that should not be there. The fact that there's a global app menu and a window specific menu is implemented as designed, though. I think having two different super menus could be confusing, the distinction between application and window is not something people think about. An example of how this can be a problem is the View as List/Grid menu items in Documents. These exact same options exist in Nautilus, but they would live in the menubar or a super menu instead of the appmenu. Per-window/per-app makes sense from a technical perspective but it's not a natural to users. -- Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Mon, May 7, 2012 at 5:24 PM, Evandro Giovanini efgiovan...@gmail.com wrote: On Mon, May 7, 2012 at 12:51 PM, Xan Lopez x...@gnome.org wrote: On Mon, May 7, 2012 at 8:15 AM, Andrew Cowie and...@operationaldynamics.com wrote: Is there a reference application doing this right? I ask this because Epiphany¹ has no menu, but does and a funky button over on the right that, upon investigation, turns out to be a menu has useful things like add bookmark ... but not preferences! Which, eventually and quite by accident, I discovered was in the global GMenu thing up top. Oh. The way it was designed is that things related to the application as a whole go in the application menu, things related to the particular window you are in go in the gear thing. I'm not sure about what you mean exactly with Epiphany has no menu in any case. Presumably that's not quite what you're aiming for. Perhaps you can suggest a current GNOME app that *is* doing precisely what it is you want us all to do? The design we have is not exactly like what it's implemented, since there's a few things in the gear menu that should not be there. The fact that there's a global app menu and a window specific menu is implemented as designed, though. I think having two different super menus could be confusing, the distinction between application and window is not something people think about. An example of how this can be a problem is the View as List/Grid menu items in Documents. These exact same options exist in Nautilus, but they would live in the menubar or a super menu instead of the appmenu. Per-window/per-app makes sense from a technical perspective but it's not a natural to users. The menu that is currently in the Web toolbar contains a fairly broad array of items, as reflected by the cog (or gear) icon that labels it - it basically means 'do something'. If I understand them correctly, the mockups [1] call for something different - a share menu. This would have a much more focused role and its scope would be clearer. It would also only be shown when displaying web pages rather than the 'pages' view - ie. it is contextual and displayed on-demand (as opposed to the cog menu that is always shown). This distinction between app menus that are global and always available and focused options that are displayed on-demand when context requires it is a key one for the design of the new applications. So in this case, I don't think the distinction between the app menu and any other menus is ambiguous (as designed, at least). Allan [1] https://live.gnome.org/Design/Apps/Web/#Tentative_Design -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
