Question about goal of Windows/Mac frameworks

Fri Oct 23 17:27:41 UTC 2015

On 23 October 2015 at 16:18, Luigi Toscano <luigi.toscano at 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