Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
WxWidgets events question
59 views
Skip to first unread message
Szyk Cech
Jul 10, 2019, 12:00:44 AM7/10/19
to
Hi
I am nevbie to WxWidgets (my experience is mainly VCL and Qt), so please
don't blame me if question is not very wise.
I there any protection against deleted binded (target) object after you
use Bind<>() (dynamic function binding)?
I don't see any mention on the page:
https://docs.wxwidgets.org/trunk/overview_events.html
But maybe it is internal matter...
thanks in advance and
best regards
Szyk Cech
I am nevbie to WxWidgets (my experience is mainly VCL and Qt), so please
don't blame me if question is not very wise.
I there any protection against deleted binded (target) object after you
use Bind<>() (dynamic function binding)?
I don't see any mention on the page:
https://docs.wxwidgets.org/trunk/overview_events.html
But maybe it is internal matter...
thanks in advance and
best regards
Szyk Cech
Öö Tiib
Jul 10, 2019, 4:43:48 AM7/10/19
to
On Wednesday, 10 July 2019 07:00:44 UTC+3, Szyk Cech wrote:
> Hi
> I am nevbie to WxWidgets (my experience is mainly VCL and Qt), so please
> don't blame me if question is not very wise.
Best WxWidgets discussions are perhaps at forums for it https://forums.wxwidgets.org/
> Hi
> I am nevbie to WxWidgets (my experience is mainly VCL and Qt), so please
> don't blame me if question is not very wise.
> I there any protection against deleted binded (target) object after you
> use Bind<>() (dynamic function binding)?
of events will for some reason outlive the target then you have to
call Unbind before destruction of target "manually".
The target of events is typically parent window of
event sources and the source is child window. The child windows get
destroyed before parent window in DestroyChildren (in
first to last order). So the lifetime is usually not problem.
> I don't see any mention on the page:
> https://docs.wxwidgets.org/trunk/overview_events.html
>
> But maybe it is internal matter...
in mind that then the lifetime of myFrameHandler must be greater
than that of MyFrame object – or at least it needs to be unbound
before being destroyed." on the page.
leigh.v....@googlemail.com
Jul 10, 2019, 4:46:29 AM7/10/19
to
On Wednesday, July 10, 2019 at 5:00:44 AM UTC+1, Szyk Cech wrote:
> Hi
> I am nevbie to WxWidgets (my experience is mainly VCL and Qt), so please
> don't blame me if question is not very wise.
>
> I there any protection against deleted binded (target) object after you
> use Bind<>() (dynamic function binding)?
>
> I don't see any mention on the page:
> https://docs.wxwidgets.org/trunk/overview_events.html
>
> But maybe it is internal matter...
What isn't very wise is using WxWidgets instead of Qt given that WxWidgets is an egregious rip off of the disaster that is MFC. Of course once neoGFX 1.0 is released using Qt will also be unwise. :)
> Hi
> I am nevbie to WxWidgets (my experience is mainly VCL and Qt), so please
> don't blame me if question is not very wise.
>
> I there any protection against deleted binded (target) object after you
> use Bind<>() (dynamic function binding)?
>
> I don't see any mention on the page:
> https://docs.wxwidgets.org/trunk/overview_events.html
>
> But maybe it is internal matter...
/Leigh
Szyk Cech
Jul 10, 2019, 11:37:52 AM7/10/19
to
W dniu 10.07.2019 o 10:46, leigh.v....@googlemail.com pisze:
- You can't write mobile apps in C++ - because they force to use vendor
lock QML (JavaScript style) language. WHEN I REALIZE THIS I DECIDE TO
SPLIT UP WITH QT!!!
- Broken properties: you declare them in C++ but you can use them only
in script languages
- Error handling by return value instead by exceptions.
- Broken classes created with rule: "Closed for modifications and close
for extendability" - so you can't make wrapers for stupid error tracking
to use comfortable exceptions (especially in SQL apps). This is mainly
due to lack virtual destructors and minor due to non virtual members in
most cases.
- Many classes are broken by design: you want to create fully featured
QTreeView? You should be prepared for writing 1000 lines of code to make
it. You want access function in QMenu which emulate key pressing - to
raise menu programmically?!? Forget about this idea!
- They claim Qt is modular == composed from many independent libraries,
but you can't even write modular programmer text editor with Qt: due to
broken QTextEdit: you can't define 2 syntax highlighter at the same time
- but it is expected from modular approach to create one plugin for
syntaxhighlighting, and other for spell checking. More: You can't attach
more that one object to QTextBlock (which store one line of code in
QTextEdit), this cause that it is impossible to have one plugin for
syntax highlighter and other for bookmarks (switchable marked places in
code - you can jump between them by hit keyboard shortcuts). So you can
have modular program with syntax highlighting or with bookmarks but not
at the same time!
- Communication with QWebEngine (JavaScript <-> C++) is piece of madman
solution.
To sum up: After selling Qt to Nokia things are going worse and worse. I
don't expect any significant improvement in approaching Qt 6. They don't
have the same philosophy as they have before Qt 4 (easy to use library
for writing apps in pure C++). How ever until Nokia days Qt has only
commercial license for commercial projects.
> What isn't very wise is using WxWidgets instead of Qt
From my point of view Qt is far from ideal C++ library:
- You can't write mobile apps in C++ - because they force to use vendor
lock QML (JavaScript style) language. WHEN I REALIZE THIS I DECIDE TO
SPLIT UP WITH QT!!!
- Broken properties: you declare them in C++ but you can use them only
in script languages
- Error handling by return value instead by exceptions.
- Broken classes created with rule: "Closed for modifications and close
for extendability" - so you can't make wrapers for stupid error tracking
to use comfortable exceptions (especially in SQL apps). This is mainly
due to lack virtual destructors and minor due to non virtual members in
most cases.
- Many classes are broken by design: you want to create fully featured
QTreeView? You should be prepared for writing 1000 lines of code to make
it. You want access function in QMenu which emulate key pressing - to
raise menu programmically?!? Forget about this idea!
- They claim Qt is modular == composed from many independent libraries,
but you can't even write modular programmer text editor with Qt: due to
broken QTextEdit: you can't define 2 syntax highlighter at the same time
- but it is expected from modular approach to create one plugin for
syntaxhighlighting, and other for spell checking. More: You can't attach
more that one object to QTextBlock (which store one line of code in
QTextEdit), this cause that it is impossible to have one plugin for
syntax highlighter and other for bookmarks (switchable marked places in
code - you can jump between them by hit keyboard shortcuts). So you can
have modular program with syntax highlighting or with bookmarks but not
at the same time!
- Communication with QWebEngine (JavaScript <-> C++) is piece of madman
solution.
To sum up: After selling Qt to Nokia things are going worse and worse. I
don't expect any significant improvement in approaching Qt 6. They don't
have the same philosophy as they have before Qt 4 (easy to use library
for writing apps in pure C++). How ever until Nokia days Qt has only
commercial license for commercial projects.
Richard
Jul 10, 2019, 12:58:56 PM7/10/19
to
[Please do not mail me a copy of your followup]
leigh.v....@googlemail.com spake the secret code
<09370ef0-c25c-45a4...@googlegroups.com> thusly:
>What isn't very wise is using WxWidgets instead of Qt given that
>WxWidgets is an egregious rip off of the disaster that is MFC. Of course
>once neoGFX 1.0 is released using Qt will also be unwise. :)
What isn't very wise is using Qt instead of WxWidgets given that Qt is
an egregious rip off of the disaster that is NIH syndrome.
In all seriousness, though, Qt and WxWidgets take very different
approaches to the same problem. Qt implements the entire GUI stack and
just subscribes to events from the underlying window system and pushes
pixels in return. (This is why you can run a Qt application on
Windows with a command-line switch that says "give me the macOS look
and feel".)
WxWidgets acts as the thinnest possible portable layer on top of the
native windowing system. This is why WxWidgets applications manage to
maintain exactly look and feel of the native window system, while Qt
applications have minor quirks and differences that are noticeable to
experienced users. It is also why WxWidgets applications have
significantly smaller footprints -- instead of reimplementing the GUI
stack, they sit on top of the native GUI stack. Oddly enough, the
latest WxWidgets can even sit on top of Qt for environments where Qt
has a windowing system implementation and WxWidgets does not.
Although personally I consider that to be a weird solution, but
obviously someone found it useful or they wouldn't have contributed
the implementation.
I've worked on non-trivial WxWidgets applications (subdivision surface
modeler) and non-trivial Qt applications (3D scene composition and
rendering). Both frameworks have their advantages and disadvantages.
My personal preference is for WxWidgets because it is a lighter layer
and matches the native windowing system more faithfully because it
doesn't try to reinvent the entire look and feel itself.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
leigh.v....@googlemail.com spake the secret code
<09370ef0-c25c-45a4...@googlegroups.com> thusly:
>What isn't very wise is using WxWidgets instead of Qt given that
>WxWidgets is an egregious rip off of the disaster that is MFC. Of course
>once neoGFX 1.0 is released using Qt will also be unwise. :)
an egregious rip off of the disaster that is NIH syndrome.
In all seriousness, though, Qt and WxWidgets take very different
approaches to the same problem. Qt implements the entire GUI stack and
just subscribes to events from the underlying window system and pushes
pixels in return. (This is why you can run a Qt application on
Windows with a command-line switch that says "give me the macOS look
and feel".)
WxWidgets acts as the thinnest possible portable layer on top of the
native windowing system. This is why WxWidgets applications manage to
maintain exactly look and feel of the native window system, while Qt
applications have minor quirks and differences that are noticeable to
experienced users. It is also why WxWidgets applications have
significantly smaller footprints -- instead of reimplementing the GUI
stack, they sit on top of the native GUI stack. Oddly enough, the
latest WxWidgets can even sit on top of Qt for environments where Qt
has a windowing system implementation and WxWidgets does not.
Although personally I consider that to be a weird solution, but
obviously someone found it useful or they wouldn't have contributed
the implementation.
I've worked on non-trivial WxWidgets applications (subdivision surface
modeler) and non-trivial Qt applications (3D scene composition and
rendering). Both frameworks have their advantages and disadvantages.
My personal preference is for WxWidgets because it is a lighter layer
and matches the native windowing system more faithfully because it
doesn't try to reinvent the entire look and feel itself.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Mr Flibble
Jul 10, 2019, 1:25:54 PM7/10/19
to
system doesn't offer a feature that your application needs on a particular
OS then you have two choices: 1) bodge your application for that
particular OS or 2) use a non-native widget system that has the same,
consistent look and feel no matter what OS it is running on. Modern
frameworks usually employ skins so you can at least get the look of native
widgets if not the feel.
/Flibble
--
"Snakes didn't evolve, instead talking snakes with legs changed into
snakes." - Rick C. Hodgin
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais
“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
Öö Tiib
Jul 10, 2019, 6:06:08 PM7/10/19
to
On Wednesday, 10 July 2019 18:37:52 UTC+3, Szyk Cech wrote:
> - You can't write mobile appqts in C++ - because they force to use vendor
The sole C++ application toolkit in existence with what we can write
GUI programs that compile and run as native applications for OSX,
iOS, Android, Windows and Linux is Qt. QML just works on all those
platforms if we want that feature.
Seems that you are one of those Dunning-Kruger types who is hugely
ignorant but wants to teach others from that miserable state.
> - You can't write mobile appqts in C++ - because they force to use vendor
> lock QML (JavaScript style) language. WHEN I REALIZE THIS I DECIDE TO
> SPLIT UP WITH QT!!!
Usage of GUI scripting with QML is not anyhow forced by it.
> SPLIT UP WITH QT!!!
The sole C++ application toolkit in existence with what we can write
GUI programs that compile and run as native applications for OSX,
iOS, Android, Windows and Linux is Qt. QML just works on all those
platforms if we want that feature.
Seems that you are one of those Dunning-Kruger types who is hugely
ignorant but wants to teach others from that miserable state.
Mr Flibble
Jul 10, 2019, 6:56:28 PM7/10/19
to
centre so that is rather telling as to what their primary focus is. My
(neoGFX) scripting support will be entirely optional in the primary work flow.
Yes Qt is currently the *least worst* offering as far as a cross platform
C++ GUI library is concerned but I intend to improve on that sorry state
of affairs with neoGFX.
Melzzzzz
Jul 10, 2019, 8:29:48 PM7/10/19
to
On 2019-07-10, Mr Flibble <flibbleREM...@i42.co.uk> wrote:
> On 10/07/2019 23:05, Öö Tiib wrote:
>> On Wednesday, 10 July 2019 18:37:52 UTC+3, Szyk Cech wrote:
>>> - You can't write mobile appqts in C++ - because they force to use vendor
>>> lock QML (JavaScript style) language. WHEN I REALIZE THIS I DECIDE TO
>>> SPLIT UP WITH QT!!!
>>
>> Usage of GUI scripting with QML is not anyhow forced by it.
>> The sole C++ application toolkit in existence with what we can write
>> GUI programs that compile and run as native applications for OSX,
>> iOS, Android, Windows and Linux is Qt. QML just works on all those
>> platforms if we want that feature.
>>
>> Seems that you are one of those Dunning-Kruger types who is hugely
>> ignorant but wants to teach others from that miserable state.
>
> Qt Company's primary product marketing on their website puts QML front and
> centre so that is rather telling as to what their primary focus is. My
> (neoGFX) scripting support will be entirely optional in the primary work flow.
>
> Yes Qt is currently the *least worst* offering as far as a cross platform
> C++ GUI library is concerned but I intend to improve on that sorry state
> of affairs with neoGFX.
Cross platform is not in interrest of M$ and Apple$...
> On 10/07/2019 23:05, Öö Tiib wrote:
>> On Wednesday, 10 July 2019 18:37:52 UTC+3, Szyk Cech wrote:
>>> - You can't write mobile appqts in C++ - because they force to use vendor
>>> lock QML (JavaScript style) language. WHEN I REALIZE THIS I DECIDE TO
>>> SPLIT UP WITH QT!!!
>>
>> Usage of GUI scripting with QML is not anyhow forced by it.
>> The sole C++ application toolkit in existence with what we can write
>> GUI programs that compile and run as native applications for OSX,
>> iOS, Android, Windows and Linux is Qt. QML just works on all those
>> platforms if we want that feature.
>>
>> Seems that you are one of those Dunning-Kruger types who is hugely
>> ignorant but wants to teach others from that miserable state.
>
> Qt Company's primary product marketing on their website puts QML front and
> centre so that is rather telling as to what their primary focus is. My
> (neoGFX) scripting support will be entirely optional in the primary work flow.
>
> Yes Qt is currently the *least worst* offering as far as a cross platform
> C++ GUI library is concerned but I intend to improve on that sorry state
> of affairs with neoGFX.
>
> /Flibble
>
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Öö Tiib
Jul 10, 2019, 8:45:12 PM7/10/19
to
On Thursday, 11 July 2019 01:56:28 UTC+3, Mr Flibble wrote:
> On 10/07/2019 23:05, Öö Tiib wrote:
> > On Wednesday, 10 July 2019 18:37:52 UTC+3, Szyk Cech wrote:
> >> - You can't write mobile appqts in C++ - because they force to use vendor
> >> lock QML (JavaScript style) language. WHEN I REALIZE THIS I DECIDE TO
> >> SPLIT UP WITH QT!!!
> >
> > Usage of GUI scripting with QML is not anyhow forced by it.
> > The sole C++ application toolkit in existence with what we can write
> > GUI programs that compile and run as native applications for OSX,
> > iOS, Android, Windows and Linux is Qt. QML just works on all those
> > platforms if we want that feature.
> >
> > Seems that you are one of those Dunning-Kruger types who is hugely
> > ignorant but wants to teach others from that miserable state.
>
> Qt Company's primary product marketing on their website puts QML front and
> centre so that is rather telling as to what their primary focus is. My
> (neoGFX) scripting support will be entirely optional in the primary work flow.
Each IT company of any significance seems to push some java, csharp,
> On 10/07/2019 23:05, Öö Tiib wrote:
> > On Wednesday, 10 July 2019 18:37:52 UTC+3, Szyk Cech wrote:
> >> - You can't write mobile appqts in C++ - because they force to use vendor
> >> lock QML (JavaScript style) language. WHEN I REALIZE THIS I DECIDE TO
> >> SPLIT UP WITH QT!!!
> >
> > Usage of GUI scripting with QML is not anyhow forced by it.
> > The sole C++ application toolkit in existence with what we can write
> > GUI programs that compile and run as native applications for OSX,
> > iOS, Android, Windows and Linux is Qt. QML just works on all those
> > platforms if we want that feature.
> >
> > Seems that you are one of those Dunning-Kruger types who is hugely
> > ignorant but wants to teach others from that miserable state.
>
> Qt Company's primary product marketing on their website puts QML front and
> centre so that is rather telling as to what their primary focus is. My
> (neoGFX) scripting support will be entirely optional in the primary work flow.
actionscript, golang, swift, qml etc. instead of C++. Microsoft has
even second level distraction language managedc++cli.
Such distract dummies to program in some kind of "C++ for dummies"
and that is good ... less dummies in my teams. ;)
> Yes Qt is currently the *least worst* offering as far as a cross platform
> C++ GUI library is concerned but I intend to improve on that sorry state
> of affairs with neoGFX.
target asm.js ... Qt kind of works in browser but feels sluggish
and that Unreal Engine is even worse. When something
runs well in browser then it will run at least 4 times better
as native app. Also it is most cheap to demo asm.js stuff in web. ;)
Szyk Cech
Jul 10, 2019, 11:57:42 PM7/10/19
to
W dniu 11.07.2019 o 00:05, Öö Tiib pisze:
If you want write mobile apps in C++ then you will see many difficulties:
* widgets not prepared for finger (small controls) - QML styled widgets
are not exposed to C++ - you will have to create your own styles for
widgets for mobile apps.
* some widgets behaviour present in QML is not exposed to C++. I talk
about animations in GUI.
p8mode wants to use QtQuick without QML and talk about this years ago on
official Qt forum:
https://forum.qt.io/topic/20843/qtquick-without-qml-pure-c-apps-possible/4
The answer was:
"While passions run high on this issue and there are good points to be
made by all parties involved, the short answer is that a QML-less Qt
Quick is not on the immediate Qt roadmap."
Up to now seems they change nothing in their minds.
> Usage of GUI scripting with QML is not anyhow forced by it.
Why do you tell this? I wrote that they force to use QML in mobile apps.
If you want write mobile apps in C++ then you will see many difficulties:
* widgets not prepared for finger (small controls) - QML styled widgets
are not exposed to C++ - you will have to create your own styles for
widgets for mobile apps.
* some widgets behaviour present in QML is not exposed to C++. I talk
about animations in GUI.
p8mode wants to use QtQuick without QML and talk about this years ago on
official Qt forum:
https://forum.qt.io/topic/20843/qtquick-without-qml-pure-c-apps-possible/4
The answer was:
"While passions run high on this issue and there are good points to be
made by all parties involved, the short answer is that a QML-less Qt
Quick is not on the immediate Qt roadmap."
Up to now seems they change nothing in their minds.
Öö Tiib
Jul 11, 2019, 1:16:47 AM7/11/19
to
On Thursday, 11 July 2019 06:57:42 UTC+3, Szyk Cech wrote:
> W dniu 11.07.2019 o 00:05, Öö Tiib pisze:
> > Usage of GUI scripting with QML is not anyhow forced by it.
>
> Why do you tell this? I wrote that they force to use QML in mobile apps.
And I wrote they don't.
> W dniu 11.07.2019 o 00:05, Öö Tiib pisze:
> > Usage of GUI scripting with QML is not anyhow forced by it.
>
> Why do you tell this? I wrote that they force to use QML in mobile apps.
> If you want write mobile apps in C++ then you will see many difficulties:
> * widgets not prepared for finger (small controls) - QML styled widgets
> are not exposed to C++ - you will have to create your own styles for
> widgets for mobile apps.
> * some widgets behaviour present in QML is not exposed to C++. I talk
> about animations in GUI.
> p8mode wants to use QtQuick without QML and talk about this years ago on
> official Qt forum:
> https://forum.qt.io/topic/20843/qtquick-without-qml-pure-c-apps-possible/4
writing QML applications. I said that QML is not needed and so
also Qt Quick is not needed for writing apps. It is OK for
whipping up some quick throw-away prototypes, that is it.
> The answer was:
> "While passions run high on this issue and there are good points to be
> made by all parties involved, the short answer is that a QML-less Qt
> Quick is not on the immediate Qt roadmap."
>
> Up to now seems they change nothing in their minds.
you don't want to write QML applications? Nonsense.
Szyk Cech
Jul 12, 2019, 11:35:51 AM7/12/19
to
W dniu 11.07.2019 o 07:16, Öö Tiib pisze:
Qt Quick classes were written in C++ and exposed to QML exclusively. So
there is no technical reasons to not use it in pure C++ apps. Only the
Qt vendor lock politics prohibit programmers from this!
If you don't know about Qt history, architecture, and politics - don't
write. Otherwise you appear as ignorant (which is soft term mean: stupid).
> So you want to use module of Qt for writing QML applications but
> you don't want to write QML applications? Nonsense.
Programmer can't be so lame to tell this! You talk nonsense!
> you don't want to write QML applications? Nonsense.
Qt Quick classes were written in C++ and exposed to QML exclusively. So
there is no technical reasons to not use it in pure C++ apps. Only the
Qt vendor lock politics prohibit programmers from this!
If you don't know about Qt history, architecture, and politics - don't
write. Otherwise you appear as ignorant (which is soft term mean: stupid).
Öö Tiib
Jul 12, 2019, 2:17:54 PM7/12/19
to
On Friday, 12 July 2019 18:35:51 UTC+3, Szyk Cech wrote:
> W dniu 11.07.2019 o 07:16, Öö Tiib pisze:
> > So you want to use module of Qt for writing QML applications but
> > you don't want to write QML applications? Nonsense.
>
> Programmer can't be so lame to tell this! You talk nonsense!
Next you start to use all caps like that false prophet Rick C Hodgin. :D
> W dniu 11.07.2019 o 07:16, Öö Tiib pisze:
> > So you want to use module of Qt for writing QML applications but
> > you don't want to write QML applications? Nonsense.
>
> Programmer can't be so lame to tell this! You talk nonsense!
> Qt Quick classes were written in C++ and exposed to QML exclusively. So
> there is no technical reasons to not use it in pure C++ apps. Only the
> Qt vendor lock politics prohibit programmers from this!
within limits of that LGPL. And LGPL just means that you have to
make source code of your hacks of library available to others.
Classes designed for one thing are hard to hack to do some other
thing (that these were not designed for) and so these may stop
functioning and start to crash.
That is all that "prohibits" you and makes you to whine about evil
conspiracies. All I was saying was that Qt without using that Qt
Quick bloat is plenty.
> If you don't know about Qt history, architecture, and politics - don't
> write. Otherwise you appear as ignorant (which is soft term mean: stupid).
stupid. Remember, you started this thread by demonstrating incapability
to read https://docs.wxwidgets.org/trunk/overview_events.html :D
Szyk Cech
Jul 12, 2019, 2:38:12 PM7/12/19
to
W dniu 12.07.2019 o 20:17, Öö Tiib pisze:
it self but Qt Creator code. I have few ideas of improvement it. But I
hate to do this with every Qt Creator release and after patching few
releases I give up! I think it will be the same with hack Qt (beside
potentially unstability). So: Qt Quick classes should be usable from C++
out of the box!
>> Qt Quick classes were written in C++ and exposed to QML exclusively. So
>> there is no technical reasons to not use it in pure C++ apps. Only the
>> Qt vendor lock politics prohibit programmers from this!
> You can use all code that is open source in Qt however you please
> within limits of that LGPL. And LGPL just means that you have to
> make source code of your hacks of library available to others.
>
> Classes designed for one thing are hard to hack to do some other
> thing (that these were not designed for) and so these may stop
> functioning and start to crash.
>
> That is all that "prohibits" you and makes you to whine about evil
> conspiracies. All I was saying was that Qt without using that Qt
> Quick bloat is plenty.
Actually I have done some thing like hack official sources. But not Qt
>> there is no technical reasons to not use it in pure C++ apps. Only the
>> Qt vendor lock politics prohibit programmers from this!
> You can use all code that is open source in Qt however you please
> within limits of that LGPL. And LGPL just means that you have to
> make source code of your hacks of library available to others.
>
> Classes designed for one thing are hard to hack to do some other
> thing (that these were not designed for) and so these may stop
> functioning and start to crash.
>
> That is all that "prohibits" you and makes you to whine about evil
> conspiracies. All I was saying was that Qt without using that Qt
> Quick bloat is plenty.
it self but Qt Creator code. I have few ideas of improvement it. But I
hate to do this with every Qt Creator release and after patching few
releases I give up! I think it will be the same with hack Qt (beside
potentially unstability). So: Qt Quick classes should be usable from C++
out of the box!
0 new messages