Windows Gui Frontend

[dn]

On 03/04/2023 02.45, Michael Torrie wrote:
> On 4/2/23 05:09, Dietmar Schwertberger wrote:
>> I also did evaluate all the GUI builder from time to time between
>> 2000 and 2016 to find one that I could recommend to colleagues,
>> but could not find one. Then I started contributing to wxGlade
>> and I can say that since a few years it's as easy again to
>> build GUIs as it was with VB6.
>>
>> I don't want to go back to coding GUIs manually. For most use
>> cases it's a waste of time and often it does not result in the
>> best GUI as it's not so easy to try out and rearrange elements.
> 
> But any modern GUI toolkit has sizers and layout managers. If you're
> manually placing elements you cannot deal with HiDPI or changing window
> sizes.  Rearranging happens automatically when using sizers and layout
> managers.
> 
> That said, the future of GUIs is declarative, using XAML or some other
> domain-specific language like QML.  Examples of this include QtQuick
> (the long-term direction Qt is heading), and the various dot Net GUI
> toolkits now popular including MS' own MAUI, WPF, Avalonia.
> 
> GUI designer tools (Qt Creator, Visual Studio) can be used to assist and
> help layout the skeleton, but ultimately the GUI is defined by code. And
> it works very well, is adaptive, and can automatically size and
> rearrange. If you want portability to mobile devices, this is where it's at.
> 
> I've tried wxGlade but never could get into it, or wxWidgets in general.
>   I used to use GTK a lot and did use Glade back then, and dynamically
> loaded the UI definition files at run time.  Lately used more Qt with
> QtDesigner, and even extended Designer to support using some custom
> widgets I made.
> 
> but the future of Qt is clearly QtQuick, so I've been learning that.
> Has its warts, but in general I like the declarative paradigm.  It's a
> learning curve.  Overall it's fairly powerful, flexible and portable.  I
> have used the designer in Qt Creator a bit, but it's often faster and
> just as intuitive to write it in QML, since you're going to be dropping
> into QML frequently anyway to set properties (not unlike having to set
> widget properties in Qt Designer.  So I guess it's 6s using the
> graphical designer vs straight Qt.

Do the two approaches acknowledge each other and enable 'round tripping'?
ie to use the best?better tool for particular jobs (and to cope with 
later-maintenance) can one start using one approach, switch to using the 
other, and then go back to the first?

-- 
Regards,
=dn