From The Document Foundation Wiki




    • Comment on the Gnome AppMenu


    • Start a thread on small icon toolbars


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


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