ken300 wrote:Colomar - another quick question:

From an earlier post of mine that was overlooked:

I'm not sure that this is what you want or not but i noticed this:

In the Neon 5 ISO suggested there's a small issue that is only an issue with Breeze, not Oxygen - when you go into System Setting > Device Actions and you edit or create an action, a pop-up appears. On that pop-up the box titled 'Devices must match the following parameters for this action', when you're using the Oxygen theme feels plenty big enough & holds just over 7 lines of text - but with the Breeze theme it's (i think) a bit too cramped and only holds just under 3 lines.

Add to the notepad or bug report??

Please add it to the notepad for now. Thanks!

Make sure your application works with at least 1024x768px, which is the minimum for KDE SC.

"On what DPI, font settings, UI Style, icon size configuration?"
And why XGA? XGA screens? What about panel struts (shrinking the available area)?
What if application A was < XGA on oxygen but is now > XGA on breeze? Who's got to fix that?
What if i've bad sight and set the font size to 24pt?

Would it make more sense to recommend a maximum amount of visible items ("don't put 20 checkboxes on one page")?

I randomly just saw:
"Modal dialogs must not be resized."

File dialogs are typically modal dialogs...
And what would be the reason for this requirement itfp
Should it rather be "error messages" than "modal dialogs"?
Why does the *modality* make a difference / is more important than the content?

luebking wrote:On what... And why... What if...

The HIG on a minimal application size was basically written to avoid applications that require a high resolution. All criticism on this guideline is valid. But please consider that at least for dialogs we demand: "Make sure there is at least one third white space, do not overload the panel."

So the question is how to improve the HIG. What do you think would be a better wording, is there need for more cross-references, what kind of advice would be really helpful?

This one commit: https://git.reviewboard.kde.org/r/120448/ will have fixed several.

We'll have to go through them next ISO.

Heiko Tietze wrote:So the question is how to improve the HIG. What do you think would be a better wording, is there need for more cross-references, what kind of advice would be really helpful?

The question in return (on this very item) is about the reason behind the XGA maximum.
If the goal is to ensure all KDE applications can be maximized on XGA screen, the inconveniernt truth™ is that this cannot be guaranteed by application developers, since they're not in control of the final size, nor the actually available screen space.

You may demand to fit into 1024x736px [sic!, 32px for a panel and the titlebar is not very much] for 96dpi, breeze style and 10pt DejaVu.
The questions are then what this helps you if the last XGA screen user in question uses 12pt or the breeze++ style has bigger margins etc.

Thus i'd only give a general advice and make clear that this is heuristically and a minimum size of 1024x768 is no good idea since it will usually/often already fail.

Keep in mind, that not everybody sits in front of a 4k screen.
KDE seeks to support down to XGA (1024x768) resolutions.
The available screen area will typically also be shrunk by panels and the window titlebar and the users fonts might be slightly bigger than yours (for configuration or higher DPI) and his style may add more whitespace.
You therefore should ideally preserve ~10% to catch those variables and try to not exceed 920x690px with <link to default setup>.
Also notice that a huge minimal size often implies a large count of <link to "do not scare the user> items visible at one time.

Of course XGA could be replaced by WXGA, SXGA or similar.

luebking wrote:Keep in mind, that not everybody sits in front of a 4k screen.
KDE seeks to support down to XGA (1024x768) resolutions.
The available screen area will typically also be shrunk by panels and the window titlebar and the users fonts might be slightly bigger than yours (for configuration or higher DPI) and his style may add more whitespace.
You therefore should ideally preserve ~10% to catch those variables and try to not exceed 920x690px with <link to default setup>.
Also notice that a huge minimal size often implies a large count of <link to "do not scare the user> items visible at one time.

That's okay, but to me a little bit too verbose. How is about a simple:

Make sure your application can be resized down to at least XGA (1024x768px) resolutions without loss of functionality.
or
Make sure your application does not require more than XGA (1024x768px) resolution to work properly.
(It's a minimum size; we don't want to scare the 4K guys off.)

On the other hand, we run into the same trouble with a short text. Perhaps an explanatory sentence makes sense.

The major aspect is, that this requirement *cannot* be fulfilled for sure.

To the application developer, the style as well as the user configuration and setup (notably dpi) remain variables.
The style could not alter the layout.

So the best thing you can do is to make the application developer aware of the situation, point things to account for and provide a rule of thumb "how to make it likely be ok".
That does not guarantee the XGA limits are met, but the developer will be aware of the problem and try to get the GUI more compact (than long in either direction), evtl. consider to split items and use a tabwidget etc.

Doing this a dt/dd that describes the intention and then informs the devloper is certainly a good way to structure the information.

Window size: We seek to support XGA!
Keep in mind, that not everybod ...

Please also keep in mind that this addresses developers, not end users.
It's imo better to be verbose than ambiguous in this context (to get what you want)

Steering back to the original topic:
We have identified five KCMs that have a default size too small to hold all content with Breeze widgets now.
What should we do in order to get the situation fixed before 5.1? File individual bugs for each one? Or just one asking to make the initial size for kcmshell bigger? And if so: How big?

See Davids post - kcms in multidialogs should be fixed by this commit:
https://git.reviewboard.kde.org/r/120448/

Haven't tested, but looks absolutely reasonable.

Apologies for taking this off-topic again - but IMO we should just say 'make your KCM X pixels by Y pixels and make it work with the Breeze theme'. The user needs to accept some responsibility for their own system, if they've changed the font size or theme etc. i think it should be up to them to live with the odd unnecessary scrollbar or to have to change the window size themselves.

I think we should just try and get it looking perfect out of the box and nothing more. This guidance still needs adding to the HIG even if the SySe window size has been increased or we'll have similar issues in the future.

the patch does not statically increase the window size but ensures that the required size is calculated after all kcms have been added.
this (scrollbars) issue is not related to the HIG off-topic, the required size can be calculated at runtime for every possible setup.

the HIG discussion was about the minimum window size (cannot be shrunk below - there are no scrollbars) being demanded to "fit an xga screen", what is not possible to ensure.
font is btw. also chosen by distros and the rasterized size depends on the users display dpi.

ken300 wrote:Apologies for taking this off-topic again...

I moved the discussion whether or not to change the HIG to the guidelines mailing list. I believe we follow luebking's recommendation, but want to wait with the update for Thomas' reply.

I'm not subscribed to kde-guidelines but am absolutely fine with the suggested text (saw it in the archive)