Part 3 Action "the GUI library"

[St_W]

Re QT not "Linux software ported to Windows":
Timeline

1990 Qt conceived by Haarvard Nord and Eirik Chambe-Eng on a park bench in Trondheim, Norway.
1995 Troll Tech 1st public release on 20 May. Qt 0.90 for X11/Linux. Commercial & open source (FreeQt license)
1996 Customer no. 1: European Space Agency. Qt 1.0, full X11 support free for free software development plus Windows. KDE project established with Qt as its underlying library.
[...]

That is fifteen years until they got it running on Windows. Go figure...

Windows support was available since the very first production-ready stable release, version 1.0, and it isn't a port as Qt was designed as multi-platform solution from the very beginning.

[lizard]

Unfortunately, the RichEdit control is a candidate for the Micros**t Hall of Shame. I use it every day, even to compile FB programs, but programming the beast is a can of worms. It's very powerful, though (->screenshot with hyperlinks, math symbols etc). Btw .txt should never be a security problem.

You forced me to check ubuntu repository for assembler. There is a package "NASM" rated five stars. The guys there are completly delighted, saying it is the best. After looking at the installed manual at file:///usr/share/doc/nasm/html/nasmdoc0.html and all the examples i believe you would fall in love with linux forever.

[jj2007]

There is a package "NASM" rated five stars. The guys there are completly delighted, saying it is the best. After looking at the installed manual at file:///usr/share/doc/nasm/html/nasmdoc0.html and all the examples i believe you would fall in love with linux forever.

The RichText editor that I posted above is in Masm syntax, i.e. it 'compiles' with the standard Microsoft assembler - try the same in Nasm. Or have a look at the deb macro. I have more than 5,000 assembler sources on my disk, many of which are beyond 10,000 lines. I need tools that can handle more complex tasks... don't be offended, please, Nasm is a nice effort but you can't do things with it beyond an occasional algo to speed up things. My editor is written entirely in Masm, 20k lines. Writing such a program with an assembler that doesn't have basic things like parameter counting and type checking would be a nightmare...

[lizard]

... don't be offended, please,

No, i am not offended. :-)

[caseih]

Which tells us that GTK didn't have a development pace like Qt, which is a pro, although with version 4 this will change, if I am to believe the latest GTK road map.

GTK is actually being developed by only a small number of developers, maybe 4 or 5, only 2 or 3 of which are being paid to work on it by interested parties. This is the reason why Windows and Mac versions are languishing. Qt development is funded by the Qt company, who makes the majority of their money licensing the framework to commercial users, mostly on Windows. Qt has always been a Windows commercial framework first and foremost, while supporting Linux on a free software basis. It may have started life on X11 in the pre 1.0 days, but the vast majority of the time Qt was developed first and foremost on Windows. The history of Qt is long, and jj got most of it wrong, especially the time line.

Given how few resources GTK developers have, I don't see any real future for GTK on Windows or Mac.

But to be fair, as said in one of the larger mails, QT is changing too (qt classic vs qt switch), there is some doubt if the relative certainty of easy QT upgrades (*) will continue
(*) I mean changes to your framework using QT, so not counting the wrapper/header stuff that can be done in a few days hard work since it is semiautomated. Initial GTK headers can also be done in that time frame.

Updates across major versions of Qt, like GTK, require developers to change their code, but updates in minor version require a recompile only, often just a re-linking, unless the developer wishes to use a method call that was introduced in a later, minor version.

Right now there are two Qt toolkits, essentially. The traditional toolkit, called Qt, and the new, Javascript-based toolkit called QtQuick. QtQuick is based on a subset of Qt (the QObject class), but other than that is completely separate, and actually much easier to wrap in other languages. QtQuick is a good candidate for an FB wrapper. I've done a small project in QtQuick lately, and I'm a bit ambivalent about it. If you want to target mobile, multi-touch devices, there's no question QtQuick is the only way to go. For regular desktop apps, I'm not so sure.

That is fifteen years until they got it running on Windows. Go figure...

