In T14619#288180, @nicolasfella wrote:

Is there something actionable here that we can do before KF 6.0?

In T14768#271218, @knauss wrote:

@ndavis: What infomation do you need to help? Have you watched the videos? And looked into the subtasks? Sorry I'm a little bit lost, what you need for information to go on. As I have deep understanding in the encrypted messages I'm somehow blind about the questions from newbies.

As a first step I want to get improve the situation when sending an encrypted message. I want to remove/replace/improve all the dialogs that pop up AFTER pressing "send". I think a user should in best case not click "OK" at any other dialog after pressing "send". The user should have information BEFORE pressing "Send", if they wants to send it under specific circumstances.

It's currently not clear from the task descriptions what your goals are. I have next to no experience with encrypted email, but I know that PGP has a lot of built-in complexity that can be difficult to abstract away (part of why it isn't used by most people). Maybe someone else in the KDE VDG has more experience with encrypted email, but I don't know anyone in particular who does.

I think it would be a good idea to show a short description of each app in the short cards because lots of people won't know what an app does just by looking at the name or icon.

right, gotta keep on topic in my own task

In T14954#264982, @ngraham wrote:

• Delete PlasmaComponents3 and make SVG Plasma styling (if it is kept) get applied via a simple QQC2 style

In T12068#264877, @gguerin wrote:

Sorry, slightly off topic, but how do you get the application tabs in the title bar as shown in the screenshot in that comment?? Many thanks

One thing that Qt's Drag attached object will need is a way to set the image via a QIcon, icon name string or we will need a way to convert QIcons/icon name strings into usable URLs for the Drag.imageSource property.

In T12435#260970, @fhek wrote:

Personally I think this would be a good layout to enforce onto our applications

In T11930#260908, @ngraham wrote:

You can force a particular color group though.

I think @felixernst has a good point. In all of these studies, the conclusion is that hamburger menus are bad for navigation, especially multi-level navigation. I agree with that, but hamburger menus are not always used for navigation.

In T14619#259036, @mikeljohnson wrote:

I thought the whole point of this is to use QPallete with above comment being more about that than the syntax

In T14619#259005, @mikeljohnson wrote:

am I correct to assume that with this approach we would go from:

Kirigami.Theme.colorSet: Kirigami.Theme.View

to

palette: Kirigami.Theme.View?

if so, that seems pretty good

I was thinking we might need equivalents to NegativeText, NeutralText and PositiveText in QPalette for this to work out, but then I realized, couldn't we have Negative, Neutral and Positive Contexts instead? Maybe it would be extreme overkill to have a whole QPalette of colors for a negative context, but it would allow us to tint backgrounds or text differently based on the type of GUI element we're giving the negative color to.

I think something we should keep in mind is that a lot of current Gwenview users don't actually want to use most of Gwenview's features. I'm not saying we shouldn't have them, but we should make sure we don't add more complexity to the UI than we really need to in the most common situations. I think the most common situation is when an image is being opened via another app like Dolphin. In that case, I think it's best to focus on just displaying the image, which Koko already does in its current state.

In T13722#256065, @ZaWertun wrote:

Try also setting mipmap to true: https://doc.qt.io/qt-5/qml-qtquick-image.html#mipmap-prop.
Maybe it will give better results (disabled by default).

In T13722#255709, @bam wrote:

Do you mean in raster?

In T13722#255696, @bam wrote:

So what should be the solution?

In T13722#255644, @driglu4it wrote:

In T13722#255639, @bam wrote:

@driglu4it we also have problem with blurring SVG icons on small sizes, could you also provide the screenshots?

Panel height is 36

In T14315#255640, @mikeljohnson wrote:

I suppose that's an option too and probably good to do anyway, but then we have to wait until we can use Qt 6.3. We can have something similar and stable in PlasmaExtras now. If we want to make a list of Platform MenuItems for Kicker's actionLists, we'll have to write embedded QML in C++, which is annoying and sub-optimal even if doable.

Couldn't we potentially just mirror Platform Menu, so we'd still have stable API even if qt killed it? I know it's suboptimal but imo still better than creating another implementation altogether

If it's possible to remove the black outline, then I guess we can use OpenMoji for flags.

In T14315#255620, @ognarb wrote:

The problem with a QAction is that it's using a QIcon instead of the icon.name stuff we have in QQuickAction :(

