abetts (Andres Betts)
User

Projects

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Friday

  • Clear sailing ahead.

User Details

User Since
Sep 15 2015, 7:12 PM (144 w, 7 h)
Availability
Available

Recent Activity

Yesterday

abetts added a comment to T9042: Kickoff improvements.

I like those improvements. Let's explore them.

Tue, Jun 19, 7:25 PM · Plasma, VDG
abetts added a comment to T7913: Make it really obvious where newly-installed apps can be found.

Right on! What do you we need to make this a reality?

Tue, Jun 19, 5:34 PM · VDG
abetts added a comment to T8753: Launcher Menus Convergence.

Let's work on it!

Tue, Jun 19, 5:29 PM · Plasma, VDG
abetts added a comment to T7913: Make it really obvious where newly-installed apps can be found.

I love the idea and I think it has a lot of potential. We have the chance to solve a very recurrent and old issue with our desktop. I think we need to move forward with this and also the HOME tab idea. Users will find their important items closer and faster. I would only ask that we also add the red dot to the tab with the new items. Just in case our users want to reorder their tabs and Home is not first. Also to have a fast clue into new items. Is that possible?

Tue, Jun 19, 5:28 PM · VDG
abetts added a comment to D13552: [Properties dialog] Improve some permissions-related strings.

+1

Tue, Jun 19, 2:19 PM · Frameworks

Mon, Jun 18

abetts added a comment to D12961: Updated alignment, keylines, messures to new radio button layout and the new qml formlayout.

I agree, our controls are pretty big and need more breathing room.

Mon, Jun 18, 11:33 PM · KDE Human Interface Guidelines
abetts added a comment to T7913: Make it really obvious where newly-installed apps can be found.

I would be in favor of that plus a special visual look for those items.

Mon, Jun 18, 8:34 PM · VDG
abetts added a comment to D13593: [Fonts KCM] Improve user-friendliness of some anti-aliasing strings.

Sometimes it's better to be precise about well-known technical terms instead of hiding them. Would a person who does not know what anti-aliasing is want/need to change that setting?

Mon, Jun 18, 7:28 PM · Plasma
abetts added a comment to D13481: Recommend window border size "None".

+1

Mon, Jun 18, 2:24 PM · Plasma
abetts added a comment to T7913: Make it really obvious where newly-installed apps can be found.

Great! Do we have any lenience to a specific design?

Mon, Jun 18, 2:20 PM · VDG

Sun, Jun 17

abetts added a comment to T9036: Checkboxes in mixed-control layouts.

Here's Dolphin's Startup page (roughly) converted to that style:

Sun, Jun 17, 9:45 PM · KDE Human Interface Guidelines
abetts added a comment to T9036: Checkboxes in mixed-control layouts.

I see what you mean. I agree. The sentences don't always lend themselves to the layout. In this instance, let's not be afraid of having no label and leaving a set of hanging checkboxes, because in the end, the natural grouping will help the user understand what the settings are about. In this case I would suggest using something like:

Sun, Jun 17, 7:36 PM · KDE Human Interface Guidelines
abetts added a comment to T9036: Checkboxes in mixed-control layouts.

I think we are forgetting one thing that was present in the KCM redesign mockups and we are not applying to this discussion.

Sun, Jun 17, 6:46 PM · KDE Human Interface Guidelines

Sat, Jun 16

abetts added a comment to T7913: Make it really obvious where newly-installed apps can be found.

Ping?

Sat, Jun 16, 10:13 PM · VDG
abetts added a comment to D12571: Modernize Settings window.

Don't they control how the view appears on startup?

Only "Split view mode" does. The other ones control things that are outside the view. How about using "On startup:" and rewording the sentences on the checkboxes where necessary?

I was using the term "View" from a user perspective. I think to people who aren't Dolphin developers, these are view settings. The technical distinction between the view, its container, and the main window are not relevant to users, or important to understand.

I disagree, but that's not the point anyway. Using "view" here would be just wrong. Why not using "window" instead?

Other comments on the UI before looking at the code:

  • In the Startup page, what does "Location" refer to? The groupbox made it clear it was the Home folder, now we are hiding this information.

