Jump to content

Special:Badtitle/NS90:Talk:KDE Visual Design Group/HIG/Units/History of the discussion in telegram for this article

From KDE Community Wiki
Revision as of 07:25, 15 September 2017 by Fabian (talk | contribs) (New thread: History of the discussion in telegram for this article)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This discussion happend in Sep 2017 in Telegram

fabian there a 2 main "units" in qml for units.smallSpacing and units.largeSpacing

Thomas Pfeiffer A supergroup for a small discussion? Okay...

fabian otherwise users that join later can't eread the whole history the problem (in my opinion is) the largeSpacing is the (internal) base unit and smallSpacing is calculated from it and the smallSpacin = Match.floor(largeSpaing / 4) so eg Eike has 18 and 4 I get 20 and 5 you could have 16 : 4 or 22 : 5 ... the ratio between smallSapcing and largeSpacing is not constant it is changing depending on the remainder of the division by 4 of largeSpaing spacing* I would recommend to use only smallSpacing and to forget about largeSpacing? or should we ask plasma devs to try what happens if largeSpacing is always 4 * smallSpacing ? I really don't like to recomend using largeSpacing if the ratio changes on each monitor btw draft to a hig page about it: https://community.kde.org/KDE_Visual_Design_Group/HIG/Units of cause icons have their own way of scaling, totally independent of both, so it's a design nightmare either way :)

Thomas Pfeiffer Do you know why units.largeSpacing exists? Since usually some multiplier is used with smallSpacing anyway, just having another unit which is 4x the size would not be all that useful, would it?

fabian It would kind of recomend that if you need a larger spacing its * 5 and not * 3 or * 5 its * 4* so would you recommend, from a ui perspective , that it's ok, to use both units small and largeSpacing, even if the ratio changes. don't get me wrong, if that's the predominant opinion on it, i will write it that way in the hig, regardless of my own opinion. and as long as no more people join, I would take your opinion as the predominant one :)

Thomas Pfeiffer I wasn't expressing any opinion Okay, I was, but it was more of a "This is what it looks like to me right now, but I'd like to understand it better" I'm the wrong person to make any decisions regarding visual things, or code things. As I'm no expert in either of them

fabian I was kind of hoping that some more people would join, I just invited you and jens because you need 3 people for a group and telegram client was suggestion the 2 of you

Thomas Pfeiffer I think it just got lost in the stream of text. Just invite people personally that you think would have a valid opinion

Alex L I'm not sure I understand what we should discuss

fabian qml is supposed to have 2 base units. smallSpacing and largeSpacing . these 2 are ppi independent and are supposed to be used by developers as base for pretty much all values eg if a developer wants to specify a rectangle it should not be Rectangle { 

 width: 20
 height: 40

} but Rectangle { 

 width: 5 * smallSpacing
 height: 10 * smallSpacing

} or Rectangle { 

 width: 1 * largeSpacing
 height: 1 * largeSpacing

} since the px in Rectangle { width: 20 height: 40 } are physical pixels and not ppi indepedent pixels, they don't scale on different dpi settings when trying to write the HIG entry I noticed that the ration between smallSpacing and largeSpacing is not constant

Alex L Why just don't use one unit that at 96 dpi is equal to 1px?

fabian yes thats what pretty much everybody uses by now (a ppi/dpi idenpendent pixel), but since kde supports older versions of qt , which don't support it, that's not an options for developrs for design and mockups that's not a problem! we can use 1px all we want, as long as we know, that we are talking about scalable pixels

fabian now my question is, if we should recommend to only use smallSpacing and forget about largeSpacing since the ratio between these 2 change depending on the dpi? Andres (Andy) Betts

fabian now my question is, if we should recommend to only use smallSpac That might make sense. Is largespacing being used anywhere now?

fabian I have no idea. but thats what d_ed told me that plasma is/should be using as base units

Andres (Andy) Betts Is he on this chat?

