Is there a reason for the wontfix designation? I've read this thread a few times and don't see one.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Feb 5 2024
Jan 11 2024
This is largely done in Plasma 6 now!
Nov 11 2023
Sep 13 2023
With https://invent.kde.org/frameworks/kirigami/-/merge_requests/1235, we have a path forward here, at least for QML apps.
Apr 2 2023
Mar 17 2023
Aug 2 2022
I am confident that instead of this, the more simple iconography should be utilized. My grandmother has a seriously difficult time trying to understand the colourful iconography, whereas the doesn't when it is at 16 pixels (but then it is unpleasantly small) and the colourful iconography is able to adhere to the currently utilized .colors file, whereas colourful iconography is not.
This is obviously desirable, but I doubt that this is actually possible unless all of KDE's software switches to tree-views. I would love this, because it would provide one consistent method of navigation and would mean that all of KDE's software would reuse the same module for this important ability.
Jul 4 2022
May 15 2022
Apr 22 2022
Mar 21 2022
Whatever we decide we would need an implementation for KEditListWidget https://api.kde.org/frameworks/kwidgetsaddons/html/classKEditListWidget.html
In lots of KCMs we show this on-hover, do we have any consensus regarding that?
Feb 22 2022
Update: all, except the archiving step, are done for games.k.o:
- "How to play" sections are shown for games having the data. These sections can also be translated;
- Accessing games.k.o pages will redirect to corresponding parts on apps.k.o, except games.k.o/old and its subpages which are left untouched.
Feb 21 2022
Feb 19 2022
In T10827#271310, @felixernst wrote:I haven't done a lot of webpage work but from what I can tell this seems like a solid plan.
How do you think?
Feb 11 2022
So as I can see, the 3 websites that are equivalent to categories of our apps, edu.k.o, multimedia.k.o, and utils.k.o, are still alive and really outdated, even though we already have some other plans for them. The other category-equivalent one, games.k.o, although has been ported to Jekyll, I think can still be improved.
Jan 23 2022
This is done now in Dolphin 22.04! See https://invent.kde.org/system/dolphin/-/merge_requests/309
Jan 6 2022
Of the current suggestions, the last one certainly is ideal – although not mutually exclusive of the previous suggestions – because the more that is automatic, the superior that the toolkit is. Obviously this is not inferent advocation for removal of the ability to override, but merely that it should not be necessary unless designing custom appearance of software. Consistency is the ultimate goal.
I am believing that the colouration of "http://phabricator.kde.org/file/data/to7e46zbo7jhwg6mbwv4/PHID-FILE-7qs7usxqzpuvfwbsrgis/sheets_alt.png" is superior, because ascertainment of which tabs are active and inactive is significantly more easy than within "http://phabricator.kde.org/file/data/4mp4omhmpt3j7mxtin42/PHID-FILE-md7fdorexja3vakdh5to/sheets.png".
The first proposal that is similar to the interface of Microsoft's Word, and the interface that is present for Gemini are utterly unsuitable for Calligra, because they are not adherent to any of the appearances of current Qt software that has been created by KDE, and are consequently more inconsistent.
Why not utilise the tree-view that is present within the "Folders" panel of Dolphin? That would mean that retainment of the current organisation is possible, without ascertaining how to improve the current weird implementation of multiple side-bars. Additionally, because addition of KConfig Modules to systemsettings5 by many distributions shall continue, organisation would be more easy, because the tree-view would adapt properly.
Why have so many people proposed static sizes if iconographic configuration is available within "kcm_icons"? Adherence to what has been specified by the user is certainly more consistent behaviour. This is important to me, because I have never desired utilisation of anything but 16-pixels for iconography, because the resolutions of my screens has been minor enough that iconography of more great resolution has been detrimental. Additionally, quick ascertainment of what the colourative/colourful iconography that has been proposed is intending to communicate is not as easy for me as the current iconography.
Dec 26 2021
If you mean a video player, there's Haruna, which is QML and works quite nicely, but it does need a bit of UI polish IMO.
Yes, there's Elisa. It's playing music for me right now. :)
Dec 21 2021
In T12667#220236, @ngraham wrote:Konqueror and Amarok are unmaintained.
DragonPlayer and KMPlayer seem to be on life support, nearly unmaintained.
Apper, Muon, and Dolphin are each used for different things.
Dolphin and Krusader target different users (normal user/expert user).
It's the same with KWrite.
It seems like the issue here, if any, is that these apps don't make their intended audience and features obvious enough on https://kde.org/applications
Dec 7 2021
@resdex there are no updates. In last KDE Sprint it was decided that such an effort it eould require man power and commitment and there was noone that step in and say, I want this and I will lead the effort.
I guess something I am missing is the "WHY?" part of the argument. Why should Plasma integrate at a default level with Latte?
@mvourlakos Do you have any updates on the current state of this topic?
What I would like to see, when using latte dock, is that it gets rendered before the Desktop is ready.
Right now after the Splash Screen I see my Wallpaper, and it takes 2-3 seconds for latte to start and render the dock.
You can make some beautiful Desktops with latte-dock. It would give plasma a boost if people could generate Global Themes with a latte-configuration that is a 1 click install.
Nov 23 2021
These post makes some mention of inconsistencies in some KCMs:
Nov 14 2021
Sep 17 2021
Aug 2 2021
In T11227#261226, @felixernst wrote:Is this meant to only be used as launch feedback?
Yes, I just replaced the current spinner icon we have in the task manager now. It shows up when the window didn't appear yet.
In T11227#261191, @GB_2 wrote:Indeterminate Progress Bar
Used when the progress is unknown at first, but can be determined after some time.
Jul 31 2021
Here is my proposal for this topic.
Jul 27 2021
Yeah, enforcing wasn't a good word in this context.
In T12435#260970, @fhek wrote:Personally I think this would be a good layout to enforce onto our applications
Sure but I think we should make it easier to follow the HIG, creating common components, good defaults, etc...
Jul 26 2021
https://develop.kde.org/hig/ < let's not reinvent the wheel. Whatever is there can be addressed if it doesn't fit. If an application doesn't fit the HIG it can definitely be addressed.
Personally I think this would be a good layout to enforce onto our applications:
Jul 25 2021
Kontact is just a shell around kmail, korganizer etc. Some note-taking / todo apps seem to be duplicated though, but whatever surivves needs to integrate into kontact, imho.
There is also the new KDE media player https://invent.kde.org/multimedia/haruna, which is quite good IMO.
Jul 24 2021
Whatever we decide we would need an implementation for KEditListWidget https://api.kde.org/frameworks/kwidgetsaddons/html/classKEditListWidget.html
FWIW we already have a red X we could use for permanent deletion, but now lists use red trash cans instead...
Right now the only thing distinguishing permanent and reversible deletion is the trash can color. Not good for accessibility.
Having only black trash can icons for reversible deletion and the red X for permanent deletion like I proposed would fix this.
Yeah currently we use a red trash can for irreversible-annoyingly-reversible deletion and a black one for reversible deletion. If we wanted to universally change the red trash can used here to a red something else, I wouldn't be against it.
Jul 7 2021
oop, my bad
In T12777#259813, @cblack wrote:Using colour alone to indicate a difference between elements is inaccessible and obtuse to read.
Using colour alone to indicate a difference between elements is inaccessible and obtuse to read.
In T12777#259810, @cblack wrote:FWIW, I think using the trashcan as the universal list removal thing isn't a good idea, mostly because a trashcan has largely meant "you can put something in the trash" and importantly "you can take it out of the trash" again, that is, a trash can indicates deletion that is:
- reversible
- "deleted" items are put in a staging place that can be accessed by the user
Most instances of the trashcan used in a list item are either destructive, or reversible but not very apparent in how you recover an item from deletion. This is inconsistent as to the meaning of the trash can icon as used by other OSes our users are familiar with, and to how we've been using it before we started slapping it on list items.
We should either- use a different icon that truthfully indicates the non-trash-like nature of deletion (shredder, X, incinerator, whatever) instead of one that lies to the user about how a UI will behave or
- revise the interaction of items using a trashcan in order to be consistent with the meaning that it implies
FWIW, I think using the trashcan as the universal list removal thing isn't a good idea, mostly because a trashcan has largely meant "you can put something in the trash" and importantly "you can take it out of the trash" again, that is, a trash can indicates deletion that is:
- reversible
- "deleted" items are put in a staging place that can be accessed by the user
There are two types of hamburger buttons: one which opens a sidebar on the left, so it makes sense to put them left, and the one that opens a menu for more actions and is often located in a toolbar. So we're kind of restricting ourselves to either always put hamburger menus left or differentiate these two types.
Jun 24 2021
tbh not a fan of that idea especially considering that we wanna minimize the amount of chrome at any given time
- I think the Koko information sidebar, when opened, should stay there as a sidebar rather than a overlay
- I think the "crop" tool is a bit behind the Gwenview's:
- Crop area should be same size as the image by default, and should not be able to be bigger or outsite the image itself
- You should be able to set a aspect ratio for cropping, potentially "keep the same ratio as original image"
Jun 20 2021
Next steps:
Jun 19 2021
That's great! @mikeljohnson, what do you think the next step for Koko is?
this has just landed 🎉
Jun 16 2021
Sweet!
started work at https://invent.kde.org/graphics/koko/-/merge_requests/69 (nice)
bad example haha, I might actually work on this today, since it should be pretty simple (famous last words)
so, just your browser with working microphone, optionally webcam, and there will be a link under meet.kde.org. It will be on kde-hosted bigbluebutton server which is web based and both chrome or firefox works okS
Jun 15 2021
I wouldn't call video support niche, as I think a lot of people who take family photos will have videos interspersed with their images. This is certainly the case for me, my wife, and my parents.
tbf feature wise koko already has most of the gwenview's features excluding some niche stuff like video support, so it's not like it can really get more complicated than it already is :P
I indicated the last hour 18-19 utc as Plasma/LAtteDock, though we can discuss about it at any point if is better for you as timing.
Of course you're invited to participate on the rest as well :)
In T12433#258028, @mvourlakos wrote:
Jun 14 2021
To close the loop on this, the feature has now been integrated, and I have submitted a merge request to remove the button from the toolbar: https://invent.kde.org/plasma/kwin/-/merge_requests/1104
I generally agree with that, but I wouldn't want to take it too far, as I think you can with minimalism. At least for the desktop use case where there is generally plenty of screen real estate available, I think it would be good to at least display the toolbar as well without requiring additional user interaction.
No prob for me whatever works best for you. Slots in Wednesday are 16:00 - 19:00 UTC so that makes it evening/night in Greece 19:00 - 22:00 and I can participate.
There are 3 hours booked for plasma on wednesday.
maybe we just can use one of those for this?
I had booked one for Monday, But Marco has a special "Plasma day" which we can maybe move to.
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.
Jun 11 2021
Jun 10 2021
Jun 8 2021
This has been more or less implemented in the form of the new GHNS dialog.
Jun 4 2021
If it is 21 June it works perfectly.
In T12433#257331, @davidedmundson wrote:Nope, lets go pick a time. All the slots are empty currently.
I have all the availability. Does Monday afternoon work?
Nope, lets go pick a time. All the slots are empty currently.
I have all the availability. Does Monday afternoon work?
@davidedmundson is there any update concerning your proposal to have a BOF for Latte in Akademy?