On Wednesday October 21 2015 11:30:46 Jaroslaw Staniek wrote: >- Looking at competition is always good. Do these MS Office/Adobe apps use >dbus?
I don't think so, and my suggestion to look at commercial software suites was unrelated to the use of dbus. It was made with deployment in mind, specifically of shared resources. >even MS isn't interested in dragging own OS' infra to the foreign OS >(Windows -> OS X, recently Android), it is mostly using the infra available >on the target OS (OS X, Android, respectively). Yes, that's what I meant when I said their products are well written. They actually have a long history of providing what one could call more advanced applications on the Mac. MS Word 5 for Mac was a great product, way ahead of its DOS counterpart, and in certain ways even of MS Word 6 for MS Windows. >- What do we miss on OS X without dbus? Any and all forms of IPC that are designed to use dbus, and the applications that rely on that IPC? KDE PIM is a prime subject, one that is crucial for me. (As in, if I cannot use Kontact/KMail/Knode and family I lose most of my incentive to bother installing KDE at all). >Except a risk for further bugs? From what I can see it works just fine, but if KDE's IPC can be written as something K-specific that uses appropriate, native backends then that would undoubtedly be preferable. >If I want to talk to system services can I use dbus on OS X? No. I will >have to use another IPC approach. You probably don't use an IPC approach at all on OS X. If enough software relies on DBus to talk to those system services, it wouldn't be unreasonable to implement whatever is missing on the other side. That would also benefit all non-KDE software that has similar requirements. >Unnecessary complication. Not necessarily if things are already done that way elsewhere. Many OS X APIs that correspond to what I think you mean with system services are tedious if not downright (over)complicated on OS X (there's a reason I haven't bothered to extend Solid's OS X implementation). Having to write and maintain large swathes of platform-specific code in applications, that's what reeks of unnecessary complication to me. (Look at the RAM size detection bug I fixed in Krita the other day ... and that one should have been completely avoidable because OS X and FreeBSD work the same in this aspect). >The approach to multiplatform development that drags infrastructure from >the original OS is the one I do not accept. I find it vastly preferable to leaving vast areas of functionality unimplemented. In my world view, you start by "dragging over" anything that doesn't easily translate immediately (and what can be dragged over, evidently) in order to get a working port, and you continue from there also as a function of demand. R. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
