On 23 October 2015 at 16:18, Luigi Toscano <luigi.tosc...@tiscali.it> wrote: > On Friday 23 of October 2015 10:31:36 Christoph Cullmann wrote: >> Hi, >> >> > Am 21.10.2015 um 12:41 schrieb Christoph Cullmann: >> >> The last time I build umbrello with kf5 (version 5.11) dbus was required >> >> to run khelpcenter and open/save file dialogs and for remote control. >> >> http://download.opensuse.org/repositories/home:/rhabacker:/branches:/wind >> >> ows:/mingw:/win32:/KF511/openSUSE_13.1/noarch/mingw32-umbrello5-installer >> >> -2.18.99-4.1.noarch.rpm (you may open this rpm with ark of 7zip file >> >> manager to get the installer) open/save stuff is fixed in KF5 master >> >> But yes, khelpcenter (if it is shipped) might need fixing >> > >> > khelpcenter is launched by klauncher5 through dbus >> >> I guess for Windows/Mac one would need to generate the help as plain HTML >> anyway, as you don't want to ship KHelpCenter with your application nor >> want to require it to be there (given it uses KHTML and more stuff ;=) > > How are you going to generate plain HTML if the proper macros should be in the > (disabled) KDocTools anyway (because the docbooks - and in future other > formats - could depend on common files? > > The funny thing about this story from my point of view is that, in order to > show that we support other platform, we are going to show that which is the > proper platform which does not force developers to cut down functionalities. > > Side note: LibreOffice ships its help viewer and I don't think anyone > complained so far.
I wouldn't use something as strong as "anyone". Technical decisions come from the StarOffice era when the target was Windows 95 without basic facilities and with limited help viewers. The same reason why some internal legacy UI framework was and still is used. There was even a replacement for entire desktop. Let's look about part of the whole frameworks goal: providing help facilities for use in apps. There's a bit of my POV. And still even this win95-like HTML4-based infra for help feels like much more *compact* (I worked with the translation team for OpenOffice back then) than dbus+docbook+init daemon+browser engine. I simply wouldn't use all that on platforms where it's easy to spot antivirus tools blocking such a bloat. That's one reason. Another is that I prefer to spend time on app features and fixes, not on making the 3rd-party OS, a FOSS-like. Thirdly, after the docbook (or its wiki converter) approach rather failed in practice because of no tooling friendly to actual people with domain knowledge (so no contributions for ages for my apps) I am investigating asciidoc and similar solutions. Or maybe Free documentation failed for that matter, what brings the same point back: commercial work on docs has to be resource-optimized, KISS like. Qt apps (for non-Linux) I've been working on, pressed on CDs back then have been running Qt Assistant bundled with the whole installation. So that was "own" help solution based on a customized template. The point is, with a self-contained component, user can run any number of apps, each employing own Assistant and there wouldn't be a flood of kdeinit or dbus sessions around. I remember that especially casual users, for a reason, notice a process bloat of a ported app. It's like current cars that hide everything from the user, especially everything that could kill her/him. And other than an exerciuse, I don't see a need for fighting for 1-1 portability of such tools that are part of the workspace infra, not the app itself. Especially that some my apps won't use that for sure on tablets. If I can strip-down the app for tablet, and even write a GUI from scratch, I can do use the same for Windows and Mac desktops as well. That's mostly the same task that scales quite well. Now I don't know last time when I've seen any user browsing the help other than API docs. I bet there are some but issue solving via documentation is way worse than via googling now. Ask yourselves. So perhaps there's even that not much to fight about. I've seen that full MS Office 2013 installation does not come with usable manual... And I tried to google a clear evidence that users complain about that, but I failed. Actually let's look as a popular ported standalone app: GTK/GNOME's help-browser that GIMP uses on Windows is the same as on Linux but I don't see it using dbus (but still webkitgtk is used). Moreover if someone caring for UX reads this: KDE's app help window calls itself KDE Help Center. Compare the complexity of KDE apps' help http://i.imgur.com/npgewCo.png to what GIMP has: http://i.imgur.com/kNKwrzK.png. I bet Krita devs won't like to share the help window with the KMail help (if it's even installed on Windows). And well, ToC (or the Home button) in that app is a ToC of "KDE", not the ToC of app :) You're welcome. For me a lot of that applies even to Linux. If we want 3rd-party software use our infra like that, make it compact, we make it trivial to use so it competes with currently used solutions, and make is do one thing well: display the apps' help, not the help of all KDE apps. That would improve things. Just compare: Java apps' help don't display Oracle server help aside of the actual help, .NET apps' help don't show help for all installed .NET apps. Until that is done, I'd accept that people strip down functionality severly, e.g. not shipping help at all in the initial versions. PS: I perceive my attitude as promoting the FOSS OS if not even particular desktops. E.g. If for some reason someone can't live without kioslaves in konqueror for the help protocol, it's easy to get them natively in their "home" OS. -- 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