Design/Meetings/2013-12-22
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
Attendees
- astron
- mahfiaz
- mirek2
Topics
- Non-native Theming Guidelines
Log
[11:52] <@mahfiaz> mirek2: getting ready for the chat? [11:52] <mirek2> yup [12:04] <mirek2> mahfiaz: do you want to talk about something today? [12:13] <@mahfiaz> mirek2: nothing in particular. You? [12:13] <@mahfiaz> (what about you? not topic named you :) ) [12:13] == mode/#libreoffice-design [+i] by mahfiaz [12:14] == mode/#libreoffice-design [+o mirek2] by mahfiaz [12:15] <@mirek2> I wanted to cover the proposed non-native theming guidelines, but given the lack of attendees, perhaps it's better to move it to next week [12:16] <@mirek2> the proposal is at https://wiki.documentfoundation.org/User:Mirek2#Non-native_Theming [12:16] <@mahfiaz> mirek2: sounds reasonable [12:19] <@mirek2> since we're waiting if others will show up, care to give your opinion on the proposal? [12:20] <@mahfiaz> about the minimum size, maybe not all people resize windows down to 100×200 px, but I have actually used e.g calc like this (removed all toolbars and extra stuff so it shows only a couple of cells of final calculation result while the other window of the same document is larger where I modify the data [12:21] <@mirek2> ok, good to know [12:21] <@mahfiaz> that was my only fear about reading the minimum size, that someone would make that size required to be sure the application doesn't look crippled or something [12:21] <@mirek2> yes and no [12:22] <@mirek2> the window should never have a size at which it's unusable [12:22] <@mirek2> which means a required minimum [12:22] <@mirek2> but also some responsiveness [12:23] <@mahfiaz> but then again without toolbars it still is usable at that size (even though the toolbar might not be entirely visible) [12:23] <@mirek2> right -- that's true [12:24] <@mahfiaz> but I do understand that making sizes below the minimum impossible to have likely benefits more people [12:25] <@mirek2> any opinions on the non-native theming side of things? [12:28] <@mahfiaz> is the idea that non-native widgets will be same everywhere or conform with the platform they are running on? [12:29] == mode/#libreoffice-design [-i] by mahfiaz [12:30] <@mirek2> non-native widgets would be the same everywhere [12:31] <@mirek2> but they wouldn't be a standard [12:31] <@mirek2> they'd only be used in the listed scenarios [12:31] <@mirek2> where native theming produces worse results [12:36] <@mirek2> thoughts? [12:37] <@mirek2> (btw, the mockups aren't binding, and given that we're working on a flat icon set, and might even be mixing flat and Tango, the widgets might be flat instead) [12:38] <@mahfiaz> the whiteboard mentions windows menubar, would that mean that all linuxes would have that custom menu look as well? [12:39] <@mirek2> no [12:39] <@mirek2> that part refers to the current state of things [12:39] <@mirek2> we have a custom menu+toolbar background on Windows, because most of Microsoft's own apps don't carry the default platform look [12:40] <@mirek2> on other platforms, native theming fits in, so we use native theming there [12:40] <@mahfiaz> okay, that makes a lot of sense :) [12:43] <@mahfiaz> changing icon sizes depending on the screen size is interesting, but would be rare on desktop [12:43] <@mahfiaz> I don't recall any program which would do that, do you know any? [12:44] <@mirek2> the ribbon resizes its icons based on window size [12:44] <@mahfiaz> oh, that one :) [12:44] == atrons [bc60c4c3@gateway/web/freenode/ip.188.96.196.195] has joined #libreoffice-design [12:44] <@mahfiaz> the sizes are in two steps? [12:44] <@mahfiaz> hi atrons [12:45] <@mirek2> iA Writer resizes all contents based on window size: http://ia.net/blog/bringing-responsiveness-the-app-world/ [12:45] <atrons> hi there [12:45] <@mirek2> atrons: hi [12:45] <@mirek2> we're talking about the non-native theming guideline proposal [12:45] <atrons> the channel seems to have been invite-only for some time... [12:46] <atrons> (i tried around 20 minutes ago already) [12:46] <@mirek2> the log so far: <piratepad link> [12:46] <@mahfiaz> atrons: sorry about that, it was my mistake [12:47] <@mahfiaz> but I'm glad you are finally here [12:47] <atrons> well, ok [12:47] <@mirek2> when you're done skimming over the log, please give us your opinion on the proposed guideline [12:49] <atrons> so, i think on mac, the impress tabs look fine... [12:50] <@mirek2> the idea was to match the icon set [12:50] <atrons> (because, inceidentally, mac tabs look like your mockup) [12:50] <@mirek2> (more the upcoming refreshed one than the current one) [12:50] <atrons> ^ceide^cide [12:51] <@mirek2> and the tabs are floating because the native non-floating tabs aren't suited for the scenario [12:51] <atrons> were talking about non-native theming? [12:51] <@mahfiaz> correct [12:52] <@mirek2> (if you look at the tabs in Gnome, the tabs just oddly float in space in Impress, with little visual connection between the tabs and the area they apply to) [12:52] <atrons> i dont get what icons have to do with widgets [12:52] <atrons> right. [12:53] <@mirek2> the guideline covers when to use non-native theming [12:53] <atrons> so, where do the icons come in? [12:53] <@mirek2> if it can't match the platform, it should probably match something else in the UI [12:55] <@mahfiaz> in gnome the impress tabs are simply missing a line at the bottom, as it seems to me, but buttons would be just as good [12:55] <@mirek2> the obvious candidate here is IMHO the icon set, as it's the same on every platform [12:56] <atrons> icon set != widget... to me, so far [12:57] <@mirek2> atrons: yes, but just like macOS windows were themed to fit with Macs, widgets that can't or shouldn't be themed based on the platform standard should be themed consistently with the icon set [12:58] <atrons> oh ok... i guess i get where you are going: you want different non-native widgets to be possible for every icon set. [12:59] <@mirek2> atrons: actually, I'd prefer if we had just one default icon set [12:59] <@mirek2> (with an option to install others, of course) [13:00] <atrons> but you want the widgets to be delivered in the same folder as the icon sets [13:00] <atrons> (or something like this) [13:01] <@mirek2> not particularly [13:01] <@mirek2> btw, you do realize we already use widgets that are not themed natively [13:01] <atrons> rulers e.g. [13:01] <@mirek2> (the problem with those is that they look really dated on just about any platform) [13:02] <@mirek2> tabs next to scrollbars [13:02] <@mirek2> additional scrollbar buttons [13:02] <@mirek2> panels [13:02] <@mirek2> etc. [13:02] <@mirek2> (as for the icon set, I'd love something along the lines of http://spiceofdesign.deviantart.com/art/Writer-Concept-351501580, using a mix of Tango and Symbolic icons) [13:03] <@mahfiaz> maybe the round 1 should be then to revamp the looks of existing custom widgets [13:04] <atrons> mahfiaz: sounds good [13:04] <@mirek2> yes, but it'd be good to have a guideline first [13:04] <@mahfiaz> true [13:04] <@mahfiaz> we might make different choices if we know where we are headed [13:05] <@mirek2> (you could argue, for example, that native tabs could be used for sheets in calc) [13:05] <@mirek2> (I would argue that those would feel out of place, just like the Impress tabs we have now) [13:06] <@mahfiaz> unfortunately there are no upside down tabs in native widgets AFAIK [13:07] <atrons> mahfiaz: i dont think thats true [13:07] <atrons> but the bigger problem with native tabs there is the colouring [13:07] <atrons> (it is possible to use background colours for differentiating between calc tabs) [13:08] <atrons> and that would not be supported by native widgets anywhere [13:08] <@mahfiaz> astrons, thank you about a hint, I didn't know it even existed [13:09] <@mirek2> what are your thoughts on the current Impress tabs? [13:10] <atrons> mine? [13:10] <atrons> i think theyd look better with a line below them [13:11] <atrons> and i wouldnt hope for anything better to come out of non-native tabs [13:12] <@mirek2> brb [13:12] <atrons> (yes, your mockup looks great, but it just wont come out of the machinery like that) [13:16] <@mirek2> sorry, I'm taking a bit longer than I thought, feel free to come up with a guideline while I'm gone, I'll give my thoughts when I come back) [13:16] <@mahfiaz> mirek2: I hope to see you back soon :) [13:19] <@mahfiaz> atrons: I agree that custom widgets should be avoided when possible [13:21] <@mirek2> I'm back [13:21] <atrons> well, i wouldnt be against them, but there never will be enough developer time to devote to pixel-perfecting some custom widget [13:22] <@mirek2> atrons: why do you think so? Chromium has been able to pull off non-native tabs incredibly well [13:22] <atrons> and making it look ok on multiple platforms [13:22] <atrons> yes, but this is libreoffice [13:22] <@mirek2> and often fit in much better with the platform than Firefox, which actually tried to look more native [13:23] <atrons> maybe. still: this is with the project structure and the developers of libreoffice [13:23] <atrons> and the code of libreoffice, too [13:23] <@mirek2> yes, I'm definitely not expecting to get beautiful non-native widgets in the next release [13:24] <@mirek2> (that said, we are able to pull off button-like tabs on macOS, so that's not an impossibility) [13:25] <atrons> because those are _native_ there [13:25] <atrons> and have you ever used libreoffice on mac? i havent. [13:25] <@mirek2> yes, I'm just saying it's technically possible, i.e. the code allows it [13:25] <@mirek2> atrons: yes [13:26] <@mahfiaz> atrons: I used it once on my brother's laptop, most of the time I spent figuring out shortcuts [13:26] <atrons> but its not really our code, its macOS's code that does most of it. [13:26] <@mirek2> (my mother owns an older Macbook, so I've had opportunities to try it out) [13:27] <@mirek2> atrons: really? I would think VCL would do most of the heavy lifting [13:28] <@mirek2> (I even think LibreOffice bases the appearance of tabs on an older macOS version, but I'm not sure) [13:28] <atrons> well, maybe it is responsible for centering the tabs, but apart from that it asks macos's apis things like: can you give me a bitmap of that widget with that text on it in approximately that size [13:29] <@mahfiaz> so is the new question this: if we can have native button-like tabs on mac while having tabs everywhere else, should we have it different there? [13:29] <atrons> mirek2: why do you think that? i thought all of VCL's own widgets were based on win-95 style [13:31] <@mahfiaz> (maybe we should include a ui dev next time who could give some insights) [13:32] <@mirek2> atrons: (I think I read that somewhere; I might be wrong though) [13:32] <atrons> mahfiaz: in that case wed need to do the chats on a week day [13:33] <atrons> i mean between mon-fri [13:37] <@mirek2> anyway, about the guidelines: if a certain developer can't design a widget well enough, we'll have to stick with native widgets there for the time being [13:37] <@mirek2> however, that doesn't mean that we should leave the possibility of non-native themed widgets off the table, because a skilled developer might come along to work on them [13:40] <@mirek2> so, let's go through the guidelines and see where we don't agree, shall we? [13:41] <@mirek2> Non-native theming should be used: For widgets that don't have an equivalent in the standard toolkit. [13:41] <@mirek2> I think this is a given, given that there's no way to theme these widgets natively [13:41] <@mirek2> (as there's no native equivalent) [13:41] <@mirek2> perhaps it could be worded better, though [13:41] <@mirek2> thoughts? [13:42] <atrons> tbh, one could also try to work around using a certain widget] [13:42] <atrons> which where feasible should be done [13:43] <@mirek2> I wouldn't say it should be done where feasible [13:43] <@mirek2> we should really consider each scenario separately [13:44] <atrons> why not? it leaves room for improvement while making less work to implement [13:44] <atrons> and thus being friendlier to the attention most new features receive [13:45] <@mirek2> (e.g. I'd rather have a non-native custom color picker where you can click on colors than just a series of entry boxes where you input RGB/HSL values) [13:46] <atrons> ok. right. [13:46] <atrons> point taken [13:47] <atrons> although id rather have an inefficient colour picker with too-large native buttons than somethign which e.g. is not keyboard accessible [13:49] <@mirek2> ok [13:49] <@mirek2> are we agreed on "Non-native theming should be used: For widgets that don't have an equivalent in the standard toolkit."? [13:49] <@mahfiaz> I like the wording as it is, it's not the law [13:52] <@mahfiaz> atrons? [13:55] <@mirek2> atrons: do you agree with the wording? [13:56] <@mahfiaz> okay, maybe add an only there: [13:56] <@mahfiaz> Non-native theming should only be used: For widgets that don't have an equivalent in the standard toolkit. [13:56] <@mirek2> it's not the sole guideline, though [13:56] <@mirek2> I'm going through parts of the guideline piece by piece [13:57] <@mahfiaz> it changes it from being encouraging to discouraging [13:59] == mahfiaz changed the topic of #libreoffice-design to: Discussion of LibreOffice design ideas https://wiki.documentfoundation.org/Design [14:02] <@mirek2> atrons: feedback? [14:09] <@mirek2> mahfiaz: so you're saying to keep the guideline as short as possible? [14:09] <@mirek2> shouldn't at least the windows look be part of the guidelines [14:09] <@mirek2> ? [14:12] <@mahfiaz> mirek2: explanations are fine, as long as they are clearly distinguishable as explanations or secondary information, but in general as short as possible seems to be the way to get people to read things in full length [14:13] <@mirek2> The "design" portion could be much shorter [14:13] <@mahfiaz> also in cases of disagreement of the guideline additional information about the decision could help to respect it, but this again is secondary [14:14] <@mirek2> also, the examples given could be shortened to fit on the same line as the parent bullet points [14:14] <@mirek2> inside parentheses [14:15] <@mahfiaz> I am not sure if that would be better [14:15] <@mirek2> I'm not sure about that either [14:22] <@mirek2> hm, wonder where astron has gone... [14:23] <atrons> sorry... [14:23] <atrons> was downstairts [14:25] <@mirek2> so, do you agree with the "Non-native theming should be used: For widgets that don't have an equivalent in the standard toolkit." part of the guideline? [14:26] <atrons> i guess. [14:27] <@mirek2> so... that's a yes? [14:27] <@mirek2> if not, what would you change about it? [14:28] <atrons> I DONT WANT TO CHANGE IT [14:28] <atrons> sorry [14:29] <atrons> for the caps [14:29] <@mirek2> ok, next up: "When native theming feels out of place. " [14:30] <@mirek2> (feel free to offer better wording) [14:30] <@mirek2> the example given are the current Impress tabs [14:33] <@mirek2> do we all agree on that part? [14:35] <@mirek2> thoughts, anyone? [14:40] <@mirek2> if you'd like, we can skip this part... :) [14:44] <@mirek2> mahfiaz: atrons: are you still there? [14:44] <@mirek2> should I assume you don't like that part, take it out, move to the next one? [14:51] <atrons> yes [14:51] <atrons> i am still here. [14:51] <atrons> but i will go now. [14:51] <@mirek2> so leave it up to next week, then? [14:52] <atrons> well, i think you should write the guidelines as you see fit, and seek a lazy consensus instead of making every meeting take hours [14:52] <atrons> sorry. [14:52] <atrons> bye [14:53] == atrons [bc60c4c3@gateway/web/freenode/ip.188.96.196.195] has left #libreoffice-design [] [14:53] <@mirek2> :) ok [14:54] <@mirek2> given astron's view, do you agree with the rest of the guidelines? [14:54] <@mirek2> If so, I'll add the non-native theming guideline to the wiki right now [15:05] <@mirek2> mahfiaz: are you still there? [15:05] <@mahfiaz> mirek2: just got back, I'm reading once again all the other points on that document [15:07] <@mahfiaz> I like the page toolbar idea since I use writer for book layout, something similar to InDesign's would be useful indeed [15:08] <@mirek2> I just meant the non-native theming guideline [15:08] <@mirek2> can I add it to the guidelines? [15:09] <@mahfiaz> mirek2: I agree on these [15:10] <@mirek2> ok, great :) [15:10] <@mirek2> shall we end the chat? [15:10] <@mirek2> (I'll upload the log) [15:10] <@mahfiaz> let's call it a day [15:10] <@mirek2> ok [15:11] <@mahfiaz> also merry christmas, if this means anything to you :) [15:11] <@mirek2> merry christmas to you too :) [15:11] <@mahfiaz> :)