On the one hand it presents itself as trying to put more value on "human-centred design". Human-centered design is about community involvement in all stages of the process among other things. This is already a core pillar of the KDE community and front and centre in KDE's code of conduct. I would have assumed this goal was about guiding users to self-organise and contribute to design effectively.

qt5's new QML_FOREIGN and QML_EXTENDED things with the new c++ type registration stuff give us another option for this: we can just QML_FOREIGN a QMenu and have QML work with those + related types pretty much directly

Well, this tangent is kinda moot now since some chatting & it's probably not going to work out having Hebrew team work on the instance I set up for the Toki Pona team.

I'm going to warn you against that, you can't create a system to automatically commit things from other people into KDE servers without human interaction, that's basically giving out your user for anyone else to [ab]use, and that's obviously not allowed.

Could we chat on a more real-time platform to hash out the details of that? My matrix is @pontaoski:kde.org and Telegram is https://t.me/pontaoski

You want to use the Weblate instance set up for the Toki Poka team for the Hebrew localisation?

@cblack What will it take to simply join them?

Another data point: the toki pona team uses a Weblate instance working directly against the SVN. Works fine, other than the fiddling of the internal checkout Weblate uses required to prevent it from dying on how many files we have in its "scanning" phase.

A welcome app would be a great way to help new users learn about Plasma's incredible features and capabilities

While the technical workflow improvements sound nice, I can't say I'm that big a fan of the proposed icon style. Something about the usage of black and white in this manner shown here just doesn't sit right with me, though I can specifically point out that it's low contrast with a lot of background areas and the bordering looks out of place compared to other elements which are generally unbordered.

ping

Like most of KDE's mobile applications, this would be better suited as a bottom navigation bar instead of a hamburger menu, like KClock.

Plasma Weather

System Settings

KClock's UI is entirely burgerless and can be considered a model of a good app design: everything is discoverable and fast to access at the bottom of the screen, without the need for a hamburger menu to hide items in.

Tok's hamburger menu is even simpler to simplify than NeoChat's: just move everything into a settings page and replace the hamburger menu in the toolbar with a settings button.

NeoChat's hamburger menu is fairly brief on items.

oop, my bad

Using colour alone to indicate a difference between elements is inaccessible and obtuse to read.

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:

1. reversible
2. "deleted" items are put in a staging place that can be accessed by the user

Sorry; I missed your comment

Hardly done; system settings and other applications are still filled with inaccessible delegates.

Commit-Rechte sind nicht global für SVN; https://community.kde.org/Infrastructure/Subversion/2020_Changes

ich hab' kein SVN-Zugriff, könnten Sie es committen?

Solution 2: Menus

Solution 1: Expandable Everything

I am strongly against overcomplicating a UI for switching between windows. What Present Windows has currently now is what I consider to be the ideal in UX: simple mouse-driven window switcher with a visually appealing animation.

In T13514#248309, @aspotashev wrote:

Btw I've started slowly rewriting scripty in Go because

• I like Go more than bash.
• It's easier to make it more configurable than in the current state with a set of scripts calling each other. We need configurability to share codebase across branches and to let users run parts of scripty end-to-end (will be useful for www that needs more frequent syncs).
• it's easier to parallelize things in Go, so we could shorten the running time.
  
  I didn't share my code yet. Don't expect fast progress, maybe I'll be able to release something by May 2021.

Crystalline: +1
Grand Canyon: +2
Vera: +1
Beach: -1
Altai: -1
Rainy Morning: -1
Slant: -1
Kay: -1
New Contest: +0

Speaking of that; if we're going to touch I think it would be advantageous to port it to an actual client-based search thing like elasticlunr or lunr instead of the homegrown thing we have right now

Does sitelenkijetesantakalu (please change the name) also handles the combined searchdata too?

The thing that will be difficult it to provide a way to browse all the different libraries and categories. Using a flat index won't work since we have products like pim and the frameworks and we need grouping. Probably the easiest way would be for each job to also upload their metainfo.yml once they are done and we can have a cronjob that simply build the index from the collection of metainfo.yml like this is done currently, this should take less than 20 seconds and would be the only thing that can't be put inside a ci job.

This is the presentation used by Index and I wouldn't be surprised if this idea is directly taken from it.

In T13927#245978, @ngraham wrote:

What is "pop shell"?

pong

A potential idea for fixing: allowing clients to request that the decoration be composited over their area. KWin/the KDecoration would be responsible for drawing the foreground, and the client would be responsible for drawing the background.

Thanks for the patch, however we use GitLab now for contributing code.

https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/305

oooh man, this'll be a doozy to rebase :D

https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/24

In D27271#676512, @ngraham wrote:

Could you move this and the dependent patches to Gitlab? It would be good to get this in for 5.21.

Moving this to GitLab: https://invent.kde.org/frameworks/kio/-/merge_requests/143

In D29466#676411, @ngraham wrote:

Putting it in KRunner could make at least a little bit of sense if it worked everywhere--i.e. with in-window menubars as well. However since it does not, I think the current location makes sense.

Could you move this to GitLab maybe?

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

-1 for Darker Flow. It's so dark that the colours and default light panel visually vibrate, which doesn't look too hot.

If we had a special CSS function for using SVGs as a frame background, it would be possible to reuse a lot of assets from Plasma themes, easing porting.

IMO using SVGs for theming is something we should move away from in Plasma 6.

i18n the strings

Redo that switchcase

Break those cases; this lang ain't got sane case behaviour

Add more descriptive authentication details

In D7563#674682, @sitter wrote:

This really cannot land right now IMHO. Dolphin can actually deadlock itself because it uses way too much nested event looping and will be entirely unresponsive to mouse inputs when certain timers happen to trigger. A trivial way to reproduce this is to try and duplicate a file in file:/

Something like this?