Just to clear up my point
On the subject of why it's important:
Generally phones have a lot less real estate to show information, so that means it's likely that an app that is optimized for touch will have multiple views
be it hamburger menu/bottom nav bar or something else.
And that's why you frequently need to go back from the view to the main screen for example
And because every app places back button in a different spot/doesn't have any
it becomes a chore
that's why a universal back button is so important (and present in iOS/android/winPhone)

Some important notes:

One day?

Well Qstyle is had to make thus stuff like kvantumn. So this will help quite a bit

I think the image gallery (or image/video) app must be like Piktures is for Android.

One idea I've been throwing around recently is using the Plasma theme for apps too, by making the QStyle load Plasma theme SVGs. This would eliminate the potential problem of Plasma dialogs having a different appearance from apps, because all of them would be using the same theme in the first place. It would also allow a single theme to apply to the entire system, producing a major consistency win, and these newly-all-encompassing systemwide Plasma themes are share-able via GHNS, which is not currently possible using binary QStyle widgets themes. In so doing, the Breeze QStyle would be essentially transformed into a theme engine. Alternatively I suppose we would fork it into a new one, or write a new one.

I wouldn't be in favor of making config windows have the plasma style. In other respect they would match the desktop style (e.g. titlebar) so that would just be weird IMO.

feasible technical solutions at the moment are

• QQmlAbstractUrlInterceptor based solution: kinda error prone but easy to do
• configuration windows in a separate process: quite complicated and error prone, would take a year to do
• having config windows with the plasma style

Related to but necessarily a duplicate of T11558: kill plasma components in favour of qqc2-desktop-style. If we do T11558, we won't have to do this, but we can do this without having to do T11558.

Ping

@ognarb thanks! It did not work out of the box, but it helped me make it run (I'm on arch linux and had to change the kirigami version to 2.4 and remove the usage of ImageColors to make it run)

@twitt The error you are getting is because you didn't source the prefix.sh with source prefix.sh then it should just work™.

Recently I got into the source code of Gwenview. I was missing a crop tool that allows arbitrary rotations. While a rough implementation in Gwenview was quite easy, I never solved all problems to also retain the old behavior, which is why I not yet committed it. However, after getting a deeper look into the codebase of Gwenview, I agree that several things could be refactored or rewritten, although I still like the application itself. If someone could review/help, I would spent some time on polish or adding some new features.
Personally, I am not a fan of mixing mobile and desktop applications as it is difficult to implement a good usability that works with touch, mouse and keyboard at the same time. A prominent example might be Adobe Lightroom which still fails to have a unified user interfaces that works for mobile and desktop devices.
However I the mookups look cool and also very much like the name Koko for an image application. Unfortunately I never worked with QML and I was not even able to start it (error message: module "org.kde.koko" is not installed :/ ). According to the git log there were nearly no new features added within the last two years, so I am not sure if replacing Gwenview would help to gain activity.

looks good

This is being moved to GitLab.

Moving to a GitLab MR

In D28873#672598, @mart wrote:

what should happen in this case?

can this be closed?

Looks like D27595 fixes the issue

Not all of the headers use toolbars, but I thought the idea was for them all to use a consistent base appearance? @mart?

I wonder if this should be specified in ToolBarApplicationHeader instead.

what should happen in this case?

can you add an example about it in /examples ?

Looking fiiiiine.

Improve the small toolbar

The plasma-framework patch is D29463

Rebase on master

Unsplit template and control for documentation purposes

Split into a template; make borders customisable

Is there no better way to do this? e.g. the KWin Rules KCM spends 20% of its startup time in "retranslate" :/

In D29462#668542, @mart wrote:

the different Units.qml depend from the style, QT_QUICK_CONTROLS_STYLE
all of them, including those in plasma-framework should be updated at once

I would like this class to be splitted in Templates/controls, so different styles could make it look slightly sifferent (or anyways easier for the app developer to make one that looks just slightly different)
the root component should be a Control, with image/icon/initials in contentItem and background collor/border in background
the one in templates would not have a background the one in controls would instantiate the one in templates and give it one.

yes, that screenshot is really broken.
to me is important that the tabbar tries to take all the space available before doing any eliding.
Probably whether starting to elide a lot and make the tabs actually scrollable, will depend case by case depending fro mthe app

When there isn't room to show all labels, eliding the labels or collapsing the inactive tabs to square-ish icons-only things that are still clickable/touchable would seem to make more sense to me. The above screenshot kind of looks like a visual glitch IMO.

In D28873#671043, @ngraham wrote:

In that window, there's plenty of space for the component to expand horizontally. I would prefer to avoid scrolling tabs; their interaction is usually not great.

In D28873#671042, @mart wrote:

If i make the window narrow enough, that's what happens

perhaps it tabbar should scroll instead?

If i make the window narrow enough, that's what happens

Cool thing. Makes me think of Nintendo Mii, and their open source counterpart, bloke (which is not really used anywhere, but whatever).

Avoid trying to display initials of non-Latin characters

+1 overall.

In D29694#669873, @filipf wrote:

Cool stuff. The commit message needs to be expanded to explain where and how this will be used, and also needs to list key implentation feats (initials, colors).

I believe we use avatars in launcher menus, the user menu, and lock, login, logout (3L) screens. The 3L have no action involved with the avatar so there's no need to buttonify it in any way for that use case. Visually they're fine as is. Launcher menus and the kcm are obviously different. But the main question is actually what do we intend to do with not using Kirigami on the desktop? That makes this component only usable in kcms?

• adress feedbacks

the different Units.qml depend from the style, QT_QUICK_CONTROLS_STYLE
all of them, including those in plasma-framework should be updated at once