Announcement

Collapse
No announcement yet.

GNOME Ended 2013 With 46k Open Bug Reports

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #71
    Originally posted by Aleve Sicofante View Post
    Finally, the one big Unity issue, non-portability, is a bit of a myth. It looks to me like more an anti-Canonical stance than anything else. Pretty immature but so common in Linuxland... Unity is available in Arch, so if you can't have it anywhere else it's just because of the "let's bash Ubuntu" trend that every geek must follow lately, or so it seems.
    Unity is only available as non-official packages in Arch Linux, and only because some dedicated Arch users spend a lot of time providing all the Ubuntu-specific stuff. The Unity-for-Arch repository contains 67 packages as of right now, including patched versions of many system packages like gtk2, gtk3, qt4, compiz, zeitgeist, nautilus. There is also, as far as I can tell, several Arch specific patches in there.
    Arch official has a pretty strict policy of staying true to upstream instead keeping patches in the distro. Unless Unity/Ubuntu changes completely, Unity can never be available in official repos. "Portable"? Could be more so.

    Comment


    • #72
      Originally posted by valeriodean View Post
      No, it isn't.
      What "it" are you referring to?

      That statement is pretty correct, what that guy means about an UI that works equally well on different screens and input devices is much more than a simple resolution proportion.
      The problem is that he isn't saying that. He's just saying resolution independence is not the problem, when in fact it's the first problem a convergent design must approach. Not the only problem, but definitely the first you must tackle before even trying to solve the puzzle.

      Devices with different DPI but similar in phisical dimension represent a very different problem than devices with very different phisical dimension even if with similar DPI.
      Of course. That's why Canonical's approach takes typical viewing distance, screen size and proportions into the equation. Abstracting your UI objects from pixel resolution is the first and inevitable step, as I just said.

      A different DPI can be solved by a resolution proportion approach, where the usability of device with very different phisical dimension cannot be solved in the same way.
      We agree (and so seems to agree the Canonical design team), but the statement says nothing about that.

      Think about the unity side bar in the ubuntu touch, it takes about 1/5 of the smartphone's width in portrait mode, right?
      So, in a perfect resolution proprortion UI, when I go on my 29'' tv-monitor, I should see a side bar with a width equal to the 1/5 of the tv's width?
      Only you are talking about "a perfect resolution proportion UI". I'm not, the guy writing the article is not and the Canonical design team is not. Who are you replying to?

      A well designed UI makes the best use of the space available, so this statement continues to be true:
      Underlying technology can of course be re-used but you simply can not make a UI which works equally well on a 75 DPI 24" screen with mouse & keyboard, on a 455 dpi touch phone, on a 300 DPI touch tablet and a 64" television with Kinect or something like that...
      Hardly. There's nothing in that statement talking about "the best use of the space available". Not a single word. The statement is a strawman argument replying to no one. Nobody's proposing to use the exact same distribution and proportion of UI objects on every device. IMO the statement is only trying to dismiss the absolute need to make UI objects resolution independent. Instead, the article and the statement tries to diverge the attention to "let's build a wholly different UI for each device using the exact same 'technology' for all of them" and the position of the KDE developers is pretty much that one. They are building the same "underlying technology" (the "framework") to show a wholly different UI dependent on platform. This is probably the opposite of convergence, but since KDE people are usually not interested in what the user finally sees and uses but the "underlying technology", they tend to mix concepts easily.

      Just google for samples/demos of the Unity convergence. You'll see the same concepts on each device and a responsive design. Familiarity, muscle-memory and consistency is what it's all about (this has been the goal since the days of the Xerox Alto, by the way...). Of course, the "underlying technology" is also the same, that should be taken for granted. The problem with KDE devs is that they stop at the "underlying technology" step, because there's actually no design step being done before. Until KDE devs understand they must work AFTER designers, not BEFORE them, they'll never have a usable product. Someone would need to actually pay for UI/UX designers, though, and nobody seems inclined to invest on that front in KDE-land.
      Last edited by Aleve Sicofante; 11 January 2014, 09:56 PM.

      Comment


      • #73
        Originally posted by jonnor View Post
        Unity is only available as non-official packages in Arch Linux, and only because some dedicated Arch users spend a lot of time providing all the Ubuntu-specific stuff. The Unity-for-Arch repository contains 67 packages as of right now, including patched versions of many system packages like gtk2, gtk3, qt4, compiz, zeitgeist, nautilus. There is also, as far as I can tell, several Arch specific patches in there.
        Arch official has a pretty strict policy of staying true to upstream instead keeping patches in the distro. Unless Unity/Ubuntu changes completely, Unity can never be available in official repos. "Portable"? Could be more so.
        As the maintainer of those Unity packages, I agree with everything you said. I certainly wouldn't consider Unity as being portable In fact, without patched packages, Unity's top bar would be completely empty because none of the indicators will work and everything would be using the ugly GTK grey theme.

        Another thing Unity needs to work on is to stop relying on hacks. Right now, the Unity environment assumes that certain things will be loaded in a specific order. So if you try to open the GNOME Control Center from the cog icon in Arch, there will be no overlay scrollbars because the panel was loaded before certain environment variables were read. Ubuntu works around this by loading everything using Upstart user jobs instead of addressing the issue properly (eg. using a GSettings configuration option). Then you also have a patched gnome-settings-daemon package, which serves no purpose other than setting $XDG_CURRENT_DESKTOP to "Unity" so that other patched packages can detect if Unity is running. It's really quite a mess...

        EDIT: Oh yeah. For those who hated GNOME for the optional systemd dependencies, well, several Unity packages can't compile without Upstart or libnih (ha).

        Comment


        • #74
          Originally posted by TheBlackCat View Post
          Strange, then, that other DE's don't have this problem. You don't see plasma widgets breaking everywhere every release, in fact the plasma folks have pretty strict backwards-compatibility guarantees.

          In reality, it isn't that hard. You just need to think through the API beforehand. But that is the problem.
          It's not a technical problem. It is a design choice. Having a stable API mean you have to freeze the underlying capabilities (and possibly even implementations). Since GS is still moving forwards, and because extensions are free to modify pretty much everything that can be modified, keeping a stable API would probably be impossible, or at least not worth the hassle.

          You can compare this with the Linux kernel, where you can never expect your driver to work with a new version. Some think this is a limitation, while others claim it is one of the reasons why Linux is actually as good as it is, because you are free to move forwards without regrets.

          Comment


          • #75
            Originally posted by kigurai View Post
            It's not a technical problem. It is a design choice. Having a stable API mean you have to freeze the underlying capabilities (and possibly even implementations). Since GS is still moving forwards, and because extensions are free to modify pretty much everything that can be modified, keeping a stable API would probably be impossible, or at least not worth the hassle.
            Exactly. To go back to the examples I used earlier - the extension that modifies Alt-Tab behaviour has worked fine across multiple Gnome versions, because that functionality hasn't changed much. But the one that modifies one of the drop-down menus broke when I upgraded to 3.10 - because the entire menu it was designed to modify no longer exists due to the way the UI has changed. Is it reasonable to expect such an extension to not break in such a situation? Hardly...

            Comment


            • #76
              Kde ui

              As lot of people subscribing to this thread complain about the way "KDE" looks (whatever they mean, as KDE is a community developing software and not software), I would like to know what part they are complaining about.
              For that I would like to cite myself from a previous comment made on page 2 of that thread:

              Originally posted by GEO1 View Post
              ...
              Which components are you talking about? The icons? (at the point I can agree that the are not the best looking ones, but definitely not the work of a teenager ..., just the style is outfashioned and not very pretty imho...)
              Oxygen theme? (At this point I have to strongly disagree, as the theme is very polished and well designed (though people complain about the grey color scheme that can be changed very easily))
              Plasma? (I cannot believe this looks like designed by a teenager ... It is very well designed and very flexible in terms of design. Have a look at http://dot.kde.org/sites/dot.kde.org...p-calendar.png)
              Default config? (Maybe the default config may not be the best, with settings like icons on buttons and in every menu ... but that can be disabled in Systemsettings/Application Appearance/Style/Fine Tuning)

              So I would like to know which component you are talking about... I suspect the icons, as they really destroy the appearance of the whole desktop imho.
              Try to disable icons in menus and on buttons, switch the icon theme (to example KFaenza which can be found on KDElook) and maybe if you do not like it, change the color scheme and believe me, you will look at something very different from an antithetical point of view.

              So a quick feedback of what could be done better in terms of UI would be appreciated.

              P.S.: Please stop talking about KDE. KDE is a community, not a dekstop environment. Do you mean plasma? applications? icons? etc.
              So you have to separate between unrelated topics. Nobody knows what you mean by "KDE" speaking in the context of software. I mean, in practice it is pretty clear: You download a distribution featuring KDE software, that means having plasma and kde applications installed with default config and default icons and all other things developed by KDE community.
              The same applies to speaking about stability: Just because a KDE application like for example Kmail crashes does not mean all KDE software is unstable. That is the problem with most people: They do not separate as it is certainly easier to find a common name for everything and if one component is bad, everything is bad. If we were not talking about software but about humans most of the people who comment here would be pretty racist.
              The KDE community is very strong, but there are different people who focus on different things. Why should Kwin or Dolphin be bad because KDEPim was unstable during the transition to Akonadi?
              Artwork again is different from applications. So you cannot call the applications bad because of for example bad icons.
              So to be honest, a statement like "KDE 4.12 is still unstable and unusable" makes no sense at all if you understand what I am trying to point out.
              Of course everything is kind of related because it is distributed under a common brand, KDE, but generalizing does not make sense.

              So the feedback I am hoping for is pointing out, which component is bad in terms of usability/design for you and again, a statement like "KDE applications have bad usability" makes no sense, you have to say which one ...

              And yes, there are areas that need work like the mentioned DPI Independence, but the developers are aware (look at https://community.kde.org/KDE/High-dpi_issues) and of course there are forces trying to improve the general usability and aiming for consistency (have a look at http://techbase.kde.org/Projects/Usability/HIG).

              No project is perfect, but people need to separate. I think the same applies for the Gnome side (but I cannot speak for those, as I have to less knowledge and experience with Gnome)

              Comment


              • #77
                Originally posted by chenxiaolong View Post
                Another thing Unity needs to work on is to stop relying on hacks.
                Do you think these hacks will still be there with Unity 8? Where they there with the old "Unity 2D"? I bet it all has to do with the peculiar idea of implementing a DE as a plugin to a window manager, Compiz, but then I'm no developer.

                I understand the whole Unity implementation is hacky, but its whole point is being a progress in usability and convergence with mobile devices, not so much a clean codebase. I guess the upcoming code should be cleaner and more "portable". I'm not a developer so I usually don't care much about how something is made as long as it works for me as a user, but I can appreciate the effects of cleaner code. I'm pretty sure the lack of customization in Unity comes both from a will to keep it "standard" AND the difficulty of removing all the hardcoding in it. I hope the new codebase addresses these issues, but if you ask me, I'll choose better usability before a clean codebase any day.

                Comment


                • #78
                  Originally posted by GEO1 View Post
                  As lot of people subscribing to this thread complain about the way "KDE" looks (whatever they mean, as KDE is a community developing software and not software), I would like to know what part they are complaining about.
                  For that I would like to cite myself from a previous comment made on page 2 of that thread:



                  So you have to separate between unrelated topics. Nobody knows what you mean by "KDE" speaking in the context of software. I mean, in practice it is pretty clear: You download a distribution featuring KDE software, that means having plasma and kde applications installed with default config and default icons and all other things developed by KDE community.
                  The same applies to speaking about stability: Just because a KDE application like for example Kmail crashes does not mean all KDE software is unstable. That is the problem with most people: They do not separate as it is certainly easier to find a common name for everything and if one component is bad, everything is bad. If we were not talking about software but about humans most of the people who comment here would be pretty racist.
                  The KDE community is very strong, but there are different people who focus on different things. Why should Kwin or Dolphin be bad because KDEPim was unstable during the transition to Akonadi?
                  Artwork again is different from applications. So you cannot call the applications bad because of for example bad icons.
                  So to be honest, a statement like "KDE 4.12 is still unstable and unusable" makes no sense at all if you understand what I am trying to point out.
                  Of course everything is kind of related because it is distributed under a common brand, KDE, but generalizing does not make sense.

                  So the feedback I am hoping for is pointing out, which component is bad in terms of usability/design for you and again, a statement like "KDE applications have bad usability" makes no sense, you have to say which one ...

                  And yes, there are areas that need work like the mentioned DPI Independence, but the developers are aware (look at https://community.kde.org/KDE/High-dpi_issues) and of course there are forces trying to improve the general usability and aiming for consistency (have a look at http://techbase.kde.org/Projects/Usability/HIG).

                  No project is perfect, but people need to separate. I think the same applies for the Gnome side (but I cannot speak for those, as I have to less knowledge and experience with Gnome)
                  Your post describes perfectly well why KDE will never be very usable. There are a lot of "forces" without leadership, without criteria. There's just no design whatsoever, except for (probably) beautifully clean code that serves no other purpose than to be an engineering achievement.

                  That "of course there are forces trying to improve the general usability and aiming for consistency" is astonishing and also explains quite well why KDE is unusable: DESIGN comes first, then comes CODE. In KDE it's always the reverse. Some folks can get close to an orgasm by looking at KDE's code or the sheer number of options, switches and configurations they have at their disposal. Most people, though, will choose something that's easy and consistent and don't give a damn about what's below. (I happen to think both UI/UX design and code are important, but if I had to choose, I'd obviously choose focused UI/UX design over a clean codebase. I'm a user -not a developer- and I'm not a masochist...)

                  Of course individual apps can't be called good or bad because of KDE, but you say "people need to separate", when it's actually quite the opposite: "KDE needs to concentrate, to focus". Focus on design, obviously. And I'm talking about end user usability design, not "design patterns", which is probably what most KDE devs understand by "design".

                  Comment


                  • #79
                    Originally posted by Aleve Sicofante View Post
                    Your post describes perfectly well why KDE will never be very usable. There are a lot of "forces" without leadership, without criteria. There's just no design whatsoever, except for (probably) beautifully clean code that serves no other purpose than to be an engineering achievement.

                    That "of course there are forces trying to improve the general usability and aiming for consistency" is astonishing and also explains quite well why KDE is unusable: DESIGN comes first, then comes CODE. In KDE it's always the reverse. Some folks can get close to an orgasm by looking at KDE's code or the sheer number of options, switches and configurations they have at their disposal. Most people, though, will choose something that's easy and consistent and don't give a damn about what's below. (I happen to think both UI/UX design and code are important, but if I had to choose, I'd obviously choose focused UI/UX design over a clean codebase. I'm a user -not a developer- and I'm not a masochist...)

                    Of course individual apps can't be called good or bad because of KDE, but you say "people need to separate", when it's actually quite the opposite: "KDE needs to concentrate, to focus". Focus on design, obviously. And I'm talking about end user usability design, not "design patterns", which is probably what most KDE devs understand by "design".
                    Calling KDE SOFTWARE "unusable" is not the right expression, just because of the lack of consistency. (BTW, you just called an community unusable again ...) .
                    So you call KDE community working without leadership, which is right, but still they try to work as good a possible together. Who would be the leadership of GNOME? As far as I know the only project having strict guidelines and a leadership is Unity and the core applications.
                    Does it make a project unusable, just because its community is very open?
                    Apart from that, you will never be able to use 100% consistent software, because if you want that you would have to ditch all other applications not explicitly designed for that environment, because it may differ in its design.
                    For example Gnome client side window decoration may look beautiful with applications that support it, but all other application with no support for it differ which is again not consistency.

                    And I have to disagree with "UI design first, then implementation", as Plasma Workspaces for example try to move to QML, where application logic and design implementation can be separated very well. Furthermore the trend is going to having one application with multiple interfaces for different from factors. Starting with the UI design first does not make that much sense to me.

                    With "people need to separate" I did not mean the people of the KDE community, but people here judging KDE software, as they do not separate between different applications, workspaces (DEs) and UX elements (icons, theme, etc.).

                    I hope the KDE usability project reaches more developers and will therefore succeed. There will always be individual developers that refuse to accept guidelines, but that will exist in every open community and guidelines are guidelines not rules.

                    In terms of themes KDE software comes with pretty great consistency: The oxygen theme looks pretty good for KDE/QT/GTK applications.
                    There are of course exceptions like firefox or libre office that use strange toolkits and therefore do not support gradients used by the oxygen theme.
                    Here one can again see one fundamental problem with "design vs. consistency": The oxygen gradients are beautiful imho, but not all toolkits support it. So from a design point of view it is nice, but it will add a bit of inconsitency. Same goes for the aforementioned Gnome client side decorations.

                    Comment


                    • #80
                      Originally posted by Aleve Sicofante View Post
                      Do you think these hacks will still be there with Unity 8? Where they there with the old "Unity 2D"? I bet it all has to do with the peculiar idea of implementing a DE as a plugin to a window manager, Compiz, but then I'm no developer.
                      Why do you think the code will be cleaner this time around? The Unity and Ubuntu teams seems to always be in a hurry, always willing to cut corners. Focusing almost entirely on "next week", "next release", "make a splash", "time to market" is what causes hacks to pile up. One also needs to continiously improve things that only have value long term*. Right now, it seems to me as an outsider that they prefer throwing things in the trash when too much junk has piled up and start over again (and again...).
                      The creation of Mir looks like a symptom of the same problem.

                      * to be fair, this is not an easy thing.

                      Comment

                      Working...
                      X