If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Announcement
Collapse
No announcement yet.
KDE Now Maintaining Their Own Set of Patches For Qt 5
C++ has become a standard in 1998. Why was Qt using it before?
Because C++ 2.0 was a formally defined programming language since 1989. If you take a look at the early history of Qt, you'll realize that they were way too far into Qt development when STL became available.
can you code an socket interface around a named pipe? If yes, then that providing this as a QAbstractSocket inteface would be preferable.
I mean, you dont complain about QString not beeing 8bit UTF on Linux...
I'm not sure I follow. Q[Tc|Ud]pSocket inherits from QAbstractSocket which in turn inherits from QIODevice. QLocalSocket inherits directly from QIODevice. That makes sense to me. For instance, what would you expect QAbstractSocket::bind() to do on a local socket?
POSIX is a standard, supported by multiple Platforms natively and many more through compat layers. Even down to hard RTOS for microcontrollers with 256K RAM. Cant get more crossplatform than that.
And yet, there are still platforms with limited POSIX support. POSIX also provides a fairly low-level functionality. In cannot draw stuff on screen, play sounds, read mouse input, lots of stuff that you need to write an end-user oriented software in the 21st century.
The reason Qt didn't use STL isn't that it didn't exist. It's that 20 years ago STL sucked.
One of the main features of Qt was to work cross-platform, and 99% of those platforms had a default included STL that sucked. So Qt either had to provide their own implementation or deal with tons of complaints about it not working very well on platform XYZ.
You could argue that these days the STL problem is largely solved, and you'd be correct. But dropping their own internal types now would be a pretty major API change that would cause a lot of pain for people porting their existing apps to new versions of Qt. Given that, I think they've decided it's easier to just maintain the existing types since they are mostly done and working anyway.
You dont need to pick Rust, std::string is a proper C++ entity, there is std::filesystem, std::networking is in work. Those are thin layers over the used OS, instead of its own plattform with absurd levels of abstractions, bad design and limitations.
Filesystems don't have encodings (NTFS being a notable exception). A filename is just a raw string of bytes with no "human meaning". QString provides both Unicode support and conversion routines to multiple encodings, the fact that it uses UTF-16 as internal representation is just an implementation detail which probably made sense back then.
Prior to Unicode 2.0 in 1996, Unicode's codepoint space was limited to 65,536 codepoints and plenty of projects (Windows NT, Java, Qt, etc.) chose a 16-bit fixed-width encoding known as UCS-2 on the reasonable-at-the-time assumption that it'd give them ASCII-like manipulation characteristics while covering all of Unicode.
UTF-16 is a compatibility hack to break out of that 65,535 codepoint limit while staying compatible with things like Windows NT APIs which were originally spec'd for UCS-2. (And that's why NTFS doesn't enforce the paired surrogates requirement for UTF-16. Filenames might have already existed on disk which used those reassigned codepoints in other ways and Microsoft didn't want to break things.)
I don't have much interest in kde, but for some purposes I use a browser (falkon) which is nominally within kde.[/URL]
Falkon works fine on Haiku as well, even back when it was still called QupZilla, but it still does as Falkon these days. And I also run it on Deepin without any KDE libs installed. So stop saying (you're not the first one to say this!) that Falkon requires KDE 'cause it's not true.
I don't write desktop applications for Linux so I'm not familiar with GTK/QT APIs, though from what I gather, QT takes the kitchen-sink approach. From what I see, Gnome developers were amenable to libhandy for augmenting GTK with new widgets that support mobile form factors, even to the point that there now exists a libadwaita to make that integration more official. What is GTK missing that Qt app developers want? Could anything less interesting to Gnome devs just be made into a library?
The only major thing I've seen people complain about is that GTK doesn't support other platforms well, but I think that argument is weaker now that mobile platforms are taking over, and afaik, Qt integration on iOS and Android is pretty terrible.
Qt integration on Android and iOS is terrible, but at least it's an option. Also, Qt runs on Windows, macOS, Haiku, AmigaOS 4, ArcaOS and QNX. GTK somewhat runs on Windows, but it's terrible, and on macOS it's not much better either. GTK doesn't run at all on Android, iOS, Haiku, QNX, ArcaOS and AmigaOS 4 (though you can emulate it on AmigaOS 4 by running a nested X server).
Falkon works fine on Haiku as well, even back when it was still called QupZilla, but it still does as Falkon these days. And I also run it on Deepin without any KDE libs installed. So stop saying (you're not the first one to say this!) that Falkon requires KDE 'cause it's not true.
I thought I said it was nominally within kde. It wants extra-cmake-modules from kde. That is the only kde package I install in my normal builds.
Anyway, you are missing my point - the browser engine is qtwebengine, falkon is a very light build on top of that. And like all browser engines, it needs to be kept up to date as new vulnerabilities are found. The Qt devs seems to have been on top of that, except that their releases are tied into predetermined release dates for Qt. With the lack of non-commercial releases, it is now necessary to pick up the fixes from git (and to be glad that the licence of qtwebengine requires the source to be available).
> > Trying to use it as an object oriented language (and also putting a C++ layer on top of it), will bring the
> > result of "an object-oriented C++ base is better and cleaner than a C++ wrapper around a not-object-oriented base...".
> Neither you can cite, nor you can argue properly [...]
Comment