On 21 October 2015 at 10:20, René J.V. <rjvber...@gmail.com> wrote: > T,FTFY :) > > Seriously, how many people on here are Mac developers with significant > experience targeting native OS X APIs, and how many have significant > experience using Macs as Unix-based workstations with a true, integrated > desktop? Think of significant as "going back to before the last few, free > iterations of the OS". > I wouldn't even call myself the former (I just have a working experience > with the native APIs) but I'm very much the latter. > > All contributions are welcome esp. on platforms where there is very little > support, but IMVHO, people not in either category shouldn't be making > official design decisions for the platform in question (and that applies > not just to Mac / Mac OS X). >
I don't think separating community this way is acceptable. Or categorising people. There are smart people that can have multiple hats. Even for example, less advanced OS X users have right to demand native UI styling on the target OS. You're proposing to use one of the Linux styles which is clearly foreign look. > I'd advise very strongly to get, install a number of commercial big > software suites (MS Office, Adobe Creative, etc) and study how they are > installed and where they put things. Both > > examples exist on multiple platforms, and MS Office is actually very well > written for OS X. > > As to DBus: it's not just a piece of foreign software that happens to work > on OS X, but is actively developed for that OS. There is nothing "anti-mac" > in using it. > > dbus is foreign in most places. Even to KDE contributors it is a bit foreign; we enjoyed other working solution for ages. It wouldn't be even used if not Qt's support coming mostly for free. A couple of open questions: - Looking at competition is always good. Do these MS Office/Adobe apps use dbus? Or run services ported from Windows? That would be equivalent. Note, 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). - What do we miss on OS X without dbus? Except a risk for further bugs? Is OS X dysfunctional in the area of IPC until dbus got ported to OS X? I am also asking as former guy who worked on Windows port of dbus. If I want to talk to system services can I use dbus on OS X? No. I will have to use another IPC approach. Unnecessary complication. - "both examples exist on multiple platforms" - from what I observe over the years at least MS Office has largely separate teams for OS X with significantly separate code base and features (no scripting for example, no MS Access at all) and entirely separate GUI, which on OS X uses native APIs when possible or at least mimicks ones. If MS used, say, .NET solutions to IPC then, yet, that would be a point in favour of your idea. The approach to multiplatform development that drags infrastructure from the original OS is the one I do not accept. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