fabian no he is on irc only :( maybe we can discuss it on irc?

Andres (Andy) Betts We are talking about David Edmundson right?

fabian yes

Andres (Andy) Betts He is on Telegram

fabian oh I didn't know, my bad could you pls invite him?

Andres (Andy) Betts Let me try

Andres (Andy) Betts hat David Edmundson eingeladen

Andres (Andy) Betts I added him, I think we can invite @DavidEdmundson to explain this further

David Edmundson Explain what? From a high Dpi perspective, pixels are fine if they're needed.

However from an everything else perspective, if you hardcore something as 12px to put some text, and a user happens to use a different font it'll look ridiculous. For spacing, that's maybe not so important, but for something like a delegate height it is.

fabian my main question was, if it makes sense (from a design point of view) to only recomend the usage of smallSpace, but not to use largeSpace. because the ratio of the two are monitor dependend that is, if I read the code correct

David Edmundson Are they? :/ The other option is we change that ..

fabian https://cgit.kde.org/plasma-framework.git/tree/src/declarativeimports/core/units.cpp?id=4f48901b05fd9e543c958561543f19f617c0b177 thats the code for generating the 2?

David Edmundson Ah, it's max(large / 4, 2) Ok

fabian if changing it does not break everything I am for changing it, because to me it makes no sense from a design point of view but since the design apparently is not depended on a fixed ratio between the 2, I would be quiet optimistic, a change would not break (too much)

David Edmundson Ok Andres (Andy) Betts My hope is that at least with changes, our applications Don't look bigger. That they look the same or smaller But something I didn't understand was what changes when we use largeSpace?

fabian Andres (Andy) Betts My hope is that at least with changes, our applications Don't lo in some setups application should get a little bit less spacing (is largeSpace is used at all). but on other monitor setups nothing changes.

fabian Andres (Andy) Betts But something I didn't understand was what changes when we use l I updated the HIG draft https://community.kde.org/KDE_Visual_Design_Group/HIG/Units . Could you take a look if that explains now better why units.smallSpacing is used / needed ? @DavidEdmundson could you please take a look if I got all the facts correct?

David Edmundson Oh, that looks like exactly what I was trying to say! Awesome.

Andres (Andy) Betts Thank you, that makes it very clear

Jens Reu fabian nicely done!

fabian Thx!

fabian @DavidEdmundson do you know what gridUnit is supposed to do and if it is used at all?

Eike Hein It's probably the most used UI API we have yeah Plasma UIs are supposed to size UIs on the grid

fabian ok, then we can not change largeSpacing without shredding everything :( since largeSpacing = gridUnit

Eike Hein for example just from my direct awareness, the default sizes of stuff like Kicker and Kickoff is set in grid units, the entire layout of dashboard is based on it, etc etc gridunit is for sizing and aligning things, *spacing is for things like inside margins and so on or in-between spacings of lists

fabian ok, so if one would change largeSpacing you would have to change gridUnit too

Eike Hein i'm not sure it's important largeSpacing and gridUnit are the same

fabian would it be hard for you to test what happens on your screen if you would change largeSpacing = gridUnit = smallSpacing * 4

Eike Hein should be pretty easy to do do you have time to write the patch?

fabian that's what I have on my screen, so it should not be total disaster i could write a patch but I have no idea how the whole commit process works

Eike Hein that's fine just send it to [email protected] or pastebin it here i mean for testing because i'm juggling a lot of balls right now so don't have the headspace to change the code

)

fabian actually I think you only have to change one number https://cgit.kde.org/plasma-framework.git/tree/src/declarativeimports/core/units.cpp line number 257 change the 2 to 4

David Edmundson What, no That code keeps the size even Changing that to a 4 keeps it...something random.

fabian while (gridUnit % 4 != 0) { 

   gridUnit++;

} ? sorry my c++ coding skills are pretty much none existent

David Edmundson Ok, well making that a multiple of 4 is definitely doable.

Eike Hein i think his goal is largeSpacing = gridUnit = smallSpacing * 4

David Edmundson Yeah. Currently small is large/4 But with rounding that's not the same thing as the top one. Makes some sense to me

fabian yes I think it would be better to base the whole system on the smallest unit, and deduct the large ones from it. that way the ratio between them stays constant

David Edmundson I fear it may be problematic, it means the font is now a different size than the largeSpacing/gridUnit, which means things are aligned in weird ways. https://phabricator.kde.org/P101

fabian ok

David Edmundson Edit: working patch: https://phabricator.kde.org/P102 I still dont' really understand what problem we're trying to solve.

fabian on my setup its 20 / 20 / 5 on eike heins its 18 / 18 / 4

Thomas Pfeiffer The problem is that the ratio between smallspacing and largespacing is currently slightly different between screen sizes Designers need pixel perfection for their designs to really work

David Edmundson fonts are selected by the user. languages (and so text length) is slected by the user. Icon sizes are selected by the user. No matter what you change in spacing you will never be able to make a pixel perfect mockup

Thomas Pfeiffer We have default sizes for everything though

fabian but you can aim to deliver pixe perfect layout for the default values

Thomas Pfeiffer And if those default sizes are well-chosen, chances are the vast majority of users will keep them as they are Especially if things look less good when they change the values

fabian but you can aim to deliver pixe perfect layout for the default v This.

David Edmundson If you start doing that, as soon as you encounter a German your design will become instantly broken.

Thomas Pfeiffer Not every part of the UI contains text

David Edmundson and if you need to hardcode a pixel, hardcode a pixel

Thomas Pfeiffer A device-independent one? We'd love to just use device-independent pixels for most things, but we keep being told by you guys that we should use gridunits and smallspacing instead

Eike Hein as mentioned if you want to hardcode "a pixel" you can use Units.devicePixelRatio and Math.round() it

fabian Rectangle { 

   width: units.largeSpacing
   height: units.largeSpacing
   color: "black"

   Rectangle {
       x: units.smallSpacing
       y: units.smallSpacing
       width: units.smallSpacing
       height: units.smallSpacing
       color: "white"
   }

} the inner rectangle will look nicly centred on my setup but not on some others oh well it won, but you get the point :) Rectangle { 

   width: units.largeSpacing
   height: units.largeSpacing
   color: "black"

   Rectangle {
       x: units.smallSpacing
       y: units.smallSpacing
       width: 2 * units.smallSpacing
       height: 2 * units.smallSpacing
       color: "white"
   }

} now it does

