Hello,

What Jason said plus:

- QPA abstraction in Qt 5.0 may make a web backend easier for widgets

- Loading pure (or almost*) QML may even avoid the need for such a backend

* Maybe post-processed QML which is statically converted to pure JavaScript
such as what Koen posted a year ago in the list, which would
avoid/alleviate the need for a browser-based QML parser?


On Mon, Jan 21, 2013 at 4:58 PM, Jason H <scorp...@yahoo.com> wrote:

> I have already made a HTML canvas painter that works* in Qt with near
> pixel-perfect accuracy (text is off, but drawing is spot on. There seems to
> be differences at the subpixel hinting level for fonts.)
> *Experimental. Not properly integrated.
>
> I would not seek that solution though. That solution is nice for legacy
> apps. I'd really want a QWLineEdit that would be rendered according to the
> back-end. If it is the Web backend, then you get a HTML <INPUT...>.  I am
> not attempting to Webify a Qt app. I am attepting to bring all of Qt to Wt.
> Web development, as you know, sucks. The amalgamation of standards is
> horrific. Wt/Qt is nice and clean, and I don't have to care about those
> standards. I would seek a singular toolkit that be run as either - desktop,
> mobile, or web so that I write my code once and compile for the back-end I
> select. Qt will cover two of those three, Wt covers the web. It would then
> be like Java or .NET, where one language could be used for both, but would
> be superior because all those standards are pushed away from the developer.
> Without knowing what platform he is targeting he can write code on them all.
>
> Qt is not one process = one application, though I know why you said that.
> There can only be one Qt GUI thread. There is not GUI when it comes to Web
> apps, so that constraint is moot.
>
> Also, there is now the complication that Qt5 is QML based, though widgets
> remain. It would be cool if both of those were supported. But due to QML
> being hardware (OpenGL) dependent, there is the issue of feature parity. I
> don't expect shaders for the web unless you're using WebGL which would be a
> killer feature.
>
> Wt remains a fringe toolkit. Moving to Qt would get you into the Qt world,
> but Qt, while still fringe is far from irrelevant. Qt is experiencing a
> surge in the mobile space. I think a rising side raises all ships. being a
> part of that ecosystem would be good for business. Ubuntu Phone,
> BlackBerry10, Sailfish all have QML as part of the SDK. Android is coming
> along and iOS is on its way. For people wanting to build front ends and
> back ends for mobile apps out of the same technology, a Wt module in Qt
> would be a no-brainer since Qt already allows you to target all those
> platforms.
>
>
>
>
>   ------------------------------
> *From:* Koen Deforche <k...@emweb.be>
> *To:* witty-interest@lists.sourceforge.net
> *Sent:* Monday, January 21, 2013 9:28 AM
> *Subject:* Re: [Wt-interest] Another Qt question
>
> Hey,
>
> If one would want to retrofit Qt's API on Wt's bastard dialect of it,
> there are however some fundamental draw-backs, from the top of my head:
>
> - events (mouse/key) are now nicely filtered by Wt based on connectivity
> -- e.g. a mouse click event is totally ignored if there is no widget
> listening for it. Because Qt does this using virtual functions, one cannot
> know whether this function has been re-implemented and thus you cannot do
> this filtering.
> - Wt embraces CSS as a fundamental constraint (or feature, depends on how
> you look at it) of layout in a browser. Qt fundamentally assumes it is
> painting everything. Merging this is tough and will require a compromise,
> which will necessarily be bad. I would be surprised if Qt is modular to the
> extent that you can express that a backend does not paint everything to
> bitmaps).
> - Wt does not assume one process = one Application. I'm not sure how
> fundamental this is baked into Qt, nor how you could make this "optional".
>
> Of course (for us) there is the business side of it, which starts with:
> how big is the market for this, and does the size of the market justify the
> initial and continuous investment ? In our experience, more and more users
> that start with Wt do not have any Qt experience or have never heard of it.
> The few users that I know of that
> actually do a single source desktop/web application, do not actually use
> Qt for the desktop part !
>
> It is probably less daunting to experiment with some true web-like backend
> (not the current bitmap-based hack!) functionality in Qt (e.g. get
> QPushButton to render as an HTML5 button) trying to work through the
> exercise of using Qt's modularity to implement a radically different
> back-end without the legacy of an existing Wt API, than to somehow merge
> the two code-bases ? I would be astonished, and intrigued, if it can be
> done.
>
> Regards,
> koen
>
>
>
>
>
> 2013/1/18 Pau Garcia i Quiles <pgqui...@elpauer.org>
>
>
>
> On Fri, Jan 18, 2013 at 10:42 PM, Jason H <scorp...@yahoo.com> wrote:
>
> With Qt5 here, Qt has been highly modularized.
> Several of us think it would be "really cool" if we could unite Qt and Wt.
> AFAIK, Boost and Qt's implementation are the only limits? Once things were
> converted over to QObjectsand the http server was ported, well the sky is
> the limit.
>
> What would the barriers be to getting Wt to merge with Qt?
>
>
> The only serious problem is the business model for Emweb.
>
> Then, there is the license, which is intimately related to the former.
>
> Boost, QObject, threads, HTTP server? There is no technical problem money
> cannot solve.
>
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)
>
> ------------------------------------------------------------------------------
> Master HTML5, CSS3, ASP.NET <http://asp.net/>, MVC, AJAX, Knockout.js,
> Web API and
> much more. Get web development skills now with LearnDevNow -
> 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122812
> _______________________________________________
> witty-interest mailing list
> witty-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
>
> _______________________________________________
> witty-interest mailing list
> witty-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> witty-interest mailing list
> witty-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
>


-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest

Reply via email to