My cracked mind once came up with the idea of using QML to render HTML/XML
pages. So I would support any such decision to split it and put it maybe not
into core, but a gui-less module.
I imaging doing web pages as QML components, served by a HTTP server that has
the QML/JS bound to it.
Page {
Head { }
Body {
Header { }
MainContent { }
Footer { }
}
}
Where Header, Body, MainContent Footer are user QML files, and Page and Head
are part of a QML/XHTML library. Other uses are possible, as you should be able
to create your own output serialization (binary formats?) Movie { Frames {
Overlay{} Frame {} ... } } etc.
________________________________
From: "[email protected]" <[email protected]>
To: [email protected]; [email protected]
Sent: Tuesday, September 6, 2011 11:33 AM
Subject: Re: [Qt5-feedback] QML/JS engine in QtCore?
On 9/6/11 1:29 PM, "ext Thiago Macieira" <[email protected]> wrote:
>On Tuesday, 6 de September de 2011 12:12:10 [email protected] wrote:
>> Yes, you're right that it adds some memory and startup overhead. The
>> question that comes up is when you look at a whole system on whether
>>this
>> matters. If 95% of the apps anyway link to QtDeclarative or scripting in
>> some way, it might not be a huge issue.
>>
>> The relocations you mention below might be fixable by using -Bsymbolic
>>and
>> -Bsymbolic-functions when linking QtV8.
>
>These numbers are with -Bsymbolic-functions already.
>
>Without it, the number of non-relative relocations would increase, but I
>don't
>think by much. There aren't many exported classes.
>
>The vast majority of these relocations are caused by the virtual tables
>of
>non-exported classes, with no exported base class:
>
> $ objdump -R libQtV8.so.5.0.0| awk '/__cxxabi/ || /__cxa_pure_virtual/{
>print
>$3 }' | uniq -c
> 525 _ZTVN10__cxxabiv120__si_class_type_infoE+0x0000000000000010
> 56 _ZTVN10__cxxabiv117__class_type_infoE+0x0000000000000010
> 2 _ZTVN10__cxxabiv121__vmi_class_type_infoE+0x0000000000000010
> 319 __cxa_pure_virtual
>
>This is caused by the code design: the visitor pattern that calls back
>into
>the the current class.
>
>I was just pointing out that it isn't free. But I agree that the impact
>will
>be there if people want to use QML anyway.
>
>It will just be nearly impossible convincing anyone not already using Qt
>that
>QtCore is acceptable (for example, to write system services on Linux).
>
>The major problem I have is that it makes any port to a new architecture
>require 40k lines of code.
Agree, the last two arguments are probably the most severe ones. A
bytecode/p-code backend in V8 would really help here.
The other option I've been discussing a bit with a few people would be to
split libQtDeclarative into a part containing the engine (JS and QML) and
one containing the graphical items. I don't think that would be
problematic for anybody. The engine would then purely depend on QtCore
(and maybe network).
It doesn't give us everything, but is probably better than the current
situation with the JS engine only being available with a Gui dependency.
Kent and Jedrzej will look into this right now so we can get a clean split
between the engine and the QML items. Let's see how we move on once that's
done.
Cheers,
Lars
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
