Can you maybe add the current look of Konsole to the task description above, so one can see directly what you changed?

In T12839#237958, @niccolove wrote:

In T12839#237957, @clel wrote:

This would be a nice addition. As I read it it introduces separate areas with separate margins. I wrote about a similar idea recently on a related GitLab issue. One thing to think about would be how many areas (two, three, more?) are sensible or whether one could easily change that in the future.

I think two is already a big number. I don't feel the need to go past that.

@yurchor I move the conversation here, since it seems to have nothing to do with the old task's topic anymore.

This would be a nice addition. As I read it it introduces separate areas with separate margins. I wrote about a similar idea recently on a related GitLab issue. One thing to think about would be how many areas (two, three, more?) are sensible or whether one could easily change that in the future.

In T12839#237949, @niccolove wrote:

I do have a touchscreen and the target is big enough to easily click. I think they do feel a bit small, but
a) It's not too small, and you can easily get used to it
b) it's weird that icons are this small. conventionally they should be 24px, but apparently iconSizes.smallMedium was decided to be 22px instead, and the svg contains an additional 2px margin meaning the actual icon is often 20px or even smaller. I think if all icons were 24px at least, the situation would be drastically better.

22px for the task manager look just too small imho. Also note the panel height should probably not be too small to make touch usage easier. I don't use it, but I think @ngraham mentioned that earlier.

In T13514#237941, @ltoscano wrote:

I already wrote it: a central place is needed so that

Thanks for those points. As I said, if you already wrote that, I'd also been happy with just a link to that.

In T13514#237910, @yurchor wrote:

In T13514#237909, @clel wrote:

Alright. Then I don't really understand what problems you have with Weblate. The things you wrote are too general for me to understand what the concrete problems are that you experience.

Sure. Just one thing that I do not understand is that people who do not really understand how the translation system works eagerly want to change that system.

Alright. Then I don't really understand what problems you have with Weblate. The things you wrote are too general for me to understand what the concrete problems are that you experience.

In T13514#237897, @yurchor wrote:

Weblate (as any online translation system) is still deadly slow compared to offline tools. On Hosted Weblate and Fedora's Weblate I witnessed constant git merge conflicts every week which should be resolved manually. This is a total nightmare for the KDE range of repositories number. Actually, I will have to prioritize some KDE translations because it is unrealistic to work with all of them through web interface (only ~15 minutes a day just to upload the translations, not saying about translating).

Weblate, Pootle, Wordbee, Transifex, Rosetta, etc. all tailored to leave several translations in a week or for *huge* teams.

In T11070#237890, @aacid wrote:

Maybe we should let actual translators define the requirements of what they need/want?

In T13514#237857, @ltoscano wrote:

Is there some other reference where it is described, why this will make things "much harder for the translators"? Basically you would in fact have one central location for all files, but per project. Ideally those could get summarized at a different place like Weblate maybe, so there is still a fast overview of all projects and languages needing attention for example. Not sure whether that is supported by Weblate, though.

Not everyone will use weblate and we would have tons of repositories. It is not a path

In T13311#237876, @aspotashev wrote:

Shall we discuss how the system is going to handle multiple translation branches (e.g. trunk/l10n-kf5, branches/stable/l10n-kf5, ...) ?

Here are the obvious options:

1. Use a web-based translation system that natively supports multiple "branches" for .po files. Does anyone know which of the listed systems have such support?
2. Enable PO Summit for all team, then wire the web system up to the .po files gathered (unified/merged) from all branches.
3. ...anything else?

In T13514#237756, @rempt wrote:

Um, yes, it is? Why else come up with "an other side of the argument"? In any case, problems with a practice we already support can hardly be relevant in discussing a practice we don't support yet?

@dkazakov I think the requirement is legitimate, at least this is the topmost task we currently have for improvement of the localization and the request seems to be in that scope. I also think that @ltoscano agrees reading his comment above.

Thanks for the insight. I also think there would be conflicts if somebody does a translation of a .po file, uploads it directly through SVN and at the same time translations for the same lines come from Weblate, correct?

Thanks @subins2000 for adding a report of your experience and also some documentation. I added this information to the task description.

In T13514#237694, @woltherav wrote:

Thanks! Maybe we should make this a subtask of that as well?

EDIT: especially because we're literally having duplicate conversations in both tasks :D

Another ping after over one year without action. Maybe the state of this issue is not really clear or the original author does not have time to implement the advise to their question. Still hopefully this can get continued soon, either way. @chinmoyr @broulik @bruns