Sorry jj, your reading comprehension is faulty there. The timeline shows that version 1.0 was available on Windows. It wasn't until Qt 4 that the Windows version had a free software license available for it. Before that, the only licence available on Windows was commercial. And to reiterate other comments, no Qt is not a port from Linux to Windows. Qt pretty much raised on Windows and you can bet they understand Windows internals pretty well.

[caseih]

The point here is that Windows doesn't need QT or GTK or whatever "framework" is around: It is built into the OS. Linux needs them, and nobody else. Using QT on Windows is like installing a second OS on top of one that maybe has its flaws but it works fine. The QT applications I have seen on Windows (very few, actually) look a bit strange, but I could tolerate that. However, they are horribly slow, and often they do not work properly.

Very very few Windows apps use the built-in Win32 gui elements these days. MS Office hasn't for as long as I can remember. The majority of current popular apps draw their own widgets using their own frameworks of various thickness: MS Office, Chrome, Firefox, every single crappy antivirus product on the market, Adobe's creative suite, Visual Studio, and many others. They do sometimes call on some common widgets (Qt does this also). Windows looks more and more like a Linux desktop all the time, and this doesn't seem to be bothering most users. I can't say whether this is good or bad. It's just the way things are on Windows. So if you say Linux is worse than Windows in this regard, you haven't been looking very closely lately!

Qt apps look pretty good on Windows. As native as any app these days. They actually use the Windows theme API to draw the elements. As far as an OS goes, Qt is pretty lightweight, and I'll take it any day over implementing common things myself, such as handling network communications. I can't imagine developing apps on any platform with this sort of framework. Doesn't sound pleasant!

It looks to me like most companies are moving away from native apps in some cases in favor of things like Electron-based applications. Talk about installing an OS on an OS! ;) Can't say I like these hybrid apps, but I completely understand why companies are producing them.

