One potential problem is that the IRC side limits the amount of connections allowed from a single IP to combat abuse. If a separate bridge is used, chances are that this one might hit limits at one point if it spawns an IRC connection per user.

we spell ourselves freenode, lowercase f, and in general we would want that bridge to be used, not the matrix one. (due to both limits and lag)

Why a rainbow for kde-chat? Is that a temporary thing due to it being June, or is there some association rainbow <> chat that I miss?

We recently upped the iline for the KDE Matrix bridge (not the regular Matrix bridge, please note that this is a completely separate thing) and whilst due to me being involved with KDE I'd like my colleagues to decide on that one, I'm pretty positive we should be able to raise limits for a cause such as adding a Telegram bridge.

Kate and Kwrite use, as far as I am aware, the same kpart, so they already are sort of merged. It makes sense to have a simple text editor to edit text files (kwrite), and a feature rich one for developers (kate)

Looks good to me, thank you very much for the work :-)

Good for me, hopefully the upstream bug will be fixed, too :)

Then as soon as you actually run the app there will be a duplicate, the launcher and the entry in the task manager. If I understood correctly, pinned tabs in browsers avoid that. You have a small, icon only variant when not open and a full variant (at the same position) when open.

If I remember correctly, the main argument against the launcher was that pinned apps should be pinned and thus not change their location / order, but exactly that would happen with a launcher once you open the app (that, or a duplicate entry in the window list)

Sidenote, maybe an upstream bug / wish can be added about

In T12322#212870, @aacid wrote:

In T12322#212839, @Fuchs wrote:

ideas called idiosyncrasies, which personally I think goes a bit against the code of conduct.

Maybe something got lost in Catalan->English translation here, i can't even begin to understand why you would feel it against the CoC

As I wrote, "I'd like to, again last time I gave up, this time I want to at least mention it." so personally I still hope we can add such a filter. But if we can't: shame, then indeed I won't read it, and I'm afraid others won't, too. But I won't fight a majority decision.

It's getting a bit tiresome with these accusations, so to clarify:
my reasoning, stated in the very chat you mention, is and was, unedited,

Could we please focus on the proposed solution.

In T12322#212841, @hein wrote:

I think goes a bit against the code of conduct.

Hmm - I tried many times in the thread to explain this, but I think you still don't have awareness on just how bad it is what you did today. You took issue with a particular blog post, which was fine under established community consensus, and decided to write a take-down to the community list in the hopes of having people gang up on it.

Political and non-controversial might be difficult, KDE or non-KDE I think should be feasible.
I agree with Lazlo that there are other systems that seem to be doing fine, so I think we should be able to do it, too.
However, I trust less in machines and automations and rather in common sense, as in: bloggers are mature enough to know if a blog post is about something KDE or something less related, but personally important.

In T12322#212816, @jriddell wrote:

I would be against this as all of life is political so it would mean covering many topic including Free Software and KDE. Discussing politics is a good thing and reading about people's activities and interests outside KDE code is a good thing which builds community.

In T12321#212791, @hein wrote:

This ticket is for making the existing rules more visible, not a filter mechanism, though.

May I suggest an alternative solution of differentiating between KDE topics and personal topics? Then we could add a filter, same as we do for languages.

sounds good to me, yeah. Note that I only created this following a discussion after I forwarded complaint from a 5.16 article in the news, I don't think I will be a good owner

In D20569#450462, @broulik wrote:

No matter where you place it, given that you can e.g. press the volume button multiple times whilst notifications are incoming, placement will be tricky and, depending on how it is solved, jumpy.

With the new system shouldn't it be too bad. I can stick the OSD at the position closest to the panel so it never moves as notifications come and go, they would just be positioned above/below the sticky OSD. That's what I'm doing with critical notifications and job progress there and it works well. Changing the sort order to prioritize "OSDs" even more than critical notifications is easy. The OSD will not jump, the notifications that are shifted ouf of the way might move, yes, but I don't think that's gonna be too awful.

I like the first, small but centered variant.

