Announcement

Collapse
No announcement yet.

The Leading Linux Desktop Platform Issues Of 2018

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

  • #41
    Originally posted by DMJC View Post
    Sadly this article doesn't address the giant elephant in the room: GTK C++ development is horrible. There is no way to auto-connect callbacks (Signal Handlers) to class member functions (Methods) automatically using glade. So in a large project, you have to write thousands of lines of boilerplate code to do simple gui development. This hampers attempts at writing complex GUI Applications. The alternatives are to use C, and have to manage god awful C style strings, and memory a lot closer, which IS harder and leads to more errors.
    https://www.gtk.org/language-bindings.php
    You see quite a few GTK Vala applications. GTK is designed around C not C++ and it comes very clear when you attempt C++ development with GTK it hates your guts the complete way. Vala was based off the ideas of C# but purely designed around the gobject system that is the base to GTK.


    Originally posted by DMJC View Post
    Or learn QT's bastardisation of the C++ language,
    QT is use on windows and other places because it nicer than native at times.

    Originally posted by DMJC View Post
    learn GNUstep and Objective-C, which is an unstable programming environment and completely alien to most programmers. Programming on GTK/QT/GNUstep is still awful in 2018, and the developers are making no moves to address these problems. Sure there are great apps written by great developers on the Linux Desktop, but the lack of easy to use APIs has severely restricted the complexity and type of software that gets written.
    Really I am not sure I think you have suffered from tunnel visioned assessment on GTK at least.

    Avoiding C++ also avoids when using opengl having a fight with mesa drivers at times with their usage of C++. So Vala and GTK is very good combination.

    The reality is graphical programming on most platforms is a pain in tail. You can make your life harder by attempting to use incompatible languages.

    GTK C or Vala would be your top choices. Like you cannot attempt QT with pure C. Some of the lack of more well known easy to use API is advertisement most programmers you ask them what Vala is you get a blank response.

    Comment


    • #42
      I agree with his points that library paths should be standardized across distributions, as well as providing common set of library and versions to retain backwards compatibility. Otherwise, binaries stop working unless recompiled and repackaged.

      Comment


      • #43
        Originally posted by oiaohm View Post
        https://www.gtk.org/language-bindings.php
        You see quite a few GTK Vala applications. GTK is designed around C not C++ and it comes very clear when you attempt C++ development with GTK it hates your guts the complete way. Vala was based off the ideas of C# but purely designed around the gobject system that is the base to GTK.



        QT is use on windows and other places because it nicer than native at times.



        Really I am not sure I think you have suffered from tunnel visioned assessment on GTK at least.

        Avoiding C++ also avoids when using opengl having a fight with mesa drivers at times with their usage of C++. So Vala and GTK is very good combination.

        The reality is graphical programming on most platforms is a pain in tail. You can make your life harder by attempting to use incompatible languages.

        GTK C or Vala would be your top choices. Like you cannot attempt QT with pure C. Some of the lack of more well known easy to use API is advertisement most programmers you ask them what Vala is you get a blank response.
        I've used GTKMM which is the C++ language binding for GTK across a few projects now. And for the most part it's actually quite pleasant for development. If you are entirely developing your application using C++/GTKMM there's no issue, and for small applications it's very functional using sigc++ to handle binding your signal handlers. Having said that. When you want to use a WYSIWYG gui editor (e.g Glade) to cut down your development time with designing/laying out GUI, there is no way to connect your callbacks automatically from your layout to the code. This is pretty core functionality of a WYSIWYG editor. It almost doesn't make sense to bother having support for loading glade files using GTKMM with that function missing. As the only benefit to using the WYSIWYG editor from that point is to play with layouts. You will waste the same time rewriting your signal handler functions to load the UI from glade and then manually binding each callback that you'd spend writing your UI entirely in code. This could be fixed, quite simply by updating Glade and GTKMM to support connecting signal handlers to class methods, and allowing you to define a class method as a signal handler in the Glade editor. Now the only reason I've seen given for not doing that is some crazy notion given by some of the developers (several people have submitted patches and feature requests to fix this) That all gui's made in glade have to work across all language bindings glade supports, even though you would not want to reuse a glade interface file across multiple languages in the one project. E.g why would you bother loading a UI in python and C++, or C and Objective-C at the same time, to access the same dialogs? That is just nutty. In that case where insanity prevails, Glade should be forked into Glade and GladeMM (which would handle Object, orientated languages). Because not allowing class methods to be used actually breaks signal handler autoconnection in C++, C#, and Objective-C, Which all have language bindings for GTK. I think you are changing my opinion of this problem though. I think, maybe responsibility for it should be shifted away from Glade and moved to gtkmm. They are responsible for maintaining the API bindings so maybe they should maintain the WYSIWYG editor for GTKMM as well. It just feels lame that Glade needs a fork/rewrite to add a feature that could have been a checkbox option.
        Last edited by DMJC; 07 October 2018, 09:26 AM.

        Comment


        • #44
          Originally posted by tildearrow View Post
          I don't understand the "type in something" sentence
          Type in something means - there are about 7000 languages and 7000 ethnicities in this World, but just about 200ish countries, etc... So, if something is not in language majority understand, then you can do that whatever that is instead of just pushing and clicking

          System76 Purism etc

          The problem is that they are niches
          Don't worry, be happy Oxford's english is also niche in comparison to simple english, but you would like to require it, isn't it?

          If you want stable distribution across the world, you or at least your huge aparatus need to understand these 7K base differences in about 200 varying packaging formats Since all that is near impossible or at least very complex to know, people tend to design OS as simple as possible for that audience, because if something does not work on click, tap or push so on a very base and simple mechanics and also every time, majority of users just tend forget about it

          Instead, when you wanna push for software freedoms, free software or whatever like that, then it is pretty much understandable of course what would happen You see, with all kind of freedoms pushing to have 300 distributions of Linux is nothing much, i expect there should be about 7K and now you know from where that number comes from

          Some corporation needs to push Linux on Desktop about 15-20 times harder, if we expect Year Of That to happen
          Last edited by dungeon; 07 October 2018, 10:27 AM.

          Comment


          • #45
            Originally posted by xiando View Post
            I also see a large number of packages in a distributions repository as a strength.
            As long as people like you are around which see it as a "strength", it will probably never go above 3% market share at best.

            This is another problem he probably forgot to mention here: the community.

            Comment


            • #46
              Originally posted by oliw View Post
              He's spent time writing solutions for a problem he perceives and that's fair enough, but centralised, managed updates and stable long-term support for a single major version of an application is a major feature, especially for enterprise deployment.
              Nobody gives a shit about enterprise. Thread title says Linux DESKTOP. D.E.S.K.T.O.P. Platform Issues.

              Anyone who disagrees with him is contributing to the cause of Linux being in such poor state on the desktop. And no, some of us really don't care at all about enterprise or servers. Make a single fucking distro for that (Red Hat) and that's it.

              We're complaining about DESKTOP DISTROS.


              Also for other fanboys, bring on the pitchforks and start spewing ignorance about how Windows also suffers from the same issues and "DLL Hell" some more please. Because no it doesn't, not to the extent that Linux does anyway. Win32 is a stable platform to target, Linux is not.

              Comment


              • #47
                Originally posted by dungeon View Post
                The leading linux desktop platform issues of 2018. are the same as in year 2004.
                Its market share is also probably just as pissful so it makes sense.
                Originally posted by dungeon View Post
                So move on, there is no issues
                So you're saying that it will forever be stuck with such shit market share on the desktop?

                Comment


                • #48
                  Originally posted by GI_Jack View Post
                  We already have Linux Desktops. They already work great.
                  No they aren't, that's the whole point of this thread. If they were working great, this thread wouldn't exist.

                  Comment


                  • #49
                    Originally posted by oiaohm View Post
                    Lets start with something basic lets look at windows. Visual studio runtime on windows of all things contains the C and C++ libraries the application use but that is not the same libc the host system uses. This requires you to be careful and free stuff the right way or stuff goes to hell under windows. Libcapsule is looking at ways of doing this without having this memory nightmare. But the reality is splitting userspace into host and user one does not work and application need to match host versions.
                    You don't have to be careful at all, you just don't have to be a retard to free a pointer with your own library allocated by another library.

                    Originally posted by oiaohm View Post
                    Now is there a correct solution to all these problems. The answer is shim like libcapsule is doing.
                    libcapsule is only needed on Linux due to how ELF is a retarded braindead fucking piece of hot garbage designed format. In fact what libcapsule does is impossible on DLLs unless the app specifically targets libcapsule (which means recompilation). It's not even needed on DLLs.

                    Your "correct solutions" are only solutions to a problem created by a shit design of ELF in the first place. Don't act like Windows suffers from the same garbage.

                    Originally posted by oiaohm View Post
                    Flatpak is not using a sandbox for no reason because mixing libraries depending on incompatible library versions is the path to hell without something like libcapsule to split dependency trees.
                    Only with ELF.


                    Here's a better solution: Either use DLLs on Linux (like Wine does), or REMOVE THE FUCKING GLOBAL SYMBOL NAMESPACE from ELF.

                    Comment


                    • #50
                      Originally posted by brrrrttttt View Post
                      That is exactly the problem with Windows. Every application needs to be managed separately, and every application implements it's own gimped upgrade mechanism which annoys me every time I run it.
                      That's the best thing about it. This bullshit mentality of "applications are part of my computer install or the system/OS or tied to a drive" needs to die in a fire.

                      Applications need to be placed on a USB drive, backed up with 2 clicks, and ran from anywhere, on any PC with Linux (or Windows).

                      Anything else is an infestation of retardation. (such as the Windows registry and "installing" applications, which is almost 100% of them in Linux, but at least Windows has far more "portable apps")

                      Comment

                      Working...
                      X