Kernel GUI config
Hi all...
I have readl all the comments about qconfig, gconfig, etc..., and I wanto to comment about an idea that perhaps can make everybody happy...
I don't like qt. As many others. Others do not like GTK. QT requires a C++ compiler to configure the kernel. Everybody agrees on putting the gui config tool outside the tree. So...
- Make a new target called 'guiconfig'. This is neutral, and just should call an utility called for example kconfig-gui.
- People can implement many different front ends and call them things like kconfig-qt, kconfig-gtk, kconfig-xaw, etc... The user can configure its own prefs with an alias or with 'alternatives' as some distros do. None of this utilities should be included in the tree. Put another dir in ftp.kernel.org.
To reduce implementation efforts (and bug chasing), as someone said, you can take all the current parts toolkit-independent (parsers, etc.) from qconf and split them in a library.
Other possibility is to let parsers in the kernel and generate some kind of XML file the utilities should read (do not know how hard would be to put dependencies on an XML file...).
This way even 'menuconfig' could be split as a separate package.
But please, don't force people to use one toolkit.
Signature · 4 lines
J.A. Magallon <[email protected]> \ Software is like sex: werewolf.able.es \ It's better when it's free Mandrake Linux release 9.1 (Cooker) for i586 Linux 2.4.20-rc1-jam0 (gcc 3.2 (Mandrake Linux 9.0 3.2-2mdk))
Quoted 5 lines · On 2002.11.03 J.A. Magallón wrote:
Other possibility is to let parsers in the kernel and generate some kind of XML file the utilities should read (do not know how hard would be to put dependencies on an XML file...).
Add to this the advantage to write config tools in script languages like perl or python.
Signature · 4 lines
J.A. Magallon <[email protected]> \ Software is like sex: werewolf.able.es \ It's better when it's free Mandrake Linux release 9.1 (Cooker) for i586 Linux 2.4.20-rc1-jam0 (gcc 3.2 (Mandrake Linux 9.0 3.2-2mdk))
Hi,
Quoted 3 lines · J.A. Magallón
To reduce implementation efforts (and bug chasing), as someone said, you can take all the current parts toolkit-independent (parsers, etc.) from qconf and split them in a library.
$ ll scripts/kconfig/libkconfig.so -rwxr-xr-x 1 roman users 76335 Oct 31 22:36 scripts/kconfig/libkconfig.so
It's already done.
bye, Roman
Quoted 3 lines · J.A. Magallón
To reduce implementation efforts (and bug chasing), as someone said, you can take all the current parts toolkit-independent (parsers, etc.) from qconf and split them in a library.
If you look into scripts/kconfig you will find a shared library: libkconfig.so Thats exactly what you ask for. A library containing the back-end. The current frontends: oldconfig, menuconfig and xconfig are based on that.
Before getting into too much discussing about how to integrate a new front-end lets see it.
Sam
Quoted 11 lines · J.A. Magallón
Hi all...
I have readl all the comments about qconfig, gconfig, etc..., and I wanto to comment about an idea that perhaps can make everybody happy...
I don't like qt. As many others. Others do not like GTK. QT requires a C++ compiler to configure the kernel. Everybody agrees on putting the gui config tool outside the tree. So...
- Make a new target called 'guiconfig'. This is neutral, and just should call an utility called for example kconfig-gui.
Why do you need a target? Just install your preferred tool into /usr/bin and invoke it directly from there.