One minor nitpick: if it is on all virtual desktops there is no text shown, related to virtual desktops, maybe some "is on all virtual desktops" or so would be nice, for consistency.

Yep, that works here, even with groups spanning multiple desktops. Thanks for the quick fix!

I'm in favour of having a different colour for the active window title bar, as this is also what controls like buttons do.
Having the same colour for the inactive title as the rest of the window is imho fine.

if it falls back then all is perfect :)

In D14105#292183, @ngraham wrote:

Thanks! @Fuchs and/or @broulik?

Ah, great, so it would not be any regression for non-PA users, thanks for the info

What happens to supported systems that do not have pulse audio?
The *BSDs we do support come to mind.
Also Linux distributions that do not use PA or offer to not use PA.

In T9113#149473, @abetts wrote:

Does this have an expected look yet? What would it look like on the desktop?

Personally I don't think that we should ship changes that rely on hard-coded theme names like

as written on Telegram, added here per your request:

In D13593#280112, @ngraham wrote:

How about in a tooltip?

Maybe add the technical term in brackets though, for those people who search for the technical term and don't find it otherwise?

I think it makes it a lot harder to see though, depending on what the background is.

Taken from VDG discussion:

Personally I am very much in favour, even to tech-savy people who had to deal with systems like the Atlassian Stack (Jira, BitBucket etc.), Redmine and GitLab, Phab can sometimes be very confusing and it's not entirely sure if a button will do what you expect it to.
I also assume that for people who don't feel terribly comfortable with English yet, it might make it even harder.

Task Switcher > Alternative (https://phabricator.kde.org/M112/390/) - What does this actually do?

In an ideal world I'd agree with you. But if the changes can only be done by few people (or not at all), it would not hurt to safely check beforehand whether a) it is possible b) someone with the needed knowledge and skill is willing to do it, because we can neither force people nor make things happen by magic, so that might safe some time and frustration. Not saying it should be the default for every minor change.

Personally I'd be okay with no borders without rounded boarders by default, even though I'd consider it a UX setback to have a less visible resize area just for the sake of a more thin look. To me form follows function.
Plus, personally I don't think we should switch defaults too often during a major release cycle, but rather decide something and then go with it for a while. This would lead to fewer inconsistencies where some areas are adapted to the new look and others are not, and give us a more polished look. (I am fully aware that we don't major release that often)

In D12969#266503, @hein wrote:

Maybe we need to discuss things, especially also with https://phabricator.kde.org/D12463 where I have an interest in, on a broader scale.

Highlighting them in the menu is a good idea and it also is what Windows does (since quite a few versions)

In T8707#143200, @abetts wrote:

Well, I think I mentioned my arguments about not wanting to override what other applications do by force. Applications where we have no control over what they do and, more important, why they do it.

In T8707#142136, @ngraham wrote:

@Fuchs Can you think of any examples where #3 would cause actual regressions, or are the issues only theoretical?

Against 3) because the window manager will modify window content which apps are not designed or prepared for.
The rest is fine, with my usual "keep in mind that changing a default, in KDE, does override what existing users had and might have liked, please change as few defaults as possible and only where really needed".

Personally I prefer the group boxes as they add some vertical separation when multiple radio groups follow.

I like the idea in general, I agree though that, despite the severity, it is technically not an error and should not be shown as such, but rather a warning indeed.

In D12462#257021, @mart wrote:

In D12462#252987, @Fuchs wrote:

In D12462#252982, @mart wrote:

I like the idea a lot,
tough i am not sure i like the implementation: right now is kindof hortogonal to pinned tasks and gets confusing as it has a partial, but not complete overlap.
I think this should just be the behavior for pinned tasks, in order to map perfectly to the workflow of browser pinned tasks (and have only one option, pin task, instead of pin task and remove text)

Pinned tasks, right now, are bound to activities iff the amount of activities is >= 2. So these do different things (arguably current "pin" is badly named):

a task still, can be pinned to all activities, so still seems like an useless complication to me.

to me pinning should mean:

