* New function formatToolTip(QString):
Format text for display as a ToolTip, breaking at lines of a certain
width. Note: this function is expensive. Better call it in a delayed manner,
i.e. not to fill in a model (see for instance the function
ToolTipFormatter::eventFilter).
* Install a global event filter that formats tooltips on-the-fly
Inspired from
3793fa09ff
but much improved.
When is formatToolTip called automatically? Whenever the tooltip is not already
rich text beginning with <html>, and is defined by the following functions:
* QWidget::setToolTip(),
* QAbstractItemModel::setData(..., Qt::ToolTipRole),
* Inset::toolTip() (added in one of the subsequent patches)
In other words, tooltips can use Qt html and the tooltip will still be correctly
broken. Moreover, it is possible to specify an entirely custom tooltip (not
subject to automatic formatting) by giving it in its entirety, i.e. starting
with <html>.
This file contains some do's and dont's for the Qt4 frontend.
General rules
-------------
Every editable field that affects the state of the dialog contents
from LyX's point of view should connect its xxxChanged() signal to
a the dialog's changed_adaptor() slot, which in turn should call
changed(). If you are using a more complicated thing anyway,
then remember to call changed() at the end (if it has changed!)
Every non-trivial widget should have a tooltip. If you don't know
what to write, write "FIXME", and it can fixed later. Don't be afraid
to use QWhatsThis too, but this must be done in the derived class's
constructor, and use _("..."). Non-trivial means that things like "OK"
/must not/ have a tooltip.
moc needs a fully qualified "std::string" for .connect() statements
to work. Be very, very careful.
Remember to check tab order on a dialog (third icon, with blue bars in
designer).
Remember to check sensible resizing behaviour on a dialog. This is
usually done by adding a top-level layout to the dialog in Designer.
Remember to use Edit->Check Accelerators
If necessary, you should override Qt2Base::isValid() for determining the
validity of the current dialog's contents.
OK/Apply/Restore/Close should be connected in the derived class's
constructor to call slotOK() etc. Refer to close/cancel as close in the
source.
Override update_contents() to update the dialog, not update(). Only
these functions may change dialog widgets that may emit changed() during
initialisation, to prevent the button controller from changing its
state.
Never call buttoncontroller functions directly from dialogs. In general,
you should use Qt2Base::changed() in all circumstances. However, if you
must call the buttoncontroller, make sure to respect Qt2Base::updating_
Naming conventions
------------------
QFoo.{cpp,h} The file that interacts with the controller _and_
the implementation of the dialog, derived from the generated files
ui/FooDialog.ui The designer file
ui_FooDialog.h Generated files from FooDialog.ui
slots should be named e.g. slotFooClicked(), slotFooSelected(), where
foo is the name of the widget.
Widgets should be named like "fooXX", where XX is one of the following
widget types :
CB - check box
CO - combo box
ED - line edit
GB - group box
LA - label
LC - LengthCombo
LV - QListView
ML - QTextBrowser
PB - push button
RB - radio button
SB - spin box
SL - slider
TE - text edit
TW - tree widget (FIXME: also TV in some files)
Qt, Unicode, and LyX
--------------------
LyX uses a different encoding (UCS4) than Qt (UTF16), therefore there are a
number of conversion functions in qt_helpers.{cpp,h}. Read the doxygen
documentation for details when to use which function.
Additionally, you should follow these simple rules :
o Use qt_() not _() in code
o Use the conversion functions of qt_helpers.h, NOT .latin1() / .c_str() etc.
059ca0f691