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

List:       kopete-devel
Subject:    [Kopete-devel] kdenonbeta/kopete/plugins/autoreplace
From:       Martijn Klingens <klingens () kde ! org>
Date:       2003-08-28 16:22:08
[Download RAW message or body]

CVS commit by mklingens: 

Port over AutoReplace to KConfigureDialog. Took me a while to figure out
how to do this properly, because the prefs and the plugin are no longer in
the same .so file and the plugin still wants to access prefs somehow.

The approach used is as follows:

- Introduce a small class with accessor methods that holds the actual
  settings and does the reading/writing of KConfig. The class is not even
  a QObject (or at least doesn't need to be), and has no GUI, just data.
- Both the KCM and the plugin instantiate this class. _ONLY_ the prefs
  class is allowed to change the settings though. If you want, you can
  enforce this through a friend declaration and making the setter methods
  private (or remove those altogether), but it's not required if you
  simply use common sense ;)
- Since only the KCM changes the settings the KCM is the only module that
  changes the data we don't have to worry about synchronization. Whenever
  the user changes options we set setChanged( true ) in the KCM. This is
  required because otherwise the Apply button will remain disabled and
  Ok will do nothing.
- Whenever we need to save KConfigureDialog calls KCM::save(), which in
  turn sets all prefs in our settings class and saves to KConfig. Don't
  forget KConfig::sync()!
- The KConfigureDialog framework also emits a signal. libkopete traps it
  in KopetePlugin. Connect to plugin::settingsChanged() and call ::load()
  in the plugin on its instance of the settings class. This keeps both
  instances in sync. See how I'm handling the signal here for an example.

Not all plugins require this, only the plugins where it's not possible or
to slow to fetch from Kconfig directly whenever a setting is needed really
need it. It's a lot of work, although it's also good practice, so ideally
all plugins should indeed move over.

The changes to Makefile.am are fairly large because we're now creating TWO
modules, but it should be quite trivial as well.

For questions, feel free to ask around. Otherwise, whoever wants to port
over plugins (Olivier, do you still volunteer after reading this? ;), go
ahead. Just let me know which plugins are being taken care of.

Please don't apply this to the protocols and move those settings to the
account prefs instead.

CCMAIL: kopete-devel@kde.org


  A            autoreplaceconfig.cpp   1.1 [GPL (v2+)]
  A            autoreplaceconfig.h   1.1 [GPL (v2+)]
  A            kopete_autoreplace_config.desktop   1.1
  M +12 -4     Makefile.am   1.4
  M +26 -22    autoreplaceplugin.cpp   1.14
  M +11 -6     autoreplaceplugin.h   1.3
  M +40 -72    autoreplacepreferences.cpp   1.10
  M +17 -24    autoreplacepreferences.h   1.7



_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]