Design/Meetings/2013-05-18

Attendees

 * astron
 * issa
 * mahfiaz
 * mirek2

Topics

 * Icons
 * Color Picker
 * Style Copying

Log
[16:08] anything new on the icon front? [16:09] have you talked to Mariano? [16:09] also, what about the shapes? [16:09] I've replied to Mariano but yet to discuss the details [16:10] ok [16:10] as for the shapes Norah sent me an svg for discussion but she couldn't make it herself [16:10] I'll upload it now [16:10] great [16:13] here it is http://www.upload.ee/files/3319375/shapesstencils.svg.html [16:15] thanks [16:15] upload it to Sparkleshare maybe [16:16] I feel like some of the icons are ok, some need work [16:16] fortunately, though, we can use some icons from the Inkscape icon set [16:16] https://git.gnome.org/browse/gnome-icon-theme-symbolic/ [16:16] that's why I didn't upload it to SparkleShare [16:16] it's just a wip [16:17] given that the whole theme is a wip, it's ok to upload to SparkleShare [16:17] sure [16:17] then I will need to make that simple guide to SparkleShare I was supposed to make earlier :p [16:18] :) ok [16:19] general feedback: [16:20] some of the icons go over the 16x16 square, so that'Đ be good to take care of [16:21] really? which? [16:22] for example, one of the text icons, the selection icon, ... [16:22] I'm sure there are more [16:22] some the icons use more colors than the gnome theme allows [16:23] it'd be good if it could use white space instead [16:23] oh ok [16:23] e.g. with the shape icons [16:23] it'd be good if icons from Gnome were utilized where possible [16:23] so that work doesn't have to be duplicated [16:24] yes the colors seem to be an error [16:24] and to fit better into the platform [16:24] I think they are [16:25] here's Gnome's other icon repository [16:25] https://github.com/gnome-design-team/gnome-icons [16:25] which is what I meant to link to earlier [16:26] there are icons for Inkscape, GIMP, and some Art Libre icons that can come in handy [16:26] yes I/we are aware of these [16:27] so, for example, for the "From file" icon, it'd be good to utilize Gnome's official "Insert image" icon [16:27] (the current LibreOffice icon doesn't make much sense) [16:28] for the select icon, it'd be good to utilize Inkscape's [16:28] true, I did use that in the gallery icon (not here) [16:28] <@mahfiaz> I wonder if it is reasonable to make these icons work on gray background as well [16:28] same for text [16:29] I think the select icon is the same as Inkscape's but stretched for some reason [16:29] mahfiaz: given that these icons are vector and monochromatic, they can simply be all recolored [16:29] issa: that's odd [16:29] yes, it does look stretch [16:30] stretched [16:30] I prefer the original [16:30] yes me too [16:30] and yes I think they can be easily colored later on [16:31] also, Inkscape has a Points icon [16:31] only Inkscape calls points nodes (that's the more common term) [16:31] tool-node-editor is the icon [16:32] mahfiaz: I think they already work on gray background, unless you mean a dark gray background [16:32] mirek2: but wouldn't it be better to stick with the LibreOffice metaphor? [16:33] I feel like Inkscape's metaphor is clearer [16:33] and, given that we also plan to redesign the default LibreOffice icons, it doesn't have to be inconsistent [16:33] cool [16:34] also, some of the icons don't align to a pixel grid [16:34] the callouts icons, for example [16:35] or the 3d box icons [16:35] they're quite blurry [16:35] yes I've noticed that [16:35] seems like the original shapes were taken and then just scaled down without caring for alignment [16:38] <@mahfiaz> icons of symmetrical shapes should never be stretched (such as the star of david or circle in "From file" icons) [16:38] icons in general should not be stretched in any way [16:39] also, there's an inconsistency in line widths [16:39] true [16:39] and roundness/sharpness [16:40] <@mahfiaz> there is a truckload of different arrow endings [16:40] e.g. compare the 3d box icon with 1px strokes with another shape icon [16:40] yeah [16:42] there seems to be a lot of inconsistencies in style altogether [16:42] would be good to see the icons in a grid, to see how they look together [16:42] the current layout is quite messy [16:42] and it seems like some of the symbols are just different takes on a single icon [16:42] <@mahfiaz> on the other hand, I don't think we need to go nuts with "exactly the same line width" everywhere or to remove the artist's touch at all [16:43] <@mahfiaz> s/at all/altogether [16:43] mirek2: yes some of them are [16:43] anyway, that's my preliminary feedback [16:45] noted, thanks :) [16:45] move onto another topic? [16:45] sure [16:45] I was wondering, have you started work on the hidden items menu easyhack? [16:46] not really [16:46] ok, I was just wondering [16:46] is there any topic you'd like to talk about? [16:47] nothing I can think of [16:47] ok [16:47] the color picker, then? [16:47] I'm currently away from the office, will go back next week [16:47] hopefully I can try to work on the HIM [16:48] sounds great :) [16:48] https://wiki.documentfoundation.org/Design/Whiteboards/Color_Picker [16:48] I updated my proposal a bit [16:48] should be much easier to access the palette now [16:49] https://wiki.documentfoundation.org/images/e/ee/Picker-mirek2.png [16:49] yes that seems way better [16:49] ok [16:50] should we pick up our conversation where we left off? [16:50] with our Recent colors dilemma? [16:50] alright [16:51] so, in my proposal, I put Recent as a tab under "Custom" [16:51] as neither palettes nor the theme require a recent section [16:52] that way, a person can quickly create an on the fly temporary palette for his document [16:52] it kind of lose its purpose as a tab [16:52] and, with Recent being a whole tab, it can hold many more colors [16:53] but the idea of having recent colors is for quick access [16:53] isn't its purpose to be able to get to custom-defined colors that would have otherwise been lost? [16:53] yes, to get to them quickly [16:53] a tab can hold many more icons than a small section [16:54] you can get to them quickly if you keep the "Recent" tab open [16:55] yes but it isn't as visible [16:55] I mean it's not "always there" [16:55] so you'd propose having them as a row below the custom sliders? [16:55] instead of the HEX box? [16:55] yes [16:56] == astron247 [~frootzowr@dslb-088-074-248-148.pools.arcor-ip.net] has joined #libreoffice-design [16:56] hm, ok [16:56] I suppose we could have a tab for HEX on its own [16:56] not instead, the HEX box should be there too [16:56] yes [16:56] oh, ok [16:56] or maybe :p [16:56] so to the left of the hex box, then? [16:56] hi astron [16:56] discussing the color picker [16:57] or beneath it [16:57] https://wiki.documentfoundation.org/Design/Whiteboards/Color_Picker [16:57] hello astron247 [16:57] while i dont really know what youre talking about: the hex value is another representtation of RGB, so it would make sense to put both on the same tab [16:57] hi all [16:58] so, with the layout I proposed, there's the problem of scalability [16:58] all sections should have the same height [16:59] it's not really a problem for themes. which the design bases its height on, or with palettes, which always have different amounts of colors so there's no ideal height there [17:00] but it does mean that the custom section should either be carefully laid out or, if that's impossible, scrollable or moved into a dialog, sacrificing the speed of access [17:00] which is acceptable in Writer, but perhaps less acceptable in Draw [17:01] at least, if we ever want that module to be a true vector editor [17:02] so... thoughts on this? [17:02] hm, right now its raison d'etre is that it supports impress and impress is an important component [17:02] (~more or less) [17:02] yup [17:02] but it could be much more if the UI was there [17:03] personally, i dont think we need draw – there should be better import of inkscapes svg format perhaps instead [17:03] the lack of quick access to color is killing it [17:03] but thats just me [17:03] mirek2: true that [17:03] anyway, i cant look at the current version of the mockup sinvce it "contains errors" (ff's words, not mine) [17:04] https://wiki.documentfoundation.org/images/e/ee/Picker-mirek2.png [17:04] really? [17:04] I'm on Firefox and it renders fine [17:04] ah, oh... [17:04] i thought we were talking about one of kevins versions [17:04] this one is fine [17:04] oh, ok [17:05] it's not a tentative design, just an update of my proposal [17:05] not sure if Kevin will be working on the design anymore, though [17:05] haven't heard from him in a while [17:05] <@mahfiaz> although the old/new bar is stylish, will this turn out that nice as a custom widget? [17:05] mahfiaz: hah good question [17:06] i would not bet money on the answer being yes [17:06] :) [17:06] so, looking through my mail, I noticed that Kévin did respond [17:06] about a month ago [17:06] but I haven't responded to his mail yet [17:06] must've missed it [17:07] ohk. that was after my last mail to the list, i guess [17:07] :) [17:07] one of us should probably respond... [17:07] anyway, that's another topic we should discuss [17:08] should the color preview be clickable? [17:08] what would that do? [17:08] <@mahfiaz> somewhere was a note or discussion that it would act as okay or cancel [17:08] I would say no, as the only time where its clickability makes sense is in the Custom section and only on the Old button [17:09] in which case it would undo the changes made to the color [17:09] unless it will open a custom color dialog like other graphics programs it shouldn't be clickable [17:09] I agree [17:09] <@mahfiaz> will clicking the old color undo the changes? [17:10] <@mahfiaz> without closing the dialog then? [17:10] I think that was Kévin's proposal [17:10] you can read through the mailing list archive to be sure [17:11] my opinion is that the preview should stay a preview [17:12] btw, why do we have a color preview above the colours and one below? [17:12] and adding affordances to show that the preview is really a button would lead to an inconsistent look [17:12] astron247: what do you mean? [17:12] the rectangle at the top shows the automatic option [17:13] <@mahfiaz> that would be no problem if the colors are previewed when hovers them [17:13] sorry... [17:13] when the color picker reaches the next stage, the top area will serve as a tab bar, letting you choose the auto option as well as single color, gradient, etc... [17:13] (at least that was the idea) [17:14] ok [17:14] btw, what are your thoughts on the clickability of the color preview? [17:15] i dont think it should be clickable. [17:15] <@mahfiaz> issa? [17:16] but tbh, i dont like the design ~at all for various reasons.and the preview below is just one more thing that bloats this [17:16] <@mahfiaz> oh, issa already said it shouldn't be clickable [17:16] astron247: alright, what do you see as the problem areas? [17:16] mahfiaz: yes :) [17:17] * the large popover completely overpowers the little button [17:17] * the navigation is confusing (theme/pallette/custom is at the bottom, but recent/hsl/rgb is at the top) [17:17] * i still hate the idea of doing custom colour selection in a popover [17:18] what little button? [17:18] the toolbar button? [17:19] also, if i'd have to think about how to explain the diffeence between themes and palettes to my mom, i am pretty sure i would be unsuccessful [17:19] astron247: I'm still indecisive about having custom color in the popover, especially since it will only benifit Draw [17:19] mire2: little button _> yes, the toolbar button [17:20] the thing with themes vs. palettes -- there needs to be a clear distinction [17:20] (if you find spelling errors you may keep them...) [17:20] is there something that you feel could make things clearer? [17:21] one thing I feel makes things clearer is labeling [17:21] well, the theme is chosen elsewhere, while the palette can be chosen in the popover, right? [17:21] yup [17:22] Theme Palette - Other Palettes [17:22] that's kind of comparing apples to oranges, though, as you can't mix themes and themes and palettes serve a very different purpose [17:22] <@mahfiaz> could the theme be just the palette selected by default? [17:23] a theme is not just a palette [17:23] i was think of a combined palette picker instead – which would also rid us of the bottom tabs [17:23] presenting it as a palette would be confusing [17:23] as I said, themes are not palettes [17:24] and as we discussed a while ago, it's dangerous to mix theme colors and non-variable colors [17:24] ie, a picker combo box with: [17:24] "Colours from my theme" (default) [17:24] --- [17:24] "Tango palette" [17:24] "Whathaveyou palette" [17:25] hm, i see your point – but the current state does not make it better [17:25] "Colours from current theme" would actually be better [17:25] or "Theme Colors" [17:26] from my pov, it's worse -- it makes it sound like the colors are constant [17:26] theme colors sounds like the colors are variable [17:26] i.e. they're not just copied over from the theme, they're actually within the theme [17:26] so, my proposal that includes the word "current" makes it worse while issa's proposal (while nice and short) makes it better? [17:27] your proposal could work as well, but it lacks a quick switch between variable and constant colors, which could lead people to use theme colors for everything [17:27] well, people can easily switch between themes and palettes [17:28] astron247: from my pov, yes, as your wording sounds like they're constant colors of the same shade as the theme colors [17:28] astron247: switching from a drop-down take much more time and effort than simply clicking a large button [17:28] mirek2: what sounds like that? [17:29] i give you the second point. [17:29] but its not like you should be doing that too often [17:29] "Colours from current theme" -- sounds like the software took the theme colors, copied them into a palette, made them constant [17:29] really? [17:30] that's what it sounds like to me [17:30] theme colors is clearer in my opinion [17:30] astron247: you might switch quite frequently if you have several documents open [17:30] clearly i am biased here – are there other opinionsß [17:30] <@mahfiaz> I think maybe we should leave the theme colors to not be so prominent, that's what InDesign calls color swatches and while it is useful in some cases, it may confuse the regular user when he changes the theme and the nice green and brown tree turns to purple and blue (or have I misunderstood the feature?) [17:30] ? [17:31] given that the picker settings aren't tied to the window, but are application-specific (I could be wrong) [17:31] mahfiaz: you understand the feature well [17:32] but the feature is quite useful when working with documents or presentations [17:32] they're so useful, in fact, that MS Office makes them much more prominent than constant colors [17:33] mirek2: if you have several documents open, each of them should have its own picker settings – just as each document may have its own document theme etc. [17:33] ok [17:34] still, I would prefer faster access to palettes [17:35] right left arrows instead of a combobox :p? [17:36] right and left arrows would, in this case, be quite ambiguous [17:36] you wouldn't know what you're getting [17:36] <@mahfiaz> will the automatic turn into none if automatic is already selected (so it's toggling button)? [17:37] re: left/right arrows:indeed - but since you wont get anything applied immediately ... it might work [17:37] mahfiaz: automatic and none are used for different objects [17:37] (automatic = text; none = text background/highlight) [17:38] could you two propose a design, then, please? :) [17:38] <@mahfiaz> Issa already did :) [17:38] <@mahfiaz> so it's astron247's turn [17:39] whats my turn? [17:39] proposing a complete colour picker design? [17:39] actually I could update to mine to be consistant with what we agreed on [17:39] *update mine [17:40] sounds good [17:40] <@mahfiaz> astron247: that was supposed to be with some funny tone, but it appears IRC ate it [17:40] mahfiaz: ok... [17:40] issa: also, please make it touch-compatible [17:41] sure [17:41] and, pretty please, don't mix theme colors and constant colors :) [17:41] <@mahfiaz> about the automatic/none, since objects and panels can have styles, then both choices are useful [17:42] mirek2: then I won't make one :p [17:42] go ahead, make a proposal [17:42] btw... a problem i just thought about: how do we show when a colours is in one of the palettes that are installed/active, but not in the currently selected one? [17:42] I think a combo box like what astron247 is suggesting sounds good [17:42] be aware that I'll always actively argue against having theme colors together with constant colors, though [17:43] :) [17:43] astron247: good point, I guess we can't [17:43] astron247: which brings us back to recent colors! [17:44] astron247: do you think it's necessary to have that? [17:44] the same color may be present in several palettes... [17:44] I know mirek2 will disagree but I think it should appear in the recent colors [17:44] issa: the current color isn't always a recent color [17:45] in fact, the recent colors may not be used in the document at all [17:45] mirek2: well, i was just thinking about it... not sure if we strictly needed, and it would definitely be nasty to switch to a different palette just for that reason [17:45] they may just be artefacts from people trying to find the right color for e.g. a rectangle [17:45] mirek2: true, but only if it was recent it has to be quickly selectable [17:45] s/needed/need that/ [17:47] astron247: for what reason? to find the current color? doesn't it make sense to have a color grabber for that use case instead? [17:48] or did you just want the user to be able to see the current color? in that case, that's what the color preview was for [17:48] well, for one, it would be cool to be able to go back and forth between old and new (even if the old one was not in a palette); for the other, it would be cool to see the colour in context of its palette [17:48] but ... yeah... [17:48] mirek2: it should appear in the custom color [17:49] issa: right. [17:49] astron247: "in context of its palette" -- are you suggesting that LibreOffice register the name of the palette a color is in along with a color? [17:50] (scanning palettes for a color wouldn't work, as a color can easily belong to several palettes) [17:50] (e.g. think of how many palettes have pure red) [17:50] i hoped wed know all the colours that are in palettes – of course with some like black/white/grey it will be hard to find an appropriate palette... so, i guess, yes, we would have to store the palette name or iD too... [17:51] i didnt think about it too hard [17:51] in documents from third parties, the color may not even be in a palette... [17:52] ...which brings us back to a document palette [17:52] ok. [17:52] despite of what someone said a while ago about it being hard to scan the document colors, Kendy told me that it shouldn't be hard [17:52] if we really want a document palette [17:53] (and I don't see any reason for why we shouldn't have it) [17:53] well, its probably not hard, but i could imagine it not scaling well [17:53] (but then you dont want hundreds of colours in your palette) [17:53] there are a lot of palettes that don't scale well [17:53] there are palettes out there with hundreds of colors [17:53] scale well = i meant performance [17:54] I think you are overthinking things a bit! [17:54] <@mahfiaz> when I copy over a drawing from draw, I wouldn't like all the colors show up in the palette [17:54] I'm sure a competent dev should figure out how to make it scalable [17:54] right [17:54] after all, LibreOffice can support, what, a million cells in a spreadsheet? [17:55] issa: re your overthinking comment: mirek or me? [17:55] mirek2: of course, still every second you add to loading a document means more grumpy users [17:55] astron247: both, with the color pallette id and things like that [17:55] *palette [17:56] issa: right – in fact, i didnt want to seriously make that proposal... [17:56] astron247: the palette doesn't have to be loaded with the document [17:56] it can be loaded when you open it in the color picker [17:57] hm, right. you could create it when opening the picker [17:58] I think Kendy said that the document colors are stored in a separate section of the XML [17:58] ok [17:58] I personally don't think we need such a thing [17:58] not sure if he was talking about ODF or OOXML [17:58] or perhaps both [17:59] I think recent colors is enough for that purpose even though they aren't exactly the same thing [17:59] they're not at all the same [18:00] I know I've previously wasted all of the Recent colors spots finding the right color for something [18:00] mirek2: odf currently has no implementation or spec of document thems, afaik [18:00] definitely not good when you need to reaccess a specific color over and over [18:00] astron247: I know [18:00] I was talking about document colors, not theme colors [18:01] ah, well. i suppose i can look into a document [18:01] mirek2: fair enough [18:04] so, I guess you can make a proposal and we'll discuss it next week? [18:04] yes [18:05] astron247: if you need the beginning of the chat, it's on http://piratepad.net/O8XuLryVJN [18:05] other topics you'd like to discuss? [18:06] <@mahfiaz> mirek2: I'd like to add a note about your font repository integration mockup [18:06] go ahead, though be aware that I need to rework it [18:06] I'm not happy with a lot of things about it [18:08] <@mahfiaz> the "Document fonts" and "Install fonts" buttons kind of double themselves in font list and in character dialog (where it is especially bad since there is only a few lines for fonts list left) [18:08] <@mahfiaz> they both kind of open font manager anyway (I suppose) [18:10] <@mahfiaz> so the "install missing fonts" button could be dropped, user already knows about the problem from the infobar which s/he closed [18:12] <@mahfiaz> nothing else, otherwise I like the idea very much :) [18:12] "Install fonts" is not the same thing as "Install missing fonts" [18:12] "Install fonts" was intended as a way to install fonts from Google Fonts [18:13] I didn't mock it up yet, btw [18:14] it might be good if it has the same functionality as "Add fonts" in Google Drive [18:14] and I now realize that "Add fonts" would be a more appropriate name [18:15] (btw, such a dialog would be useful to streamline the font list, as it's a mess on most systems right now) [18:16] <@mahfiaz> these dialogs might end up pretty similar, it feels like consolidating these into one is natural (but who knows, maybe not :) ) [18:16] if you think so, you're welcome design them :) [18:17] or, rather, it [18:17] in your case [18:17] <@mahfiaz> I am tight on time due to my thesis, so I will skip this one [18:18] ok :) [18:19] given that nobody's working on the feature, it doesn't really matter, though [18:19] any other topics to discuss? [18:19] <@mahfiaz> not from me [18:19] me neither [18:20] <@mahfiaz> astron247? [18:20] yes? [18:21] <@mahfiaz> would you like to discuss anything? [18:21] we could discuss template copying again [18:22] ok, sure [18:22] also, id like to make you aware of the new stepped lines option for calc diagrams [18:22] https://wiki.documentfoundation.org/Design/Whiteboards/Copying_Styles_from_Templates [18:22] ah, didnt notice you did somethign there [18:23] looking quite good, actually. [18:24] of course, it would be more than cool if you could also mockup how to integrate this with existing ui [18:24] anyway: thanks! [18:24] astron247: [18:25] what exactly do you mean? [18:25] it's triggered with a simple entry in the styles menu [18:25] well, the whole flow [18:25] would be interesting to see [18:25] hm..., I'll see [18:25] maybe I will [18:25] i know – maybe it seems unimportant to you, but its not [18:26] it doesn't seem unimportant, but my time is limited and I think it's explained quite clearly in the description [18:26] ok. [18:26] right [18:27] I think it'd be good to have the name of the file along with a file selector at the top of the theme selector, though [18:27] something I should add, imho [18:28] ok [18:28] though not sure if there should be two slightly different dialogs for themes and files [18:28] ok. [18:29] astron247: were you able to make it for the ESC call? [18:30] no, sorry [18:30] ok [18:30] if there are no more topics, then I guess we can end the chat [18:30] (i was roped into another call at that time) [18:30] ok [18:30] https://wiki.documentfoundation.org/ReleaseNotes/4.1#Calc [18:31] please check point 2 – from this list, if you have a nightly somewhere [18:32] check how? [18:32] not necessarily. [18:32] but if you have input, you may wnat to address it to ux-aadvise [18:32] i have yet to get to do that [18:33] (i gave some input before) [18:33] it seems like a fairly simple matter [18:33] I might take a look at it [18:33] right, but he added a new dialogue box [18:33] not making any promises, though [18:34] so, it would be good to review that a bit [18:34] the "Properties..." one? [18:35] yes [18:36] ok, I might take a look at it