Going to the topic (no I'm not going to read anything before the last 40 or 50 posts to be sure), although I really like Qt, it's not a good fit for FB.

[jj2007]

The history of Qt is long, and jj got most of it wrong, especially the time line.

I got it here: https://wiki.qt.io/Qt_History

[caseih]

I got it here: https://wiki.qt.io/Qt_History

Yes but you misread it, particularly the timeline. Qt was developed on Windows, Mac, and Linux all at the same time from the first 1.0 release onwards. No 15 years to get windows support! Anyway. None of this matters because Qt just isn't ever going to work with FB without significant resources to maintain a C++-based wrapping layer. QtQuick might be possible to at least use from FB.

[Munair]

QtQuick might be possible to at least use from FB.

I'm not a fan of using scripting languages/interpreters for developing applications. I'm also not a fan of .NET or JIT compilers in general for that matter.

[marcov]

Very very few Windows apps use the built-in Win32 gui elements these days. MS Office hasn't for as long as I can remember. The majority of current popular apps draw their own widgets using their own frameworks of various thickness: MS Office, Chrome, Firefox, every single crappy antivirus product on the market, Adobe's creative suite, Visual Studio, and many others.

(I don't know what happened here, probably pressed submit instead of cancel) Anyway, since we can't delete: I started to reply that the top 100 apps is a bad mirror, for many small self employed or small company programmers windows apps are still 95%+ of the business, and while (fairly traditional) web(or -service) and cloudapps slowly eat away at that, changing to imitate whatever MS does with Office internals is madness.

They might have a couple of mobile apps too, but they are usually simplified clients for those web/cloudapps, and usually provided as part of the deal, not a very central premise to the deal.

languages/interpreters for developing applications. I'm also not a fan of .NET or JIT compilers in general for that matter.

Off topic here, but as much as it loathes me to admit it, I think we're just going to have to get used to such things. The future is so-called "hybrid apps" I'm afraid. Everything from Skype to popular editors like Atom or Visual Studio Code are built using Electron, which is basically a mini browser engine that uses Javascript for interactive front-end UIs. I can see the appeal and temptation of these hybrid apps, but I'm not super excited about them.

Do you have paying customers for that kind of apps?

[caseih]

languages/interpreters for developing applications. I'm also not a fan of .NET or JIT compilers in general for that matter.

Off topic here, but as much as it loathes me to admit it, I think we're just going to have to get used to such things. The future is so-called "hybrid apps" I'm afraid. Everything from Skype to popular editors like Atom or Visual Studio Code are built using Electron, which is basically a mini browser engine that uses Javascript for interactive front-end UIs. I can see the appeal and temptation of these hybrid apps, but I'm not super excited about them.

[JohnK]

This will be my last post on this thread. No matter what is said, I still am biased by my own experiences. For the apps I develop, all my end users are on PCs, a dedicated Mac workstation, or (mostly) dedicated dumb net terminals hosted by Citrix servers (eg 'cloud computing' on tiny boxes probably running linux). The software runs in a private non-profit organization.

<bloat>
As long as development is smooth and quick, this has never has been an issue for me. For GUI heavy apps, I use RapidQ as my primary GUI. FB has been very good to me for making the time critical code go fast if I put it in a DLL. If you know what your doing it runs like a champ from Win95 all the way to Win10 64-bit, and MacOS under WINE. And is fairly easy to port VB6 code. This results in a 0.5-3 MB exe. No big deal in comparison to the multiple GB in databases or large videos that the exe uses. Now bloat is the developer tools, and after I purchased VS2006, then tried VS Community, got so frustrated with both, I went back to RapidQ. I found I could get the same result with a lot less effort.

<widget set>
I could care less. All I want is to spend minimum time on the GUI and spend it making the program meet a purpose. If you have a large project, the last thing you need is debugging a complicated widget set. I will never go back to that old native WinAPI GUI coding with obscure resource handles.

<Theme>
I have had several end users comment on how professional my apps look. Never once did they comment on the "theme." All they really care about is how easy is it to run it.


<multi-platform>
I suggested supporting multi-platform for the sake of FB's mission. But for me personally, it has always been about Windows. Our organization is willing to support a few Linux and Mac workstations. After that, forget it. However the VM /cloud computing situation is a blessing and a curse for those of us stuck in Win32 API limbo. The server can host multiple OS (even multiple versions of Windows), however your speed and quality really takes a hit. But think about the VM /cloud computing situation -- if you have 1000's of end users attempting to run in a secure environment, all of them needing updates all the time -- the cloud is much easier to control. Because of the internet, Javascript and it's like are becoming more and more important, which means our great BASIC programming language has fewer and fewer users. While we sit here and battle over Win/Linux, Android is a major focus of development.

[Munair]

If the whole world goes scripting, then at one point we may forget about all the advanced compilers, like GCC and the like. I don't think it will go that fast. There's still a lot of desktop operation going on, like in companies doing graphics, video editing and other specific stuff. But if we were to continue the reasoning, there may come a time when devices/desktops trying to access internet independently, i.e. with local software other than a required minimalistic OS, will no longer be allowed.

Let me elaborate on this a bit. Several years ago there were many maintenance tools for Windows, like TuneUp, CCleaner, etc. A life-time license could be purchased and you were all done. Today, only a yearly subscription is available. The next step could be a payed service whereby the software functions remotely. I believe this was the philosophy with .NET from the beginning. At this point we might reconsider the development of advanced programming tools. Anyone?

[jj2007]

Today, only a yearly subscription is available. The next step could be a payed service whereby the software functions remotely. I believe this was the philosophy with .NET from the beginning.

Sure, they are trying to go that road - same as online journals btw. But remote code and clouds require a perfectly functioniong infrastructure and absolute trust. Both are difficult to get, so being independent from the cloud might remain a marketing argument. German motto: "Die Clowd klaut" ;-)

Yearly subscription is slightly different, this may succeed because a) you don't feel the full cost at once and b) software advances, and the promise will be that you always have the latest and best version. A bit like leasing for cars - partly successful as a business model.

Btw this seems a bit OT - why do you raise it in the GUI lib thread? Do you have a subscription model for a GUI lib in mind?

[Munair]

Btw this seems a bit OT - why do you raise it in the GUI lib thread? Do you have a subscription model for a GUI lib in mind?

Not really off-topic. As I said: "The next step could be a payed service whereby the software functions remotely." which would have a great impact on desktop development. This is already happening with MS Office apps, if I'm not mistaken.