In T11665#201378, @ngraham wrote:

In T11665#201377, @mglb wrote:

Adding border to all toolbar buttons will be super heavy in cases where there is more than a few buttons.
To do changes like this I think we should separate concept of classic toolbars (few toolbars, each with many buttons/controls) and modern "widgets row" (few controls visually aligned with window/content). Or just use QToolButtons with disabled autoRaise to get the border on them.

Yeah, I agree that this would be totally inappropriate for e.g. LibreOffice or FreeCAD with have huge toolbars stuffed to the gills with unlabeled toolbuttons (whether it's ever a good idea to do this in the first place is left for another discussion...). I was thinking about our apps, really.

In terms of changelogs, you can already use the FEATURE: and CHANGELOG: tags in your commit message. That's already there and similarly we're not actually using it. Might it make sense to develop better documentation around using those throughout all of KDE?

In T10243#201333, @ngraham wrote:

In T10243#201329, @alex-l wrote:

EDIT: I have already said this here and there but please don't run any automated script to SVG icons, because when opening them back in Inkscape they are corrupted and everytime I edit a Breeze icon I have to do additional work to fix shapes and gradients corrupted by the scripts.

This is something you should bring up in the VDG chatroom and discuss with @ndavis in particular as we currently make heavy use of these scripts for optimization purposes. Hopefully we can come up with a solution together.

+1 lgtm

In D24068#534280, @ngraham wrote:

Is this Conventional Commits spec something we think we want to use elsewhere? I'm sure I can get used to it, but the prefix thing seems kind of rigid and I'm wondering what it really adds other than a bunch of process that will need to be explained over and over again to each patch submitter.

Is this Conventional Commits spec something we think we want to use elsewhere? I'm sure I can get used to it, but the prefix thing seems kind of rigid and I'm wondering what it really adds other than a bunch of process that will need to be explained over and over again to each patch submitter.

I for one use this :)

rebase

Too late, what's pushed is pushed (no force-push allowed, it would break existing checkouts with non-pushed work on top).

belated +1

• Grammar fix

Updated tabbed UI with clearer groups.

• Add period
• Change or to and

Makes sense?

In T11665#201377, @mglb wrote:

Adding border to all toolbar buttons will be super heavy in cases where there is more than a few buttons.
To do changes like this I think we should separate concept of classic toolbars (few toolbars, each with many buttons/controls) and modern "widgets row" (few controls visually aligned with window/content). Or just use QToolButtons with disabled autoRaise to get the border on them.

Adding border to all toolbar buttons will be super heavy in cases where there is more than a few buttons.
To do changes like this I think we should separate concept of classic toolbars (few toolbars, each with many buttons/controls) and modern "widgets row" (few controls visually aligned with window/content). Or just use QToolButtons with disabled autoRaise to get the border on them.

vk.com/@ilyandl-novosti-kde-pim-za-iulavgust-2019

If you don't like the proposed vertical toolbar, that's okay, but then we're going to need to sort out a lot of tricky UI issues for the horizontal toolbar and have perfect icons.

I already tested the version without icons.
Worked as expected

I started to fill-out the Submission 1 form.
Any help welcome.
After all is filled out, we can pick some build to use.

Ok, how about KConfigDialog ?

In T10243#201370, @alex-l wrote:

I don't think glasses will ever look good at small sizes, can't we use something else for Okular? A clip? A highlighter?

Awesome job, Eric!
I've tested it with simulators and everything looks good. Having the HFR-values displayed makes it much more transparent what the focusing algorithm does.

Thanks. Along with the area filter, it's really more stable than the single-star focus procedure in my opinion (with my setup in fact).

Thanks so much for the patch, Jason! Feel free to keep on submitting more if you encounter any further issues.

@yurchor Can you please check the i18n in this patch? I do recall we were advised against using "%1 is foo bar" format before but I'm not sure.

1. Advanced tab .. maybe we should rename this to "Parameters"?

That would make "Settings" and "Parameters". Maybe I should replace "Settings" with "Basic" if I move some stuff in from "Advanced"?
I'll try to move stuff around. I would expect for instance SEP parameters to get a new tab.

Updating D24048: Inline styles from k.o/products/kirigami moved to aether-sass

@ltoscano The plus sign does not work.

+update to only add Qt5Core check

In D24062#534157, @vkrause wrote:

Nope, it's a CMake setting, default is OFF, ECM sets it to ON. So this is actually still relevant and in use.

Oh, and I removed years from dates to compact the view even more.

Dawn and dusk offsets tested over two nights, work as expected (this change is actually far simpler than the UI stuff...).

Also slightly changed the Option dialog creation so that the dialog is effectively prepared before modules connect signals to it.

Manager dimensions restricted to 796x568, to leave room for window manager decoration and remain under 800x600.
Rehauled the Scheduler UI completely, removed ALL size specificities, and had the layout manager do its job on its own for the entire UI.
Qt layouts are nice, but one need to trust logic and hierarchy, not Qt Designer views.

Here is a first version:

I don't think glasses will ever look good at small sizes, can't we use something else for Okular? A clip? A highlighter?

In D23849#534169, @ngraham wrote:

+1. Do you wanna commit this, or should I?

+1. Do you wanna commit this, or should I?

on the other hand, after checking that the dials keep the old appearance when "wrapping" is turned on, and since dials are rather seldom used anyway, I have no strong feeling against the change (still prefer the old look though)

In D23849#534154, @romangg wrote:

Or let's just get it in. It's a small change and we still have the beta phase to test it.