Re: [Interest] Bringing Qt, C++ To The Web
to know a minimum of 3 technologies, but more like 6: HTML, JS, CSS, MIME, MIME's a tech?!?! I thought it's just a standard used in emails and HTTP headers to define the content type. SQL, .NET or Java or PHP, not to mention Linux/IIS server administration. The reason I puke is the number of standards you have to be famialr with. The reason I kick the puppy is this cannot be the best paradigm software development can have. It is an organic evolution of indepenendt technologies that don't come together to make a race horse, they make some kind of creature that has an arm, and leg, a hoof, a claw, and am mouth and exit hole. It's very much like a Swiss army knife - does everything but damn dangerous when you use all the things at once. Wt on the other hand, is C++ and takes care of all of that for you. You can provide a CSS, but you don't have to. It doesn't matter if tomorrow the web ditches HTML for XML or pure javascript, or ditches MIME headers for JSON MIME and JSON seem quite unrelated in this context. You probably meant XML being ditched for JSON...which is already happening. JSON increasingly seems to be the choice for data exchange over XML (esp for web apps). I don't think we can wish away these new web standards - CSS3/JS/HTML5 etc. If anything more and more people are adopting them. Just my 2 cents. -mandeep ones. The toolkit will take care of it for you. Don't recode, just recompile. And let the toolkit take care of browser sniffing. Everything made hard by traditional web development is made obsolete by Wt. And yes, I would love it if Qt and Wt merged. From: Nikos Chantziaras rea...@gmail.com To: interest@qt-project.org Sent: Thursday, January 17, 2013 11:00 AM Subject: Re: [Interest] Bringing Qt, C++ To The Web On 17/01/13 17:51, Konstantin Tokarev wrote: 17.01.2013, 19:38, Nikos Chantziaras rea...@gmail.com: On 17/01/13 17:31, Pau Garcia i Quiles wrote: On Thu, Jan 17, 2013 at 4:28 PM, Nikos Chantziaras rea...@gmail.com mailto:rea...@gmail.com wrote: I'm thinking more of ScummVM, DOSBox, Snes9x, etc. Would you run those on the server? Sure you can do it. But running on the client instead has enormous benefits. Having to download 10MB of JS is a small price to pay. If that really was such a concern, YouTube wouldn't bee that popular. And here we are finally, back to the thin client vs fat client debate :-) It always happens when webapps are involved. Not when you don't have a server, just dump web-space ;-) Google had the right idea with NaCL, but since other browsers don't plan to support it, we're stuck with JS. 'Stuck' is keyword here, because JS from Emcscripten is not going to run as fast as NaCl or even close to it. However, anyone can implement NaCl for Firefox and other browser via NPAPI plugin. If the browsers don't come with it out of the box, then people will have to download that plugin. But if they have to download the plugin, then they might as well download the native executable application instead. The point it to be able to give a URL and have it just work without users having to manually download anything. Pretty much what web deployment is about. ___ 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 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QNetworkAccessManager in a command line, non-eventloop application
On Fri, Jan 18, 2013 at 7:19 AM, Scott Aron Bloom scott.bl...@onshorecs.com wrote: -Original Message- From: interest-bounces+scott.bloom=onshorecs@qt-project.org [mailto:interest-bounces+scott.bloom=onshorecs@qt-project.org] On Behalf Of Thiago Macieira Sent: Thursday, January 17, 2013 5:27 PM To: interest@qt-project.org Subject: Re: [Interest] QNetworkAccessManager in a command line, non-eventloop application On sexta-feira, 18 de janeiro de 2013 00.59.13, Scott Aron Bloom wrote: I have a command line application, with no event loop. We can stop here. QNetworkAccessManager requires an event loop. But if you're going to block anyway in order to do work, you can use QEventLoop to start the event loop until the request finishes. -- I don't want to block :) I would like a background thread and have the request run in there, using the QThreads event loop. But you still are waiting for this thread to finish work and then quit the app, correct? Just curious here, but why don't you want to run the event loop in the main thread but only run it in a different thread? -mandeep Scott ___ 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
Re: [Interest] Bringing Qt, C++ To The Web
18.01.2013, 12:44, Mandeep Sandhu mandeepsandhu@gmail.com: to know a minimum of 3 technologies, but more like 6: HTML, JS, CSS, MIME, MIME's a tech?!?! I thought it's just a standard used in emails and HTTP headers to define the content type. It's also a common way to distinguish file types on Unix-like systems. -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QNetworkAccessManager in a command line, non-eventloop application
On Friday 18 January 2013 10:02:24 Mandeep Sandhu wrote: Just curious here, but why don't you want to run the event loop in the main thread but only run it in a different thread? Probably because the environment it's going to be used in already utilizes its own event loop... I had a similar situation once when I wrote a Samba VFS plugin with Qt, mainly for being able to use QThread's. However, doesn't the QNAM also work in a QThread which runs its own event loop?! HTH, René ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Bringing Qt, C++ To The Web
On Fri, Jan 18, 2013 at 2:46 PM, Konstantin Tokarev annu...@yandex.ru wrote: 18.01.2013, 12:44, Mandeep Sandhu mandeepsandhu@gmail.com: to know a minimum of 3 technologies, but more like 6: HTML, JS, CSS, MIME, MIME's a tech?!?! I thought it's just a standard used in emails and HTTP headers to define the content type. It's also a common way to distinguish file types on Unix-like systems. OT, but isn't that done by examining file extensions or file headers (like how the 'file' command works in Linux)? -mandeep -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Bringing Qt, C++ To The Web
18.01.2013, 13:35, Mandeep Sandhu mandeepsandhu@gmail.com: On Fri, Jan 18, 2013 at 2:46 PM, Konstantin Tokarev annu...@yandex.ru wrote: 18.01.2013, 12:44, Mandeep Sandhu mandeepsandhu@gmail.com: to know a minimum of 3 technologies, but more like 6: HTML, JS, CSS, MIME, MIME's a tech?!?! I thought it's just a standard used in emails and HTTP headers to define the content type. It's also a common way to distinguish file types on Unix-like systems. OT, but isn't that done by examining file extensions or file headers (like how the 'file' command works in Linux)? Yep, it's how MIME type is being determined. -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Bringing Qt, C++ To The Web
On 18/01/13 11:35, Mandeep Sandhu wrote: On Fri, Jan 18, 2013 at 2:46 PM, Konstantin Tokarev annu...@yandex.ru wrote: 18.01.2013, 12:44, Mandeep Sandhu mandeepsandhu@gmail.com: to know a minimum of 3 technologies, but more like 6: HTML, JS, CSS, MIME, MIME's a tech?!?! I thought it's just a standard used in emails and HTTP headers to define the content type. It's also a common way to distinguish file types on Unix-like systems. OT, but isn't that done by examining file extensions or file headers (like how the 'file' command works in Linux)? Once you've detected what the data is, you need to tell whomever asked about it what it actually is. You need a communication protocol for that. Like MIME. So you get the request what is this data? You look at it, and then answer audio/mpeg, which is a MIME type. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Bringing Qt, C++ To The Web
On 01/17/2013 05:00 PM, Nikos Chantziaras wrote: On 17/01/13 17:51, Konstantin Tokarev wrote: 17.01.2013, 19:38, Nikos Chantziaras rea...@gmail.com: On 17/01/13 17:31, Pau Garcia i Quiles wrote: On Thu, Jan 17, 2013 at 4:28 PM, Nikos Chantziaras rea...@gmail.com mailto:rea...@gmail.com wrote: I'm thinking more of ScummVM, DOSBox, Snes9x, etc. Would you run those on the server? Sure you can do it. But running on the client instead has enormous benefits. Having to download 10MB of JS is a small price to pay. If that really was such a concern, YouTube wouldn't bee that popular. And here we are finally, back to the thin client vs fat client debate :-) It always happens when webapps are involved. Not when you don't have a server, just dump web-space ;-) Google had the right idea with NaCL, but since other browsers don't plan to support it, we're stuck with JS. 'Stuck' is keyword here, because JS from Emcscripten is not going to run as fast as NaCl or even close to it. However, anyone can implement NaCl for Firefox and other browser via NPAPI plugin. If the browsers don't come with it out of the box, then people will have to download that plugin. But if they have to download the plugin, then they might as well download the native executable application instead. The point it to be able to give a URL and have it just work without users having to manually download anything. Pretty much what web deployment is about. No, NaCL provides sand-boxing as well and is thus a very safe alternative to downloading a native executable. Downloading and installing a browser plugin tends to be a much more stream-lined process too. I guess someone just needs to write a killer application in Qt that is deployed via a web page and NaCL, and people will switch to Chrome in order to run it (until other browsers get NaCL support). Since Qt makes it much easier to write a killer application that shouldn't be too hard? :p -- Samuel ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Bringing Qt, C++ To The Web
On 18/01/13 13:41, Samuel Rødal wrote: No, NaCL provides sand-boxing as well and is thus a very safe alternative to downloading a native executable. Downloading and installing a browser plugin tends to be a much more stream-lined process too. I guess someone just needs to write a killer application in Qt that is deployed via a web page and NaCL, and people will switch to Chrome in order to run it (until other browsers get NaCL support). Since Qt makes it much easier to write a killer application that shouldn't be too hard? :p There are already fairly popular cases of such (even dual plugin/NaCL) setups, for example Unity ( http://docs.unity3d.com/Documentation/Manual/nacl-gettingstarted.html ) which do seem a lot more appealing than going JS with something the caliber of Qt. PNaCL might make the native approach maybe even more appealing in the future. Best regards, Attila ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Bringing Qt, C++ To The Web
Except of course in Wt, where you can mark C++ functions for export to JavaScript. Which might seem trivial but It gives you a built-in abstraction layer if MS decides to be insolent and only support JScript or F# or something. From: Nikos Chantziaras rea...@gmail.com To: interest@qt-project.org Sent: Thursday, January 17, 2013 11:29 PM Subject: Re: [Interest] Bringing Qt, C++ To The Web On 17/01/13 22:50, Jason H wrote: What is the web you speak of? LOL It's this one: http://en.wikipedia.org/wiki/WWW ;-) Anyway, that [zero-install] is definitely a legitimate issue. However I have to puke and kick a puppy when it comes to overall web development. We were approaching something really good with Java and .NET, but these got sidelined by a handful of easy-to-implement standards that now requires you to know a minimum of 3 technologies, but more like 6: HTML, JS, CSS, MIME, SQL, .NET or Java or PHP, not to mention Linux/IIS server administration. [...] Wt on the other hand, is C++ and takes care of all of that for you. You can provide a CSS, but you don't have to. It doesn't matter if tomorrow the web ditches HTML for XML or pure javascript, or ditches MIME headers for JSON ones. The toolkit will take care of it for you. Don't recode, just recompile. And let the toolkit take care of browser sniffing. Everything made hard by traditional web development is made obsolete by Wt. And yes, I would love it if Qt and Wt merged. I did try Wt and do find it awesome for server-side development. But the thing when being server-side is that you can always come up with your own solutions. After all, you can run native code on the server. If Wt didn't exist, you could always write your own abstraction layer for your C++ code. They key is, you *can* run your C++ code. When being client-side there's no such freedom. Your C++ codebase is completely useless as you can't run it on the client. Which is why Emscripten is such an amazing technology. I expect it to get faster with time, especially as JS itself evolves, eliminating more bottlenecks. And do not forget that Emscripten is not just a C++ to JS compiler. It's an LLVM bitcode to JS compiler. So it can potentially allow deployment of code written in any language. *From:* Nikos Chantziaras rea...@gmail.com *To:* interest@qt-project.org *Sent:* Thursday, January 17, 2013 11:00 AM *Subject:* Re: [Interest] Bringing Qt, C++ To The Web On 17/01/13 17:51, Konstantin Tokarev wrote: 17.01.2013, 19:38, Nikos Chantziaras rea...@gmail.com mailto:rea...@gmail.com: On 17/01/13 17:31, Pau Garcia i Quiles wrote: On Thu, Jan 17, 2013 at 4:28 PM, Nikos Chantziaras rea...@gmail.com mailto:rea...@gmail.com mailto:rea...@gmail.com mailto:rea...@gmail.com wrote: I'm thinking more of ScummVM, DOSBox, Snes9x, etc. Would you run those on the server? Sure you can do it. But running on the client instead has enormous benefits. Having to download 10MB of JS is a small price to pay. If that really was such a concern, YouTube wouldn't bee that popular. And here we are finally, back to the thin client vs fat client debate :-) It always happens when webapps are involved. Not when you don't have a server, just dump web-space ;-) Google had the right idea with NaCL, but since other browsers don't plan to support it, we're stuck with JS. 'Stuck' is keyword here, because JS from Emcscripten is not going to run as fast as NaCl or even close to it. However, anyone can implement NaCl for Firefox and other browser via NPAPI plugin. If the browsers don't come with it out of the box, then people will have to download that plugin. But if they have to download the plugin, then they might as well download the native executable application instead. The point it to be able to give a URL and have it just work without users having to manually download anything. Pretty much what web deployment is about. ___ 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
Re: [Interest] Bringing Qt, C++ To The Web
SOAP with attachments can get quite tricky with it's attachment headers.
No, I meant what I wrote. MIME ditched for JSON. Convert the MIME array of
headers to a JSON dictionary. It is more flexible. While no one in the real
world has called for it, it would eliminate the need to learn MIME (aside from
mime-types). Then you can do cool things like multiplex data streams over a
socket, which is what WebSockets are about. The fact that your header can now
be a data structure or array thereof would allow you to transmit chunks of data
for various files interleaved over the same socket. Currently, codec containers
do that for media files. But what if you could control the order of the loading
by instructing the servers on how to deliver the files. Like end all at once,
or sequential. It would help on large-latency systems, while reducing the
number of sockets needed meaning you can serve more clients on the same
hardware.
But I digress. You close by pointing out that more people are adopting HTML,
JS, and CSS. I'm sure that will continue until someone on some mailing list
says Hey this really sucks and I think we can do better And then people
realize that they have been doing it wrong all this time. Well, a man can hope.
I fully don't expect C++ to rule the web again, if it ever did. I do expect for
people to say hey, we can accomplish HTML a whole lot better as a JSON
structure (I'll call JML) as {'html' : {'body': { 'this is my body.' } } }
Which is garenteed to be, in current terms XHTML compliant. It gets even better
if we allow limited JS in the JSON, because then you can define a style
function i.e. {'html' : {'body': { ApplyStyles('H1,Red','this is my body.') } }
} where H1 is defined as {'html' : {'styles' : {'H1: 'font-size': '17pt'},
'Red' : {'font-color':'#FF'} then you can combine the dictionaries. You
could also do conditionals and maybe even functions
as ApplyStyles('H1+Red-RedIfPrinterMediaType()')
The whole web (aside from backend SQL) could be a dialect of JS. If you coded
your application right, none of this would matter, because you'd download the
latest application library and recompile. We'd be able to rely on linked data
better because everything would be XPATH-able. DOM stays, IDs stay, interop
(beyond linked data) gets easier. You can still code in Python, C++, etc, your
language of the day, and programmers don't have t worry about Tags.
Bringing this discussion back to Qt, there is something that elegantly does
this already. QML. Drop the idea that it
is for GPUs and graphics and instead use it to serialize to HTML/JS/CSS (or my
JML) and you have your new, 1-technology web, that incidentally can do local
apps as well. Is your mind blown yet?
From: Mandeep Sandhu mandeepsandhu@gmail.com
To: Jason H scorp...@yahoo.com
Cc: Nikos Chantziaras rea...@gmail.com; interest@qt-project.org
interest@qt-project.org
Sent: Friday, January 18, 2013 3:43 AM
Subject: Re: [Interest] Bringing Qt, C++ To The Web
to know a minimum of 3 technologies, but more like 6: HTML, JS, CSS, MIME,
MIME's a tech?!?! I thought it's just a standard used in emails and
HTTP headers to define the content type.
SQL, .NET or Java or PHP, not to mention Linux/IIS server administration.
The reason I puke is the number of standards you have to be famialr with.
The reason I kick the puppy is this cannot be the best paradigm software
development can have. It is an organic evolution of indepenendt technologies
that don't come together to make a race horse, they make some kind of
creature that has an arm, and leg, a hoof, a claw, and am mouth and exit
hole. It's very much like a Swiss army knife - does everything but damn
dangerous when you use all the things at once.
Wt on the other hand, is C++ and takes care of all of that for you. You can
provide a CSS, but you don't have to. It doesn't matter if tomorrow the web
ditches HTML for XML or pure javascript, or ditches MIME headers for JSON
MIME and JSON seem quite unrelated in this context. You probably meant
XML being ditched for JSON...which is already happening. JSON
increasingly seems to be the choice for data exchange over XML (esp
for web apps).
I don't think we can wish away these new web standards - CSS3/JS/HTML5
etc. If anything more and more people are adopting them.
Just my 2 cents.
-mandeep
ones. The toolkit will take care of it for you. Don't recode, just
recompile. And let the toolkit take care of browser sniffing. Everything
made hard by traditional web development is made obsolete by Wt.
And yes, I would love it if Qt and Wt merged.
From: Nikos Chantziaras rea...@gmail.com
To: interest@qt-project.org
Sent: Thursday, January 17, 2013 11:00 AM
Subject: Re: [Interest] Bringing Qt, C++ To The Web
On 17/01/13 17:51, Konstantin Tokarev wrote:
17.01.2013, 19:38, Nikos Chantziaras rea...@gmail.com:
On 17/01/13
Re: [Interest] Bringing Qt, C++ To The Web
OT, but isn't that done by examining file extensions or file headers (like how the 'file' command works in Linux)? Once you've detected what the data is, you need to tell whomever asked about it what it actually is. You need a communication protocol for that. Like MIME. So you get the request what is this data? You look at it, and then answer audio/mpeg, which is a MIME type. Right, but MIME is not the communication protocol. That would be something like HTTP. MIME just says: for xzy file type, use set the content type to some standard string (like you mentioned). -mandeep ___ 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
Re: [Interest] Bringing Qt, C++ To The Web
On Fri, Jan 18, 2013 at 3:19 PM, Jason H scorp...@yahoo.com wrote: Bringing this discussion back to Qt, there is something that elegantly does this already. QML. Drop the idea that it is for GPUs and graphics and instead use it to serialize to HTML/JS/CSS (or my JML) and you have your new, 1-technology web, that incidentally can do local apps as well. Is your mind blown yet? I know Emweb (the company behind Wt) have already done experiments in that direction because Koen and Wim told me last year at FOSDEM. They have also mentioned that in the Wt mailing list. The only difference is they are using something which looks almost like QML but it's pure JavaScript. I would have preferred they'd use QML as-is. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Bringing Qt, C++ To The Web
That is not a fair simplication of mime. Base64 encoding anyone? Chuncked-length encoding? From: Mandeep Sandhu mandeepsandhu@gmail.com To: Nikos Chantziaras rea...@gmail.com Cc: Interest@qt-project.org interest@qt-project.org Sent: Friday, January 18, 2013 9:22 AM Subject: Re: [Interest] Bringing Qt, C++ To The Web OT, but isn't that done by examining file extensions or file headers (like how the 'file' command works in Linux)? Once you've detected what the data is, you need to tell whomever asked about it what it actually is. You need a communication protocol for that. Like MIME. So you get the request what is this data? You look at it, and then answer audio/mpeg, which is a MIME type. Right, but MIME is not the communication protocol. That would be something like HTTP. MIME just says: for xzy file type, use set the content type to some standard string (like you mentioned). -mandeep ___ 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___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Bringing Qt, C++ To The Web
Well I've been posting about QML as a web technology for over a year now. Maybe 2. And I'm on the Wt list for about a year ;-) I can understand why they want that - it would work in existing browsers. I would have preferred QML as well, however this would require a plug-in for what is a small formatting change. They could come out with QML2 er, QMLWeb2 or whatever if the QML approach takes off. One works in a current browser, the other one need a plugin or upgrade. If we can compile QML to the pure JS format, that is ok too. We could have the web servers do that automatically and cache the results. From: Pau Garcia i Quiles pgqui...@elpauer.org To: Jason H scorp...@yahoo.com Cc: Mandeep Sandhu mandeepsandhu@gmail.com; interest@qt-project.org interest@qt-project.org; Nikos Chantziaras rea...@gmail.com Sent: Friday, January 18, 2013 9:23 AM Subject: Re: [Interest] Bringing Qt, C++ To The Web On Fri, Jan 18, 2013 at 3:19 PM, Jason H scorp...@yahoo.com wrote: Bringing this discussion back to Qt, there is something that elegantly does this already. QML. Drop the idea that it is for GPUs and graphics and instead use it to serialize to HTML/JS/CSS (or my JML) and you have your new, 1-technology web, that incidentally can do local apps as well. Is your mind blown yet? I know Emweb (the company behind Wt) have already done experiments in that direction because Koen and Wim told me last year at FOSDEM. They have also mentioned that in the Wt mailing list. The only difference is they are using something which looks almost like QML but it's pure JavaScript. I would have preferred they'd use QML as-is. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Bringing Qt, C++ To The Web
Heh, I looked back, he wrote as a reply to my thread. His sample code was:
load('wt.js');
var w;
var widget = new Wt.WContainerWidget({
width: '100px',
height: '200px',
children: [
w = new Wt.WText({
width: '100px',
height: '200px'
})
]
});
w.on('click', function(event) {
++widget.width;
});
var label, line;
var widget2 = new Wt.WTemplate({
text: div${label}: ${line}/div,
bindings: [
label = new Wt.WLabel({
id: 'label',
text: Enter your name
}),
line = new Wt.WLineEdit({
id: 'line',
text: 'initial'
})
]
});
--Not as elegant as I'd like but a very goo d start.
From: Jason H scorp...@yahoo.com
To: Pau Garcia i Quiles pgqui...@elpauer.org
Cc: Nikos Chantziaras rea...@gmail.com; interest@qt-project.org
interest@qt-project.org
Sent: Friday, January 18, 2013 9:39 AM
Subject: Re: [Interest] Bringing Qt, C++ To The Web
Well I've been posting about QML as a web technology for over a year now. Maybe
2. And I'm on the Wt list for about a year ;-)
I can understand why they want that - it would work in existing browsers. I
would have preferred QML as well, however this would require a plug-in for what
is a small formatting change. They could come out with QML2 er, QMLWeb2 or
whatever if the QML approach takes off. One works in a current browser, the
other one need a plugin or upgrade. If we can compile QML to the pure JS
format, that is ok too. We could have the web servers do that automatically and
cache the results.
From: Pau Garcia i Quiles pgqui...@elpauer.org
To: Jason H scorp...@yahoo.com
Cc: Mandeep Sandhu mandeepsandhu@gmail.com; interest@qt-project.org
interest@qt-project.org; Nikos Chantziaras rea...@gmail.com
Sent: Friday, January 18, 2013 9:23 AM
Subject: Re: [Interest] Bringing Qt, C++ To The Web
On Fri, Jan 18, 2013 at 3:19 PM, Jason H scorp...@yahoo.com wrote:
Bringing this discussion back to Qt, there is something that elegantly does
this already. QML. Drop the idea that it
is for GPUs and graphics and instead use it to serialize to HTML/JS/CSS (or my
JML) and you have your new, 1-technology web, that incidentally can do local
apps as well. Is your mind blown yet?
I know Emweb (the company behind Wt) have already done experiments in that
direction because Koen and Wim told me last year at FOSDEM. They have also
mentioned that in the Wt mailing list. The only difference is they are using
something which looks almost like QML but it's pure JavaScript. I would have
preferred they'd use QML as-is.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
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
Re: [Interest] Bringing Qt, C++ To The Web
18.01.2013, 18:24, Pau Garcia i Quiles pgqui...@elpauer.org: On Fri, Jan 18, 2013 at 3:19 PM, Jason H scorp...@yahoo.com wrote: Bringing this discussion back to Qt, there is something that elegantly does this already. QML. Drop the idea that it is for GPUs and graphics and instead use it to serialize to HTML/JS/CSS (or my JML) and you have your new, 1-technology web, that incidentally can do local apps as well. Is your mind blown yet? I know Emweb (the company behind Wt) have already done experiments in that direction because Koen and Wim told me last year at FOSDEM. They have also mentioned that in the Wt mailing list. The only difference is they are using something which looks almost like QML but it's pure JavaScript. I would have preferred they'd use QML as-is. If they used QML, they had to write QML parser in JavaScript, introducing both development/maintenance and run-time overheads. They've chosen straightforward path instead. If Qt developers used existing general-purpose language allowing declarative constructions, like JavaScript or Lua, instead of inventing QML, they would also save development time and could use existing language ecosystem. -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QNetworkAccessManager in a command line, non-eventloop application
-Original Message- From: interest-bounces+scott.bloom=onshorecs@qt-project.org [mailto:interest-bounces+scott.bloom=onshorecs@qt-project.org] On Behalf Of Thiago Macieira Sent: Thursday, January 17, 2013 5:27 PM To: interest@qt-project.org Subject: Re: [Interest] QNetworkAccessManager in a command line, non-eventloop application On sexta-feira, 18 de janeiro de 2013 00.59.13, Scott Aron Bloom wrote: I have a command line application, with no event loop. We can stop here. QNetworkAccessManager requires an event loop. But if you're going to block anyway in order to do work, you can use QEventLoop to start the event loop until the request finishes. -- I don't want to block :) I would like a background thread and have the request run in there, using the QThreads event loop. But you still are waiting for this thread to finish work and then quit the app, correct? Just curious here, but why don't you want to run the event loop in the main thread but only run it in a different thread? -mandeep -- 99% (ok made up number) of the runs, take minutes (some 10s of hours, some 1-2 seconds), the 1-2 seconds in the thread will be done way way before the application is finished. In the SMALL number of cases, its ok to block the exit of the application. The HTTP request is made at the startup of the application Scott ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QNetworkAccessManager in a command line, non-eventloop application
On sexta-feira, 18 de janeiro de 2013 01.49.35, Scott Aron Bloom wrote: I don't want to block Yet you're describing exactly a blocking situation: I would like a background thread and have the request run in there, using the QThreads event loop. The background thread runs an event loop, sure, but what is the main thread doing in the meantime? Since it doesn't have an event loop, it cannot receive events. The only synchronisation mechanisms left are QWaitCondition and QSemaphore, which means the main thread must block waiting for the background thread to finish the operation. You really don't have a choice besides those two. Network access is not instantaneous. You must either use the event loop or you need to block. Choose one. - Blocking at the end, is ok... Blocking while the application is running is not. Yes, I want my cake and to eat is as well :) I essentially want to kick off the request at the beginning of the run, then let the request run its course in the backround. If the main application (no event loop at all, non-event driven, nonQt for the most part), finishes first (rare occasion) I can block on the background thread ending. However most times, the single http request will have finished long before Scott ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Bringing Qt, C++ To The Web
On 16/01/2013 09:30 م, Pau Garcia i Quiles wrote: On Wed, Jan 16, 2013 at 9:16 PM, Jan Krause jan.krause.n...@gmail.com wrote: I read this post yesterday, I found Emscripten-Qt really promising project, even I found it in Qt repository. Does anyone know whether Emscripten-Qt will join to Qt project? This is a great project. Hopefully it is in a stable state in the next time. It would be a pleasure if there is technology for bringing qwidgets- and/or qml-based applications in the web. Problem with Emscripten-Qt is it's far from optimized. It downloads and executes several megabytes of _javascript_ to run a simple "Hello World". It's better than nothing but really far from what you can achieve with web-targetting libraries such as Wt or QMLweb http://webtoolkit.eu https://gitorious.org/qmlweb Acutally I considered Emscripten-Qt as C++ replacement to Java applet because it works just like it so it's not fair to compare it to Wt. -- Best Regards Muhammad Bashir Al-Noimi ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Bringing Qt, C++ To The Web
On 17/01/2013 09:50 م, Jason H wrote: What is the "web" you speak of? LOL Anyway, that [zero-install] is definitely a legitimate issue. However I have to puke and kick a puppy when it comes to overall web development. We were approaching something really good with Java and .NET, but these got sidelined by a handful of easy-to-implement standards that now requires you to know a minimum of 3 technologies, but more like 6: HTML, JS, CSS, MIME, SQL, .NET or Java or PHP, not to mention Linux/IIS server administration. The reason I puke is the number of standards you have to be famialr with. The reason I kick the puppy is this cannot be the best paradigm software development can have. It is an organic evolution of indepenendt technologies that don't come together to make a race horse, they make some kind of creature that has an arm, and leg, a hoof, a claw, and am mouth and exit hole. It's very much like a Swiss army knife - does everything but damn dangerous when you use all the things at once. Wt on the other hand, is C++ and takes care of all of that for you. You can provide a CSS, but you don't have to. It doesn't matter if tomorrow the web ditches HTML for XML or pure _javascript_, or ditches MIME headers for JSON ones. The toolkit will take care of it for you. Don't recode, just recompile. And let the toolkit take care of browser sniffing. Everything made hard by traditional web development is made obsolete by Wt. And yes, I would love it if Qt and Wt merged. +1 Merging Wt and Qt is a dream comes true. -- Best Regards Muhammad Bashir Al-Noimi ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QNetworkAccessManager in a command line, non-eventloop application
On sexta-feira, 18 de janeiro de 2013 17.08.46, Scott Aron Bloom wrote: On sexta-feira, 18 de janeiro de 2013 01.49.35, Scott Aron Bloom wrote: I don't want to block Yet you're describing exactly a blocking situation: I would like a background thread and have the request run in there, using the QThreads event loop. The background thread runs an event loop, sure, but what is the main thread doing in the meantime? Since it doesn't have an event loop, it cannot receive events. The only synchronisation mechanisms left are QWaitCondition and QSemaphore, which means the main thread must block waiting for the background thread to finish the operation. You really don't have a choice besides those two. Network access is not instantaneous. You must either use the event loop or you need to block. Choose one. - Blocking at the end, is ok... Blocking while the application is running is not. Yes, I want my cake and to eat is as well :) If you don't block, then you have a loop. Maybe you don't have Qt's event loop mechanism (QEventLoop), but you have an event loop nonetheless. Since you can't use Qt events for this and you don't want to make a blocking call, you may use a QSemaphore tryAcquire() or equivalent to check whether the work is done. But you also need to determine when your main thread's other business is done, because then you'll need to use acquire() instead and block (if you don't, you'll have a busy-wait loop). In other words, your solution is to have *both* blocking calls and a loop. I essentially want to kick off the request at the beginning of the run, then let the request run its course in the backround. If the main application (no event loop at all, non-event driven, nonQt for the most part), finishes first (rare occasion) I can block on the background thread ending. However most times, the single http request will have finished long before You describe a fire-and-forget situation: you kick off the request and you don't care when it finishes. You'd only have to care that the application doesn't exit before the request is finished processing. However, there's no such thing as a fire-and-forget network request. Even the simplest request (a PUT) results in a success or failure result. I imagine your application is interested in whether the request failed, as it may need to take some action in that case. That means you need to rearchitect your application so that it can receive the communication from the other thread. So we go back to an event loop or a blocking call. Or both. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Bringing Qt, C++ To The Web
On Fri, Jan 18, 2013 at 7:19 AM, Jason H scorp...@yahoo.com wrote: Bringing this discussion back to Qt, there is something that elegantly does this already. QML. Drop the idea that it is for GPUs and graphics and instead use it to serialize to HTML/JS/CSS (or my JML) and you have your new, 1-technology web, that incidentally can do local apps as well. Is your mind blown yet? /r/'ing link to QML - HTML/JS/CSS conversion library/tool, or are you only talking hypothetically? That, as well as seamless translation of user events from QObject bindings to Wt WApplication slots (or whatever they'd be called post-merge), would be the best way for Qt and Wt to merge (a plus would be progressive enhancement (and/or graceful degradation) to JS/WebGL commands translation). There's still the issue of resource sharing (desktop apps are coded for one user at a time, web apps need to account for many users at a time), but that could maybe/probably be solved at a lower/db layer. A single business layer and a single gui codebase to target both single-user/desktop and multi-user/web sounds like a pipe dream, but it can be done (hypothetically :-P). My beef with QML isn't it's potential, it's the stupid overhead introduced in the current implementation (JS interpreter, in MY C++ framework?) and lack of interoperability because it's just a binding to the framework, not a core part of it (don't believe me? Look at all the expose X to QML threads created in the past few months). inb4 raeg, d3fault ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Bringing Qt, C++ To The Web
-Original Message- Anyway, that [zero-install] is definitely a legitimate issue. However I have to puke and kick a puppy when it comes to overall web development. We were approaching something really good with Java and .NET, but these got sidelined by a handful of easy-to-implement standards that now requires you to know a minimum of 3 technologies, but more like 6: HTML, JS, CSS, MIME, SQL, .NET or Java or PHP, not to mention Linux/IIS server administration. [...] Wt on the other hand, is C++ and takes care of all of that for you. You can provide a CSS, but you don't have to. It doesn't matter if tomorrow the web ditches HTML for XML or pure javascript, or ditches MIME headers for JSON ones. The toolkit will take care of it for you. Don't recode, just recompile. And let the toolkit take care of browser sniffing. Everything made hard by traditional web development is made obsolete by Wt. And yes, I would love it if Qt and Wt merged. I did try Wt and do find it awesome for server-side development. But the thing when being server-side is that you can always come up with your own solutions. After all, you can run native code on the server. If Wt didn't exist, you could always write your own abstraction layer for your C++ code. They key is, you *can* run your C++ code. When being client-side there's no such freedom. Your C++ codebase is completely useless as you can't run it on the client. Which is why Emscripten is such an amazing technology. I expect it to get faster with time, especially as JS itself evolves, eliminating more bottlenecks. And do not forget that Emscripten is not just a C++ to JS compiler. It's an LLVM bitcode to JS compiler. So it can potentially allow deployment of code written in any language. Going WAY off topic, but: If they can convert LLVM to Javascript, why can't they convert to a JVM bytecode for Android, etc? Sounds like a great project! Regards, Tony ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