Eike Hein that's not how you would do this though Rectangle { anchors.fill: parent; anchors.margins: units.smallSpacing } done that said i get how making things divisable is generally a nice property yeah

Thomas Pfeiffer So, how about this: We design always in pixels, you guys make sure things look exactly like in the mockups in English with default values, independent of the screen resolution and DPI ? I feel that designers trying to come up with solutions for implementation is not very effective We shouldn't even care how it's done, as long as the result is correct

Eike Hein if you're assuming that (a) designers will not write qml code (which imho they should) and (b) designers are ok with designs changing minutely in the transition, then yeah but the guide fabian is writing is also useful for whoever ends up writing the code designer or not so it's still something worth working out

Thomas Pfeiffer Yes, the HIG part is certainly useful! The HIG is written for both designers and developers, anyway What I mean is that if you guys (devs) are sure that the system for the grid units you currently have is adequate for producing pixel-perfect implementation (with default values), then we should believe you. And maybe you could directly edit the HIG and insert code examples for how to achieve what we aim for from the design side

fabian that's actually only part of the problem. we do want to have consistent spacing and paddings in mockups as well as in the actual code. so designers must? use some concept of smallSpacing and largeSpacing

David Edmundson Mockup for what anyway?

Thomas Pfeiffer fabian that's actually only part of the problem. we do want to have con How is this supposed to work, though? Inkscape doesn't know arbitrary units. Inkscape knows pixels.

