Hi Jason, Wt (witty) can run as you describe with your server code bound directly to WebKit executing the html, css, etc. in a free-standing exe. But getting rid of the text and accessing the WebKit objects directly, doesn't really fix anything! The functionality of the WebKit objects is still the same - the same workarounds for different OS's, different CSS standards, different interpretations of the effects on the box model, and on and on. So until someone comes up with a better model of the browser experience, it won't improve. Lots of people are trying - Qt with QML, Embacadero's Delphi with FireMonkey, for example could be candidates. I can't see how they are going to replace the existing stack anytime soon - no matter how much people would like them to!
Regards, Tony. > -----Original Message----- > From: interest-bounces+tony=rightsoft.com...@qt-project.org > [mailto:interest-bounces+tony=rightsoft.com...@qt-project.org] On Behalf > Of Jason H > Sent: Saturday, 12 April 2014 1:47 AM > To: Interests Qt > Subject: [Interest] Off-topic Web / Webkit talk. (But I'l tie it back to Qt) > > I have nothing but contempt for the current state of web development. > HTML/CSS/JS/DOM/AJAX/MIME, not including your server implementation > (JS|.NET|Java|PHP) and SQL/NoSQL. I've been asking the question on why > we can't migrate HTML,CSS,DOM, and MIME to JSON. It would be a > monumental effort for little gain. > > But I've also been using Witty, a C++ web toolkit that mimics Qt. Basically, you > only get push a DIV element (automatic) and the library takes care of the rest. > This is a great step in the right direction. But it is still subject to limitations > of HTML/CSS/JS/DOM/AJAX/MIME, and the browser implementations > thereof. (The obsoleting of XP and IE6 and the rejoicing of various web devs > at not having to support IE6 is what got me on this particular track.) > > In Qt we have a webkit implementation. (I told you I was going to tie it back > to Qt ;-) ) Webkit is client-side. What I am thinking is if there was a server- > side webkit that communicated directly (or as close to) the client webkit as > possible, over say websockets. In my mind, this would get us closer to using > Qt for web apps. If we could program Qt with server side webkit objects (I'll > call these subclasses of QServerWidgets) so that we can create the widget > hierarchies which communicate to the standard Webkit client-side libraries. > Creating a QServerWidget creates the corresponding WebKit widget. I'm no > Webkit expert. But I think this would more elegantly > replace HTML/CSS/JS/DOM/AJAX/MIME, without having to go through > standards processes. And maybe Webkit is bound > to HTML/CSS/JS/DOM/AJAX/MIME internally for the time being. > > But, in the end, if we handled QWidgets and QServerWidgets the same > (QPA?) we could code a Qt application and get a web version, a mobile > version, and a desktop version from the same code base. > > I am no means Webkit person, I only have a basic understanding of webkit. > > Comments? > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
