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.
--
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))
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.
--
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,
On Sun, 3 Nov 2002, J.A. Magall?n wrote:
> 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
On Sun, Nov 03, 2002 at 12:14:35AM +0100, J.A. Magall?n wrote:
> 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
On Sun, Nov 03, 2002 at 12:14:35AM +0100, J.A. Magall?n wrote:
> 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.