fabian maybe we can just define smallSpacing = 4 and largeSpacing = 16 for mockups, drafts, ...

David Edmundson Sure

fabian maybe I should try to add to some hig entries a guide how to convert a mockup into code that might be a good help for new developrs and it would show designers what is important ina mockup, and what does help developers

Thomas Pfeiffer In theory, every HIG was supposed to contain code examples

fabian ok, I will give it a try, Units is aparently one of the most important aspects for that anyway and if designers and/or devs don't like it we just remove it

Thomas Pfeiffer I'd put that in the examples section of the spacing and alignment guidelines Because those are the ones that should be dealing with this fabian and if designers and/or devs don't like it we just remove it I see no reason why anybody would dislike having examples ;) "Hey, here is an example:" "Go away, I don't want your example, I want to figure it out all by myself goddammit!" <- Unlikely dialogue to ever happen ;)

Eike Hein i know a kde dev who recently reimplemented flickable because he didn't like the qt one when i asked him he told me "you will love this code if you like automata theory" never presume lack of weirdness

David Edmundson But with examples note we do have 3 different toolkits on the go currently..

fabian qml, kirigami and qwidgets?

David Edmundson Effectively

Plasma, QtQuick (widget themed) and qwidgets.

Thomas Pfeiffer The idea was to have the classic HIG focused on QWidgets and the Kirigami HIG focused on QtQuick

David Edmundson Ok

Thomas Pfeiffer For Plasma, we'd actually need its own HIG Because many things are different in Plasma vs. applicaiton development

David Edmundson Including spacing! fabian

google introduced dp as the label for density independent pixels https://material.io/guidelines/layout/units-measurements.html maybe we could use that too for distinguish what we are talking about Units & measurements - Layout [Bild] Andres (Andy) Betts Thomas Pfeiffer How is this supposed to work, though? Inkscape doesn't know arbi I think it uses pixels and points. But the default is pixels.

fabian I added a section "From design to code" to the HIG entry, could you take a look at it? Is something like that helpful? Any suggestions how to improve it? and is the code ok that way?

fabian updated the hig entry, added some more examples and updated px values for smallSpacing and largeSpacing to the correct values, if you use our default font settings feedback welcome

fabian [Bild] @DavidEdmundson @eikehein what I do not understand how one is supposed to align controls to the grid. all controls have different heights does every control needs it's own Item container with a multiple of units.largeSpacing as height?

David Edmundson It does not

fabian so controls just don't align?

David Edmundson You don't know how big the theme elements are on the user's system as you don't know what theme they're using So you can't design assuming that you do

fabian ok, then I will change the HIG entry about placement accordingly

Thomas Pfeiffer I disagree We should not let flexibility get in the way of doing good design Things should be aligned with Breeze, because as said before, that is what the vast majority of users are going to use If things look less good with other themes, that's a pity, but I think having things look 100% good with Breeze and 70% good with other themes is better than having them look 80% good with any theme

fabian the problem probably is that breeze controls have very different height. and these heights are not multiples of the gridUnit

Thomas Pfeiffer Breeze is what we use in screenshots, Breeze is what the vast majority of distros use by default

fabian and I don't think we can change the height in breeze controls without breaking everything Thomas Pfeiffer

fabian the problem probably is that breeze controls have very different Well then either we need to adapt the controls or the grid

fabian for qWidgets there is a QFormLayout that aligns the controls to a grid? maybe something like that could be possible in qml as well? Andres (Andy) Betts What is the spacing in the grid?

fabian units.gridUnit = 18px on a default setup with normal dpi = 18px dpi independent

Andres (Andy) Betts I see

David Edmundson If something should be aligned state it should be aligned. Draw a line in the mockup, perfect.

If you try and fake it being aligned by guessing pixels without telling us, after we have user settings and translations and hidden items it won't be. Regardless of what margins are.

