Design/Meetings/2013-02-02
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
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