Design/Meetings/2013-07-20

Topics

 * Editing PPS/PPSX files
 * Gnome AppMenu
 * "Improve Toolbars in LibreOffice" GSoC Project

Tasks
Astron:
 * Comment on the Gnome AppMenu

Mirek2:
 * Start a thread on small icon toolbars

Samuel:
 * Put "Edit Presentation" in a PPS/PPSX slide show's right-click menu

Log
[15:58] Hello all [15:59]  Hi [15:59] hi [16:01] any topic one of you wants to discuss? [16:02] pacraddock: are you still on for the icons? [16:03] do you have a github account so that I can add you? [16:03]  I'd like to discuss the pps/ppsx Autplay issue (I sent a mail to ux-advise yesterday) [16:04] ok, sure [16:07] so, having just looked over it, I would go for solutions 2 and 3 [16:07]  For the others, here's my message: https://lists.freedesktop.org/archives/libreoffice-ux-advise/2013-July/002162.html [16:08]  mirek2: You mean we should implement both? [16:08] that's my impression [16:09] In practice, I see that the "escape to allow edit" is not ideal: [16:09] whenever people are giving a presentation and have a 20-slide presentation but only show 10 slides, [16:09] they don't necessarily want the "edit" mode to appear when stopping their presentation [16:10]  pacraddock: So what would your suggestion be? [16:10] Could there be some form of middle-ground, where you show an option to edit when closing? [16:11] I'm not sure if when closing is the best time to show it [16:11] e.g. a dialog upon "ESC" saying with clause selected by default, but edit as a possibility [16:11] close* [16:12] how about having the option to edit under the right-click menu? [16:13] or perhaps "shift - ESC" for edit, "ESC" for close [16:13] that doesn't solve the discoverability problem [16:14] true, but if it appears in the right-click menu as you suggest, along with a keyboard shortcut shown… [16:15] in that case, it's fine [16:15]  There is an entry in the right-click menu saying "Exit Presentation". Now what do you expect this entry to do? [16:15] I would say "close" [16:16]  close what? the presentation or also the editing window? [16:16] "Exit presentation mode" would close the presentation, but "Exit presentation" will be understood as "close the whole window" [16:16] How about "Edit presentation"? [16:17] Yup [16:17]  The problem is that the "Exit presentation" entry has two different actions: In a normal presentation, it closes only the presentation screen, in an autoplay presentation it closes the whole program [16:17]  I don't like that [16:18] == astron247 [~frootzowr@dslb-094-222-164-109.pools.arcor-ip.net] has joined #libreoffice-design [16:18]  Ok, it's actually named "End Show" in the english version [16:19] samuel_m: think of the slide show as separate from the editor [16:19] "End show" simply closes the slide show [16:19] if the editor is open in the background, it will stay there [16:20] in this case, the editor isn't open in the background [16:20]  Hi astron247, here's the log up to now: http://pastie.org/8158924 [16:20]  mirek2: ok, that makes sense [16:21] alright [16:21] == astron247 [~frootzowr@dslb-094-222-164-109.pools.arcor-ip.net] has quit [Remote host closed the connection] [16:21] so we've agreed on the right-click menu solution? [16:21] == astron247 [~frootzowr@dslb-094-222-164-109.pools.arcor-ip.net] has joined #libreoffice-design [16:21]  named "Edit Presentation"? [16:22] yup [16:22] I think that would make it very clear [16:22]  Ok, then I'll change the patch accordingly. [16:23] Thanks! [16:23] == astron247 [~frootzowr@dslb-094-222-164-109.pools.arcor-ip.net] has quit [Remote host closed the connection] [16:23] sounds good [16:23] :) [16:23] == astron247 [~frootzowr@dslb-094-222-164-109.pools.arcor-ip.net] has joined #libreoffice-design [16:25] pacraddock: my questions above still stand :) [16:25] Heh, my answers too ;-) My username on GitHub is pacraddock [16:26] samuel_m: btw, if you have extra time, it would probably be good to implement solution 3 as well [16:26] right-click commands aren't that discoverable, tbh [16:27] pacraddock: thanks, I'll add you [16:28]  mirek2: I have no idea how to distinguish whether the user used the File->Open menu or clicked the file in the file manager [16:28] oh, ok [16:28]  I could create a bug report for that, but I don't find that more intuitive than the right-click menu. I would not try that. [16:29] samuel_m: alright [16:31] any other topics to discuss? [16:32] hi & what have you discussed so far? [16:33] http://piratepad.net/lqKy6GtNGF [16:33] ah, thanks [16:34] just this bug: https://bugs.freedesktop.org/show_bug.cgi?id=45233 [16:34] well, i commented on gerrit [16:35] on samuel's first patch [16:36] where exactly? [16:36] https://gerrit.libreoffice.org/#/c/4827/ ? [16:36] https://gerrit.libreoffice.org/#/c/4921/ [16:38] so, for one, i like the idea of checking if the presentation was started from the Open menu item or from a file manager. [16:38] astron247: :) funny that we both came to the same conclusions [16:39] i dont like the idea of pressing Esc to reach the editor, because it makes the programmes workings look rather intransparent to me. [16:41] (also, samuel_m, mirek2, sorry for not answering before – i was already disconnected when you posted the log/said hi) [16:41] that's ok [16:42] anyway, I think we can move to a different topic now, with the agreement being to have "Edit Presentation" in the right-click menu [16:42] topic suggestions? [16:42] by any chance, did you notice: https://bugs.freedesktop.org/show_bug.cgi?id=48835 [16:42] ? [16:43] haven't noticed [16:43] cool [16:44] I hope more apps adhere to the new Gnome HIG [16:44] proposals what else should be in there? [16:44] let's see... [16:44] Templates, wizards, recent documents... [16:45] all that? [16:45] Open, Options, Customize, ... [16:46] == pacraddock [51a48642@gateway/web/freenode/ip.81.164.134.66] has left #libreoffice-design [] [16:46] all the stuff from the Help menu [16:46] and we should get rid of the Window menu as well [16:47] wait are you just proposing to remove the traditional menu? [16:47] no [16:47] I mean the menu labeled "Window" [16:48] then, what do you mean by getting rid of it? [16:49] we could move the "New Window" command to the file menu and get rid of the menu [16:49] it's just an alternative way to manage windows [16:50] but it's not a very good one and that task should be up to the OS [16:50] mirek, are you still speaking about the bug i posted? [16:51] it's borderline relevant [16:51] the Window menu contains mostly commands related to the app as a whole [16:51] i think you lost me some time ago [16:51] :) [16:51] ok [16:51] but right, i mostly see where your disdain for the window menu is coming from [16:52] rather than move the window switching commands to the App menu, where they theoretically belong, I'd just get rid of them [16:53] and on all platforms, seeing as it's the OS's job to switch between windows [16:53] well, for now, i would rather _duplicate_ menu items in the gmenu, not move them there [16:53] – because this thing has a discoverability of ~0 [16:54] that kind of defeats the purpose of the menu, though [16:54] maybe [16:55] yes, the menu is not widely used, but that's because, for most apps, it just contains the Quit command [16:55] its also because it is: [16:55] * very far away from the window [16:55] * too simplistic for most applications [16:56] it doesn't have to be far from the window [16:56] and how is it too simplistic? [16:56] I think it offers more widgets than standard menus [16:57] far away – it is perfect for card-style windows (as on mobile os's) [16:57] simplistic – its just a single menu, too little for an application like libo (or even nautilus) [16:59] astron247: you're right that it works better in e.g. WebOS and that it can be harder to reach on bigger monitors, but hey, it's Gnome's choice to make, not ours [16:59] as for being too little, I disagree [17:00] the commands it contains have traditionally shared space with tons of window-related commands in the File menu [17:00] I guess in most apps, there weren't enough to warrant their own menu [17:01] as for Nautilus, I'm quite happy with the meno [17:01] -o +u [17:01] note that nautilus still has three menus :) [17:02] astron247: you realize that the application menu is not supposed to replace the menu bar? [17:03] you will agree that having both is very confusing? [17:03] but that it's just supposed to host the window-insensitive commands [17:04] astron247: given that no other application with menus uses the App menu, yes [17:04] but we have to start somewhere, no? [17:04] thats very much incorrect [17:04] what is? [17:04] gnome terminal, empathy, gedit, totem, and more [17:05] I only get the "Quit" command in Terminal... [17:05] same with Totem [17:05] you probably still have gnome 3.6 (at least in parts) [17:06] Empathy I don't use [17:06] forgot that gedit used it [17:06] astron247: yeah, I'm using the 3.8 PPA in Ubuntu Gnome [17:06] I may switch to Fedora in the future [17:07] or opensuse :) [17:07] (although you have to use the equivalent of a ppa to get 3.8 right now, too) [17:07] :) [17:08] well, honestly, I'd leave the decision up to the Gnome folks [17:08] it might be a good idea to duplicate the items for a release, but we'll have to drop them at some point [17:09] on the other hand, moving them might finally get people and devs to use the menu... [17:09] but what for?# [17:11] for what reason do we want to move them? how does it benefit us? is that what you're asking? [17:11] yes – how does it benefit anyone if we irritate people this way [17:11] ? [17:11] well, for one thing, we'd have more browseable menus [17:12] also, I wouldn't say it should irritate people [17:12] Nautilus uses it, they're fine with that [17:12] gedit uses it [17:13] on the contrary -- they should be happy that applications are finally starting to follow the HIG [17:13] most people dont read higs :) [17:13] (and if they loathe the menu, perhaps there'll be a Gnome extension for them?) [17:14] astron247: ok, I should've said that more apps are fitting into the platform, following its norms [17:14] I, for one, hate only finding the Quit command in the app menu [17:15] and I'm looking forward to when Firefox and Inkscape support it [17:15] and I'm looking forward to the cleaner window menus [17:16] in any case, I would say this thing really is for the Gnome folks to decide [17:16] anyway. i guess we got off the topic which menu entries should be in the gmenu [17:19] i would add the extension manager, and the various sub-types of new documents [17:19] Extension Manager, XML Filter Options, AutoCorrect Options, possibly Printer Options (not sure if it apples only to the window), and all the other stuff I said above [17:20] well, customise is a per window command [17:21] astron247: I guess you're right, though the changes can apply for the whole app [17:22] == samuel_m [~samuel@dslb-094-219-111-025.pools.arcor-ip.net] has quit [Quit: samuel_m] [17:22] honestly, I'd be happier if it was a per-app setting [17:22] well, it applies only for one component [17:22] hm... given that the application is presented as Writer, not as LibreOffice, perhaps New should only start a new document [17:23] astron247: Writer is presented as the app (the menu is labeled LibreOffice Writer), so that's not a problem [17:23] ugh. thats really ugly [17:24] im not particularly sure were exporting different menus for different component [17:24] s [17:24] well, we should... [17:25] I know it doesn't reflect the way LibreOffice works, but I prefer the workflow of separate apps [17:25] about Customize: I thought you were alluding to the fact that the changes can be saved within the document [17:26] thats true too [17:26] however, now that I look at it, it lists all the open documents, so it is window-insensitive [17:26] what lists what? [17:27] The Customize dialog has a "Save in" dropdown that lists LibreOffice Writer and all the open documents [17:28] (I mistakenly thought that it only offered "LibreOffice Writer" and "Current Document", which would make it window-sensitive) [17:29] so... [17:30] though it would be interesting to open customise when youre in a wizard, i guess [17:30] we need to ask how the menu is implemented, to make sure that each component has its own menu [17:31] I haven't used any wizard other than the annoying one Impress opens with, but aren't those wizards tied to a specific component? [17:32] usually – yes. but it may stil lgive the impression that you could customise the wizard [17:33] the other thing is, that customise usually opens with the configruation for a particular window, so [17:34] I'm looking at the default wizards and it seems that they're modal dialogs tied to the main window [17:35] astron247: but Customize changes the configuration for all open windows at once [17:35] not just for the current and future windows [17:35] in any case, it's probably futile that us two argue over this [17:36] right [17:36] ill add a comment with our proposals then, i guess..? [17:37] how about opening up a thread on the ux list, listing all the commands we've thought of, tagging Allan Day in the thread and asking what he thinks [17:38] and tagging Caolán to see if there's just one App menu or if there is an App menu for each component [17:38] (and if it's the former, asking whether it could be the ladder) [17:39] ^ladder^latter :) [17:39] yes, that's what I meant :) [17:40] also, asking whether the commands should be moved or duplicated [17:40] it seems that app-related toolbar items would stay, though [17:41] (I see gedit still has "New" in its toolbar) [17:41] http://cgit.freedesktop.org/libreoffice/core/commit/?id=b163772e77e64261b62a9e8196799a499e4ef77d – clearly libo-wide, there is just one menu, i think [17:41] oh, nevermind, gedit's "New" means New tax [17:41] tab, not tax [17:42] in gedit: new tab = new document [17:42] or not? [17:43] yes, but it's a tab inside the window [17:44] so it matters what window you carry the command out in [17:44] New window, on the other hand, is window-insensitive [17:44] right [17:45] ok, then let's ask Caolán if LibO could have one app menu per component [17:45] ok [17:46] feel free to make the comment [17:47] (I don't think my mailing list idea would be better) [17:48] right – we could also move this to the ux-advise component [17:49] that might be best [17:49] ok. i will leave now, i guess... [17:50] alright [17:50] see you next week [17:50] there wasn't a chat last week, I assume? [17:50] and no important news from the ESC call? [17:50] i dont think so – issa and i were both there, for a short time though [17:51] i wasnt on this weeks call, nut i think not [17:51] ok [17:51] ^nut^but [17:51] thanks for the info [17:51] == elixir__ [~elixir@14.139.122.114] has quit [Read error: Connection reset by peer] [17:51] I'll upload the log [17:51] ok. thnaks [17:51] == elixir__ [~elixir@14.139.122.114] has joined #libreoffice-design [17:51] & bye then, have a good weekend [17:52] bye [17:52] elixir__: anything you'd like to discuss [17:52] ? [17:52] == astron247 [~frootzowr@dslb-094-222-164-109.pools.arcor-ip.net] has left #libreoffice-design [] [17:56] <elixir__> mirek2: Hi, I had a talk with kendy and he told me that he had a chat with you. We are likely to start with our next task: individual setting of visibility of text descriptions of toolbar buttons. [17:56] == elixir__ has changed nick to elixir [17:56] great! [17:57] anything you want to ask? [17:58] or simply discuss? [17:58] Actually he could tell me the physical description as to what is to be implemented. Its a per icon per toolbar setting i think? [17:58] But due to lack of time, he couldn't tell me the technical part of it [17:58] you'll need to ask Kendy about the technical part [17:59] I am still waiting for him to guide me some technical aspects, coding part [17:59] I can't help you there [17:59] Yes, waiting for the same :-) [18:00] are there any design aspects you'd like to ask about? [18:01] == astron247 [~frootzowr@dslb-094-222-164-109.pools.arcor-ip.net] has joined #libreoffice-design [18:01] == astron247 [~frootzowr@dslb-094-222-164-109.pools.arcor-ip.net] has left #libreoffice-design [] [18:01] Rest, just to update you, 10 panels are converted to .ui format from .src/.hrc! OK, so are we going to make some variation in icon size too with this task? [18:02] Or, icon size remaining same, only make it per-toolbar-setting? [18:03] One additional query, is the task priority of te small/large icons one is much less that we'd not be picking it up in this gsoc or will we continue it afterwards (after this task) ? [18:03] elixir: the icon size task is one that still has to be discussed [18:04] Okay. [18:04] I myself would imagine something like http://spiceofdesign.deviantart.com/art/Writer-Concept-351501580 [18:05] where the toolbar height is the same, but the icons are small, appear inside buttons, and are grouped [18:06] MS Office offers a similar button style: http://img.afreecodec.com/top/screenshot/50497dba3984a.jpeg [18:06] iWork does, too: http://maymay.net/blog/wp-content/uploads/2008/09/example-burn-down-chart-in-numbers.png [18:07] Yes, I really liked these designs, you've already sent them to me in e-mail, and I had a chat with kendy too regarding this. He told me that he'll discuss it with the design about which design would be best to be selected for implementation [18:07] I would say there are definitely things with higher priority, though [18:07] s/design/design-team [18:08] Yes, I understand [18:08] but I'll start a thread on the Design mailing list about it [18:08] Sure. [18:08] Apart from it, what would be the next hit task on your priority list? [18:09] [apart from the current one- that I am going to start with] [18:09] I talked to Kendy about this [18:09] I think I said overflow menus [18:09] As in? [18:09] the menus that show hidden items in a toolbar [18:10] the idea would be to show a menu at the end of each toolbar if it has any hidden items [18:10] and a "Customize..." entry at the bottom of the menu [18:11] Section 1.2 here - http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/elixir3192/1 ? [18:11] Do i understand the implementation correctly or is there anything else to be done? [18:12] exactly right [18:12] Okay! [18:12] a nice addition would be the ability to change the icon [18:12] through the Customize dialog [18:12] Means change the icon of the button added? [18:13] change the icon that the menu has [18:13] The eye-shaped icon that I added? Ofcourse it is adjustable :) [18:13] Ok. [18:13] the idea being that this menu could serve as the window menu, like Chrome has [18:14] Okay! [18:14] (the gear menu at the right of thee toolbar) [18:14] the icon setting should be per-toolbar [18:14] I read you mentioned this thing in some archive mail, I've researched about what you need to implement there and then mentioned it in the proposal [18:15] Yes, sure [18:15] great :) [18:15] Thanks :-) [18:16] thank you :) [18:16] I'm glad we'll finally have some UI improvements in LibreOffice [18:16] I hope and wish Kendy could guide me soon so that I can start asap and finish as more work as I can :) [18:16] Me too ;-) [18:17] :) I'm glad you're motivated [18:17] I am getting started with my colleges here in India from 22nd July [18:17] Thanks a lot :-) [18:17] But hope this would not be a barrier.. [18:17] let's hope not [18:18] best of luck to you [18:18] Thanks, have a great weekend ahead :-) [18:18] you too :) [18:18] I'll write to you in case of any discrepancy :) [18:18] Bye, Good Night :) [18:18] sounds good :) [18:19] bye