From The Document Foundation Wiki


    • alexanderW
    • astron
    • hiok
    • medieval
    • mirek2
    • stevebell
    • thibaut


    • EasyHack suggestions


    [15:56] <mirek2> hi everyone
    [15:57] <stevebell> hey mirek2
    [15:58] == thibaut [] has joined #libreoffice-design
    [16:00] <medieval> hi
    [16:01] <thibaut> hi
    [16:01] <@hiok> Hi guys.
    [16:02] <mirek2> hello
    [16:02] <mirek2> let's wait a few minutes, then we'll start
    [16:03] <@hiok> Alright.
    [16:04] <@hiok> First time participating. By the way, thanks for the hard work you've been putting on lately, mirek.
    [16:04] <mirek2> :) thanks for coming
    [16:04] <thibaut> me too
    [16:05] <mirek2> btw, while we're waiting, any ideas on improving the design experience?
    [16:05] <@hiok> mirek2, you think I should change nickname? I often use hiok, but in the lists i'm daud.
    [16:06] <medieval>
    [16:06] <mirek2> hiok: it's up to you
    [16:06] <medieval> i have gathered something
    [16:06] <medieval> mine name is confusing to: medieval vs hillar
    [16:06] <@hiok> OK, let's keep it that way.
    [16:06] <thibaut> I think the UI lines should be cleand-up:
    [16:07] <mirek2> alright, let's start :)
    [16:07] <mirek2> let's start with Medieval's proposal
    [16:07] <medieval> new icon theme is under way
    [16:07] <mirek2> yup
    [16:08] <mirek2> and it'd be good if anyone could help
    [16:08] <mirek2> as basically only one person is working on it and in his free time
    [16:08] <medieval> Close button for Styles and Formatting
    [16:08] == alexanderW [] has joined #libreoffice-design
    [16:08] <mirek2> hi alex
    [16:08] <alexanderW> Hi
    [16:08] <mirek2> medieval: before we get into that,  I'd like to address "Improving look of tabs in Impress" first
    [16:08] <medieval> ok
    [16:08] <mirek2> it's somewhat similar to a problem we had with the templates dialog
    [16:09] <medieval> to me these look quite ugly now
    [16:09] <mirek2> I understand, and I agree
    [16:09] <mirek2> however, we've had the same problem with the templates dialog
    [16:10] <alexanderW> No gtk style hints
    [16:10] <mirek2> where the original design asked for a split button navigation
    [16:10] <@hiok> you mean not the Organize dialog, but the other one?
    [16:10] <mirek2> the new 4.0 templates dialog
    [16:10] <@hiok> Ah, sorry.
    [16:11] <mirek2> the problem was that it would be hard to implement a way to do this kind of split button natively
    [16:11] <medieval> ok
    [16:11] <mirek2> and since tabs cannot be non-native, we had to settle for the standard tab widget
    [16:11] <mirek2> however, what would be possible is moving tabs to the bottom
    [16:11] <medieval> why not but these to status bar?
    [16:12] <mirek2> the status bar is already pretty crowded
    [16:12] <mirek2> however, what seems like Apache OpenOffice will be doing is put them on the bottom
    [16:12] <mirek2> like Lotus Symphony did
    [16:12] <mirek2> and we'll be able to take that code and integrate it
    [16:13] <mirek2> (though, as the donation of Symphony is available for use only to Apache, we can't integrate it yet)
    [16:13] <@hiok> do you have a picture of that?
    [16:13] <medieval>
    [16:13] <medieval> this?
    [16:14] <mirek2> it will be more native-looking, I promise
    [16:14] <medieval> yes
    [16:15] <@hiok> looks nice to me.
    [16:15] <medieval> but idea is same
    [16:15] <medieval> is it possible to integrate slide show icon to there too?
    [16:15] <medieval> as in lotus symphony
    [16:15] <alexanderW> shouldn't be too hard
    [16:16] <mirek2> right
    [16:16] <mirek2> so, in this case, let's wait for the AOO implementation and build on that
    [16:17] <mirek2> next topic
    [16:17] <mirek2> Close button for Styles and Formatting
    [16:17] <alexanderW> might make it overcrowded
    [16:17] <medieval> if we remove it from toolbar then it is needed
    [16:17] <alexanderW> There are already 7 buttons in the top row
    [16:18] <mirek2> I don't think it's crowded
    [16:18] <@hiok> it's too overcrowded indeed.
    [16:18] == astron247 [] has joined #libreoffice-design
    [16:18] <alexanderW> Hi Astron
    [16:18] <mirek2> hi astron
    [16:18] <astron247> hi alex, all
    [16:18] <medieval> to me it is now very hard to use without close button (i have removed icon from toolbar)
    [16:18] <medieval> hi
    [16:19] <mirek2>
    [16:19] <@hiok> there's shortcuts. Crtl+t and F11.
    [16:19] <mirek2> they're not discoverable
    [16:19] <mirek2> I would argue that:
    [16:20] <@hiok> true. still, i have an idea.
    [16:20] <medieval> yes, i can use them, but other people?
    [16:20] <mirek2> * the current sidebar is not overcrowded (there's ample room; compare with Styles sidebar)
    [16:20] <thibaut> hi astron
    [16:21] <astron247> mirek2: thanks
    [16:21] <@hiok> if the buttons for style type (paragraph, character, page etc., don't how's it called) were tabs instead of buttons, then one more button wouldn't feel overcrowding.
    [16:21] <medieval> but right click function to close ?
    [16:21] <mirek2> * a close button makes sense in terms of ux-discoverability and ux-natural-mapping
    [16:22] <mirek2> a right click function isn't really discoverable
    [16:22] <@hiok> agreed
    [16:23] <medieval> most dockable windows have close buttons (in impress)
    [16:23] <@hiok> besides right click should be avoided, cause it's time-expensive.
    [16:23] <mirek2> btw, the principles I'm talking about are from
    [16:23] <mirek2> ok, then let's agree to make this into an easy hack
    [16:23] <mirek2> everyone agrees?
    [16:24] <@hiok> still not sure, sorry.
    [16:24] == stevebell [~paul@] has quit [Quit: Colloquy for iPad -]
    [16:24] <@hiok> still feels overcrowded to me
    [16:25] <mirek2> the button would be small and could be light
    [16:25] <mirek2> could someone produce a mockup?
    [16:26] <@hiok> well, i would like to try some.
    [16:26] <astron247> mirek, not sure about the close button thing yet, either.
    [16:26] <@hiok> perhaps rearrange one or two things.
    [16:26] <medieval> look the buttons from impress
    [16:27] <@hiok> ok, in impress there's lots of room, but not in writer.
    [16:27] <medieval> adding headers?
    [16:27] <medieval> doesnt take too much space
    [16:28] <@hiok> could be fine
    [16:28] <@hiok> then the buttons for style type could go also in the header, in the form of tabs.
    [16:28] <mirek2> to anyone interested, make some mockups
    [16:28] <mirek2> I'll try to make a quick one as well
    [16:28] <astron247> ok.
    [16:28] <@hiok> ok
    [16:29] <mirek2> meanwhile, let's move on
    [16:29] <mirek2> "Styles preview"
    [16:29] <medieval> there is bug
    [16:29] <astron247> maybe one possibility to reduce ui clutter in the styles tool bar first would be to combine the five leftmost buttons into a combo box
    [16:29] <medieval> it don't show font effects
    [16:29] <astron247> (a la evince sidebar)
    [16:29] <mirek2> I think both suggestions are the next logical step
    [16:30] <mirek2> astron247: I would be against that
    [16:30] <astron247> why that?
    [16:30] <mirek2> I know that when I use styles extensively enough to need a sidebar, I need to switch between character and paragraph styles quite often
    [16:30] <astron247> because iwe then have comboboxes at the top and the bottom?
    [16:30] <mirek2> that would be horrible with a combo box
    [16:31] <mirek2> astron247: sorry, I didn't understand that
    [16:31] <astron247> another option would be to have collaipsible areas for eaach sort of style in the main area
    [16:32] <astron247> ^collaipsible^collapsible
    [16:32] <astron247> ^eaach^each
    [16:32] <mirek2> given that these are easy hacks, let's stick to easy fixes, not grand redesigns
    [16:32] <mirek2> though, of course you're free to make a mockup
    [16:32] <astron247> well, fine
    [16:32] <mirek2> but let's leave bigger redesigns for later discussion
    [16:32] <@hiok> ok.
    [16:32] <astron247> then you will indeed have to add a header to the sidebar
    [16:33] <mirek2> I think a small close icon would work fine
    [16:33] <mirek2> I'll post a mockup
    [16:33] <astron247> ok
    [16:33] <mirek2> anyway, back to medieval's style suggestions for now
    [16:33] <mirek2> back to the sidebar later
    [16:33] <mirek2>
    [16:34] <mirek2> I think both ideas under Styles preview are the natural progressions of the new style preview feature, so I would definitely turn them into easyhacks
    [16:34] <mirek2> agreed?
    [16:34] <@hiok> medieval's preview is for the dropdown in toolbar, right?
    [16:34] <medieval> both
    [16:34] <medieval> to it too
    [16:35] <@hiok> ok, so toolbar and sidebar.
    [16:35] <medieval> yes
    [16:35] <astron247> do we have bugs for these two already?
    [16:35] <medieval> no
    [16:35] <@hiok> you don't have a mockup, have you?
    [16:35] <medieval> for what?
    [16:36] <@hiok> for the preview
    [16:36] <mirek2> we already have an implementation
    [16:36] <mirek2>
    [16:36] <@hiok> mirek2: thanks. sorry, i wasn't able to see 4.0 yet.
    [16:37] <astron247> hm, the second bug does warrant a mockup still, because there is a hierarchic view in the styles dock
    [16:37] <astron247> so wed need to look how we can make the previews look good next to plus/minus signs
    [16:38] <medieval>
    [16:38] <mirek2> I'd vote against that
    [16:38] <medieval> it's quite overkill
    [16:38] <@hiok> :-) that's my mockup.
    [16:38] <mirek2> it's too complex
    [16:38] <astron247> or alternatively, decide it is better to only change the applied styles panel
    [16:39] <astron247> agree, its quite complex and disorganised (badly needs some sort of grid)
    [16:39] <mirek2> you're right -- this second idea requires further thought
    [16:39] <mirek2> so let's leave it for later discussion
    [16:39] <@hiok> ok.
    [16:39] <astron247> still, what do you think of only changing "applied styles"?
    [16:40] <mirek2> is there no hierarchy there?
    [16:40] <astron247> no
    [16:40] <astron247> and it only shows a small number of styles generally which lends itself well to a graphic presentation of them
    [16:40] <mirek2> hm... sounds good as a first step
    [16:41] <mirek2> though it'd be good to extend previews to the whole panel for consistency
    [16:41] <@hiok> what if the preview wasn't inline, but in ta separate box in the sidebar? too complex still?
    [16:41] <@hiok> ^ta^a
    [16:41] <astron247> it means you have to click before you see the styles... unless you do hover effects
    [16:42] <mirek2> exactly
    [16:42] <astron247> ... which we have some bad experiences with
    [16:42] <thibaut> wouldn't that be inconsistent?
    [16:42] <mirek2> yes, that too
    [16:42] <@hiok> but you could see the style in context, which is very good for paragraph style
    [16:42] <mirek2> anyway, let's leave this discussion for later
    [16:43] <medieval> borders mess next?
    [16:43] <mirek2> and move to "UI: Borders are not drawn correctly"
    [16:43] <mirek2> yes
    [16:43] <@hiok> ok. I'll review that proposal and try to simplify and break it in smaller pieces.
    [16:43] <mirek2>
    [16:43] <alexanderW> Is it even fesible to draw all borders correctly with VCL?
    [16:44] <alexanderW> *feasible
    [16:44] <mirek2> it should be
    [16:44] <astron247> it was possible before kendy made the changes
    [16:44] <astron247> (i believe)
    [16:44] <mirek2> really? I thought the only changes Kendy made was remove the 3D border from the document area
    [16:45] <mirek2> which happened to result in a loss of visible border for some elemetns
    [16:45] <mirek2> elements
    [16:45] <astron247> yes, and that broke lots of things, because it wasnt done entirely consistently
    [16:45] <alexanderW> Ah, I though the bug report also covered the various borders/handles
    [16:45] <astron247> btw, similar bug report:
    [16:45] <mirek2> astron247: right, but these things are fixable
    [16:46] <mirek2> so I'd vote to make it an easyhack
    [16:46] <mirek2> agreed?
    [16:46] <astron247> mirek2: i never said they weren't. i am just saying that work wasnt really completed there
    [16:46] <mirek2> yes -- that's why the easyhack
    [16:46] <astron247> mirek2: how do you want to amke it an easy hack? you dont develop
    [16:47] <astron247> you can only add it to suggested easy hacks ...
    [16:47] <mirek2> yes
    [16:47] <astron247> ... and, actually, everyone can do that on their own.
    [16:47] <mirek2> I was thinking we could either go through the ESC call or through Kendy
    [16:47] <astron247> ok
    [16:47] <astron247> to find suitable mentors?
    [16:48] <mirek2> just to turn them into easyhacks
    [16:48] <mirek2> and perhaps promote them a bit
    [16:48] <astron247> easy hacks need mentors
    [16:48] <astron247> thats whats so good about them
    [16:48] <mirek2> right
    [16:49] <mirek2> basically, the point of this is to produce a set of design team-approved UX-related easy hacks
    [16:49] <astron247> ok...
    [16:49] <mirek2> so that the UX side of things can finall get rolling
    [16:49] <mirek2> and, yes, the ESC call would be a good place to find mentors
    [16:50] <mirek2> so... everyone agree with drawing borders correctly?
    [16:50] <astron247> why would anyone not like that?
    [16:51] <mirek2> I would be surprised as well, but perhaps there are reasons
    [16:51] <astron247> ok, lazy consensus, next →
    [16:51] <mirek2>
    [16:52] <mirek2> let's start with extension manager, as it's a simpler proposal
    [16:52] <mirek2> label wording
    [16:52] <mirek2> (under "Labels should be more descriptive")
    [16:53] <mirek2> would everyone agree with that?
    [16:53] <alexanderW> Agree with the suggestions
    [16:53] <astron247> dont agree with the word "filter"
    [16:53] <astron247> that sounds like technobabble to most people
    [16:53] <astron247> (i think)
    [16:54] <mirek2> really? I thought that word was quite common
    [16:54] <astron247> also, i dont know... do we even need the label?
    [16:54] <mirek2> what would you use instead?
    [16:54] <mirek2> how about "Show:"?
    [16:54] <mirek2> or "Display:"
    [16:54] <astron247> nothing, just more descriptive tick boxes
    [16:55] <astron247> but show would be fine with me also
    [16:56] <mirek2> what do others think?
    [16:56] <medieval> working for me
    [16:56] <medieval> display is better
    [16:56] <medieval> i think
    [16:56] <mirek2> ok
    [16:57] <@hiok> display is also a substantive. show sounds more direct.
    [16:57] <astron247> also, maybe the whole ticks at the bottom of the window thing is not so great.
    [16:57] <astron247> how about a little menu button like in the template manager?
    [16:57] <mirek2> where?
    [16:57] <mirek2> add a toolbar just for one button?
    [16:58] <medieval> no
    [16:58] <astron247> either next to Add... or somewhere at the top of the window
    [16:58] <@hiok> and it wouldn't be cumulative, but alternative to what's to show.
    [16:58] <medieval> i will work with ticks
    [16:59] <mirek2> astron247: would you like to create a proposal in Glade?
    [16:59] <astron247> ok
    [16:59] <mirek2> alright
    [16:59] <mirek2> what team should we talk to about the rewording?
    [16:59] <astron247> but im not sure, this dialogue will be ported to gbuilder soon
    [16:59] <astron247> (since the list view is quite complicated)
    [17:00] <mirek2> ok
    [17:00] <thibaut> I'll have to go, sorry
    [17:00] <thibaut> bye
    [17:00] <astron247> bye :/
    [17:00] <mirek2> alright, see you later
    [17:00] <alexanderW> cu
    [17:01] <mirek2> astron247: the perhaps let's talk to the developer working on it?
    [17:01] <@hiok> see ya
    [17:01] <mirek2> astron247: do you know who it is?
    [17:01] <astron247> mirek2: working on what?
    [17:01] <mirek2> on porting the dialog
    [17:01] <astron247> is it being ported already?
    [17:02] <astron247> if not, the developer is rather unclear.
    [17:02] <mirek2> oh, I assumed that there was
    [17:02] <alexanderW> The rewording coul
    [17:02] <astron247> but caolan did most of the work to interpret .ui files, if that helps
    [17:02] <mirek2> hm, ok
    [17:03] <alexanderW> *ld be done without talking to any dev, right?
    [17:03] <astron247> mirek2: i think they are going for low hanging fruit first
    [17:03] <mirek2> anyway, we all agree on the labels proposed except instead of filtering we'll use displaing
    [17:03] <mirek2> right?
    [17:03] <alexanderW> Yes
    [17:04] <mirek2> and aligning the checkboxes to the left
    [17:04] <mirek2> ?
    [17:04] <astron247> no
    [17:04] <mirek2> ok
    [17:04] <medieval> and cjanging other labels=
    [17:04] <medieval> ?
    [17:04] <@hiok> yes, more descriptive ones.
    [17:04] <mirek2> medieval: which other labels?
    [17:04] == thibaut [] has quit [Ping timeout: 252 seconds]
    [17:05] <astron247> tick boxes on the left would fill a third of the dialogue = no
    [17:05] <mirek2> ok
    [17:05] <medieval> "Installation" could be "Bundled with LibreOffice" "Shared" could be "Available for all users" "User" could be "Available only for current user"
    [17:05] <mirek2> yes, I think we all agree on those
    [17:05] <medieval> ok
    [17:06] <mirek2> and what about ""Get more Extensions online" should be a bit more highlighted, maybe it can be a button. It should also get some space below."?
    [17:06] <@hiok> adding the word "extension" to each would facilitate recognition of the filtering
    [17:06] <mirek2> I think that would require further design
    [17:06] <mirek2> so I would say not now
    [17:06] <@hiok> it should definitly be a button
    [17:07] <mirek2> hiok: adding "extension" would make the labels a lot longer, though
    [17:07] <mirek2> I'd prefer to just change the category label to "Display extensions:"
    [17:07] <@hiok> yes, so then all of them could be aligned left
    [17:08] <@hiok> ok, that sounds better.
    [17:08] <astron247> doesnt make sense to me
    [17:08] <astron247> "display these extensions" makes more sense but is clumsy
    [17:08] <@hiok> what aboute 'show'?
    [17:08] <astron247> much better than display :)
    [17:08] <mirek2> I think we agreed display was better
    [17:09] <@hiok> "show extensions:"
    [17:09] <@hiok> we didn't. i opposed
    [17:09] <mirek2> oh, ok
    [17:09] <@hiok> display is also a substantive, show is more immediate
    [17:09] <mirek2> so everyone alright with using "show" for the word
    [17:09] <mirek2> show is a substantive as well
    [17:10] <medieval> i am not againt it
    [17:10] <astron247> hiok: display is a verb as well. and show is a noun, too
    [17:10] <@hiok> of course, in portuguese the translations will be terrible, but that's another thing hahaha
    [17:10] <mirek2> astron247: I think "display extensions related to the user" makes more sense then "display these extensions related to the user"
    [17:10] <mirek2> just like there's a "View" menu, not a "View these" menu
    [17:10] <astron247> nah, you re reading it as a sentence.
    [17:10] <@hiok> astron247: but show is not a substantive in computer context
    [17:10] <astron247> you shouldnt, i think
    [17:11] <mirek2> astron247: if there's a colon, I believe you should
    [17:12] <@hiok> if there's a verb, it's a sentence, no matter what
    [17:13] <mirek2> would you be ok with "Show extensions:", then, astron?
    [17:14] <astron247> hiok: right. i didnt mean that, though. what i meant was that mirek tried to read the group label and the tick box labels together
    [17:14] <@hiok> astron247: oh, i see.
    [17:14] <mirek2> the colon is what makes the difference
    [17:14] <astron247> mirek2: "show" still makes more sense to me, as users hopefully know they are in the extensions dialogue
    [17:14] <mirek2> as a colon is often used to introduce a list that completes a sentence
    [17:15] <astron247> mirek2: not in german...
    [17:15] <mirek2> astron247: yeah, but "Show related to the user" doesn't make as much sense
    [17:15] <astron247> not in english, as far as i can see either.
    [17:15] <@hiok> then "show extensions: " with the tick boxes with the more descriptive labels. Sounds good?
    [17:15] <medieval> yes
    [17:15] <astron247>  ... what ever
    [17:15] <astron247> bikeshedding, i guess
    [17:16] <@hiok> ok.
    [17:17] <mirek2> hm, I guess I've been using colons the wrong way
    [17:17] <@hiok> i should be in the portuguese translation team, because i like those details
    [17:17] <mirek2> you're right, astron, according to the grammar rules, "Show these extensions:" is correct
    [17:17] <mirek2> so everyone agree with that?
    [17:18] <@hiok> that's ok for me. let's not argue over that no more.
    [17:18] <mirek2> ok, great
    [17:18] <mirek2> now let's go to the other proposal: "Impress: Custom Animation Pane"
    [17:18] <@hiok> The labels are also agreed upon, right?
    [17:18] <medieval>
    [17:18] <mirek2> yes
    [17:19] <mirek2> Make „Add“, „Change“ and „Remove“ Image Buttons, so that they fit in one row, put the "Up" and "Down" buttons next to them
    [17:19] <mirek2> everyone agree with that?
    [17:19] <astron247> yes.
    [17:19] <astron247> wholeheartedly
    [17:20] <astron247> the one thing i would question is if these buttons shouldnt be under the list view though
    [17:21] <astron247> and the other is if we need the preview button down there – we could just have a little "play" image button
    [17:21] <mirek2> let's go by the points one by one
    [17:22] <mirek2> we all agree with having a toolbar for „Add“, „Change“, „Remove“, "Up", and "Down", right?
    [17:22] <medieval> yes
    [17:22] <mirek2> ok, cool
    [17:22] <mirek2> where should it be
    [17:22] <alexanderW> yes
    [17:22] <medieval> down
    [17:22] * astron247 doesn't liek the icon smauel used for edit though
    [17:22] <mirek2> I'm with Astron that it should be at the bottom
    [17:22] * astron247 cant spell
    [17:23] <@hiok> bottom
    [17:23] <alexanderW> bottom of the animation list
    [17:23] <mirek2> astron247: you don't like the symbolism used? a pencil is usually used to signify "Edit"
    [17:23] <alexanderW> a wrench as edit maybe?
    [17:23] <mirek2> and obviously, we would use Gnome icons
    [17:23] <mirek2> alexanderW: we use a pencil in "Edit File"
    [17:24] <astron247> right. but i find the usual pencils really easy to mistake for odd triangles or whatever
    [17:24] <alexanderW> well, here you edit settings
    [17:24] <astron247> i dont think pencils make great icons at that size
    [17:24] <mirek2> I disagree
    [17:25] <medieval> doesn't we have some "edit" icons somewhere in LO
    [17:25] <medieval> ?
    [17:25] <mirek2> a) a pencil is not only used in LibreOffice for edit, it's the symbol Android uses as well
    [17:25] <astron247> e.g. see this one next to "Confirmed":
    [17:26] <@hiok> A pencil over a paper could do as well
    [17:26] <astron247> hiok: that would be even more complicated
    [17:26] <@hiok> astron247: hahaha, that's horrid
    [17:26] <mirek2> astron247: well, the icon would be bigger and the pencil could be better defined
    [17:27] <@hiok> don't we have standard tango icon for that?
    [17:27] <astron247> okay... maybe still we could use the wrench...
    [17:27] <astron247> hiok: not as far as i know
    [17:28] <mirek2> b) I don't think a wrench works that well at small sizes either
    [17:28] <mirek2> and a wrench tends to be used as an "Options" icon, rarely as an edit icon
    [17:28] <@hiok> i don't like the wrench; it seems refer to the application rather than the document
    [17:29] <@hiok> that
    [17:29] <mirek2> in any case, this icon wouldn't be tiny
    [17:29] <mirek2> it would be about as big as the current up/down icons, and those are huge
    [17:30] <@hiok> medieval is right, we do have a tango icon that's a pencil over a paper in "edit file"
    [17:30] <mirek2> yes
    [17:30] <mirek2> we'll need to remove the paper, though
    [17:30] <mirek2> as that's the symbol for file
    [17:30] <@hiok> we could use the same or a small variation of that, depending on the state of art of the icons issue
    [17:31] <mirek2> alexanderW: since you're working on the new icons, would you like to find fitting icons for this sidebar?
    [17:31] <@hiok> astron247: what about a pen instead of pencil? any better?
    [17:31] <mirek2> or would anyone else like to take this job?
    [17:31] <mirek2> hiok: I've never seen a pen used to symbolize edit
    [17:31] <mirek2> a pencil is a common convension
    [17:32] <@hiok> true
    [17:32] <alexanderW> I will
    [17:32] <mirek2> ok, great
    [17:33] <mirek2> so we've agreed to have a toolbar at the bottom of the animation list
    [17:33] <mirek2> how about removing the slide show button?
    [17:33] <@hiok> ok guys, i'll leave too. It's lunch time here. Thanks for the discussion.
    [17:34] <mirek2> ok, bye
    [17:34] <astron247> sorry, was afk for some time. bye rafael
    [17:35] == hiok [b18de303@gateway/web/freenode/ip.] has quit []
    [17:36] <mirek2> so, about removing the slide show button?
    [17:36] <alexanderW> Yes
    [17:36] <medieval> slide show button with tabs to bottom? or the one on custo manim.?
    [17:36] <medieval> if we have two: toolbar and tabs one, then third one is not needed
    [17:37] <mirek2> no other edits
    [17:37] <mirek2> so only the toolbar one
    [17:38] <medieval> (if we put tabs down, i think there should be slide show button)
    [17:38] <astron247> hm, would be good if the toolbar button were more prominent
    [17:39] <mirek2> medieval: as I said, that would be done after Apache OO implements it
    [17:39] <medieval> yes
    [17:39] <medieval> removing it then is ok from custom anim.
    [17:40] <mirek2> astron247: I agree -- I'd propose to do that with a streamlined configuration, which we'll discuss when we discuss my easyhack proposals
    [17:41] <mirek2> would you agree with removing the slide show button from the sidebar even if it wasn't made more prominent
    [17:41] <astron247> yes
    [17:41] <mirek2> ok good
    [17:42] <astron247> mirek2: one thing our current toolbar implementation lacks is the ability to show labels next to (some) icons. that would go a long way
    [17:42] <mirek2> astron247: I agree
    [17:42] <mirek2> do others agree as well?
    [17:43] <alexanderW> yes
    [17:43] <mirek2> ok
    [17:44] <mirek2> what about removing the „Automatic Preview“ checkbox?
    [17:44] <mirek2> I personally am not sure about it
    [17:44] <alexanderW> I hate that flickering black background
    [17:45] <mirek2> me too
    [17:45] <astron247> yes
    [17:45] <mirek2> I'd leave the checkbox in
    [17:46] <astron247> turn this off always?
    [17:47] <astron247> (and remove the tick box)
    [17:47] <mirek2> no, just keep the checkbox
    [17:47] <mirek2> it's useful to be able to preview your presentation
    [17:48] <mirek2> as for redoing it in .ui format -- that should be the plan for all parts of LibreOffice, so I don't think a special easyhack is needed for that
    [17:48] <astron247> whats the slideshow button good for then?
    [17:48] <astron247> mirek2: yes, but libo has huge amounts of ui, so you would need to prioritise that
    [17:48] <mirek2> I thought we agreed on removing the slideshow button in favor of the one on the toolbar, no?
    [17:48] <astron247> i mean the toolbar slideshow button
    [17:49] <mirek2> astron247: if anyone starts working on the sidebar, I would think that the mentor would recommend to just do it in .ui
    [17:50] <mirek2> astron247: sure, but if you're looking at what each transition looks like, it'd be a very long process without the live previews
    [17:50] <astron247> not sure how the button reacts now, but F5 now starts at the current slide
    [17:51] <mirek2> F5 isn't discoverable
    [17:51] <mirek2> in any case, we have disagreement, so the safest way to go is keep the current behavior
    [17:52] <astron247> well then...
    [17:52] <mirek2> what do you think about putting the "Play" button in the new toolbar?
    [17:52] <mirek2> there should be room for it, and it would streamline the sidebar quite a bit
    [17:53] <astron247> yes
    [17:53] <mirek2> great :)
    [17:54] <mirek2> I suppose we can move to my suggestions: ?
    [17:55] <mirek2> what do you think of having a responsive layout for toolbar icons?
    [17:55] <mirek2> agree with both the suggestions for the main proposal and the optional enhancements:
    [17:55] <mirek2> ?
    [17:56] <mirek2> anyone?
    [17:56] <medieval> kinda
    [17:56] <astron247> useful, but sounds a bit hard...
    [17:57] <astron247> really useful, actually.
    [17:57] <mirek2> could be a harder hack, then
    [17:57] <astron247> a third extra point for hiding/showing important labels responsively...
    [17:57] <astron247> ?
    [17:58] <mirek2> that's something to have after labels are implemented
    [17:58] <mirek2> but yes, I agree
    [18:01] <mirek2_> medieval: care to explain your stance in more detail?
    [18:02] <mirek2_> what do you agree with and what don't you agree with?
    [18:02] == mirek2 [59b0ae7b@gateway/web/freenode/ip.] has quit [Ping timeout: 245 seconds]
    [18:03] <mirek2_> alexanderW: what do you think?
    [18:03] <medieval> i like idea about changing size based on screen resolution
    [18:04] <alexanderW> It sounds good
    [18:04] <medieval> but i hope i can change icons size myself too(small, big...)
    [18:04] <mirek2_> medieval: yes -- that would still be an option
    [18:04] <medieval> then it ok
    [18:04] <mirek2_> btw, the proposal wasn't based on screen resolution, but based on window size
    [18:05] <mirek2_> so everyone agrees, right?
    [18:06] <medieval> ok
    [18:06] <mirek2_> "page toolbar"
    [18:06] <astron247> uhuh
    [18:06] <mirek2_> it would be a first step to contextual page actions
    [18:06] <mirek2_> would be followed by "page selection"
    [18:07] <astron247> right, but ... what would be the use initially?
    [18:07] <astron247> i say _initially_
    [18:07] <mirek2_> as said, it's a first step
    [18:07] <mirek2_> I think both a page toolbar and page selection is too much for an easyhack
    [18:08] <mirek2_> no?
    [18:08] <astron247> so, i cant see how you could put that toolbar to good use right now
    [18:08] <mirek2_> it wouldn't be very useful, initially, true
    [18:09] <astron247> it would clog up your toolbars with  things you rarely need
    [18:09] <mirek2_> but you have to go step by step
    [18:09] <astron247> sure
    [18:09] <mirek2_> no, it wouldn't be shown by default
    [18:09] <mirek2_> so it wouldn't really clog anything
    [18:09] <astron247> ok
    [18:10] <mirek2_> others agree as well?
    [18:10] <astron247> i bet it will be hard finding anyone to work on this then
    [18:10] <mirek2_> you'd propose to have a Medium Hack (is that what they're called?) with both page selection and page toolbar, then?
    [18:10] <astron247> but, sure, ultimately it sounds great
    [18:11] <astron247> mirek2, i dont believe there is such a thing as medium hacks
    [18:11] <astron247> there are hard hacks, but thats anentirely different thign altogether
    [18:11] <astron247> ^anentirely^an entirely; ^thign^thing
    [18:11] <mirek2_> right
    [18:12] <astron247> (those are 5 bugs weekly, usually from the most annoying list, proposed by QA)
    [18:12] <mirek2_> so include both under a "more interesting" easy hack?
    [18:12] <mirek2_> I think I'll ask Kendy on the best way to do this
    [18:13] <mirek2_> do others agree with the proposal?
    [18:13] <medieval> yes
    [18:13] <astron247> sure. but please dont put it at the forefront now – it will remove the simpler hacks from eyesight
    [18:14] <mirek2_> alright
    [18:15] <mirek2_> "Optional Hidden Items Menu"?
    [18:15] <mirek2_> what do you think about it?
    [18:15] <medieval> like that one
    [18:16] <astron247> ok
    [18:16] <astron247> but you should probably make a new mockup for this
    [18:16] <mirek2_> is a mockup really needed?
    [18:16] <astron247> (that shows the functionality in a clearer way
    [18:16] <astron247> )
    [18:17] <astron247> i meant if you want to advertise it with a mockup
    [18:18] <mirek2_> well, it would look the same as when you have window icons that don't fit in the window, except with a "Customize..." button at the bottom
    [18:18] <mirek2_> initially, at least
    [18:18] <mirek2_> but yes, I might make a better mockup
    [18:18] <astron247> good
    [18:18] <mirek2_> what about "Toolbar alignment"?
    [18:19] <mirek2_> (I think a right-aligned toolbar would be good to visually separate two distinct toolbars)
    [18:19] <astron247> hm, mozilla has felxible placeholders for that...
    [18:20] <astron247> ^felxible^flexible
    [18:20] <alexanderW> we could lock the default toolbars
    [18:20] <mirek2_> alexanderW: sure, but that's different from right-aligning
    [18:20] <alexanderW> if we want to ship right-aligned toolbars
    [18:20] <mirek2_> i.e. chaning the windows size should keep the toolbar at the right
    [18:21] <mirek2_> I was thinking there could be three states: left-aligned, right-aligned, and unlocked
    [18:21] <mirek2_> (left-aligned would always align to the very left, so that there would be no space between two left-aligned toolbars)
    [18:21] <alexanderW> what happens with two left-aligned toolbars?
    [18:22] <alexanderW> wrt the order
    [18:22] <alexanderW> just keep the order it had before?
    [18:22] <mirek2_> yes
    [18:23] <mirek2_> well, left-aligning a toolbar would put the toolbar on the very left
    [18:24] <mirek2_> hm... I suppose this does need further design/specs
    [18:24] <mirek2_> I'll work on that
    [18:25] <mirek2_> what about "Style menus"?
    [18:26] <mirek2_> (the proposal would basically look and work like the Google Docs implementation)
    [18:26] <alexanderW> I like that
    [18:27] <mirek2_>
    [18:27] <alexanderW> Would "Edit Style Based on Selection" replace the style with the formatting of the selection?
    [18:27] <medieval> (it has been topic from earlier chat?)
    [18:28] <mirek2_> alexanderW: it would use the selection's formatting, yes
    [18:29] <mirek2_> medieval: yes, I think so
    [18:29] <mirek2_> this should make it easier to vote
    [18:29] <astron247> it would look like an unholy non-native mess ... but ive expressed that before...
    [18:29] <medieval> i liek the idea
    [18:29] <mirek2_> astron247: do you think Google's implementation looks like an unholy non-native mess?
    [18:30] <medieval> but is it possible to be done?
    [18:30] <mirek2_> (I mean, pop-overs in general are non-native, and I don't think there's a problem there)
    [18:30] <mirek2_> medieval: probably -- I'll ask
    [18:31] <medieval> it would be great improvement in style handling
    [18:31] <astron247> mirek2: no. but googles implementation does not try to be native at all
    [18:32] <mirek2_> right, and it's not an unholy non-native mess
    [18:32] <astron247> libreoffice isnt just a website
    [18:32] <mirek2_> as I said, LibO's pop-overs aren't native
    [18:32] <mirek2_> does that make them a mess?
    [18:33] <astron247> what pop-overs do you mean? colors etc.?
    [18:33] <mirek2_> yes
    [18:33] <mirek2_> pop-overs in general are something that isn't really present in most toolkits
    [18:33] <astron247> specifically what i am worried about are split entries in the combo box
    [18:34] <mirek2_> right, but that too isn't possible to do natively
    [18:34] <mirek2_> and, honestly, it's just a matter of putting an arrow and a separator in the style list
    [18:34] <astron247> yes, but i am worried about how these will look (and work)
    [18:35] <mirek2_> it's been tested in Google Drive
    [18:35] <astron247> it isnt.
    [18:35] <astron247> * should both areas have different colours
    [18:35] <astron247> * how should the menu look (grey or white)
    [18:35] <astron247> etc
    [18:36] <mirek2_> I would use white
    [18:36] <mirek2_> to be consistent with the style drop-down
    [18:36] <astron247> if we ever get better integration with gtk/aqua combo boxes, it would look even worse
    [18:37] <mirek2_> so would the style dropdown, as it's been designed for a white background
    [18:39] <astron247> i wasnt even speaking of that but how the dropdown would look centred over the chosen item...
    [18:39] <mirek2_> what do you mean?
    [18:40] <mirek2_> (for how it would look, just look at what Google's implementation looks like)
    [18:40] <astron247> ...
    [18:42] <mirek2_> ?
    [18:43] <astron247> i was arguing that google's look wouldnt work for us
    [18:43] <mirek2_> I still don't see the argument though
    [18:44] <astron247> the template manage looked good in a mockup, right?
    [18:44] <astron247> +r
    [18:45] <mirek2_> I mean, if we use a white color background for the style previews despite platform defaults, what's wrong with using white for menu backgrounds triggered by the style dropdown
    [18:45] <mirek2_> astron247: sure, and the implementation changed a lot of things
    [18:45] <mirek2_> split buttons were dropped because they weren't doable
    [18:45] <mirek2_> that's not the case here
    [18:45] <astron247> so, will the implementation of this change lots of things.
    [18:46] <mirek2_> is having a white menu background really that hard to implement?
    [18:47] <mirek2_> (I'll ask Kendy about it)
    [18:47] <astron247> please do
    [18:47] <mirek2_> in any case, you would agree with implementing it with a whtie background, right?
    [18:47] <astron247> are you going to meet again soon?
    [18:47] <astron247> sure.
    [18:47] <mirek2_> I could ask to meet
    [18:48] <mirek2_> ok, let's move to "Drag to Open Pop-over"
    [18:48] <astron247> ok
    [18:48] <astron247> doesnt seem very intuitive to me
    [18:49] <mirek2_> not intuitive perhaps because no one else implemented this
    [18:49] <mirek2_> but, on a touch-based interface, I can't think of a more intuitive way to open a split button
    [18:50] <alexanderW> long press
    [18:50] <alexanderW> ?
    [18:50] <astron247> dont have a split button seems like an option
    [18:50] <mirek2_> is that really more intuitive?
    [18:50] <astron247> alex: long press takes time and people dont like that
    [18:50] <alexanderW> I'm not sure if we should focus on touch-interfaces
    [18:51] <mirek2_> the drop-down drops down from the icon -- how is dragging down to reveal not intuitive?
    [18:51] <alexanderW> Office 2013 even has those options to make things bigger for touch-devices and it's still not touch-friendly
    [18:52] <astron247> "inappropriate touching" ©ars technica
    [18:52] <astron247> at the same time ... we have nothing at all
    [18:52] <astron247> while at least ms's ribbons sorta kinda work
    [18:52] <mirek2_> alexanderW: it's not good only for touch UIs, though -- a split button can be hard to open on certain platforms because the arrow can be a really small clickable area
    [18:52] <mirek2_> (tested on macOS)
    [18:53] <mirek2_> astron247: I think we're not that bad in terms of touch compatibility
    [18:53] <astron247> what happens specifially on macOS?
    [18:53] <mirek2_> we have large icons, at least
    [18:53] <mirek2_> astron247: the split button target area for the pop-over is really small
    [18:53] <mirek2_> having an alternative way to open it would help
    [18:53] <alexanderW> Well, all those dialogs aren't that great for touch input
    [18:53] <astron247>  but isnt that just a simple bug in libo?
    [18:54] <alexanderW> I'd rather vote for bigger target areas
    [18:54] <mirek2_> alexanderW: yes -- that's why we should strive to make it not necessary to use dialogs
    [18:54] <mirek2_> (there are dialogs in MS Office as well, only they aren't usually necessary)
    [18:55] <mirek2_> astron247: maybe it's just using bad OS defaults
    [18:56] <astron247> can't really imagine... ill see if i find screenshots...
    [18:57] <mirek2_> in any case, this way of opening the pop-over wouldn't really hurt anything in LibreOffice and would enable using split buttons on touch devices
    [18:57] <astron247> the size looks pretty normal to me:
    [18:58] <mirek2_> it looks normal, but the clickable area is pretty small
    [18:58] <astron247> okay
    [18:58] <mirek2_> in any case, even if the only reason for this was touch integration, I don't understand why we shouldn't implement it -- it doesn't hurt anything
    [18:58] <astron247> it takes time
    [18:59] <astron247> especially, because libreoffice doesnt really interpret any touch events right now
    [18:59] <astron247> apart from that, there are no good arguments against it
    [19:00] <mirek2_> (I really need to find a Windows 8 tablet to test whether it translates touch drag events into mouse drag events)
    [19:00] <mirek2_> alright, then, let's skip this one for now
    [19:01] <astron247> shall we finish here?
    [19:01] <mirek2_> there was a mailing list post with a few bugs
    [19:01] <mirek2_> "How to provide usability-related suggestions"
    [19:01] <mirek2_> on ux-advise
    [19:01] <astron247> ah right.
    [19:02] <astron247> take a look at them, they are pretty good, if a little power-user-y
    [19:03] <mirek2_> should I suggest they become easyhacks as well?
    [19:03] <mirek2_>
    [19:04] <astron247> dont know...
    [19:05] <mirek2_> I do use Navigator from time to time, but I don't use it enough to be able to judge the proposals
    [19:05] <mirek2_> proposal, not proposals
    [19:06] <astron247> i dont really use navigator much...
    [19:06] <mirek2_> but I suppose the person who submitted the bug knows what they're talking about
    [19:07] <mirek2_> and ask for a "Customize..." dialog redesign
    [19:07] <mirek2_> which I agree with, but it certainly needs more thought and isn't really an easy hack
    [19:08] <mirek2_> -- I agree with it, should probably be part of a new Options dialog
    [19:09] <mirek2_> I agree with, and that could be an EasyHack, I think
    [19:10] <mirek2_> as well
    [19:11] <mirek2_> -- I wonder what the cause of that is, but it might fit under an Easy Hack's scope as well
    [19:11] <mirek2_> so, would you agree with me to make these 3 bugs into easyhacks?
    [19:12] <astron247> yes
    [19:12] <medieval> yes, i personally don't use navigator much
    [19:13] <mirek2_> ok, good
    [19:13] <mirek2_> I think we're done for today, then
    [19:13] <mirek2_> I can post the log
    [19:13] <medieval> one thing
    [19:13] <mirek2_> go ahead
    [19:13] <medieval> find and replace should have special characters like in ms o
    [19:14] <mirek2_> don't have MS Office -- what exactly do you mean?
    [19:14] <medieval> (paragraph mark, tab character etc
    [19:14] <mirek2_> a button to insert special characters?
    [19:14] <medieval> i make quick screen
    [19:14] <astron247> hm... you can search for them with \n etc... but youre right, probably
    [19:14] <alexanderW> there's a help page for regexp
    [19:14] <astron247> remember this from office 2000, even
    [19:14] <medieval> they should be more visible
    [19:15] <astron247> alex: regexp are great, but not for the average user. that libo uses them at all is occasionally cited as a downside of the software
    [19:16] <alexanderW> okay...
    [19:16] <astron247> (visibility of that would solve it though)
    [19:18] <medieval>
    [19:19] <alexanderW> I'm pushing a few updated icons now, maybe you want to give some feedback via mail
    [19:19] <mirek2_> alright
    [19:20] <medieval> how about special characters then?
    [19:21] <mirek2_> sounds good, though we'd really need specifications to turn this into an EasyHack
    [19:21] <mirek2_> (and as this would be an easyhack, it probably wouldn't have the same scope as the MSO implementation)
    [19:22] <medieval> yes, is there some discoverable list where i can see what options are available?
    [19:22] <astron247> alex, are you pushing directly or are you going through gerrit?
    [19:22] <astron247> medieval: press help in the find/replace dialogue
    [19:23] <astron247> then click on list of regular expressions
    [19:24] <alexanderW> astron247: directly
    [19:24] <medieval>
    [19:24] <astron247> ok
    [19:24] <astron247> medieval: or that way :)
    [19:25] <mirek2_> astron, any updates from the ESC call?
    [19:25] <astron247> anyway, regexps are not really understandable without a good tutorial
    [19:25] <medieval> yes
    [19:26] <astron247> mirek: not so much – i told petr mladek (who was leading the call, because so many people were not there) that we should have an idea for new branding on feb 11
    [19:26] <astron247> ... let me check the log again
    [19:26] <medieval> it would be good when same are available as in mso
    [19:27] <astron247> (i didnt want to discuss everything that was said on the marketing list, that would have been unproductive, i guess)
    [19:27] <mirek2_> right
    [19:27] <mirek2_> anything about color themes?
    [19:27] <mirek2_> I mean, theme colors?
    [19:28] <astron247> i didnt discuss that either, sorry. but i can try next week when people are back from fosdem hopefully
    [19:28] <mirek2_> alright
    [19:29] <astron247> anyway, there still is no progress on the text-selection bug you wanted me to highlight a few weeks ago...
    [19:29] <mirek2_> ok, I think we can finish
    [19:29] <medieval> why not implement color picker without colors in use ot themes now?
    [19:29] <astron247> i guess that is what will happen anyway...
    [19:30] <mirek2_> because these two features could do a lot with the design of the picker
    [19:30] <astron247> but some ui doesnt make a lot of sense without the features
    [19:30] <medieval> we can implement these later?
    [19:30] <astron247> waht mirek said^^
    [19:30] <medieval> yea
    [19:30] <astron247> ^waht^what
    [19:30] <mirek2_> we can implement them later, but just need to know if the features will come later
    [19:31] <mirek2_> (who knows, maybe there's a plan to do theme colors differently in ODF)
    [19:31] <astron247> hm, i think the calligra people spoke about that at some point...
    [19:32] <mirek2_> when? where?
    [19:32] <mirek2_> this?
    [19:33] <astron247> i guess
    [19:33] <astron247> yes
    [19:34] <astron247> thanks for lookigfn
    [19:34] <astron247> ...looking for it
    [19:34] <mirek2_> hm, I guess I'll e-mail Jarosław Staniek and ask about the progress
    [19:34] <alexanderW> Usually ./g should support 'config', right?
    [19:36] <astron247> alexanderW: what are you doing with config?
    [19:36] <astron247> (but i guess, yes it should)
    [19:37] <alexanderW> ./g config remote.origin.pushurl ssh://
    [19:38] <alexanderW> But I get './g does not support command: config'
    [19:38] <astron247> why not just try with git config then? (since you dont want to push to help/l10n/...)
    [19:40] <alexanderW> seems to work
    [19:40] <alexanderW> ^^
    [19:40] <astron247> btw, where is the documentation for that? i thought g.fd.o was going to be read-only?
    [19:41] <alexanderW>
    [19:41] <alexanderW> Haven't pushed for a while
    [19:42] <alexanderW> Now it works with gerrit
    [19:43] <astron247> alex, have you pushed already?
    [19:43] <alexanderW> The command is running
    [19:43] <alexanderW> yes
    [19:44] <astron247> i see them :)
    [19:44] <alexanderW> Alright :)
    [19:44] <mirek2_> ok to end the chat now?
    [19:45] <alexanderW> Yeah
    [19:45] <medieval> bye
    [19:45] <astron247> i considered the official part ove for some time, actually
    [19:46] <alexanderW> Have a nice weekend, everyone
    [19:47] <mirek2_> alright
    [19:47] <mirek2_> I'll upload the log
    [19:47] <mirek2_> bye
    [19:48] <alexanderW> bye
    [19:48] <astron247> bye