Instead of having a QQuickItem based MenuItem with no visual content, we could just expose QAction and QActionGroup to QML for use in the Menu as things like PlasmaExtras.MenuAction and PlasmaExtras.MenuActionGroup. QAction doesn't come with every property we might want it to have, but we can add the missing properties by making a subclass. Most of the missing properties can already use getters and setters from QAction's public API (e.g., setSeparator, isSeparator).

In T14315#255483, @nicolasfella wrote:

@ndavis didn't you do some investigation around this?

Yes, I agree that 10pt noto sans is too small.

Another thing: @ndavis showed interest in being one of the judges.

makes sense to me too

IMO, It's best to enter the hover state quickly (or instantly) an leave it more slowly but still pretty quickly (shortDuration == 100ms). In order to make the QStyle match, the Breeze animation engine would need to be redesigned (it already doesn't match our Qt Quick animations), but this is easy to do in Qt Quick.

In T11661#250770, @ognarb wrote:

I agree that forking the current Breeze theme would probably be the best or maybe even better forking Lightly since Lightly figured out many ways to remove frames and is probably a better start. Also a fork would allow us to progress faster.

In T11661#250740, @mwolff wrote:

Good point with the blinking cursors, that could indeed work out in the end!

@ndavis The problem with "a wider variety of background colors" is that you would have to find a way to implement that without changing application code. I.e. both Code and QTC apply application specific styles, and don't need to be generic - quite the contrary. What you all are trying to achieve here, by changing the central QStyle that will be used by *all* Qt applications on Plasma is _much_ harder. That is why I'm so weary here, call me pessimistic if you will ;-)

That said, I'm totally on board with the vision you have - getting rid of more frames is something I would like to see too. And I also agree the both Code and QtCreator look more pleasant than KDevelop. So to repeat what I said before already: Feel free to experiment with this as much as you like, and if you have questions that you think I may be able to answer, feel free to ping me. But please try to keep these experiments out of the default style until the end result is pleasant in all applications. I.e. what @ngraham wrote about forking breeze like oxygen sounds totally fine to me actually. Fork breeze - make it work, and if it then turns out to be better in a year or two than breeze then me and many others will jump ship without shedding a tear.

@mwolff For complex UIs with many adjacent view areas, I've looked to Visual Studio Code and Qt Creator for inspiration.

Could the KDE sounds contest be open to artists that don't use LMMS? I can understand disallowing things like FL Studio, Bitwig and proprietary plugins since they're not FLOSS, but there are other FOSS DAWs, sequencers and things like SuperCollider or Pure Data.

In case anyone didn't realize, the "New Contest" option is about doing the new contest now.

In T13467#249433, @paulm wrote:

I think any new theming engine needs to universally apply its theme (particularly the window decorations and in-app decorations for dockable controls) to GTK as well as Qt. Too many major applications are GTK and not going away. The current theme engine is next to useless as GTK apps aren't affected by changing the standard theme.

In T13467#249508, @ngraham wrote:

Another option we've discussed is migrating to a CSS-based system like GTK has. If we do this, it would be worth coordinating with them and potentially just lifting their system and proposing it as a freedesktop standard for which we would then add support. This would allow a single CSS theme to theme both Qt and GTK apps, with obvious benefits. This could have some side effect benefit in that the GNOME people would gain a disincentive to break their theming based on convenience as this would be breaking the spec too.

In T12724#248646, @niccolove wrote:

I think we might want to do a wallpaper contest for 5.22, to get a round of new wallpapers. We used most of the best ones collected in previous contests.

In T10891#248063, @vkhatab wrote:

Looks good. The main things I would suggest however are:

1. Highlight the whole button on hover instead of drawing a glowing outline. This is a stronger visual cue than an outline, and it doesn't rely on adding any distracting lines and colors.

I just hoped user could choose one flags icon pack or another without mixing. I'm not sure if Plasma theme's engine allows this.

Maybe we're not communicating with each other well? My impression is that any emoji set we pick will become the default system-wide emoji set. If that is the case, then we need to be prepared for emojis to show up at any size. I think Twemoji's style has a good enough compromise between accuracy and legibility at small sizes.

It seems to me Twemoji still has much more details for that flag.

