Announcement

Collapse
No announcement yet.

Multi-Process Support For GTK's HTTP Back-End

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

  • #11
    Originally posted by drago01 View Post
    No.
    No.
    And No.
    Why not?
    Maybe only pure GTK apps work?
    Maybe software with dependency on X11 does not work?

    Comment


    • #12
      Originally posted by newwen View Post
      Speaking of Wayland remoting, I have come across some Microsoft patents filed between 2008 and 2011, related to the Remote Desktop Protocol describing the intented remoting solution for wayland. I hope devs read them carefully so they can come up with a solution that circunvents them.
      DO YOU READ THE NEWSPAPER???

      The patent damages against Marvell were TRIPLED because they READ THE PATENTS CAREFULLY.

      The moral of the story is to NOT READ THE DAMNED PATENTS.

      IGNORE THE PATENTS.

      And of course you PRESUME that these patents have some sort of VALIDITY to them!

      But you can just IGNORE all that with your FUD!

      READ THOSE PATENTS! GET SUED! LOSE YOUR MONEY! What a troll you are.
      Last edited by frantaylor; 28 December 2012, 11:05 AM.

      Comment


      • #13
        Love this community

        Comment


        • #14
          Emscripten-Qt

          A little off-topic, but I've recently been working on something broadly similar for Qt, except that instead of using a VNC-ish solution, I've used emscripten to convert Qt to HTML5 + Javascript. The upside of this is that you don't need a server and internet connection to run your Qt + C++ app; the downside is that it is almost certainly slower, plus you don't have threads, local event loops, or multiple processes (mostly due to limitations in Javascript), and you need a recent browser with full typed array support. You can read more about it here:

          Another quick update to my series of blogs about trying to get Qt ported over to the wonderful Emscripten , so that a Qt + C++ app can b...

          Comment


          • #15
            Originally posted by GeneralZod View Post
            A little off-topic, but I've recently been working on something broadly similar for Qt, except that instead of using a VNC-ish solution, I've used emscripten to convert Qt to HTML5 + Javascript. The upside of this is that you don't need a server and internet connection to run your Qt + C++ app; the downside is that it is almost certainly slower, plus you don't have threads, local event loops, or multiple processes (mostly due to limitations in Javascript), and you need a recent browser with full typed array support. You can read more about it here:

            http://ssj-gz.blogspot.com/2012/12/q...n-liverer.html
            That is just awesome! Too bad Qt does not have the functionality (yet) which Broadway facilitates for GTK.

            Maybe, in 10 years, we will only need a browser .

            Comment


            • #16
              Originally posted by Rexilion View Post
              Maybe, in 10 years, we will only need a browser .
              Am I the only one around here that loves to run stuff outside the browser?

              or

              Yo dawg, I heard you love OS, so we've put an OS in your OS.

              or

              1. Build OS
              2. Build browser application
              3. Make browser application a second OS
              4. ???
              5. Profit!

              That's all I have to say ;-)

              Comment


              • #17
                Originally posted by droste View Post
                Am I the only one around here that loves to run stuff outside the browser?
                No, not really. But if browser standards become part of the core system libraries, used to run all the applications then your argument is m00t. Never said you always require an active internet connection or something.

                I just envision that the notion of different toolkits becomes only an issue for development. If everything is ran over HTML5 and friends, who cares what you use???

                Comment


                • #18
                  Originally posted by Rexilion View Post
                  If everything is ran over HTML5 and friends, who cares what you use???
                  I'm totally ok with it, if the toolkits use HTML5 + HTML5 render engine to draw their UI (on a per application basis as a library). I'm not ok with it, if it is done inside one application and especially not if it's a full browser.

                  Comment


                  • #19
                    Originally posted by droste View Post
                    I'm totally ok with it, if the toolkits use HTML5 + HTML5 render engine to draw their UI (on a per application basis as a library). I'm not ok with it, if it is done inside one application and especially not if it's a full browser.
                    You have a point. But vulnerability's also occur in library's, no matter how you use them. Not using an application and only using librarie's does not make a program more secure by definition.

                    But, I also feel your point. Since browsers implementing pages as seperate processes is somewhat the same as an operating starting different processes. So why not use what the operating system has, and not go with the browser which is already very complex.

                    Comment


                    • #20
                      Originally posted by Rexilion View Post
                      But vulnerability's also occur in library's, no matter how you use them. Not using an application and only using librarie's does not make a program more secure by definition.
                      It's also about reliability not only security. If the browser crashes, everything is gone. You have a single point of failure and this is by definition bad. We already have that with the kernel so it's not a good idea to put another on top of it.

                      /edit:
                      Well we already have that with the kernel, the init process and Xorg, so it would be the 4th single point of failure ;-)
                      Last edited by droste; 29 December 2012, 11:15 AM.

                      Comment

                      Working...
                      X