Thinking about LDCad 2.0 and open sourcing it


RE: Thinking about LDCad 2.0 and open sourcing it
#12
(2016-05-31, 6:21)Milan Vančura Wrote:
(2016-05-31, 5:20)Travis Cobbs Wrote: With LDView, the Windows version is native Win32, the Mac version is native Cocoa, and the Linux version is native Qt. Of course, that means that I had to write the interface twice, and someone else had to write it once. (I mentioned above that Peter maintains the Qt code.) But a majority of all LDView code is cross-platform C++ (written before C++11 was available, so not at all what "modern" C++ would look like).
I do not know what was the (historical) reason for this with LDView but one of the biggest advantages of Qt is that it is really multiplatform. Not only Linux/Windows/Mac but also iPad or Android. So for new projects, there is no need to write GUI three times.
In fact, if Roland didn't want to implement his own GUI library, I'd strongly recommend Qt (even I am really not a KDE fan!). Just being pragmatic: there is a lot of work done - it's a C++ library with both its own scripting language and python bindings. It's mutiplatform and developed for many years, stable. And, even I do not know it to work with, I am able to read the others' Qt code and fix some bugs there. What shows the code is relatively easy to read. And, also, it allows the application to look natural on all platforms and supports multilingual applications with Unicode very well. So my opinion is it might make sense for Roland to use it and concentrate on direct openGL usage for time-critical issues like fast model rendering. But it's up to Roland.

I don't know how Qt is now, but historically, it was very much a second-class citizen on Mac and Windows. Sure, it worked, but you could always tell that such apps weren't truly native. Such basic things as file open and save dialogs didn't use the system-standard ones, leading to user frustration, and every time a new OS came out with any kind of different look and feel, Qt apps were stuck with something that mostly had the old look and feel, but was never quite right in the little details.

Now, I'm not saying that Qt apps are bad, but it bothered me enough to have native Mac and Windows versions. Look at how Export and Save Snapshot are even now in the Qt version of LDView. Instead of having the options right there in the dialog where they belong, the options are separate. It could well be that this could be fixed now, but it was a problem when those were initially implemented. (Note: I think support for native open/save dialogs was added to Qt, but that support didn't include the ability to customize such dialogs. So once they fixed the first problem, you were left with the second problem if you needed customized versions of those dialogs.)

Now, I realize that Qt by its very nature can't be expected to provide hooks into all the latest and greatest native functionality provided by each OS that it supports, but the fact is that true native apps can almost always be made to have a more standard-seeming (and I would argue better) UI.

There were historically license issues with Qt also. I think the free version required any apps that used it to be GPL. I think they fixed that (although LDView is GPL, so it's not an issue for LDView). I haven't personally looked at Qt in years, so it could well be that modern Qt is fine, and solves the problems. But since I'm pretty sure that part of the Qt design is that Qt itself draws the widgets, I don't see how it can ever be a perfect match on all platforms. Mind you, what it does provide is good enough to produce good apps; it's just that they'll likely always feel just a bit off to people using Mac and Windows.
Reply
« Next Oldest | Next Newest »



Messages In This Thread
RE: Thinking about LDCad 2.0 and open sourcing it - by Travis Cobbs - 2016-05-31, 16:46

Forum Jump:


Users browsing this thread: 1 Guest(s)