Hopefully this can proceed soon, this seems like a pretty nice step towards better maintainability and consistency to me. Looks like all major work is already done and only some minor things need discussion or changes. @broulik do you have time to look at it again in the near future?

I'd vote for that, can you create a mockup? Also, is the workspace switcher next to it having any margins applied? Mine is alot more simple, so I don't really know how that would look like. Currently for me it uses almost no margins (and I think I like it).

In T12839#236882, @niccolove wrote:

2. a 44px panel with 22px widgets and 32px task manager (which would be consistent with applets who extend to panel margins, such as the pager)
   

In T12839#236864, @ognarb wrote:

For me unifying the size of the applets is not something we should strive for. The visual difference in the size of icons allows to communicate a visual hierarchy between elements, e.g. task manager icons are more often used than system trays icons.

In D26720#596999, @davidedmundson wrote:

This doesn't appear to be containment-aware (e.g. multi-screen, activities, etc).

As Kai said, changing status just to clean up the queue.

I was also under the impression that we wanted to perform crop and resize in the cached image to solve your other feature of only shipping 1 size with the distro.

Related to https://phabricator.kde.org/T11070?

In T11070#233717, @ltoscano wrote:

Integration with identity is a basic requirement for any new service; I don't think it needs its own ticket.

In T11070#192334, @lydia wrote:

The proposal is still focused a bit too much on the solution. What is it that we actually want to achieve? Make our software available to more people speaking different languages?

Although too late, since this might be revisited some day:

In T11743#203516, @mart wrote:

In T11743#202164, @IlyaBizyaev wrote:

From the point of users' love, this indeed is a very popular request, plus it's a good way to showcase Plasma's customizability.
https://www.youtube.com/watch?v=RX5HwumKPP8

It's a popular request, but my fear is that would end just providing things that look like cheap imitations (and can only be like that, neither we should spend more resources in changing our stuff in a way that looks more like imitations of other stuff) being potentially detrimental to our quality

I'm not against shipping different layouts in the global theme as default (i'm strongly against a new kcm tough) but i just fear that may damage the perception of quality so the message should be very clear that is *not* an attempt to provide the very same user experience

In T12308#216754, @manueljlin wrote:

dolphin with breadcrumbs inside view

I came across this from bugzilla. Apparently unfortunately there has not been anybody reviewing this until now. Is this still relevant? At least I hope it can get sorted out, soon!

In D28310#635217, @meven wrote:

We follow libinput maintainer opinion https://gitlab.freedesktop.org/libinput/libinput/issues/185 that the platform (or the toolkit) should implement this.

(sway compositor implements this https://github.com/swaywm/sway/pull/3018/files#diff-40846134db734aabaf9eb9e98bccab5eL1005)

It is an open issue for gnome https://gitlab.gnome.org/GNOME/gtk/issues/1308

We might want to let some apps the real "untouched" events, we could allow a "X-KWin-No-ScrollFactor" in their service file for instance.

@raddison If your comment was for me: I did not feel like the linked task represented the topic of my comment, so I went here, although already closed.

Thanks for your reply. My problem is that I consider this as some kind of Meta discussion that should be held. It contains some strategic decisions and I did not find a good place where to do this.

Hm, so if I was a developer thinking about implementing this then Phabricator is the right place?

Alright, thought this can be also used for discussions like https://phabricator.kde.org/T8187

In T7928#170247, @michaeltunnell wrote:

In T7928#170246, @clel wrote:

Do you have a source that the goal of Plasma default is to resemble the Windows look and feel?

Look at it. It looks like a modified Windows 10 in many ways, it has a bottom panel, start menu on the left and system tray on the right of the panel . . . like Windows. It doesn't matter if they intended it to or not, it does. However, yes I can give multiple examples. KDE has pretty much always mimic'd Windows in a way.

In T7928#170236, @michaeltunnell wrote:

There is a metric to use. Plasma default resembles Windows in look and feel. Windows uses double-click by default . . . millions of people expect it to be double.

Is this issue just for the selection "problem" of single click or also about other problems, (like some meta issue)? Because I'd recommend either being just about selection and then rename the title accordingly or to have it as a meta issue and then maybe only link the corresponding issues.

I came here from https://forum.kde.org/viewtopic.php?f=83&t=135696&p=408438 where I got when searching on previous discussions about making double click the default.

FWIW just to mention ist: single-click is consistent with the webpage/app behaviour and webapp/pages get more and more common.