Jump to content

Design/Meetings/2013-02-02

From The Document Foundation Wiki

Attendees

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

Topics

  • EasyHack suggestions

Log

[15:56] <mirek2> hi everyone
[15:57] <stevebell> hey mirek2
[15:58] == thibaut [~user@95-89-200-80-dynip.superkabel.de] 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> https://wiki.documentfoundation.org/User_talk: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: http://ubuntuone.com/70gT9RcCdaGO2GIcHYsxjn
[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 [~alexander@d53649cc.access.ecotel.net] 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> http://www-03.ibm.com/software/lotus/symphony/theme/images/presentations_title_slide_new.gif
[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 [~frootzowr@dslb-088-074-085-156.pools.arcor-ip.net] 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> http://piratepad.net/J4umv2DpOY
[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 https://wiki.documentfoundation.org/Design/Principles
[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@89.204.130.214] has quit [Quit: Colloquy for iPad - http://colloquy.mobi]
[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> https://wiki.documentfoundation.org/User_talk:Medieval
[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> http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/permalinks/2012-11-24T21_03_58.html
[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> https://wiki.documentfoundation.org/Design/Whiteboards/Style_management
[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> https://bugs.freedesktop.org/show_bug.cgi?id=59718
[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: https://bugs.freedesktop.org/show_bug.cgi?id=50506
[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> https://wiki.documentfoundation.org/User:Sam_m
[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 [~user@95-89-200-80-dynip.superkabel.de] 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> https://wiki.documentfoundation.org/User:Sam_m#Impress:%20Custom%20Animation%20Pane
[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": https://bugs.launchpad.net/bzr/+bug/1112797
[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.177.141.227.3] 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: https://wiki.documentfoundation.org/User:Mirek2 ?
[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.89.176.174.123] 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_> https://clickortap.wordpress.com/2012/02/19/notice-google-docs-new-style-management/#jp-carousel-973
[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: http://screenshots.en.sftcdn.net/en/scrn/241000/241525/libreoffice-35.png
[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_> https://bugs.freedesktop.org/show_bug.cgi?id=51923
[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_> https://bugs.freedesktop.org/show_bug.cgi?id=52331 and https://bugs.freedesktop.org/show_bug.cgi?id=52335 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_> https://bugs.freedesktop.org/show_bug.cgi?id=52387 -- I agree with it, should probably be part of a new Options dialog
[19:09] <mirek2_> https://bugs.freedesktop.org/show_bug.cgi?id=52116 I agree with, and that could be an EasyHack, I think
[19:10] <mirek2_> https://bugs.freedesktop.org/show_bug.cgi?id=52115 as well
[19:11] <mirek2_> https://bugs.freedesktop.org/show_bug.cgi?id=51401 -- 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> http://imageshack.us/f/194/aaaaaspecialchara.png/
[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> https://help.libreoffice.org/Common/List_of_Regular_Expressions
[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? https://blogs.kde.org/2011/12/14/fruits-css2-shared-themes
[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://git.freedesktop.org/git/libreoffice/core
[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> https://wiki.documentfoundation.org/Git_For_LibreOffice_Developers
[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