Andres (Andy) Betts I see That is good to know. I should be more aware of my mesurements That is why I need to know these things because I can recreate them in my svg editor, I can change the size of the grid and alignment Or use guides to place the content in the right spots

David Edmundson Just leave any guide lines in, the more semantic data we have the more we can understand what the design is. Yep

Andres (Andy) Betts Ok

Thomas Pfeiffer David Edmundson Just leave any guide lines in, the more semantic data we have t That sound like a sensible approach indeed

Andres (Andy) Betts Actually, I remember when David asked me for the measurements for the bootup sequence and I had to measure from border to border to where the object was. The svg editor I have right now has all that built in so it is a snap to show that information

fabian I still don't understand how you would align the controls in qml to the base grid.

David Edmundson Just leave any guide lines in, the more semantic data we have t I will add some more advice for designers what to add in their mockups

Andres (Andy) Betts I think that would be helpful, especially when we enter the production stage it's when the work gets real! haha, enough of pretty pictures!

fabian I added some advice already to the units page

Andres (Andy) Betts Great So fabian have you seen the discussion of making a new HIG website?

fabian in the main room?

Andres (Andy) Betts What are you thinking? Should we tweak wikis to include a global menu or do what others say to create a new website? Yes

fabian please can we keep this room to discussion abut units/measurements/... i'll reply in the main room

Andres (Andy) Betts I know, that's why I asked you. So that we can have some replies in the main room ;)

fabian @anditosan @Colomar maybe we need to ask ourself first what we actually would like to be able to align to the grid. I tried to align the top left corner of the bounding of the components to the grid But that already inches padding for some components Eg the checkbox Maybe we would rather align the center?

Andres (Andy) Betts Oh for sure, and be aware that maybe a lot of this is not defined. Defining that could be like restraining designs but I think we can talk about the major elements in a design and how they should align

Thomas Pfeiffer I'll let you guys figure that out, not my area of expertise ;)

Andres (Andy) Betts Oh! @Colomar I can't live without you! You know it! hahaha I will do my best

Eike Hein He was a rogue combobox. Used to staying off the grid. --Breeze Noir

Andres (Andy) Betts lol

Thomas Pfeiffer

joy:

fabian Thomas Pfeiffer I'll let you guys figure that out, not my area of expertise ;) who's area of expertise is it?

Thomas Pfeiffer Andy's and yours, I suppose?

Andres (Andy) Betts I think this is purely UI/UX work that's why Thomas says that

Thomas Pfeiffer Both of you have done visual design stuff

Andres (Andy) Betts Basically we are defining what the visual element placement is for buttons, margins, etc So UI

Thomas Pfeiffer My area is interaction design. When it comes to visual design, I can tell you if I find something ugly or not, and be very vocal about it, but that's as far as it goes for me Well, not exactly true: I know the Gestalt laws so I can tell you why things are or are not seen as belonging together, but the aesthetics part I know only from the very theoratical side

Andres (Andy) Betts and by the way @Colomar I will need your help a lot when working with the redesign for syse, stay tuned.

fabian I think, we would actually like to align the baseline of the text in the components to each other ? Andres (Andy) Betts Sure Should we do a screen share some time?

fabian sure, we can do that (even though I have no idea how to do something like that :) )

Andres (Andy) Betts Google Hangouts can do it, I think Thomas Pfeiffer Or Jitsi Or OpenTok

Andres (Andy) Betts I have to see what you mean, I don't think I will understand everything by talking here Oh true, I liked Jitsi

fabian [Bild]

Andres (Andy) Betts So are you aligning the font to the grid line? and the buttons around it centered to the font?

fabian I didn't do anything, except adding a line to my screen from earlier. that is what happens when you align breeze component on the top

Andres (Andy) Betts Oh ok I think we need to have a shared screen conversation, hehe Not today though, but maybe this weekend?

