4 ms·
Neither KParts nor D-Bus are better than COM though. KParts is just some way to expose a Qt widget, at best comparable to something like ActiveX (a very specif
by badsectoracula 2y ago
Neither KParts nor D-Bus are better than COM though.
KParts is just some way to expose a Qt widget, at best comparable to something like ActiveX (a very specific use of COM, not the entirety of what you can do with COM), but even the functionality it exposes is limited. Hell, it might be closer to OLE 1 than even OLE 2. It feels like it was made by someone looking at a specific use of COM/OLE2 in some popular Windows application back in the 90s and decided that that's everything the tech is all about and can do - so you could probably make something like custom WordPad controls with it (though from the docs i don't see any way to store instance-specific data, so you probably can't even get OLE-like functionality) but you couldn't make something like, say, Visual Basic / VBA. Of course being written for Qt it is also inherently limited to be usable only in terms of C++ and with specific Qt versions, which certainly makes is less generic than COM.
D-Bus is a bit closer to COM in that like COM it can be used to have a centralized registry of methods exposed via interfaces in objects to call, but is still also more limited in that it is only meant for passing messages across processes - you can't, e.g., use it to create a "decoder" object with a method you call from several threads in which you give it two memory pointers, one with a buffer of encoded bytes and another to place the decoded bytes into. The closest with D-Bus would be to communicate details for the decoding (perhaps via other IPC methods like shared memory, but that'd be outside of D-Bus itself), though with little control over how it is done. Also FWIW D-Bus has nothing KDE-specific in it (if anything it came out of the GNOME world).
COM might have seen little improvement since Windows 95 but even COM in Windows 95 provides more functionality than what KParts or D-Bus do in modern Linux, so i wouldn't call the latter more technically advanced at all. The only benefit they have is being designed a few years after COM so they didn't had the constraint of having to run in systems with 8MB of RAM.
- pjmlp 2y agoIn what concerns developer tooling, 100% definitely better than COM. "Modern" COM tooling, is only modern in that the MIDL language is now at version 3.0, everything else is as modern as using Visual C++ in Windows 95 with either MFC or ATL 1.0. Which is kind of unbeliveble, given how much COM gets pushed everywhere on Windows, that WinDev likes so much their primitive tooling, even Borland provides a much better COM developer experience. The only time in COM's lifetime that they actually improved the developer experience, with C++/CX, it was killed by an internal riot, and replaced by a bad joke reminiscient of the same ATL experience WinDev loves so much.
- badsectoracula 2y agoI won't argue that COM tooling is bad - and really even the tech itself is overall more complicated than it should be, but at the end of the day between a tech with awful tooling that can do something you need and a tech with good tooling that is incapable of doing something you need, i'd still call the former overall better from a technical perspective (even if in practice i'd rather use neither).
- pjmlp 2y agoWell, I have C, JavaScript, PHP, Go in the same bucket of "awful tooling that can do something you need...", which doesn't make COM any better. Windows developers basically have no option, as since Windows Vista, most of native APIS are no longer classical Win32 C APIs, rather COM, and on top, we have to write .NET bindings by hand, because why would WinDev care about other programming stacks developed by their employer anyway.