[Interest] QtDesigner needs redesign.

André Somers andre at familiesomers.nl
Thu Jan 5 08:53:39 CET 2017


While I agree that the current plugin system is not convenient, I don't 
get why you would spend a week with QDialogBox-debugging instead of 
building your own Qt Designer in debug mode and run that in a debugger 
against plugins also build in debug mode?


Op 04/01/2017 om 15:32 schreef Serge K via Interest:
> Среда, 4 января 2017, 14:39 +03:00 от Jean-Michaël Celerier 
> <jeanmichael.celerier at gmail.com <mailto:jeanmichael.celerier at gmail.com>>:
>     On Wed, Jan 4, 2017 at 11:58 AM, Viktor Engelmann
>     <viktor.engelmann at qt.io <mailto:viktor.engelmann at qt.io>> wrote:
>         Custom components in Qt are just QWidget derivates and they
>         can be taken
>         from a designer plugin. This requires some extra code for
>         making them
>         findable (+give them an icon and name etc.) and plugins are
>         technically
>         shared libraries. This explains very clearly why recompiling a
>         custom
>         component requires a restart if we want a perfect preview like
>         in .net,
>         but I still think that there is a lot of room for improvement.
>     Something that would, I think, boost the usage of the designer is
>     to skip the "recompilation" part
>     and just have something that scans your code and interprets the
>     C++ instead of compiling it, with
>     something like
>     https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus .
>     You would just add some metadata to your Widget with
>     Q_CLASSINFO("DesignerName", "My widget"),
>     the code looks for classes with this specific key, "compiles" it
>     and adds it to the designer.
> And how implementation ot this differs from clean rebuild? Plugin is a 
> shared library with some specific macros - these macros already are 
> related to Designer and nothing else. And pluign contains specific C++ 
> code to be supported by Designer. Even entire additional class with 
> set of mandatory methods needed for each plugin main class. And plugin 
> can depend from other files including resources and so on. Which one 
> another "compiler" should process this all? Isn't that a 
> "micros..t-like-way" to build monstrous and expensive tools? OH, NO!
> Exactly plugin auto reloading feature needed for Designer. It is much 
> more simpler and powerful that add just another one macro and create 
> another one compiler. But... this cannot help with other annoying 
> issue when developing plugins. Even Designer custom plugins need to be 
> debugged. Now in "designer mode" even qDebug() doesn't work. Nothing 
> to say about interactive debugger. It doesn't work for plugins loaded 
> to Designer. The only way to debug is - include QMessageBox() and hope 
> the QtCreator won't crash. Yes... it crashes if Designer plugin 
> contains errors. It crashes immediately if you just call QMessageBox() 
> in paintEvent() of custom plugin. I developed custom extended plugin 
> based on QSlider. It allows load SVG animated images for groove and 
> knob and has some other useful features (they cannot be implemented 
> using stylesheets). First time when running in application it looked 
> very different from when it was run in Designer. Yes - application and 
> designed worked on different platforms. I killed lot of time (about 
> week) to understand why they are different and how I must fix this. 
> Without ANY debugging options while plugin runs in Designer. I had to 
> explore source code of several Qt internal classes to understand how 
> this works. But with normal debugging feature I would find solution 
> within minutes.
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20170105/ff31297e/attachment.html>

More information about the Interest mailing list