fabian ok

Andres (Andy) Betts Thanks fabian [Bild] if I didn't screw up in qml that's the dimensions and the text alignment of plasma breeze components as you see the text aligns very nicely

David Edmundson Looks like checkbox has a bug..

fabian no I actually think checkbox might be fine, because you want to have them as a list most of the time

David Edmundson Baseline offset should still match though? Where do these dimensions come from?

fabian I create them in qml from the width and height of the items text = Math.round(item.width * 100) / 100 + " x " + Math.round(item.height * 100) / 100;

David Edmundson Oh, didn't expect to see some of that

fabian to me it seems that Label RadioButton Slider seem to be off by 1px (1.2px??) that's what I'm doing: https://cgit.kde.org/scratch/fabianr/HIG.git/tree/Placement/Test.qml and outline is messured and drawn with https://cgit.kde.org/scratch/fabianr/HIG.git/tree/Outline.qml remember that code is just create screenshots, so don't scratch out your eyeballs when looking at it ;-)

David Edmundson Oh, there's loads of stuff.. I like the generator you made And you have mad canvas skillz. I don't get why you're explicitly importing a style?

fabian Probably copy and paste I have no idea why

fabian @DavidEdmundson do you think my measurements are correct? or did I do something wrong? David Edmundson If that's what it says it is, that's what it is. Though note these are the implicit sizes not definitive sizes.

fabian implicit sizes? you mean they vary depending on font, dpi, theme settings?

David Edmundson Well, for one the width of the label will be bigger if the text is longer. fabian I'm only talking about the height

David Edmundson Label also does something weird. Put it in a grid, that height changes

Andres (Andy) Betts You have to think that we use different sizes of text in the interface. Maybe we can determine how the text looks in relation to checkboxes or buttons!

fabian https://community.kde.org/KDE_Visual_Design_Group/HIG/Units added more guidelines for designers and small improvements

fabian so back to my problems with the spacing / grid alignment of controls: [Bild] [Bild] as I see it we can either use the recomended margins (units.smallSpacing and units.largeSpacing) as in the first img or align it to the grid, as in the second image the HIG states at the moment to do both at the same time, but I don't see any way that can be done so I think we need to choose one. I personally would opt for the first one

David Edmundson The hig also says one should use a gridlayout Which is either a third conflict? Or makes this a non issue

fabian how would a GridLayout solve the problem that all controls are not a multiple of the baseUnit? I think you can create both screenshots with a GridLayout depending on the Grid.spacing.

David Edmundson Well, it fixes the two column issue I agree, it would be better if all components were the same size I don't think it has anything to do with margins, or grid units.

That's just them not being the same size. fabian ok, I think we cross talked a bit. Sometime chat just @@@@ :/ forget the right side just look at the left side the first one hast units.smallSpacing / units.largeSpacing as margins between the controls => no alignment to the base grid the second one hast strange margins (6px / 24px) but aligns to the grid it's not about the implementation, both could easily(?) implemented. but what do we want from an ui point of few units.smallSpacing / units.largeSpacing as margins or alignment to the base grid because I think we can't hace both

David Edmundson We normally do small spacing. We don't really "align to the grid"

fabian ok, then we should just remove that part from the hig at least for components

David Edmundson I don't think it has anything to do with margins, or grid units. and yes that probably would be nice ;-) but if we don't align to the grid and only work with margins, it would matter much will not matter much*

David Edmundson Yeah I think remove it, it's more a concept of things being similar sizes not globally lining up.

Andres (Andy) Betts We have so many different controls that are different that are usually going to clash with grid alignment. I agree with Dave here. Aligning may work most of the times but it will also be challenged by the differences in the controls

Retrieved from "https://community.kde.org/index.php?title=Special:Badtitle/NS90:Talk:KDE_Visual_Design_Group/HIG/Units/History_of_the_discussion_in_telegram_for_this_article&oldid=78517"