I'm not a fan of the style of OpenMoji, even if the black outlines were removed. Also, looking at the Afghanistan flag you linked, the OpenMoji variant leaves out quite a bit of detail. Some of the details even seem wrong.

@bam I suppose I could take the Twemoji flags, sharpen the corners and then put them in breeze-icons. It'll probably take a long time though since there are a lot of flags and I'll have to recreate any bits of the flag that were cut off by having the corners rounded.

My opinions are basically the same as last time, obviously excluding Shell since we're already using that.

Seems like it would be useful to show on devices with a touch screen.

Personally, I think it's a good effect. It makes it possible to see what's below the window while you're moving it. It's useful because if you just want to see what's below the window, you don't even have to move it out of the way.

I agree, a cursor theme update would be good.

Kind of a shame that this extensive write-up has sat around for 2 months with no comments, but unfortunately, I don't have much to add. I don't really use virtual desktops or activities much and haven't seen a great need to, so it's hard for me to really see how they should work. I have tried them and they have been somewhat useful, but I never really stick with them. It's just easier for me to control everything with the task manager. I'm not saying your reasons for liking Virtual Desktops aren't valid, but perhaps one of the reasons why nothing moved forward is that a lot of people don't understand them, including KDE developers and designers like myself?

In T13722#241999, @bam wrote:

Thanks for input everyone.
About option 2, if someone knows emoji font resemble these: https://lxr.kde.org/source/frameworks/kdelibs4support/src/l10n/ (the flags are inside 2-letter dirs, installing to kf5/locale/countries/%1/flag.png), please let us know. I think non-waving version is preferable.

In T13722#241992, @davidre wrote:

If we want to go the icon theme route we could create an icontheme for the flags and breeze could inherit from that. So we could still do QIcon::fromTheme("flag-DE")

I don't think non-Breeze icons should go into breeze-icons. I especially don't want PNGs in breeze-icons unless they really need to be there.

I prefer option 2

@debnath I agree, but I don't remember the reason why previous attempts to get rid of the title were stopped. Maybe if we pushed again it would be successful.

In T10891#241266, @roberts wrote:

Would love to do some more work on this area but slightly struggling to understand which tasks don't already have merge requests (here or over on invent) or design questions needing resolution.

Can anyone clear up which tasks are still in need of help? :)

My goal with the breeze evolution is to make something inspired by what came before (including aspects of the Breeze QStyle and Breeze Plasma style), but with a focus on improving contrast. Not to a ridiculous degree, but enough to make reading text and symbols easier.

In T10997#241262, @clel wrote:

I guess it has been settled on a design already? Does that mean it has been agreed to use round edges everywhere then and make the overall appearance rather soft?

Also I saw a design from @ndavis today which I really liked and which I copied into my mockup. That then looks like this:

In T10891#239685, @clel wrote:

I am wondering, is there some central point where the overall breeze theme "design philosophy" is documented? Or where that can be discussed? Since I think it makes sense to have some broader overall guidelines in order to make consistent decisions about the design of specific UI elements.

I agree with @clel. I think this has gone too far away from our current style.

I've been staying out of this because I've just been feeling very negative about changes to the Breeze QStyle in general and I didn't want to spread that negativity, but I think I should talk.

Crystalline: -2
Grand Canyon: +1
Vera: -1
Beach: -2
Flow Dark: -1
Altai: +2
Milky Way: +1
Rainy Morning: +1
Slant: -2
Kay: +1
Iridescent Shell: +1

How about we try a point based voting system?

I kinda prefer Altai, but all the proposals look pretty good.

In T13467#236628, @The-Feren-OS-Dev wrote:

In T13467#236623, @ndavis wrote:

In T13467#236621, @The-Feren-OS-Dev wrote:

If this also gets integrated into Kirigami as well, that'd be even better.

I don't think this would be integrated into Kirigami. Rather, Kirigami would get its theming from the QQC2 style.

...which'd technically still be the Plasma Style?

In T13467#236621, @The-Feren-OS-Dev wrote:

If this also gets integrated into Kirigami as well, that'd be even better.

We haven't used webcams much in our VDG meetings, but as a general rule, let's agree not to use webcams unless we actually need to. I think using webcams greatly increases the CPU usage of BigBlueButton.

I've committed the icon.

Haven't changed the padding yet.

yeah, I'm going to try it again