- User Since
- Apr 9 2019, 9:23 AM (80 w, 20 h)
Mon, Oct 5
Sep 14 2020
Okay, thanks. I think I understand all the properties now.
Sep 4 2020
Just a little addition: If the documentation property exists we could use it instead of the description. This way we wouldn't have to worry about making sure they are in perfectly match with the other one. And then the descriptions still have a purpose, because inline help is still a TODO(while not the priority and there are other issues that have to be sorted out first).
Sep 3 2020
Sounds good 👍
Danke für die Blumen :]
But there is a help page that is actually useful: https://userbase.kde.org/Plasma/Krunner
That one is completely outdated, unfortunately :/
Sep 2 2020
Firstly: I think this is quite an important thing to solve. IMO most users would be interested in knowing at least the general purpose features of KRunner (like calculation, unit conversion, time zones, window switching) but will only learn about them if they are observant enough and find them by chance.
Aug 3 2020
Did you have any problems with software used? (BigBlueButton and Greenroom)
Jul 28 2020
The tweaked design in the mockup looks great.
Jul 14 2020
I think the rule is that things that are interactive give feedback on hover. The pointy finger cursor is the weakest form of such feedback because it doesn't communicate the size of the click target or what will happen on click.
I don't think we need the pointy finger cursor but should instead give proper hover feedback and this is AFAIK already what we are aiming for.
Jun 30 2020
In (Re-)Add tooltips using a contextual help button I am proposing a way how we could be replacing "What's This"-help in system settings with contextual help buttons in the future. I believe this is a right way forward for settings pages specifically because those pages' main task (aside from organisation of settings) is to communicate the effects of settings which is why buttons to display tooltips seem sensible to me here.
Jun 29 2020
You are certainly picturing a more demanding and nitpicky user than I am but those do exist. I wonder where those expectations you mention would be coming from but I agree that if an apple® fan installs Plasma with the preconception it can be made to be exactly like macOS they'll be in for a reality check. I don't really think the existence of a "Cupertino/Pear/Raincoat" theme would worsen that problem though. That's what I meant when I said "I don't think users actually expect that unless we market it as such."
Anyways, going with "some layouts using existing plasma stuff" is alright as well even though this feels like we would be needlessly limiting us from offering layouts that are tried and tested.
Jun 28 2020
Jun 26 2020
I can't quite remember if that was discussed before but I think we want all highlight effects on the panel to be the same in the long run. That would really help with the overall user experience imo. I don't think the first one would really work for task managers or at least some design work is necessary to make it work. Aside from the panel highlight aspect I don't really have an opinion on this but I encourage you to make a patch if you think it is an improvement. :^)
Jun 14 2020
Jun 13 2020
Jun 1 2020
I guess waiting for approval didn't go anywhere. I'll continue work on this soon then and I'll move it to invent.kde.org.
May 30 2020
The clock will be a lot bigger in most non-english speaking countries:
a relatively tiny clock
May 16 2020
This sounds good to me overall. I am not that familiar with the technicalities of the different scaling methods (which seems to be quite a difficult subject) so I can't comment too much on this. To me it looks like proposal 3, 5 and 6 depend on proposal 4 e.g. the 135% scale factor in proposal 5 should normally be avoided AFAIK.
May 9 2020
I think good tooltips and good UI should be enough.
So "1) Focus on comprehensive tooltips" it is?
+1 to this change.
Having the exact same panel and buttons on the left instead of at the bottom is a change that IMO even the most computer-illiterate Windows user should have no major trouble adapting to. Anyone else can change the panel position if they want to. In any case I can't picture a scenario in which it would stop someone from getting work done so I wouldn't be too worried about changing this default.
May 6 2020
I can see why you would think that those three would fit a bit better to Behavior. Concerning "switch between split view panes with tab key" I would prioritise keeping all three split view settings together and therefore not move it to Behavior.
Perhaps it could be a sub/page tab of Behavior called "Main window" or something.
I wouldn't be opposed to that but I don't think putting these two/three settings in their own tab in Behavior would overall be an improvement. Firstly it is difficult to find a common tab label for them that is descriptive. Secondly I do think they have enough connection to Interface to be there i.e. "rename inline" changes the Interface for renaming, "show tooltip" is a purely visual change.
I created a task.
Behavior (new top level page)
- Folders & Tabs
Show on startup: (X) Folders, tabs, and window state from last time (from Startup) ( ) [Select start folder location] (from Startup) Opening folders: [X] Open new folders in tabs (from Startup, I couldn't figure out what was meant by "new folders" without searching online. Maybe "Prefer tabs to new windows".) [ ] Open archives as folder (from _Navigation_) [ ] Open folders during drag operations (from _Navigation_)
May 5 2020
Alright. Seems like at best Filelight could make use of Dolphin's calculated sizes and even that is probably not worth the trouble. I was just thinking that Filelight was quite fast to calculate the recursive sizes of all folders on my SSD and if Dolphin just had this data this task would be done but that was apparently too naive a thought.
Would it make sense for this to share a directory size counting algorithm with Filelight?
May 4 2020
Apr 29 2020
Yes, feel free to edit the mockups in this thread at any time. Older versions are kept in the history anyways.
Apr 28 2020
Not so elegant with Numlock for one layout
Apr 27 2020
First of all: It's always great to see a new contributor! Welcome! :)
The keyboard KCM redesign is triaged to be high priority for a while now so a new mockup like this might give someone the inspiration they need to do it.
Here is some feedback on the placement of settings:
Apr 22 2020
Sure, take your time. :) An in-depth code review might not be necessary at the moment because the current implementation will change quite a bit if/when I implement meven's suggestion of having a DolphinUrlNavigator in the toolbar have direct control over the view. I am mainly looking for approval that you would be alright with me working on having the location in the toolbar as an option at all. And maybe you also have a strong opinion on the general approach for this.
Apr 17 2020
That's the kind of solution I was hoping for. With this idea I can see all KDE applications be it Dolphin, Marble, KDevelop or Okular use the same component although I know that that might seem like too much to ask for. There might still be some decision making necessary for specific applications to figure out which interface appearance would be best but as long as we would be using one component in the background all the groundwork would be done to facilitate easy switching between complete solutions if the situation calls for it.
I hope this idea will also work nicely on a technical level.
Apr 16 2020
Well, I guess that's one way to look at it. ^^ But I already feel like I was a bit bold when I created this patch and ignored Angelaccio's concerns so I wouldn't really want to put more pressure on him by continuing work on this. If I was hungry for more work right now I would be contributing towards the consistency goal.
Apr 15 2020
I'll have the icon removed for my next diff. Méven already told me the one-liner to remove it above.
Mar 30 2020
Anyway, I still think that the UX is more annoying and less informative at a glance than using the array of buttons.
Well, the problem is that we can't expect users to be able to identify window types by their icons. Maybe if we had icons as recognisable as for the desktop, the normal and the dialog window for all of them it would be alright but even then users might still want to hover over some of the other icons to be sure they selected the right one(s). This is especially difficult because some of the window types can seem similar like Dialog and Utility or Dock, Toolbar, Torn-Off Menu and Standalone Menubar.
There really needs to be a list with the actual names of the window types somewhere IMO. And while I don't think this ComboBox will win any design awards I do think it works well enough. There might still be a better way of doing this though.
I really like how easily the window type condition can be read when only one type is selected. I hope that covers the vast majority of use cases.
Mar 29 2020
Another way of solving this is to display what is selected as the text of the ComboBox like "'Normal Window' selected" or "5 selected". Here is roughly how this can be done: https://stackoverflow.com/questions/47575880/qcombobox-set-title-text-regardless-of-items (if you copy any code from this the file would need to be GPL 3 as part of a CC-BY-SA 4.0 one-way conversion AFAIK)
Mar 9 2020
I didn't know this idiom but I did feel the cold water. ^^ Thank you for reconsidering.
Feb 28 2020
I strongly disagree with the space conern. In many configurations putting the UrlNavigator into the toolbar actually increases the space available for the path. As an example in the following screenshots the information panel is open and the UrlNavigator in the toolbar therefore only has ~14 px (< 3%) less space.
Keep in mind that when split view mode is enabled the two UrlNavigators currently only get half of this space. Also keep in mind that the space in the toolbar can be greatly increased by removing unwanted buttons from there.
Furthermore this change mainly increases the available space of the view area.
Feb 26 2020
@manueljlin: Thanks! I hope so too.
I'm adding you're ideas to the task to-do list
I am happy to hear that!
I don't know easy or feasible is to map applications to its wmclass string
I was wondering about that. Hopefully there is an easy way. But ye, this is one of the things that can be done any time later I think.
- Only display conditions that are in use: I am a bit unhappy that I solved this differently than with the "Show all rules"-button. I went with the approach of adding/removing conditions because I thought having a checkbox to enable/disable conditions wasn't easy enough to understand. I especially thought this would be a problem when a new rule is created and the user is faced with five unchecked conditions.
I find your approach (Add/Remove) better from an user point of view, although the problem I see is how to present the possible effects that can be added to the user, that is, what happens when you press "+ Add.... Have you something in mind?
I was thinking about this some more but didn't come up with a way to solve this better than in my mockup. I think it might be fine though. For the "conditions" list the "Add conditions" button would have a dropdown with entries like "Add application condition", "Add window title condition", "Add window type condition", … This way no secondary window is necessary to create a rule. I would guess that most of the time only one or two conditions would be added this way and because there are only a few possible conditions to choose from a dropdown is a great fit here.
For the "rule effects" list the current behaviour has the same benefit of not making a secondary window necessary. The big list of possible "effects" needs to be somewhere and putting it in another window that spawns when clicking an "Add …" button wouldn't make the UI more understandable IMO (although this wouldn't be a bad way to solve this either). The workflow of activating effects in a rule by clicking its checkbox also makes sense IMO (contrary to the "conditions" list).
So yea, although it is a bit unfortunate to have two different ways to add objects to a list in the same window it might still be the best solution for the window rule modification/creation.
Feb 23 2020
This looks much better! Only showing preferences that are part of the rule by default for already existing rules is a good idea too imo.
Feb 21 2020
I didn't mean to discriminate. :P
Feb 20 2020
Add my copyright because I forgot
I want to preface this with saying that I greatly appreciate @elvisangelaccio's work. I am interested in working on Dolphin because it is such a great piece of software.
Nevertheless I went ahead and implemented moving the url navigator to the toolbar as an option. I was hoping that if I provide a decent implementation of this it won't seem that unmaintainable anymore. I have to admit it was more tricky than I expected but I think it worked out okay. Let's hope I succeeded. :)
Have a look:
I want to preface this with saying that this is not a push to ignore the maintainers opinion on this matter. I was hoping that if I provide a decent implementation of this it won't seem that unmaintainable anymore. I have to admit it was more tricky than I expected but I think it worked out okay.
Feb 13 2020
Feb 12 2020
It probably helps that they don't know much German yet. :)
I believe it does. :D I once was at one of their concerts.
Would yo like to open that task?
If it wasn't clear yet I really dislike grouping. So much so that I switch to a TTM when a grouped workflow would be necessary. So I am imo the wrong person to open a task for it because I wouldn't even be interested in using the improved version.
Even for the improved version I would still say that it is a similarly good default choice as the TTM.
However I would have some passion for switching to an IOTM if the target was to have an ungrouped IOTM on the left with the idea of my previous comment implemented because at this moment I feel like it might just be the best of both worlds. If that's ever what we are trying to accomplish you can count on my assistance. ^^
I like that as well. How would you want to handle menus then where tooltips don't show up currently? It could seem a bit redundant to hover Dolphin>Tools>Open Terminal and get a tooltip labeled "Open Terminal [linebreak] Show more". Well in most cases the tooltips aren't identical to the label so it wouldn't be that bad most of the time.
Feb 9 2020
That does sound like an improvement! Most of the time users want to switch to the window that they used last anyway so with this change they would only have to click the grouped entry once in this case. It would remain a bit awkward when jumping to the other windows.
I would say let's think about where users are supposed to find help and then we'll see if What's This is part of that solution. I see the following help "concepts" but I am unsure about the details:
Feb 1 2020
There is already an open task for this: T9986: Delete "What's This" inline help functionality. Maybe the discussion should continue there instead of having a second discussion here?
The discussion there also already covers that the "?" users are complaining about will be hidden by default for Dialogs with Qt 6.
Which KDE windows will then be left that show a "?"? I know of System Settings, Dolphin and KSysGuard.
- In System Settings the "?" is a usability problem imo because so many KCM don't have "What's This?"-help texts. Users might have tried to get help with the "?" and got nothing. We should probably just talk about System Settings instead.
- For Dolphin and KSysGuard it is good for usability I think. Well I wrote the "What's This?"-help for Dolphin so I am as biased as can be about that one but still.
- Kate also has "What's This?" for some items but doesn't show a "?" in the title bar. I doubt users complain about that one.
Jan 31 2020
Jan 30 2020
TL;DR: IOTM better for most users, TTM better when using many windows, IDK which should be default, maybe polling among KDE contributors would give us a clear answer?
Jan 10 2020
I do not share the concern that the toolbar will be too crowded when the path is added. Looking at the mockups I feel like there is enough space left even if we keep the current labels as they are. The path becomes a relative one anyways when there isn't enough space which isn't terrible. When this change was discussed in the VDG chat half a year ago there was a consensus that it looked better and I am pretty sure users will be happy with this change as well.
Jan 2 2020
@esokrates, I think that's a good idea. It does make sense to me to be able to collapse it even further. This would make a "Hide Sidebar"-button in a toolbar even less necessary. So consider it added to my proposal.
Nov 28 2019
Be aware that with the selected pictures alone people will not know what the conference is about if they don't know KDE.
This is a bit of a problem for the banner on the college website - but they are only a click away to find out.
This isn't a problem for the facebook event page.
Just something to consider if you are planning on actually printing a poster. I think my poster is still the best choice for this.
Nov 17 2019
This one isn't about contrast though is it?
The Breeze re-theming?
Nov 16 2019
@KonqiDragon, try to only quote things that are necessary to understand your comment. This way it's easier to keep the overview and readers don't have to scroll so much. :)
Nov 15 2019
Between opaqueness, blur, contrast and saturation it might be quite hard to figure out the best settings but this definitely already seems like a big step in the right direction to me. So many options!
Nov 11 2019
This is what I got so far. I hope it is up to par:
And here is the GIMP file I used (contrast/brightness changes not included):
I won't mind if anyone changes anything about it. So just go ahead if you are unhappy with anything.
Nov 1 2019
Those mockups look fantastic to me. I think it is because the colours have such a high saturation of the various colours that still fit together because wallpapers tend to have matching colours. The screenshots further down that are based on the actual semi-transparency that is commonly used look way worse to me because the background colour is de-saturated towards the base colour (white):
Oct 27 2019
Sep 22 2019
Sep 21 2019
I was mostly thinking about manual resizing by the user. In a picture:
Sep 12 2019
Some of the VDG people seem to be in favour of approach 1/1b and I think it definitely can work. But so far I still think having 2 as the basis is the best way forward. Here is a mockup that expands on 2 and @fabianr's comment.
Sep 7 2019
Oh okay. I understand. I only referred to the arrow removing step then.
Thanks for the analysis :) I still think we should get the change in with the current KToolBarPopupAction functionality (like Nate suggest), and then work on refining the user experience. But feel free to pinch in on the user experience part.
This is such a big discussion already. Which suggestion of Nate do you refer to specifically? I thought the current approach that shows indicators was denied.
Sep 2 2019
Current (?) one for comparison (from Kubuntu 18.04 since the one from Neon Unstable crashes for me)
I feel like there was a lot of thought put into the current design of the dashboard and the search field in particular:
- It does fit the style of having different logical parts of the dashboard purely divided by white space (and not by borders, lines).
- It makes very clear that typing will trigger the search while in your screenshot it looks like the search field doesn't have focus and typing might not trigger the search.
- In addition the size of the elements of the dashboard should loosely correspond to their importance. The search is arguably the most important feature of the dashboard. The way you changed it it seems a bit too minor to me.
I agree that the search as it currently is is inconsistent with how we display search fields anywhere else but it does fit with the rest of the dashboard. The overall style of the dashboard is pretty unique imo (for better or worse). So imo keeping the current search would be fine for now.
Aug 26 2019
Yes, that would be alright imo. That's actually mostly what I meant when I said
Aug 25 2019
@Leon0402 and I were just discussing this change in the VDG chat room so I'll write down some opinions I got.
Overall I think it is very helpful and elegant to teach the shortcuts within that combobox. We need to make sure though that the area description + default shortcut fits into a row in most locales.
If the user has changed the shortcuts to something that doesn't fit into the combobox I would favour simply not displaying the shortcut because in this case the benefit of teaching the user a shortcut is hardly there anymore. Making the dropdown wider is the other option but I'd imagine that might look kinda bad. This needs testing.
Aug 18 2019
I think it is fine having two actions that both open the Search/Findbar. The new 'toggle-search' would replace 'open-search' in the Toolbar and 'open-search' would still be associated with Ctrl+F.
This is similar to having two actions for typing a new location:
Making the names of the two actions more distinct might be enough to keep the users from getting super confused.
Aug 12 2019
Aug 10 2019
There wasn't much discussion about using the view mode button in the VDG:
Jul 28 2019
I kept the names lowercase because after trying both I liked them lowercase better. The visible difference between lowercase separator/spacer and title case actions makes the list a tiny bit more neat imo. I don't mind changing the names to title case though. Judge for yourself:
Rename to "expanding spacer", Cast to QToolBar instead
Jul 22 2019
You all are too kind!
Jul 21 2019
Use insertWidget(before, spacer) instead of addWidget(spacer)