Announcement

Collapse
No announcement yet.

Compiz Will Not Be Ported To Wayland

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

  • #41
    Originally posted by ChrisXY View Post
    If the fragmentation is so bad and it is so hard to release games for linux, how is it possible that every single humble indie bundle game does just fine while most of the developers hardly have the manpower to invest much time into that?
    What do you think you're doing here, with all your logic and reasoning?

    Comment


    • #42
      Good. Just that - good. Go Weston, go Openbox. A project of critical system component should be allowed to struggle only for a short period of time. Too long - it should die, as either the team is not up to the task or it needs to be re-written from the ground up.

      On a side note - overcomplicating a critical software layer just for the sake of visual effects should be punishable or made possible only via separate modules.

      As for the fragmentation. While you may disagree with this being a problem, but the point about wasting resources is still valid and there's nothing you can say to undermine that. Let's be honest. Vast majority of OSS projects are just for the sake of fun and their authors don't have think about the end results, nor the place of the project in Linux desktop let alone end-user.

      Canonical:
      Let's look at it from a different direction. How do they distribute their efforts?
      Upstream - near 0%
      In-house projects that serve no one but Canonical - a lot

      Comment


      • #43
        Originally posted by torturedutopian View Post
        Canonical could have made a difference by supporting massively GNOME for instance. They chose to make their own shell and shopping lenses instead of fixing essential existing stuff (to be fair, it's not that black or white, they also do)
        The problem is, of course, that GNOME upstream (whatever or whomever that might be; some people suggest it's actually just Red Hat ) did not agree with Canonical's vision on how Ubuntu/GNOME should work. So Canonical had 2 choices: following GNOME blindly (and listening to everybody complaining that they didn't contribute enough to GNOME while knowing that GNOME would likely turn down the patches they wanted included...) or implement their own desktop shell. And when they started to go for the second option, they found out mutter was not a usable choice back then (it also didn't become until several releases further), so they chose a solution that did actually work at the time... (but is presently proving to be less than ideal).

        Now, looking back at things, it would probably have been better if they could have worked together, but working together has to come from two sides, and it seems like right now the GNOME (Shell) people are still not wanting to actively work together with others (or at least, I don't see any other reason why the Linux Mint people would want to fork mutter).

        BTW: forks also happen in closed source software, usually when 2 partners disagree on the future of a project. Microsoft Windows NT & IBM OS/2 were forks of the same project, and so are Sybase's & Microsoft's SQL database servers (actually MS SQL Server forked from Sybase, itself a fork of the Ingres database which was also forked into several other commercial databases like Illustra/Informix and HP NonStop SQL). Illustrating that this is not only a problem with open source projects...

        Comment


        • #44
          Originally posted by johnc View Post
          It's kinda the same on Windows also. There are 400 million different applications that all do the same thing.

          Granted there is usually one that is a cut above the rest... but a lot of times those are coming from a corporation.
          OTOH, I know (knew) lots of open source & freeware applications that easily beat any commercial alternative for it on Windows (and Linux). Let's say that the software license does not imply any quality, and maybe that certain types of applications work better as open source (or freeware, for that matter) than others. Complicated specialist software means that the number of skilled developers is quite low, and as such a company might be able to ask lots of money for a working solution that is difficult to build by a couple of volunteers.

          BTW: Maya was mentioned here somewhere as an example of closed source software being better, but Maya actually depends on several open source projects like Python, Qt, etc., and where they don't use open source, like in l10n of text strings, their own solution is inferior to the common open source solutions.

          Comment


          • #45
            Originally posted by JanC View Post
            OTOH, I know (knew) lots of open source & freeware applications that easily beat any commercial alternative for it on Windows (and Linux).
            mplayer2 and XBMC being examples

            Comment


            • #46
              Originally posted by JanC View Post
              The problem is, of course, that GNOME upstream (whatever or whomever that might be; some people suggest it's actually just Red Hat ) did not agree with Canonical's vision on how Ubuntu/GNOME should work. So Canonical had 2 choices: following GNOME blindly (and listening to everybody complaining that they didn't contribute enough to GNOME while knowing that GNOME would likely turn down the patches they wanted included...) or implement their own desktop shell.
              Or they could've modified GNOME Shell by writing extensions or they could've chosen another existing DE like Plasma Desktop (for which Canonical wrote applets anyway to implement Ayatana things).

              Comment


              • #47
                Originally posted by Awesomeness View Post
                Or they could've modified GNOME Shell by writing extensions
                I could be wrong but I was under the impression that initially the extension-related stuff was fairly limited. It wasn't until a few releases in that Gnome shell developers decided to allow people to make more significant changes to the function and appearance of the shell.

                Originally posted by Awesomeness View Post
                or they could've chosen another existing DE like Plasma Desktop (for which Canonical wrote applets anyway to implement Ayatana things).
                As ROSA shows it is not very hard for a distro to ship their own alternative plasma interface. But so much of what Ubuntu relies on is Gnome-based it would be hard to just have the desktop environment use KDE. When frameworks 5 rolls around it will be easier, but that is probably still all least a year off.

                Comment


                • #48
                  Originally posted by TheBlackCat View Post
                  I could be wrong but I was under the impression that initially the extension-related stuff was fairly limited. It wasn't until a few releases in that Gnome shell developers decided to allow people to make more significant changes to the function and appearance of the shell.
                  I don't think GNOME Shell extensions were limited on purpose or anything like that. As more people developed extensions, GNOME shell developers accomodates the changes that were required but extensions always could practically do anything needed. The changes that were done was coming up with a more stricter flow so that the API doesn't have to change so often. In that sense, the extension framework has become mature but Canonical could very well have contributed their changes as extensions but my understanding is that they just thought going their own way gives them better control which is absolutely true but the maintenance headaches are quite large and this was something anybody who goes their own way learns after sometime. Unfortunately it appears that every organization including Red Hat, Novell, Google etc have to independently learn the same lesson. So either Canonical has to hire up or share the maintenance and development costs of the core technology pieces. It will be interesting to see which direction they go. So far it looks they prefer to got their own way which is a valid choice certainly.

                  Comment


                  • #49
                    A modular and extensible wayland compositor. Contribute to WayfireWM/wayfire development by creating an account on GitHub.

                    Comment

                    Working...
                    X