src/frontends/kde/dlg/README

   1 These files are generated with qtarch-1.4-5 which can be downloaded
   2 from
   3
   4 http://qtarch.sourceforge.net/
   5
   6 Currently you also need this patch :
   7 http://www.movement.uklinux.net/patches/lyx/qtarch-1.4.6.diff
   8
   9 Eventually the intent is to fold this patch into the official qtarch and
  10 release a qtarch-1.4-6 tarball.
  11
  12 Note this is *not* the latest version, as they only support Qt 2.
  13
  14 You should compile in the KDE module when you compile qtarch-1.4.
  15 For me this was just a case of a make in the module/kde/ directory,
  16 and then you can add the .so library file in the qtarch GUI.
  17
  18 The files in this and the kde/ directory have the following naming
  19 scheme :
  20
  21 random.dlg         - the dlg file for qtarch
  22 FormRandom.[Ch]    - LyX's notion of the dialog, real implementation modified
  23                      via functions only
  24 randomdlg.[Ch]     - Derived Qt class, edited by hand. The interface between widgets
  25                      and LyX FormRandom file
  26 randomdlgdata.[Ch] - qtarch-generated files, not to be touched by human hands
  27
  28 The class names are FormRandom, RandomDialog, and RandomDialogData
  29
  30 Note that the .dlg files have no entries for the derived class header and source
  31 filenames. This is because these files have to be edited by hand and should only
  32 be generated once (and they belong in the parent directory, not dlg/). The
  33 className field, though, has a special meaning. If it is blank, then qtarch
  34 will assume there is no derived class defined at all. Currently this has the effect
  35 of making mapped variables public access. If there is a name, then it assumes that
  36 a derived class exists, and leaves mapped variables protected. It's done like
  37 this to avoid the rat's nest of friend declarations and un-necessary derived classes,
  38 and because the new MVC architecture needs direct access to buttons etc.
  39
  40 There is a naming scheme for any variabled widgets, similar to the xforms frontend :
  41
  42 buttons         - button_
  43 spinboxen       - spin_
  44 tabstack        - tabstack
  45 comboboxen      - combo_
  46 checkboxen      - check_
  47 lengthentry     - length_
  48 radio buttons   - radio_
  49 line edits      - line_
  50 emptytable      - table
  51 list box        - list_
  52
  53 Some tips and guidelines for qtarch and the KDE frontend :
  54
  55 o the default button should be the one that causes least harm, unless
  56   the action can be undone. So Print should default to cancel, whereas
  57   insert index entry can be undone, so should default to OK
  58
  59 o the dialog should derive from QWidget (set in Properties)
  60
  61 o the dialog should always have the gettext option set
  62
  63 o give every widget a name - useful for the geometry layouts later
  64
  65 o don't bother setting min/max sizes for anything, but do set the size Hint
  66   stuff appropriately. e.g. QLineEdit's should have a max height specified by
  67   size Hint, but variable width
  68
  69 o if you map a variable make it the same as the widget name
  70
  71 o radio groups are done automagically based on positioning
  72
  73 o grid units are 5 pixels
  74
  75 o set alignment before placing a widget inside a layout, it doesn't seem to
  76   update properly. Alternatively you can just edit the .dlg file directly
  77
  78 o push buttons are arranged symmetrically across the dialog e.g.
  79   <1 stretch> <button> <2 stretch> <button> <2 stretch> <button> <1 stretch>
  80
  81 o for GroupBox and similar, you set the children in the layout manager
  82
  83 o do the geometry layouts last. you cannot alter the geometry of widgets
  84   whilst they're being managed which makes any settings a pain, which
  85   are useful mainly while editing the dialog in qtarch
  86
  87 o remember tab order, and keyboard access in general. Tab order is decided by
  88   instantation order of each widget, NOT the heirarchical layout. This translates
  89   to ordering the widget descriptions in the qtarch .dlg file correctly.
  90
  91 o when doing layout, add all the layouts before any of the widgets otherwise
  92   qtarch has a tendency to get confused
  93
  94 o qtarch can produce code that initialises stuff in the wrong order.
  95   This is nasty, but usually dumps core so is noticable. Either way, the
  96   cheesy perl script checkinitorder.pl will verify the produced files for
  97   you - if it complains you need to hack the .dlg file to re-arrange the order.
  98
  99         - jbl