"Home folder" has an established meaning: it's your user's own home folder. Using the label "Home folder" always seemed to imply that you could change your home folder, which was not true. In fact, this setting simply controls what folder dolphin shows on startup. The fact that you're on the "Startup" tab I think does a good job of suggesting that the settings on this page control Dolphin's behavior and appearance when it launches. Maybe I could add a small label at the top of the window explaining that?

Fair enough. How about "Start in:" ?

  • The Confirmation tab now is better but still confusing. I don't see why we need to touch it at all honestly, given that there are only checkboxes in there.

I feel like there's resistance to the visual design conception itself. I'm getting the feeling that you simply don't like the labels-on-the-left paradigm itself. Perhaps we should address that rather than arguing over individual examples of its application.

Guys, this work has been going on for a long time on something rather simple in aligning the settings design to what Plasma is doing. There should not be this much resistance to the change. Can we please move forward with the approval?

Honestly I'm quite disappointed to read this.

I can assure you there is no resistance to the visual design change from me.
Is it true that I don't particularly like it and I'm sad that my feedback was ignored, but if that's what the VDG wants, so be it.

But this patch currently has still issues (in particular, the Confirmations tab) and will be approved only when it's ready.

Sat, Jun 16, 5:17 PM · Dolphin

Fri, Jun 15

abetts added a comment to D12571: Modernize Settings window.

Guys, this work has been going on for a long time on something rather simple in aligning the settings design to what the rest of Plasma is doing. There should not be this much resistance to the change. Can we please move forward with the approval?

Fri, Jun 15, 2:03 PM · Dolphin

Thu, Jun 14

abetts added a comment to T8854: Smooth Screen Brightness Level Transition.

It would be very nice! I have things to do that will take 1-2 month. If nobody interested till then, please ping to me. I can work on it.

Also we should talk about the details imho. It will be a nice transition but also it should be fast so the design details are important.

Thu, Jun 14, 10:04 PM · Plasma, VDG
abetts added a comment to T7270: Boot splash (kinda done).

I thought the grid layout was applied to it. Am I wrong?

Thu, Jun 14, 8:01 PM · Plasma: KCM Redesign
abetts added a comment to T7251: Mouse.

Awesome!

Thu, Jun 14, 8:00 PM · Plasma: KCM Redesign
abetts moved T8871: Systematic KCM reorganisation from Medium priority to WIP on the Plasma: KCM Redesign board.
Thu, Jun 14, 7:58 PM · Plasma: KCM Redesign, VDG
abetts closed T8546: Pholio mock of every KCM as Resolved.

This is done! Now creating a new version visual template style.

Thu, Jun 14, 7:57 PM · Plasma: KCM Redesign
abetts moved T7270: Boot splash (kinda done) from Medium priority to WIP on the Plasma: KCM Redesign board.
Thu, Jun 14, 7:56 PM · Plasma: KCM Redesign
abetts moved T7251: Mouse from High priority to WIP on the Plasma: KCM Redesign board.
Thu, Jun 14, 7:55 PM · Plasma: KCM Redesign
abetts added a comment to D13543: Treat scrollbar as overlay.

+1

Thu, Jun 14, 4:40 PM · Konsole
abetts added a comment to D13542: [effects/slide] Add "Slide desktop background" option.

+1

Thu, Jun 14, 4:35 PM · KWin
abetts added a comment to D13534: Change the 'Dismiss all notifications' icon.

The icons are almost identical. Maybe a different icons can help? I believe we have a standard mute icon and a "find" or "search" icon as well.

The icon will definitely need to be improved !

Thu, Jun 14, 3:20 PM · KDE Connect
abetts added a comment to D13534: Change the 'Dismiss all notifications' icon.

Could the buttons on the top right be a toggle instead? Except the directory icon, of course.

The left red button comes from a local patch that mutes notification that I did not send for review yet. It's not related to the other button that correspond to the 'Find my phone' feature. Sorry for the confusion.

Thu, Jun 14, 3:16 PM · KDE Connect
abetts added a comment to T9020: Standardized Templates for KCMs.

What we need is standard templates for the basic styles that are emerging:

  • "A grid of tiles from which you choose your preferred one" (colors, theme, icons, etc)
  • "A roughly centered column of controls" (mouse, touchpad, launch feedback, bluetooth)
  • "A list of re-orderable items, with the top one being the preferred/favorite one" (language, any others?)
