Design/Meetings/2013-02-02

Attendees

 * alexanderW
 * astron
 * hiok
 * medieval
 * mirek2
 * stevebell
 * thibaut

Topics

 * EasyHack suggestions

Log
[15:56] hi everyone [15:57] hey mirek2 [15:58] == thibaut [~user@95-89-200-80-dynip.superkabel.de] has joined #libreoffice-design [16:00] hi [16:01] hi [16:01] <@hiok> Hi guys. [16:02] hello [16:02] 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] :) thanks for coming [16:04] me too [16:05] 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] https://wiki.documentfoundation.org/User_talk:Medieval [16:06] hiok: it's up to you [16:06] i have gathered something [16:06] mine name is confusing to: medieval vs hillar [16:06] <@hiok> OK, let's keep it that way. [16:06] I think the UI lines should be cleand-up: http://ubuntuone.com/70gT9RcCdaGO2GIcHYsxjn [16:07] alright, let's start :) [16:07] let's start with Medieval's proposal [16:07] new icon theme is under way [16:07] yup [16:08] and it'd be good if anyone could help [16:08] as basically only one person is working on it and in his free time [16:08] Close button for Styles and Formatting [16:08] == alexanderW [~alexander@d53649cc.access.ecotel.net] has joined #libreoffice-design [16:08] hi alex [16:08]  Hi [16:08] medieval: before we get into that, I'd like to address "Improving look of tabs in Impress" first [16:08] ok [16:08] it's somewhat similar to a problem we had with the templates dialog [16:09] to me these look quite ugly now [16:09] I understand, and I agree [16:09] however, we've had the same problem with the templates dialog [16:10]  No gtk style hints [16:10] 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] the new 4.0 templates dialog [16:10] <@hiok> Ah, sorry. [16:11] the problem was that it would be hard to implement a way to do this kind of split button natively [16:11] ok [16:11] and since tabs cannot be non-native, we had to settle for the standard tab widget [16:11] however, what would be possible is moving tabs to the bottom [16:11] why not but these to status bar? [16:12] the status bar is already pretty crowded [16:12] however, what seems like Apache OpenOffice will be doing is put them on the bottom [16:12] like Lotus Symphony did [16:12] and we'll be able to take that code and integrate it [16:13] (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] http://www-03.ibm.com/software/lotus/symphony/theme/images/presentations_title_slide_new.gif [16:13] this? [16:14] it will be more native-looking, I promise [16:14] yes [16:15] <@hiok> looks nice to me. [16:15] but idea is same [16:15] is it possible to integrate slide show icon to there too? [16:15] as in lotus symphony [16:15]  shouldn't be too hard [16:16] right [16:16] so, in this case, let's wait for the AOO implementation and build on that [16:17] next topic [16:17] Close button for Styles and Formatting [16:17]  might make it overcrowded [16:17] if we remove it from toolbar then it is needed [16:17]  There are already 7 buttons in the top row [16:18] 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]  Hi Astron [16:18] hi astron [16:18] hi alex, all [16:18] to me it is now very hard to use without close button (i have removed icon from toolbar) [16:18] hi [16:19] http://piratepad.net/J4umv2DpOY [16:19] <@hiok> there's shortcuts. Crtl+t and F11. [16:19] they're not discoverable [16:19] I would argue that: [16:20] <@hiok> true. still, i have an idea. [16:20] yes, i can use them, but other people? [16:20] * the current sidebar is not overcrowded (there's ample room; compare with Styles sidebar) [16:20] hi astron [16:21] 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] but right click function to close ? [16:21] * a close button makes sense in terms of ux-discoverability and ux-natural-mapping [16:22] a right click function isn't really discoverable [16:22] <@hiok> agreed [16:23] most dockable windows have close buttons (in impress) [16:23] <@hiok> besides right click should be avoided, cause it's time-expensive. [16:23] btw, the principles I'm talking about are from https://wiki.documentfoundation.org/Design/Principles [16:23] ok, then let's agree to make this into an easy hack [16:23] 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] the button would be small and could be light [16:25] could someone produce a mockup? [16:26] <@hiok> well, i would like to try some. [16:26] mirek, not sure about the close button thing yet, either. [16:26] <@hiok> perhaps rearrange one or two things. [16:26] look the buttons from impress [16:27] <@hiok> ok, in impress there's lots of room, but not in writer. [16:27] adding headers? [16:27] 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] to anyone interested, make some mockups [16:28] I'll try to make a quick one as well [16:28] ok. [16:28] <@hiok> ok [16:29] meanwhile, let's move on [16:29] "Styles preview" [16:29] there is bug [16:29] 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] it don't show font effects [16:29] (a la evince sidebar) [16:29] I think both suggestions are the next logical step [16:30] astron247: I would be against that [16:30] why that? [16:30] 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] because iwe then have comboboxes at the top and the bottom? [16:30] that would be horrible with a combo box [16:31] astron247: sorry, I didn't understand that [16:31] another option would be to have collaipsible areas for eaach sort of style in the main area [16:32] ^collaipsible^collapsible [16:32] ^eaach^each [16:32] given that these are easy hacks, let's stick to easy fixes, not grand redesigns [16:32] though, of course you're free to make a mockup [16:32] well, fine [16:32] but let's leave bigger redesigns for later discussion [16:32] <@hiok> ok. [16:32] then you will indeed have to add a header to the sidebar [16:33] I think a small close icon would work fine [16:33] I'll post a mockup [16:33] ok [16:33] anyway, back to medieval's style suggestions for now [16:33] back to the sidebar later [16:33] https://wiki.documentfoundation.org/User_talk:Medieval [16:34] 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] agreed? [16:34] <@hiok> medieval's preview is for the dropdown in toolbar, right? [16:34] both [16:34] to it too [16:35] <@hiok> ok, so toolbar and sidebar. [16:35] yes [16:35] do we have bugs for these two already? [16:35] no [16:35] <@hiok> you don't have a mockup, have you? [16:35] for what? [16:36] <@hiok> for the preview [16:36] we already have an implementation [16:36] 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] hm, the second bug does warrant a mockup still, because there is a hierarchic view in the styles dock [16:37] so wed need to look how we can make the previews look good next to plus/minus signs [16:38] https://wiki.documentfoundation.org/Design/Whiteboards/Style_management [16:38] I'd vote against that [16:38] it's quite overkill [16:38] <@hiok> :-) that's my mockup. [16:38] it's too complex [16:38] or alternatively, decide it is better to only change the applied styles panel [16:39] agree, its quite complex and disorganised (badly needs some sort of grid) [16:39] you're right -- this second idea requires further thought [16:39] so let's leave it for later discussion [16:39] <@hiok> ok. [16:39] still, what do you think of only changing "applied styles"? [16:40] is there no hierarchy there? [16:40] no [16:40] and it only shows a small number of styles generally which lends itself well to a graphic presentation of them [16:40] hm... sounds good as a first step [16:41] 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] it means you have to click before you see the styles... unless you do hover effects [16:42] exactly [16:42] ... which we have some bad experiences with [16:42] wouldn't that be inconsistent? [16:42] yes, that too [16:42] <@hiok> but you could see the style in context, which is very good for paragraph style [16:42] anyway, let's leave this discussion for later [16:43] borders mess next? [16:43] and move to "UI: Borders are not drawn correctly" [16:43] yes [16:43] <@hiok> ok. I'll review that proposal and try to simplify and break it in smaller pieces. [16:43] https://bugs.freedesktop.org/show_bug.cgi?id=59718 [16:43]  Is it even fesible to draw all borders correctly with VCL? [16:44]  *feasible [16:44] it should be [16:44] it was possible before kendy made the changes [16:44] (i believe) [16:44] really? I thought the only changes Kendy made was remove the 3D border from the document area [16:45] which happened to result in a loss of visible border for some elemetns [16:45] elements [16:45] yes, and that broke lots of things, because it wasnt done entirely consistently [16:45]  Ah, I though the bug report also covered the various borders/handles [16:45] btw, similar bug report: https://bugs.freedesktop.org/show_bug.cgi?id=50506 [16:45] astron247: right, but these things are fixable [16:46] so I'd vote to make it an easyhack [16:46] agreed? [16:46] mirek2: i never said they weren't. i am just saying that work wasnt really completed there [16:46] yes -- that's why the easyhack [16:46] mirek2: how do you want to amke it an easy hack? you dont develop [16:47] you can only add it to suggested easy hacks ... [16:47] yes [16:47] ... and, actually, everyone can do that on their own. [16:47] I was thinking we could either go through the ESC call or through Kendy [16:47] ok [16:47] to find suitable mentors? [16:48] just to turn them into easyhacks [16:48] and perhaps promote them a bit [16:48] easy hacks need mentors [16:48] thats whats so good about them [16:48] right [16:49] basically, the point of this is to produce a set of design team-approved UX-related easy hacks [16:49] ok... [16:49] so that the UX side of things can finall get rolling [16:49] and, yes, the ESC call would be a good place to find mentors [16:50] so... everyone agree with drawing borders correctly? [16:50] why would anyone not like that? [16:51] I would be surprised as well, but perhaps there are reasons [16:51] ok, lazy consensus, next → [16:51] https://wiki.documentfoundation.org/User:Sam_m [16:52] let's start with extension manager, as it's a simpler proposal [16:52] label wording [16:52] (under "Labels should be more descriptive") [16:53] would everyone agree with that? [16:53]  Agree with the suggestions [16:53] dont agree with the word "filter" [16:53] that sounds like technobabble to most people [16:53] (i think) [16:54] really? I thought that word was quite common [16:54] also, i dont know... do we even need the label? [16:54] what would you use instead? [16:54] how about "Show:"? [16:54] or "Display:" [16:54] nothing, just more descriptive tick boxes [16:55] but show would be fine with me also [16:56] what do others think? [16:56] working for me [16:56] display is better [16:56] i think [16:56] ok [16:57] <@hiok> display is also a substantive. show sounds more direct. [16:57] also, maybe the whole ticks at the bottom of the window thing is not so great. [16:57] how about a little menu button like in the template manager? [16:57] where? [16:57] add a toolbar just for one button? [16:58] no [16:58] 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] i will work with ticks [16:59] astron247: would you like to create a proposal in Glade? [16:59] ok [16:59] alright [16:59] what team should we talk to about the rewording? [16:59] but im not sure, this dialogue will be ported to gbuilder soon [16:59] (since the list view is quite complicated) [17:00] ok [17:00] I'll have to go, sorry [17:00] bye [17:00] bye :/ [17:00] alright, see you later [17:00]  cu [17:01] astron247: the perhaps let's talk to the developer working on it? [17:01] <@hiok> see ya [17:01] astron247: do you know who it is? [17:01] mirek2: working on what? [17:01] on porting the dialog [17:01] is it being ported already? [17:02] if not, the developer is rather unclear. [17:02] oh, I assumed that there was [17:02]  The rewording coul [17:02] but caolan did most of the work to interpret .ui files, if that helps [17:02] hm, ok [17:03]  *ld be done without talking to any dev, right? [17:03] mirek2: i think they are going for low hanging fruit first [17:03] anyway, we all agree on the labels proposed except instead of filtering we'll use displaing [17:03] right? [17:03]  Yes [17:04] and aligning the checkboxes to the left [17:04] ? [17:04] no [17:04] ok [17:04] and cjanging other labels= [17:04] ? [17:04] <@hiok> yes, more descriptive ones. [17:04] medieval: which other labels? [17:04] == thibaut [~user@95-89-200-80-dynip.superkabel.de] has quit [Ping timeout: 252 seconds] [17:05] tick boxes on the left would fill a third of the dialogue = no [17:05] ok [17:05] "Installation" could be "Bundled with LibreOffice" "Shared" could be "Available for all users" "User" could be "Available only for current user" [17:05] yes, I think we all agree on those [17:05] ok [17:06] 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] I think that would require further design [17:06] so I would say not now [17:06] <@hiok> it should definitly be a button [17:07] hiok: adding "extension" would make the labels a lot longer, though [17:07] 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] doesnt make sense to me [17:08] "display these extensions" makes more sense but is clumsy [17:08] <@hiok> what aboute 'show'? [17:08] much better than display :) [17:08] I think we agreed display was better [17:09] <@hiok> "show extensions:" [17:09] <@hiok> we didn't. i opposed [17:09] oh, ok [17:09] <@hiok> display is also a substantive, show is more immediate [17:09] so everyone alright with using "show" for the word [17:09] show is a substantive as well [17:10] i am not againt it [17:10] 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] astron247: I think "display extensions related to the user" makes more sense then "display these extensions related to the user" [17:10] just like there's a "View" menu, not a "View these" menu [17:10] nah, you re reading it as a sentence. [17:10] <@hiok> astron247: but show is not a substantive in computer context [17:10] you shouldnt, i think [17:11] 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] would you be ok with "Show extensions:", then, astron? [17:14] 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] the colon is what makes the difference [17:14] mirek2: "show" still makes more sense to me, as users hopefully know they are in the extensions dialogue [17:14] as a colon is often used to introduce a list that completes a sentence [17:15] mirek2: not in german... [17:15] astron247: yeah, but "Show related to the user" doesn't make as much sense [17:15] 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] yes [17:15] ... what ever [17:15] bikeshedding, i guess [17:16] <@hiok> ok. [17:17] 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] you're right, astron, according to the grammar rules, "Show these extensions:" is correct [17:17] so everyone agree with that? [17:18] <@hiok> that's ok for me. let's not argue over that no more. [17:18] ok, great [17:18] now let's go to the other proposal: "Impress: Custom Animation Pane" [17:18] <@hiok> The labels are also agreed upon, right? [17:18] https://wiki.documentfoundation.org/User:Sam_m#Impress:%20Custom%20Animation%20Pane [17:18] yes [17:19] 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] everyone agree with that? [17:19] yes. [17:19] wholeheartedly [17:20] the one thing i would question is if these buttons shouldnt be under the list view though [17:21] and the other is if we need the preview button down there – we could just have a little "play" image button [17:21] let's go by the points one by one [17:22] we all agree with having a toolbar for „Add“, „Change“, „Remove“, "Up", and "Down", right? [17:22] yes [17:22] ok, cool [17:22] where should it be [17:22]  yes [17:22] down [17:22] * astron247 doesn't liek the icon smauel used for edit though [17:22] I'm with Astron that it should be at the bottom [17:22] * astron247 cant spell [17:23] <@hiok> bottom [17:23]  bottom of the animation list [17:23] 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] and obviously, we would use Gnome icons [17:23] alexanderW: we use a pencil in "Edit File" [17:24] 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] i dont think pencils make great icons at that size [17:24] I disagree [17:25] doesn't we have some "edit" icons somewhere in LO [17:25] ? [17:25] a) a pencil is not only used in LibreOffice for edit, it's the symbol Android uses as well [17:25] 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] hiok: that would be even more complicated [17:26] <@hiok> astron247: hahaha, that's horrid [17:26] 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] okay... maybe still we could use the wrench... [17:27] hiok: not as far as i know [17:28] b) I don't think a wrench works that well at small sizes either [17:28] 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] in any case, this icon wouldn't be tiny [17:29] 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] yes [17:30] we'll need to remove the paper, though [17:30] 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] 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] or would anyone else like to take this job? [17:31] hiok: I've never seen a pen used to symbolize edit [17:31] a pencil is a common convension [17:32] <@hiok> true [17:32] <alexanderW> I will [17:32] ok, great [17:33] so we've agreed to have a toolbar at the bottom of the animation list [17:33] 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] ok, bye [17:34] sorry, was afk for some time. bye rafael [17:35] == hiok [b18de303@gateway/web/freenode/ip.177.141.227.3] has quit [] [17:36] so, about removing the slide show button? [17:36] <alexanderW> Yes [17:36] slide show button with tabs to bottom? or the one on custo manim.? [17:36] if we have two: toolbar and tabs one, then third one is not needed [17:37] no other edits [17:37] so only the toolbar one [17:38] (if we put tabs down, i think there should be slide show button) [17:38] hm, would be good if the toolbar button were more prominent [17:39] medieval: as I said, that would be done after Apache OO implements it [17:39] yes [17:39] removing it then is ok from custom anim. [17:40] 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] would you agree with removing the slide show button from the sidebar even if it wasn't made more prominent [17:41] yes [17:41] ok good [17:42] 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] astron247: I agree [17:42] do others agree as well? [17:43] <alexanderW> yes [17:43] ok [17:44] what about removing the „Automatic Preview“ checkbox? [17:44] I personally am not sure about it [17:44] <alexanderW> I hate that flickering black background [17:45] me too [17:45] yes [17:45] I'd leave the checkbox in [17:46] turn this off always? [17:47] (and remove the tick box) [17:47] no, just keep the checkbox [17:47] it's useful to be able to preview your presentation [17:48] 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] whats the slideshow button good for then? [17:48] mirek2: yes, but libo has huge amounts of ui, so you would need to prioritise that [17:48] I thought we agreed on removing the slideshow button in favor of the one on the toolbar, no? [17:48] i mean the toolbar slideshow button [17:49] astron247: if anyone starts working on the sidebar, I would think that the mentor would recommend to just do it in .ui [17:50] 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] not sure how the button reacts now, but F5 now starts at the current slide [17:51] F5 isn't discoverable [17:51] in any case, we have disagreement, so the safest way to go is keep the current behavior [17:52] well then... [17:52] what do you think about putting the "Play" button in the new toolbar? [17:52] there should be room for it, and it would streamline the sidebar quite a bit [17:53] yes [17:53] great :) [17:54] I suppose we can move to my suggestions: https://wiki.documentfoundation.org/User:Mirek2 ? [17:55] what do you think of having a responsive layout for toolbar icons? [17:55] agree with both the suggestions for the main proposal and the optional enhancements: [17:55] ? [17:56] anyone? [17:56] kinda [17:56] useful, but sounds a bit hard... [17:57] really useful, actually. [17:57] could be a harder hack, then [17:57] a third extra point for hiding/showing important labels responsively... [17:57] ? [17:58] that's something to have after labels are implemented [17:58] 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] i like idea about changing size based on screen resolution [18:04] <alexanderW> It sounds good [18:04] 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] 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] ok [18:06] <mirek2_> "page toolbar" [18:06] 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] right, but ... what would be the use initially? [18:07] 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] 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] it would clog up your toolbars with things you rarely need [18:09] <mirek2_> but you have to go step by step [18:09] sure [18:09] <mirek2_> no, it wouldn't be shown by default [18:09] <mirek2_> so it wouldn't really clog anything [18:09] ok [18:10] <mirek2_> others agree as well? [18:10] 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] but, sure, ultimately it sounds great [18:11] mirek2, i dont believe there is such a thing as medium hacks [18:11] there are hard hacks, but thats anentirely different thign altogether [18:11] ^anentirely^an entirely; ^thign^thing [18:11] <mirek2_> right [18:12] (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] yes [18:13] 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] like that one [18:16] ok [18:16] but you should probably make a new mockup for this [18:16] <mirek2_> is a mockup really needed? [18:16] (that shows the functionality in a clearer way [18:16] ) [18:17] 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] 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] hm, mozilla has felxible placeholders for that... [18:20] ^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] (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] it would look like an unholy non-native mess ... but ive expressed that before... [18:29] i liek the idea [18:29] <mirek2_> astron247: do you think Google's implementation looks like an unholy non-native mess? [18:30] 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] it would be great improvement in style handling [18:31] 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] 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] 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] 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] yes, but i am worried about how these will look (and work) [18:35] <mirek2_> it's been tested in Google Drive [18:35] it isnt. [18:35] * should both areas have different colours [18:35] * how should the menu look (grey or white) [18:35] etc [18:36] <mirek2_> I would use white [18:36] <mirek2_> to be consistent with the style drop-down [18:36] 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] 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] ... [18:42] <mirek2_> ? [18:43] i was arguing that google's look wouldnt work for us [18:43] <mirek2_> I still don't see the argument though [18:44] the template manage looked good in a mockup, right? [18:44] +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] 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] please do [18:47] <mirek2_> in any case, you would agree with implementing it with a whtie background, right? [18:47] are you going to meet again soon? [18:47] sure. [18:47] <mirek2_> I could ask to meet [18:48] <mirek2_> ok, let's move to "Drag to Open Pop-over" [18:48] ok [18:48] 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] dont have a split button seems like an option [18:50] <mirek2_> is that really more intuitive? [18:50] 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] "inappropriate touching" ©ars technica [18:52] at the same time ... we have nothing at all [18:52] 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] 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] 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] 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] 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] 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] it takes time [18:59] especially, because libreoffice doesnt really interpret any touch events right now [18:59] 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] 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] ah right. [19:02] 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] 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] 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] yes [19:12] 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] one thing [19:13] <mirek2_> go ahead [19:13] 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] (paragraph mark, tab character etc [19:14] <mirek2_> a button to insert special characters? [19:14] i make quick screen [19:14] 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] remember this from office 2000, even [19:14] they should be more visible [19:15] 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] (visibility of that would solve it though) [19:18] 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] 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] yes, is there some discoverable list where i can see what options are available? [19:22] alex, are you pushing directly or are you going through gerrit? [19:22] medieval: press help in the find/replace dialogue [19:23] then click on list of regular expressions [19:24] <alexanderW> astron247: directly [19:24] https://help.libreoffice.org/Common/List_of_Regular_Expressions [19:24] ok [19:24] medieval: or that way :) [19:25] <mirek2_> astron, any updates from the ESC call? [19:25] anyway, regexps are not really understandable without a good tutorial [19:25] yes [19:26] 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] ... let me check the log again [19:26] it would be good when same are available as in mso [19:27] (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] 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] 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] why not implement color picker without colors in use ot themes now? [19:29] 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] but some ui doesnt make a lot of sense without the features [19:30] we can implement these later? [19:30] waht mirek said^^ [19:30] yea [19:30] ^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] 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] i guess [19:33] yes [19:34] thanks for lookigfn [19:34] ...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] alexanderW: what are you doing with config? [19:36] (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] 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] 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] alex, have you pushed already? [19:43] <alexanderW> The command is running [19:43] <alexanderW> yes [19:44] i see them :) [19:44] <alexanderW> Alright :) [19:44] <mirek2_> ok to end the chat now? [19:45] <alexanderW> Yeah [19:45] bye [19:45] 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] bye