KDM + Interface Modules

Nicholas Hagen tommy at zidnet.net
Fri Jul 19 22:40:26 BST 2002


Not sure which email list to throw this at, but I have been hacking away at the KDM source in order to make myself a new interface, since I got bored with the older one.  I also noted that according to the KDE 3.1 Feature Plan, Chris Howells was supposedly working on something similar in order to use UI files from QT Designer.  I am not sure what he has implemented, but seemingly nothing has been done in the HEAD of CVS as I have been compiling and building from that.  Nonetheless, if anyone is interested in seeing the code or wants more information, let me know and I can let you know the information you need.  I am also not on the mailing list, so please include me in any replies.

To get to the point, here is so far what I have implemented or plan to implement:

- Made new library libkdm in the kdelibs directory (kdelibs/kdm).
    - This library includes generic classes for the following classes:
        - KDMWindow: The main dialog window to be shown.  KGreeter now inherits this class rather than FDialog.  The class also contains the functionality for loading the KDMWidget modules.
        - KDMWidget: The main widget module that is used within KDMWindow to generate the view.  This is the class that is inherited by each module in order to create a custom KDM module.  KDMWindow basically just has a QHBoxLayout with one widget, that being the KDMWidget or the class inherited from it.
        - KDMConfig: The base class that provides the structure for KDM options.  This class is used by KDMWindow and KDMWidget in order for the user to layout the correct information according to the configuration.  Actual reading/writing the configuration is handled by the actual KDM code within kdebase/kdm

- Changed KDMConfig class in kdebase/kdm/kfrontend/kdm_greet to KDMConfiguration : public KDMConfig.  This class does the same as before, but inherits from KDMConfig so that KDMWidget and KDMWindow correctly use it.

- In process of fully changing KGreeter to use KDMWindow and its functionality.

- In process of fully moving the UI code from KGreeter into KTraditional that inherits from KDMWidget in order to create the traditional look.  KTraditional, however, is compiled into KDM itself, instead of a module, in order that a UI always exists for the user in case no modules exist.  Most of this code has not been ported, but I have a small portion in order to compile and test that KDM correctly loads it

- In process of creating a module library Klassic that inherits from KDMWidget, but is not compiled into KDM.  I think that all these plugins for future modules should eventually go into kdeaddons if anyone thinks this implementation is worth it.  This module is very generic right now, but is able to be installed as a library and then loaded by KGreeter and KDMWindow on the fly.

This isn't the same route that Chris was taking as he was dealing with UI files, although I think it might be easy to add that functionality as well and just create a default module based on the UI that would be loaded by KDM.

Now what has not been done and prolly needs to be done:

- The KDM configuration needs a way to save the module name that should be loaded.  This module will then prolly have a .desktop file associated to it which will contain the library name and create function.  This code would be done similar to how KCModule is handled for KControl modules.  Currently I do not read any .desktop files and I just have a hardcoded library name supplied that gets loaded, and if that load fails, then the default gets loaded.

- Source would need to be added to the KControl KDM module in order for the user to see a list of KDM modules that exist as well as select the module they wish to use.

- The API for the kdelibs/kdm library needs to be finalized in order that it provides all the functions necessary for the main Widget and main Window to correctly work effectively.  Most of the functions in these classes are pure virtual calls so that inherited classes must define them.

Anyways, let me know what anyone thinks.

Thanks,
Nicholas Hagen
tommy at zidnet.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20020719/3b0ba12e/attachment.htm>


More information about the kde-core-devel mailing list