In T14619#288180, @nicolasfella wrote:Is there something actionable here that we can do before KF 6.0?
- Queries
- All Stories
- Search
- Advanced Search
Feed Advanced Search
Advanced Search
Advanced Search
Aug 7 2023
Aug 7 2023
Feb 23 2023
Feb 23 2023
Sep 1 2022
Sep 1 2022
Aug 2 2022
Aug 2 2022
rokejulianlockhart awarded T11713: Reorganize colorscheme colors and use them in a logical manner a Like token.
Feb 18 2022
Feb 18 2022
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.
Feb 16 2022
Feb 16 2022
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.
Nov 16 2021
Nov 16 2021
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.
Oct 24 2021
Oct 24 2021
Oct 18 2021
Oct 18 2021
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
Oct 17 2021
Oct 17 2021
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
Oct 3 2021
Oct 3 2021
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.
Jul 27 2021
Jul 27 2021
In T12435#260970, @fhek wrote:Personally I think this would be a good layout to enforce onto our applications
Jul 25 2021
Jul 25 2021
In T11930#260908, @ngraham wrote:You can force a particular color group though.
Jul 12 2021
Jul 12 2021
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.
Jul 2 2021
Jul 2 2021
Jun 26 2021
Jun 26 2021
Jun 25 2021
Jun 25 2021
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
Jun 24 2021
Jun 24 2021
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.
ndavis renamed T14619: [RFC] KColorScheme replacement from KColorScheme replacement to [RFC] KColorScheme replacement.
Jun 12 2021
Jun 12 2021
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.
May 17 2021
May 17 2021
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).
May 14 2021
May 14 2021
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
May 13 2021
May 13 2021
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).
May 10 2021
May 10 2021
In T14315#255483, @nicolasfella wrote:@ndavis didn't you do some investigation around this?
May 6 2021
May 6 2021
Yes, I agree that 10pt noto sans is too small.
Apr 12 2021
Apr 12 2021
Another thing: @ndavis showed interest in being one of the judges.
Apr 6 2021
Apr 6 2021
makes sense to me too
Apr 5 2021
Apr 5 2021
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.
Mar 4 2021
Mar 4 2021
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.
Mar 2 2021
Mar 2 2021
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.
Feb 24 2021
Feb 24 2021
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.
Feb 21 2021
Feb 21 2021
In case anyone didn't realize, the "New Contest" option is about doing the new contest now.
Feb 16 2021
Feb 16 2021
Crystalline: | -1 |
Grand Canyon: | +1 |
Vera: | -1 |
Beach: | -2 |
Altai: | +2 |
Rainy Morning: | +1 |
Slant: | -2 |
Kay: | +1 |
New Contest: | -2 |
Feb 9 2021
Feb 9 2021
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.
Jan 23 2021
Jan 23 2021
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.
Jan 13 2021
Jan 13 2021
In T10891#248063, @vkhatab wrote:Looks good. The main things I would suggest however are:
- 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.
Jan 11 2021
Jan 11 2021
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.
Jan 10 2021
Jan 10 2021
It seems to me Twemoji still has much more details for that flag.
Jan 9 2021
Jan 9 2021
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.
Jan 5 2021
Jan 5 2021
@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.
Jan 1 2021
Jan 1 2021
My opinions are basically the same as last time, obviously excluding Shell since we're already using that.
Dec 27 2020
Dec 27 2020
Seems like it would be useful to show on devices with a touch screen.
Dec 9 2020
Dec 9 2020
Nov 23 2020
Nov 23 2020
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.
Nov 10 2020
Nov 10 2020
I agree, a cursor theme update would be good.
Nov 9 2020
Nov 9 2020
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?
Oct 7 2020
Oct 7 2020
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.
Oct 5 2020
Oct 5 2020
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
Oct 4 2020
Oct 4 2020
@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.
Sep 28 2020
Sep 28 2020
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? :)
Sep 27 2020
Sep 27 2020
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:
Sep 19 2020
Sep 19 2020
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.
Sep 11 2020
Sep 11 2020
ndavis added a comment to T13451: Combine the best aspects from the various Breeze style proposals (Final style: "Blue Ocean").
I agree with @clel. I think this has gone too far away from our current style.
Sep 7 2020
Sep 7 2020
ndavis added a comment to T13451: Combine the best aspects from the various Breeze style proposals (Final style: "Blue Ocean").
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.
Sep 6 2020
Sep 6 2020
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?
Aug 21 2020
Aug 21 2020
I kinda prefer Altai, but all the proposals look pretty good.
Jul 31 2020
Jul 31 2020
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.
alexde awarded T13442: Tweak the design of context menus a Love token.
Jul 29 2020
Jul 29 2020
I've committed the icon.
Jul 27 2020
Jul 27 2020
yeah, I'm going to try it again