From kde-devel Thu Feb 12 15:53:55 2004 From: Ravikiran Rajagopal Date: Thu, 12 Feb 2004 15:53:55 +0000 To: kde-devel Subject: Re: Idea: KAction based dialogs Message-Id: <200402121053.57268.ravi () ee ! eng ! ohio-state ! edu> X-MARC-Message: https://marc.info/?l=kde-devel&m=107660125522443 > So I would like to propose another way to implement dialogs classes. > Implement your GUI as a set of actions, which interact with each other, > like in the recommended implementation for forms (main windows). Define > the actual GUI layout in an external resource file, which is load and > evaluated at runtime. If you use the XMLGUI framework for it, you can get > the other features of this framework, too, like multiple versions of the > dialog, possible merging of sub documents, etc. Like KConfigXT and friends, this is yet another push towards autogenerated code. However, I do not see why runtime parsing of the widget configuration is necessary, unless you wish the layout to be modifiable. > > This is mixing up the visual representation with contents. I would rather see this split up into two files: 1. The visual representation 2. The content The visual representation would be a simple Qt designer file. Since we wish to have autogenerated code, the handler of any kind of visual representation must be aware of the allowable classes/widgets. Note that this is exactly the capability of Qt designer with KDE widgets. The issue of run-time vs compile-time parsing is also handled by designer (via libqui). The content, which is typically a list of actions and action groups, would be represented as an XMLGUI rc file. We would simply connect the actions with the appropriate widgets at run-time via the XMLGUI framework as we do now. The missing glue functionality is what needs to be provided. I would follow the design of KAutoConfigDialog/KConfigXT and friends and simply map between the widget name and the action it represents. With the addition of one class to kdelibs, we would then have this available to all applications. Note that much of the design work for a glue class can be copied from the configuration classes mentioned above. Automating general dialog creation is a logical successor to automating configuration dialog creation, and I would be surprised if you were the only one considering this idea. Regards, Ravi >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<