• 1 Post
  • 2 Comments
Joined 3 months ago
cake
Cake day: June 29th, 2024

help-circle
  • Here is my take:

    1. Stability - I’d say very important, especially for a DE that is used by a lot of people as a daily driver.
    2. Customization - IMO this isn’t a simple yes/no question. It shouldn’t be about the number of settings exposed to users but rather the number of “useful states” a user can achieve.

    Let me give you an example with the multiline Icons-and-Text Task Manager. Of the main DEs I’ve tested, KDE is by far the most customizable and provides many related options, resulting in lots of different combinations (states). However, with none of those states I can achieve what I think would be much better (see my recent post here). My proposition is of a completely new alternative layout. I don’t think that can be efficiently achieved by simply adding a bunch of “partial” settings (such as, for example, a checkbox for keeping the rows at fixed height), because going that way would result in:

    • Many more potential combinations (different possible states). And an increased % of those would be unnatural (not very useful & confusing) to the end user.
    • Increased complexity of the code that tries to handle all the possible combinations (hence, more potential for bugs).

    So for the multiline task manager, I don’t need most of the current settings, so I could say I don’t need a lot of customization. But what I’d love to have is something that is currently not available, and that in itself could be interpreted as “a need for (another) customization”.

    Finding the “right” amount and type of customization is the key, but that’s very hard. Largely because making changes gets increasingly harder at the later stages. And also, what is “right” is subjective, of course.


  • To further illustrate my point, here are some more screenshots of the current layout:

    As well as what I think would look better:

    This is a completely different perspective from the current “grid” layout. The idea here is:

    • We have exactly N rows.
    • We have a list of “items”, where an “item” is either a pinned (unopened) icon or a button for an opened application/window with a title (will call it “button” here for short, can’t come up with a better term).
    • The row height should never change while opening/closing windows (applications).
    • The width of (unopened) icons should never change.
    • The width of “buttons” should be determined dynamically, depending on the number of items and space available. But I imagine that it should start from something like 300 px - something that could be considered wide enough to display “enough” of the title text (maybe ‘px’ is not the best unit, but just to illustrate the point), and only decrease the width when needed (i.e. no space left).
      • In the simple case when N=1, let’s say the available space is with width W units, there are P pinned icons and their width is K units, then the available space for all “buttons” could be calculated with something like buttons_total_space = (W - (P*K)). To get the target single button width, we could do something like button_width = min(300, buttons_total_space / buttons_count) (not sure if the case of “too small button_width” should be handled in any special way - IMO probably not worth it).
      • To handle the N>1 case, the formula would become more complicated of course, as it would need to account for different available horizontal space in each row and figure out how many buttons to put in each row. For example, if N=3 and we have 8 pinned unopened icons, they will probably fit in the first row. Then we might end up with, say, 480px left in the first row and 800px in the other two, so if we need to distribute 10 buttons, we might decide to put 2 buttons (with width 240px) in the first row and 4 buttons (with width 200px) on each of the remaining 2 rows.