• i say what are the most important tasks to me (regardless if it's for one activity or for all activities)
• i want them always there, no matter whether running or not
• they stay always exactly in the same place (muscle memory) therefore can't have text and never move when they are started
  
  to achieve that, i should do one action, not 2, it looks like bad UI for me otherwise.

In D12462#252982, @mart wrote:

I like the idea a lot,
tough i am not sure i like the implementation: right now is kindof hortogonal to pinned tasks and gets confusing as it has a partial, but not complete overlap.
I think this should just be the behavior for pinned tasks, in order to map perfectly to the workflow of browser pinned tasks (and have only one option, pin task, instead of pin task and remove text)

On the existing bug: it's related to the TODO at line 1513, changing that to

In D12463#252419, @ngraham wrote:

This is a neat feature, but I worry that it would muddy the difference between the regular task manager and the icons-only task manager. It's not inconceivable that a user wanting to get an IOTM-style panel would resort to using this feature to force every single window to be icon-only.

Also needs https://phabricator.kde.org/D12463

happy fox now happy, says thanks :)

In D11201#231223, @ngraham wrote:

All right folks, how about this?

In D11201#228593, @abetts wrote:

I wanted to summarize our thoughts visually so far. I added a 4th idea of mine at the end of this image.\

Personal opinions, based on discussions here and on TG

In D11231#227114, @mart wrote:

I don't think screenshots of other (and potentially proprietary) apps should ever be used in our pages.
if on those telegram screenshots there are concepts we may want to reuse, we need to replicate something in qml, which looks not too close

+1, looks great to me.
Bit of duplicate control, but given there can be one at most, that seems fine to me.

In D11306#225695, @ngraham wrote:

I agree that consistency is important! For that reason, I would propose adding text everywhere. Buttons without text are inherently ambiguous unless their icons are perfect (and even a broom icon doesn't quite get there IMHO, though it's better). I know designers hate excessive text, but users appreciate the clarity and obviousness of buttons with text.

In D11306#225691, @ngraham wrote:

How about just "Clear" for the text? That should be short enough even in German, no? The word "history" is pretty redundant anyway.

In D11306#225671, @broulik wrote:

Do whatever you want with this button.

In D11306#225667, @broulik wrote:

Either remove the icon or put it on the right, then I wouldn't really mind this change.

Sorry, but clear -1 from me for the reasons outlined in the Telegram channel.

Please definitely no hover. Whilst I agree that some things get way too tailored for other form factors, this is not one of them. I just very recently discovered that the plasma theme chooser has a preview button that magically appears on hover, so I agree with that being hard to discover and user hostile.

Yes, I very much like the overflow and the usage you describe, as per the discussion on Telegram and https://phabricator.kde.org/D11231, I think mixer is however not an example where it should be used, because in the mixer it's not an overflow of functionality, but rather a menu on its own.

In D11261#224058, @abetts wrote:

In D11261#224056, @Fuchs wrote:

In D11261#224054, @abetts wrote:

We have discussed something like this before. My only worry with this implementation is that we have so much red on the screen that it becomes distracting. Not the fault of this patch, but I am wondering if there is a way that we can use a monochrome X button?

Both broulik and I would have prefered the trash icon, however, due to consistency ...

red, on the other hand, is good. It is a destructive action which can't be undone, so a bit of red doesn't hurt.

Then please use the same X icon at the top of the list, to clear all.

In D11261#224054, @abetts wrote:

We have discussed something like this before. My only worry with this implementation is that we have so much red on the screen that it becomes distracting. Not the fault of this patch, but I am wondering if there is a way that we can use a monochrome X button?

New screenshot with fixes

• Better hack for placement

• Change the layout import according to kbroulik

• Use Math.round() as per discussion

• Capitalized History in the tooltip label as per discussion

Screenshot:

Updated, I didn't see that old community wiki entry, that is of course way better. Linked until it gets ported, which also fixes the second comment as side effect.

• Link to the community wiki as per phab comment

Whilst I like the labeled one more than the current one, I can't say I'm a huge fan of either.