Thu, Jun 14, 3:08 PM · Plasma, VDG
abetts added a comment to D13534: Change the 'Dismiss all notifications' icon.

Thu, Jun 14, 3:06 PM · KDE Connect
abetts updated the task description for T8871: Systematic KCM reorganisation.
Thu, Jun 14, 2:39 PM · Plasma: KCM Redesign, VDG
abetts updated the task description for T9020: Standardized Templates for KCMs.
Thu, Jun 14, 2:38 PM · Plasma, VDG
abetts triaged T9020: Standardized Templates for KCMs as Normal priority.
Thu, Jun 14, 2:38 PM · Plasma, VDG
abetts added a comment to T8985: KCM Template in QML.

Visually, I'm not a huge fan of how those sub-labels and sub-fields break the alignment pattern. What's the application for them? Are they even needed at all?

Thu, Jun 14, 2:34 PM · Plasma: KCM Redesign
abetts added a comment to T8854: Smooth Screen Brightness Level Transition.

Ping anyone?

Thu, Jun 14, 2:30 PM · Plasma, VDG
abetts added a comment to D12278: WIP: [Colors KCM] Port to new design.

Ping? Is this KCM doing alright?

Thu, Jun 14, 2:29 PM · Plasma
abetts added a comment to T8985: KCM Template in QML.

Here is a first mockup that can help!

Thu, Jun 14, 2:26 PM · Plasma: KCM Redesign
abetts added a comment to T8871: Systematic KCM reorganisation.
Thu, Jun 14, 2:12 PM · Plasma: KCM Redesign, VDG

Wed, Jun 13

abetts updated the task description for T8871: Systematic KCM reorganisation.
Wed, Jun 13, 4:50 AM · Plasma: KCM Redesign, VDG

Mon, Jun 11

abetts added a comment to T2027: VDG: Add high contrast cursor theme.

I do feel though that the breeze pointer could use sharper edges. Maybe even to the 1 pixel. The current form being somewhat round doesn't really help looking precise.

Mon, Jun 11, 4:52 AM · VDG, Plasma
abetts added a comment to T8871: Systematic KCM reorganisation.

Pretty interesting and I agree. There should not be a whole lot of navigation. My .2 cents are that we make also our search very prominent. I can make mockups based on your suggestions Nate.

Mon, Jun 11, 4:48 AM · Plasma: KCM Redesign, VDG
abetts added a comment to T8985: KCM Template in QML.

Let me know if I can help with anything

Mon, Jun 11, 1:26 AM · Plasma: KCM Redesign
abetts added a comment to T8753: Launcher Menus Convergence.

How does this relate to T3833: LiftOff - an idea for a new launcher? Should we subsume the proposals and mockups from there into this one, or move this discussion over there?

Mon, Jun 11, 1:24 AM · Plasma, VDG

Fri, Jun 8

abetts added a comment to D13390: Fonts KCM: Fix text readability regression.

Maybe this is for another ticket, but... can we make the field where the font is named the actual field where you select the fonts from?

Fri, Jun 8, 2:19 PM · Plasma

Wed, Jun 6

abetts added a comment to M112: System Settings Alpha Graphic Redesign.

I agree, the user doesn't know what to expect.

Wed, Jun 6, 7:52 PM · KDE Developers, VDG
abetts added a comment to D13215: FrameSvg: Recache maskFrame if enabledBorders has been changed.

What can we do to help this patch move forward @zzag ?

Wed, Jun 6, 3:22 PM · Frameworks
abetts added a comment to D13284: [decorations] Let KDecoration plugins recommend a border size per default.

What I'm concerned about is accessibility. Accessibility in the case of users who learned that they need to hover over the border of a window. In case of an adjacent window they get the resize handle of the window, but it resizes the other window. This is totally unexpected and I wouldn't know how to explain this to my mother.

Even worse is the situation of two inactive windows not bordering but shadows overlapping. There is then no visual hint at all which window is going to be resizes.

Wed, Jun 6, 4:41 AM · KWin

Tue, Jun 5

abetts added a comment to D13284: [decorations] Let KDecoration plugins recommend a border size per default.

No border won't help for Kirigami apps running outside of Plasma and won't help with a change of the decoration.

It will.

