This is what the current 32px version with arrowheads added looks like, but it can't be done like that with 16px or 22px.

@ngraham Here's something similar to what you asked for:

Is there any tutorial about how to build our software to Windows and put it to Windows Store?

In D19694#434169, @ngraham wrote:

I was talking about the problem of small monochrome icons in the sidebar itself, not in the tooltip. But anyway since then I fixed the tooltip too.

Any more VDG or Plasma opinions on this?

In D7700#382897, @ngraham wrote:

Bugs found:

• If there are no tags, creating one does not cause the Tags section to appear in the Places panel until Dolphin is restarted.
• If the Tags section is already visible because there are already some tags, creating a new tag does not cause that new tag to appear in the Tags section until Dolphin is restarted.

It fails here w/ 5.9.4 in the tests and .7 was the current so that's why I picked it.

I was talking about the problem of small monochrome icons in the sidebar itself, not in the tooltip. But anyway since then I fixed the tooltip too.

Ping? Any opinions regarding what I wrote in https://phabricator.kde.org/D17167#383242?

Nah.

Doesn't make sense; @nicolasfella's new Places Panel section makes more sense to put in once it's ready.

Could someone from the Promo team please check the proposed schedule and give feedback?

Thank you @Bollebib,

The spacing change is clearly correct. As for the width change, we should match the exact calculation used for the other combobox we're trying to match, which is width: theme.mSize(theme.defaultFont).width * 24. Otherwise they'll drift out of sync when formAlignment changes or the next time Kirigami.Units.largeSpacing is modified.

I'm interested in solving the problem you brought up. We do in fact have a common, re-usable component in the QML side with Carl's recently added component. Creating one on the QTWidgets side would be good too. I'm always in favor of high-level controls with semantic meaning, e.g. "this is a search field" rather than "this is a text field that we happen to be using as a search field by doing all this stuff so it over and over again". Then we can use the same control everywhere and control the behavior and appearance in just one place.

I think I'm still off by a pixel, will test better tomorrow.

In T10258#179103, @ngraham wrote:

In T10258#179033, @aacid wrote:

Hey, i was sent here from https://phabricator.kde.org/D19773#433272

I have some questions:

• This task says "labels throughout Plasma" but then I'm seeing patches to Cantor, Okular and other non Plasma software. Is this on purpose?

Looks like someone changed the task title to be more appropriate since you asked this question. I think the intention was always to make them consistent throughout KDE Software.

aaa

Yes, sorry :)

They should all go into the build dir IMO.

xxx

In D19812#434089, @ngraham wrote:

Thanks, it compiles with CMake now! \o/

I'm not a fan of how it dumps all this stuff in the source directory. Ideally it would put everything to the build directory when doing an out-of-source build so the source dir isn't cluttered up with transient and rapidly-changing information. Then you also wouldn't need to add these files to gitignore.

Thanks for all these nice Yakuake patches, Lionel!

Agreed, repeating information in the placehodler that is already avaliable in the label doesn't seem to make much sense to me either

Add context to i18n calls

OMG I love this one! +1000 shipit!

Abandoning due to the impending overhaul of notifications.

LGTM

Thanks, it compiles with CMake now! \o/

maximize didn't work very well.
now it's resizing again, but using a different saved geometry.

• Merge branch 'master' into arcpatch-D18818
• don't maximize

In D19812#433941, @guoyunhe wrote:

In D19812#433916, @ndavis wrote:

Could you use #eff0f1 and #31363b for the light and dark backgrounds since those are the colors we normally use for window backgrounds?

Like this?

I don't have much time now, so if someone want to clain this task instead you are welcome.

In D19311#433917, @hallas wrote:

I couldn't help spending a little time looking more into this arrow stuff :D I have tried to adjust the down arrow so that it is much smaller and put in the lower right corner of the button, also it doesn't change the size of the button. I guess a screenshot says more then a 1000 words:

@ngraham - What do you think? Is this closer to what you have in mind? Also, should I post a new review where we can discuss this issue?

aaa

Makes sense, thanks. This fix works and looks sane to me.

BTW, I'm not sure how it could possibly be related, but the placesitemmodel test has started consistently failing after this commit went in: https://build.kde.org/job/Applications/job/dolphin/job/stable-kf5-qt5%20SUSEQt5.10/30/testReport/junit/projectroot.src/tests/placesitemmodeltest/

aaaa

generic

coco

• Rebase on master
• Specify tooltip timeout
  • The documentation says -1 is the default, but apparently that wasn't working. With -1 expicitally specified, the no devices warning tooltip does not time out

In D19844#433980, @elvisangelaccio wrote:

Sorry to be pedantic, but we are fixing two different bugs, right? Would it be possible to split this patch into two commits?