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

List:       kde-core-devel
Subject:    Re: KQuickHelp replacement (was: kdevelop/kdevelop)
From:       Carsten Pfeiffer <carpdjih () cetus ! zrz ! TU-Berlin ! DE>
Date:       1999-09-07 13:55:10
[Download RAW message or body]

On Tue, Sep 07, 1999 at 02:50:17PM +0200, Harri Porten wrote:

Hi,
 
> Marios idea to invoke it via the RMB might have caused conflicts with
> context menus in the long run but it was *easy* and *fast*.

I actually like the invocation via popupmenu. There just had to be an
interface for applications to use that popupmenu as well. E.g. 

KQuickHelp::add( QWidget *, const QString&, QPopupMenu *menu=0L );

If menu is not 0L, KQuickhelp would use the first entry in the popupmenu.
 
> a) setting the focus on the widget and typing Shift-F1 or

Speaking of shortcuts in Qt - there is still that problem that KDE can't
provide a means to change them. Reggie, could you ask the Trolls (or do it
yourself :o) if they could implement some QStdAccels class similar to
KStdAccel? Just without the read/write capability and instead with virtual
methods that we could override. And finally some 
QApplication::setStdAccels() to specify them application-wide.
 
> b) a "What's this ?" tool bar button that will enable a special mode
> 
> IMO a) is not suitable for beginners. b) would be fine but where should
> I put the Help button in a dialog that doesn't have a toolbar ? MS
> Windows solution with the `?' button in the window title would be
> suitable as well but we want to be WM independant, don't we ?

The best thing would be an interface in QWhatsThis to manually invoke the
help, e.g. 
QWhatsThis::showWhatsThis( QWidget *widget, const QPoint& pos=QCursor::pos() );

That way, KQuickHelp could become a wrapper around QWhatsThis and the
popup-menu stuff would just call that that function.

Cheers,
Carsten Pfeiffer
-- 
http://www.geocities.com/SiliconValley/1632/

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