That thread is an absolute mess, but underneath it's a really simple problem that's been very poorly explained and evidently poorly understood.

  • Kirigami looks fine with a border. It is not broken outside of the Breeze decoration on Plasma.
  • Breeze is using a clever hack to make it look like there is no visual border even when one is set. This behaviour relies on a false assumption and therefore results in things looking broken.

    That is the part we need to finish so it's done properly. I'm fully on board with this patch that does it on a per theme basis.

something something Accessibilty

Breeze currently has no visual borders.

If you set breeze style to no size borders and you add to breeze

BreezeStyle::polish() { if (widget->isWindow() { widget->setContentMargins(2,0,2,0);}

QWidget apps will look pixel for pixel identical.

Tue, Jun 5, 7:56 PM · KWin
abetts updated subscribers of D13284: [decorations] Let KDecoration plugins recommend a border size per default.

Nevertheless I want to add that I still think that switching to no border is IMHO the wrong solution to the problem the VDG wants to address. No border won't help for Kirigami apps running outside of Plasma and won't help with a change of the decoration. In addition I see an accessibility issue. With no side borders it's difficult to recognize which window will be resized for adjacent windows.

This may not be entirely true if the window selected keeps a shadow underneath. The selected window will overshadow the window adjacent to it. Therefore, you will see that one is selected and which one is not. The one that is selected will get the focus, so will the ability to use the border handles to resize. If you want to resize the other window, in this example, you click on it to give it focus and the borders activate for the user to resize.

yes. So something you could do in one click, you now do in two clicks, and by targetting a region which is outside the window you want to resize. In my humble oppinion, this is not "simple by default".

Tue, Jun 5, 7:40 PM · KWin
abetts added a comment to D13346: Use more contextual strings for some button labels.

In D13346#274446, @abetts wrote:
Could we have a button that enables/disables bluetooth instead? We can show the warning message only if it doesn't seem to be working? or for example, if it runs into an error when enabling, "then" show a warning sign?

Thoughts?

A switch like you mention will function perfectly in this case. Possibly positioned in the same line with the title (next to it or at the right) so then the text and button are not necessary anymore. Also functions in the same way as the tray widget(which has a check box instead of a toggle, but it's close enough)

Tue, Jun 5, 7:07 PM · Plasma
abetts added a comment to D13284: [decorations] Let KDecoration plugins recommend a border size per default.

Nevertheless I want to add that I still think that switching to no border is IMHO the wrong solution to the problem the VDG wants to address. No border won't help for Kirigami apps running outside of Plasma and won't help with a change of the decoration. In addition I see an accessibility issue. With no side borders it's difficult to recognize which window will be resized for adjacent windows.

Tue, Jun 5, 7:06 PM · KWin
abetts added a comment to D13346: Use more contextual strings for some button labels.

Red is for errors, orange is for warnings, and blue is for information. The red is not as harsh as it used to be, but do you think orange would be a more appropriate color?

Tue, Jun 5, 6:52 PM · Plasma
abetts added a comment to D13346: Use more contextual strings for some button labels.

I feel this is a must. We are trying to convey that the user needs to enable Bluetooth in order to make it work. There is real issue there. In fact, could we maybe change the color message from RED to something more informational?

Tue, Jun 5, 2:37 PM · Plasma

Mon, Jun 4

abetts added a comment to T8707: Window borders.
In T8707#146165, @hein wrote:

Sorry, I don't have time to take screenshots currently. The proposals in the text can be mimicked with seperate settings also mentioned there. I'll not summarize them here again because I don't think it helps if no one actually reads the full big picture :).

Mon, Jun 4, 9:32 PM · VDG
abetts added a comment to T8707: Window borders.
In T8707#146163, @hein wrote:

Let's approach it from a visual point of view, perhaps.

Let's consider a window sans any decorations, i.e. the client area rectangle. Our system provides clients with a system color palette. The system color palette contains a window background color. The expected default case is that the client area rectangle is solid-filled with the window background color, or something visually close to this (Oxygen used a gradient fill).

Now, window decorations. The system palette also contains a color for window title bars. Typically, this would be a color that contrasts from the window background color. Decorations now broadly-speaking have two choices when it comes to putting a border around the client rectangle on all sides: They can have this corder visually extend the client rectangle by filling the border with the window background color, or they can make the border have contrast to the client area by using the title bar color.

Breeze colors borders using the window background color. Plastik uses the title bar color.

Classic widget-based apps for the most part - though not fully - work OK with both. What constitutes "working" vs. "not working"? It's mostly about the window bg color borders case and whether the edges of the client area content have widgets along them that are designed to exist in a sea of window background color or not. For example, take a standard list view with a standard rectangular frame: It's designed to embed into a fill of window bg, so a border color that extends this sea is OK. What doesn't work, on the other hand, is edge-aligned widgets that expect the edge to terminate in a contrast color, i.e. either no border or a contrasting border. An example of this in classic widget apps is putting QTabBar in "document mode", which hides the tab widget frame and makes the tab bar baseline run the width of the widget and terminate by cut-off. This has always looked visually very awkward with both the Breeze and the Oxygen decos, so this is not a new problem.

Now we have to contend with a growing variety of applications that do whole lot of things like QTabBar does in document mode. They eschew frames, and they will run hard-contrasting horizontal and vertical lines right up to the edges of the client area, expecting it to terminate in contrast. These applications include our own Kirigami apps, but also many third-party apps shown earlier in the ticket.

Where is this design trend coming from? Mobile. On mobile, there are no window borders: There's only the screen edge, which provides hard contrast, and it's OK to run things up to the screen edge. As a result, there's now an entire zoo of new common widgets (such as drawers, etc.) and visual conventions that are designed around this assumption.

I think this design trend isn't going to go away. In particular, I don't think we want to redesign Kirigami's widgets to work any differently. I don't see the gain, and at this point I think it'd ill-serve users who have built up new familiarity and skills using this UI generation.

This means we have two options: We can either do away with window background-colored borders (arguably this was always a misuse of the system color palette) and go with no borders, or we can make the borders a contrasting color.

I get the feeling most of us don't want a contrasting color border, or we wouldn't have switched from Plastik to Oxygen and then Breeze. This hasn't been our preference for a long time now.

So, what option if not "No borders" is there really?

Then there's the whole IMHO only tangentially related (it's a wholly seperate design question!) question of whether windows should have rounded corners at the bottom or not. Personally, I don't find these important. With my engineering hat on, meanwhile, I don't find them feasible: Masking the client area is IMHO not acceptable, which means they could only be done by using CSDs with participation of the clients. We don't want CSDs for various usability/accessibility/technology reasons, and that we could get all clients to use them consistently is a pipe dream, considering the slow, hard-fought process of getting even "assume SSDs" standardized so far.

Mon, Jun 4, 9:25 PM · VDG
abetts added a comment to T8707: Window borders.

I'm really sorry for how this discussion turned out, everyone.

I'd like to propose a do-over for this discussion, and this time I promise to involve all stakeholders, listen honestly, and not pre-suppose a particular solution. How does that sound?

Mon, Jun 4, 8:59 PM · VDG
abetts added a comment to D13141: Touchpad KCM Redesign Using Kirigami.

+1

Mon, Jun 4, 8:50 PM · Plasma
abetts added a comment to D13334: When using a different background color, use highlightedText as text color.

Looks great! I don't have any suggestions.

Mon, Jun 4, 4:33 PM · Kirigami
abetts added a comment to T8899: Utilities.

I think for photos, we already have a basic gallery. Vvave can be used as a music player.
For the rest, tasks seem to exist already: https://phabricator.kde.org/project/view/28/

Mon, Jun 4, 4:10 PM · Plasma: Mobile (PM 1.0)
abetts added a comment to T8899: Utilities.

Can other possible apps be added to this list? I feel there can be a few others that are very useful to have by default:

Mon, Jun 4, 2:25 PM · Plasma: Mobile (PM 1.0)
abetts added a comment to D12571: Modernize Settings window.

Sorry but now there are even more visual regressions than the original revision had.

This started as an attempt to drop groupboxes, but now I see a lot of unrelated and debatable changes (e.g. why touch the checboxes at all?).
I suggest to go with small and incremental changes instead.

Mon, Jun 4, 3:29 AM · Dolphin
abetts added a comment to M112: System Settings Alpha Graphic Redesign.

I got plenty to do! Thanks Nathan.

Mon, Jun 4, 3:14 AM · KDE Developers, VDG

Sun, Jun 3

abetts added an inline comment to M112: System Settings Alpha Graphic Redesign.

@hein Can I ask to please list the changes we have decided on that require that I update the mockups? I know we have a few, but I am not sure that I know all of them. @ngraham Can you point those out to me as well please? I will work on a smaller KCM mockup subset to show the updates.

Sun, Jun 3, 8:26 PM · KDE Developers, VDG
abetts added a comment to T8707: Window borders.

@ngraham it looks weird at the top where the titlebar and the sideborder contact
How about a nice gradient between them?


(This would be just a breeze specific change)

Sun, Jun 3, 7:43 PM · VDG

Sat, Jun 2

abetts accepted D13278: Keep default border value in line with KWin's setting.

+1

Sat, Jun 2, 1:42 AM · Plasma
abetts accepted D13277: Turn off the extended resize handle/black triangle when there are no borders.
Sat, Jun 2, 1:40 AM · Plasma
abetts accepted D13276: Display "No Borders" by default.
Sat, Jun 2, 1:39 AM · KWin

Fri, Jun 1

abetts added a comment to T8707: Window borders.

Assuming we can live without rounded bottom corners, all we want to do here is change a user-facing default. That isn't a technical solution. It's a visual tweak that is absolutely under the purview of the VDG.

You had a problem and you had requirements. You did not check with the experts on how to achieve your requirements and instead came up with an own solution. Whether we call that user-facing default or technical solution is just quick-quack. The thing is you didn't ask me on how to achieve this. And I'm quite disappointed that I as author of the code and maintainer was not consulted and that my requests for rethinking were met with what felt to me hostility.

I as maintainer of the component and author of the relevant code disapprove the change and think more work is required. You can decide for yourself which way to follow. Take a step back and work with the domain expert for a solution meting your requirements or change the user facing default.

Fri, Jun 1, 7:49 PM · VDG
abetts added a comment to T8707: Window borders.

I appreciate the discussion and insight. We won't be able to have rounded borders at this time, but we can work on them in the future. Instead, we should still proceed with no borders.

Fri, Jun 1, 3:56 PM · VDG
abetts added a comment to D13215: FrameSvg: Recache maskFrame if enabledBorders has been changed.

+1 on this! Love it!

Fri, Jun 1, 2:01 PM · Frameworks
abetts added a comment to D13154: [effects] Improve the Scale In effect.

I support this patch

Fri, Jun 1, 3:59 AM · KWin

Thu, May 31

abetts added a comment to D13155: [effects] Add Scale Out effect.
In D13155#271278, @zzag wrote:

In general I'm against adding new effects to KWin and would rather prefer to remove effects such as scale in.
I think everything which is not default should be on store.kde.org and not added to KWin directly.

I don't agree with you about store.kde.org part. Scale animation is _really_ basic thing and if someone has to go somewhere on internet to get it, I think that's a problem. That's like GNOME Shell, you have to install a bunch of third-party plugins/extensions to get basic things (like system tray, etc). No hate about GNOME or GNOME devs, etc.

Maybe, it would be better to create kwin-extras repo(like kio-extras) and dump these effects there.

Thu, May 31, 2:27 PM · KWin

Wed, May 30

abetts added a comment to D13154: [effects] Improve the Scale In effect.
In D13154#271077, @zzag wrote:

I am not sure how. I am running git dev unstable. Would it show if I do an update?

No-no, I am about videos, I re-recorded them. See summary for this diff and D13155. ;-)

Wed, May 30, 7:54 PM · KWin
abetts added a comment to D13154: [effects] Improve the Scale In effect.
In D13154#271054, @zzag wrote:

@abetts I recorded the Scale In effect and the Scale Out effect at higher frame rates with the default animation duration(160ms). Could you please check them?

Wed, May 30, 7:44 PM · KWin

Tue, May 29

abetts added a comment to D13202: Circular user avatar for Kickoff.

It doesn't look any different to me. They are both the same. Maybe the screenshot is too small? I can see the pixels from far on both images.

Yeah, the same to me as well. The screenshots are natural size from my 1920x1080 screen. I'll keep looking for options, features, settings, mystic spells...

Tue, May 29, 9:00 PM · Plasma
abetts added a comment to D13202: Circular user avatar for Kickoff.

AA option not set

AA option set

Does the second option look dramatically better or different?

Tue, May 29, 8:56 PM · Plasma
abetts added a comment to D13192: Implement a triangle filter for mouse events on the Kickoff tabbar.

While that's true, it would represent a significant change to the interaction pattern. I'm not totally against it, but I think we should try out the triangle filter here first and see if that's good enough.

Tue, May 29, 8:37 PM · Plasma
abetts added a comment to D13192: Implement a triangle filter for mouse events on the Kickoff tabbar.

If we removed the hover interactivity, I would want to see the buttons' appearance become distinctly more button-like or tab-like so that people can figure out that they're clickable. But honestly I don't mind the hover effect right now. Is there any particular reason why you'd like the buttons to require a click?

Tue, May 29, 8:21 PM · Plasma
abetts added a comment to D13192: Implement a triangle filter for mouse events on the Kickoff tabbar.

Could a different approach work here? No change on hover, but just on click? The user controls the entire action.

Tue, May 29, 7:37 PM · Plasma
abetts added a comment to D13202: Circular user avatar for Kickoff.

The one visual improvement I could think of is adding a thin light gray outline around the circle to help separate it from the background. This is done on the login and lock screens; might be able to mine those implementations for ideas, if it's not too hard. But even without that, this is looking good. :)

The bordered avatars are done in a different manner than this (mine involves less math!). I'll see if there's a way I can sort it out.

By the way, visual gurus: "light gray" or theme-specific color?

Tue, May 29, 4:45 PM · Plasma
abetts added a comment to D13202: Circular user avatar for Kickoff.

Nice work! Will test it out later today.

There's no reason to have the appearance user-selectable, IMHO. Part of the goal here is a consistent visual appearance. I vote for always showing the round avatar and marking this as fixing Bug 386656.

The one visual improvement I could think of is adding a thin light gray outline around the circle to help separate it from the background. This is done on the login and lock screens; might be able to mine those implementations for ideas, if it's not too hard. But even without that, this is looking good. :)

Tue, May 29, 4:40 PM · Plasma
abetts added a comment to D13202: Circular user avatar for Kickoff.

+1

Tue, May 29, 4:34 PM · Plasma
abetts added a comment to D11848: [Kickoff] Reduce hover delay before switching tabs.

Could a different approach work here? No change on hover, but just on click? The user controls the entire action.

Tue, May 29, 2:11 PM · Plasma

Mon, May 28

abetts added a comment to D12992: New elisa icon.

@abetts Yes, I've been concepting a little on different ideas but not really coming anywhere I feel would fit in.

Looks great!

As for the background, when I think of soundwaves I think of something that would be produced by a visualizer, or a sine wave.

Did you make the letters yourself or is it a font? I'm asking just in case the font is licensed.

Mon, May 28, 7:35 PM · Frameworks, Elisa
abetts added a comment to D13154: [effects] Improve the Scale In effect.
In D13154#269748, @zzag wrote:

Love it! Is the effect going to be that slow?

No, it will be faster. On the videos, I set animation duration to 5s(default is 160 ms) to see clearly what effects are doing.

I'm afraid that increasing animation duration changes overall feel of the scale animations. Recording these effects with the default animation duration(160ms) is a little bit challenging for me. It would be great if you could test them by yourself and give me some hints on how to improve them.

Mon, May 28, 5:31 PM · KWin
abetts added a comment to D13155: [effects] Add Scale Out effect.

I like it. It is very smooth. How fast is it?

Mon, May 28, 4:57 PM · KWin
abetts added a comment to D13154: [effects] Improve the Scale In effect.

Love it! Is the effect going to be that slow?

Mon, May 28, 4:56 PM · KWin
abetts added a comment to D13154: [effects] Improve the Scale In effect.

Can you also show an example of what this would do to the shutdown screen? Before and after please?

Mon, May 28, 3:41 PM · KWin
abetts added a comment to D6280: Dolphin softer drop shadow for thumbnails.

+1

Mon, May 28, 3:39 PM · Dolphin
abetts added a comment to D12992: New elisa icon.

I think we are trying hard to accommodate and the elements are not lending themselves to turn them into an E with some musical tones. I reviewed a few music sheets looking for commonalities. I feel also that the icon is busy, it is trying really hard to tell you that this app is about music. I feel we can simplify and provide other ideas.

Mon, May 28, 12:39 AM · Frameworks, Elisa

Sun, May 27

abetts added a comment to D13141: Touchpad KCM Redesign Using Kirigami.

As for wanting to making this non-scrollable: in general, we should aspire for the main views of our KCMs to never require scrolling (subviews like tables are okay, of course). It's very awkward to able to scroll a UI that's packed full of UI controls. It can even introduce issues since some controls respond to scroll events; it becomes easy to accidentally manipulate a control via a scroll event when you means to just move the view. Let's shoot for keeping all the content fully in view with a 1024x768 window size.

Sun, May 27, 6:07 AM · Plasma
abetts added a comment to T8721: Make Color Picker in System Settings Color Module Pick Colors from Any Area on Screen.

Either I'm not understanding your request properly, or the color picker does work as you're requesting. See the following YouTube link - video is too large to upload directly to Phab.

https://youtu.be/pB9RophlRJs

Sun, May 27, 6:05 AM · Plasma, VDG
abetts added a comment to T8871: Systematic KCM reorganisation.

I would also submit to have a section for either OTHER, or GENERAL, or MOST FREQUENTLY USED.

Sun, May 27, 6:03 AM · Plasma: KCM Redesign, VDG

Sat, May 26

abetts accepted D11848: [Kickoff] Reduce hover delay before switching tabs.
Sat, May 26, 3:35 AM · Plasma
abetts added a comment to D11848: [Kickoff] Reduce hover delay before switching tabs.

+1

Sat, May 26, 3:32 AM · Plasma

Fri, May 25

abetts added a comment to D12571: Modernize Settings window.

Looks good to me!

Fri, May 25, 10:00 PM · Dolphin

Thu, May 24

abetts triaged T8854: Smooth Screen Brightness Level Transition as Normal priority.
Thu, May 24, 3:41 PM · Plasma, VDG
abetts added a comment to D12571: Modernize Settings window.

I've decided not to play with the location of the Navigation settings in this patch and use it only for layout clean-up. We can play with that in a follow-up patch.

Thu, May 24, 2:41 PM · Dolphin
abetts added a comment to D12571: Modernize Settings window.

So VDG has decided to use with the "labels on the left" style going forward (reflecting what was already going on with Plasma and the System Settings KCM redesigns), and the HIG is being updated to reflect this. I'm working on all the pages here to modernize them, including the trash page, which comes from KIO: D12986

What do folks think about the {nnav Nvigation} top-level category? Right now it only has two checkboxes in it. How do people feel about removing that category and moving those checkboxes onto the Behavior page, like this?

Or does that feel like there's too much stuff in there?

Thu, May 24, 2:20 PM · Dolphin

Wed, May 23

abetts added a comment to D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup.

Should we also add a symbol on icons to say that they are non-dangerous ? (even if not a menu ?)

In fact, we already do signal danger by using red icons for potentially destructive actions.

My thoughts come from a more foundational level. At ground level, to signal or not signal that the menu does or doesn't open a new window or a dropdown menu is irrelevant because the user doesn't care for what happens with the button prior to clicking it.

I think we've come to the real question: does the user click on the button even if they can't work out ahead of time what it does? If they do, then signaling isn't very important, because they will learn by doing. But if they don't, then it's important to provide as many signals as possible so we can coax them into feeling comfortable enough to click on it in the first place.

This is part of the icon's job, after all: to signal what it will do if you click it. That's why we design our icons first and foremost to be clear and descriptive rather than abstract and artistic. In my mind, the downward-pointing arrow is just an extension of this logic.

Wed, May 23, 9:03 PM · Plasma
abetts added a comment to D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup.

'Fraid I gotta disagree with you on this one, @abetts. I think it's important to signal that these buttons will bring up a menu because without that, there is no way to distinguish it from an ordinary action button. It's the same reason why comboboxes have arrows rather than looking like a pushbutton.

But there's a deeper reason. With the downward-pointing arrow, users are signaled that the button doesn't initiate an action (which may be unknown, non-undoable, possibly dangerous, etc), but rather displays a menu of textual, easy-to-understand options. In essence, the arrow says, "this is safe, go ahead and click me even if you don't know what I might do". Without the arrow, fearful users might avoid clicking on the menu button because they don't know what it will do and nothing hints at them that the button brings up a benign menu rather than immediately executing a possibly unknown action.

Wed, May 23, 8:48 PM · Plasma