lyx_mirror/src/frontends/kde/dlg
..
dialogs
moc
.cvsignore
checkinitorder.pl
citationdlgdata.C
citationdlgdata.h
copyrightdlgdata.C
copyrightdlgdata.h
docbulletsdlgdata.C
docbulletsdlgdata.h
docdlgdata.C
docdlgdata.h
docextradlgdata.C
docextradlgdata.h
docgeometrydlgdata.C
docgeometrydlgdata.h
doclanguagedlgdata.C
doclanguagedlgdata.h
docsettingsdlgdata.C
docsettingsdlgdata.h
emptytable.C
emptytable.h
helpers.C
helpers.h
indexdlgdata.C
indexdlgdata.h
lengthentry.C
lengthentry.h
logdlgdata.C
logdlgdata.h
Makefile.am
paraabovedlgdata.C
paraabovedlgdata.h
parabelowdlgdata.C
parabelowdlgdata.h
paradlgdata.C
paradlgdata.h
paraextradlgdata.C
paraextradlgdata.h
parageneraldlgdata.C
parageneraldlgdata.h
printdlgdata.C
printdlgdata.h
README
tabcreatedlgdata.C
tabcreatedlgdata.h
tabstack.C
tabstack.h

These files are generated with qtarch-1.4-5 which can be downloaded
from 

http://qtarch.sourceforge.net/

Currently you also need this patch :
http://www.movement.uklinux.net/patches/lyx/qtarch-1.4.6.diff

Eventually the intent is to fold this patch into the official qtarch and
release a qtarch-1.4-6 tarball.

Note this is *not* the latest version, as they only support Qt 2.

You should compile in the KDE module when you compile qtarch-1.4.
For me this was just a case of a make in the module/kde/ directory,
and then you can add the .so library file in the qtarch GUI.

The files in this and the kde/ directory have the following naming
scheme :

random.dlg         - the dlg file for qtarch
FormRandom.[Ch]    - LyX's notion of the dialog, real implementation modified
                     via functions only
randomdlg.[Ch]     - Derived Qt class, edited by hand. The interface between widgets
                     and LyX FormRandom file
randomdlgdata.[Ch] - qtarch-generated files, not to be touched by human hands

The class names are FormRandom, RandomDialog, and RandomDialogData

Note that the .dlg files have no entries for the derived class header and source 
filenames. This is because these files have to be edited by hand and should only
be generated once (and they belong in the parent directory, not dlg/). The
className field, though, has a special meaning. If it is blank, then qtarch
will assume there is no derived class defined at all. Currently this has the effect
of making mapped variables public access. If there is a name, then it assumes that
a derived class exists, and leaves mapped variables protected. It's done like
this to avoid the rat's nest of friend declarations and un-necessary derived classes,
and because the new MVC architecture needs direct access to buttons etc.

There is a naming scheme for any variabled widgets, similar to the xforms frontend :

buttons 	- button_
spinboxen 	- spin_
tabstack 	- tabstack 
comboboxen 	- combo_
checkboxen 	- check_ 
lengthentry 	- length_ 
radio buttons 	- radio_
line edits	- line_ 
emptytable	- table 
list box	- list_ 
 
Some tips and guidelines for qtarch and the KDE frontend :

o the default button should be the one that causes least harm, unless
  the action can be undone. So Print should default to cancel, whereas
  insert index entry can be undone, so should default to OK

o the dialog should derive from QWidget (set in Properties)

o the dialog should always have the gettext option set

o give every widget a name - useful for the geometry layouts later

o don't bother setting min/max sizes for anything, but do set the size Hint
  stuff appropriately. e.g. QLineEdit's should have a max height specified by
  size Hint, but variable width

o if you map a variable make it the same as the widget name

o radio groups are done automagically based on positioning
 
o grid units are 5 pixels

o set alignment before placing a widget inside a layout, it doesn't seem to
  update properly. Alternatively you can just edit the .dlg file directly

o push buttons are arranged symmetrically across the dialog e.g.  
  <1 stretch> <button> <2 stretch> <button> <2 stretch> <button> <1 stretch>

o for GroupBox and similar, you set the children in the layout manager
 
o do the geometry layouts last. you cannot alter the geometry of widgets
  whilst they're being managed which makes any settings a pain, which
  are useful mainly while editing the dialog in qtarch
  
o remember tab order, and keyboard access in general. Tab order is decided by
  instantation order of each widget, NOT the heirarchical layout. This translates
  to ordering the widget descriptions in the qtarch .dlg file correctly.
 
o when doing layout, add all the layouts before any of the widgets otherwise
  qtarch has a tendency to get confused

o qtarch can produce code that initialises stuff in the wrong order. 
  This is nasty, but usually dumps core so is noticable. Either way, the 
  cheesy perl script checkinitorder.pl will verify the produced files for 
  you - if it complains you need to hack the .dlg file to re-arrange the order.

	- jbl