[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: KHelpCenter navigator-sidepanel might overinform
From:       Frans Englich <frans.englich () telia ! com>
Date:       2004-11-06 12:07:58
Message-ID: 200411061207.58517.frans.englich () telia ! com
[Download RAW message or body]

On Friday 05 November 2004 19:29, cies wrote:
> HI!
>
> I'm afraid that KHelpCenter's navigator-sidepanel might overinform the
> possibly young users of my app, KTurtle.

Yes, I also think it's a problem. When users selects "Help-> Foo Handbook", 
they don't want a list of each and every document on the system, ranging from 
man pages to what not. They want the application documentation, tightly 
integrated.

I think this problem comes from the split personality of khelpcenter: on one 
hand it is for viewing application manuals independently(or is at least used 
that way), but it is also this reference covering everything on earth. I 
think the vast majority of the users have a small interest in the latter.

The real solution is to, AFAICT, split khelpcenter into three components:

* A library handling the core functionality, such as opening and transforming 
the documentation. Part of kdelibs(kutils, perhaps).

* A dialog for viewing application documentation(kutils). It uses the core 
library. Applications' "Help -> Foo Handbook" would use it, insteead of 
khelpcenter.

* KHelpCenter, as per the appearance we know to day. Part of kdebase, and uses 
the core library from kdelibs. It would be as we know it, the "reference" 
documentation, where everything can be reached.

The advantages of this refactoring is it solves the information overflow 
problem khelpcenter currently has with viewing app docs(as you describe) -- 
the application documentation would be a nice, light dialog.

Another advantage, worth its weight in gold, is that the doc viewing would be 
in-process. This means much better communication(you have a class interface 
instead of program arguments), faster, lighter on resources, proper window 
handling(KWin knows the windows are related), and you can do all kind of 
exciting stuff. For example, the Docbook language could be extended with 
elements that specifies widgets in the GUI(the QObject name), and the output 
could then have "[Show me!]" and when clicked, the widget in the application 
was highlighted. There are many possibilites in this, with the flexibility of 
docbook and Qt.

But of course, one can add DCOP calls until the same functionality is met..

It would also solve the packaging-problem which was highlighted on a 
kde-core-devel discussion some time ago; where should khelpcenter be? kdelibs 
or kdebase? (that's a mess to resolve right now, because it does two things)

Implementing it is probably possible to do in a "finite" timescale; sloccount 
says khelpcenter consists of 6700 lines of code.


As most else on kde-usability it sounds nice, but no patch(I won't do it, 
busy).


Cheers,

		Frans

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]