Kconfig (qt) -> Gconfig (gtk)
Hi,
I noticed there is a new configuration tool (Kconfig) written in qt for replacing the current one written in tcl/tk (Xconfig).
Is there any plan to develop a similar configuration tool in GTK+ (Gconfig) ? I will be interested in writing a such one...
roms
Signature · 3 lines
Romain Lievin, aka 'roms' <[email protected]> Web site <http://lpg.ticalc.org/prj_tilp> "Linux, y'a moins bien mais c'est plus cher !"
Quoted 8 lines · Romain Lievin
Hi,
I noticed there is a new configuration tool (
Kconfig) written in qt for replacing the current one written in tcl/tk (Xconfig).Is there any plan to develop a similar configuration tool in GTK+ (Gconfig) ? I will be interested in writing a such one...
roms
Yes please :)
GTK+ is probably the most common (decent) toolkit out there - nearly any system with X has it installed, from what I've seen.
Quoted 11 lines · * Nero ([email protected]) wrote:
Quoted 9 lines · Romain Lievin
Hi,
I noticed there is a new configuration tool (
Kconfig) written in qt for replacing the current one written in tcl/tk (Xconfig).Is there any plan to develop a similar configuration tool in GTK+ (Gconfig) ?
I will be interested in writing a such one...
Quoted 5 lines
Quoted 1 line
roms
Yes please :)
GTK+ is probably the most common (decent) toolkit out there - nearly any system with X has it installed, from what I've seen.
Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM, SPARC and HP-PA | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
Quoted 8 lines · Dr. David Alan Gilbert
Quoted 2 lines · * Nero ([email protected]) wrote:
GTK+ is probably the most common (decent) toolkit out there - nearly any system with X has it installed, from what I've seen.
Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?
Uhoh .. my flamewar detector is glowing ...
Xavier Bestel intoned:
Quoted 6 lines · Dr. David Alan Gilbert
Quoted 5 lines · * Nero ([email protected]) wrote:
Quoted 2 lines
GTK+ is probably the most common (decent) toolkit out there - nearly any system with X has it installed, from what I've seen.
Quoted 7 lines
Quoted 4 lines
Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?Uhoh .. my flamewar detector is glowing ...
Glowing is it? I await the 1130 sense switch implimentation or how about an 1800 version in Nutran.
Cheers,
Dave
Quoted 17 lines · Dr. David Alan Gilbert
Quoted 10 lines · * Nero ([email protected]) wrote:
Quoted 9 lines · Romain Lievin
Hi,
I noticed there is a new configuration tool (
Kconfig) written in qt for replacing the current one written in tcl/tk (Xconfig).Is there any plan to develop a similar configuration tool in GTK+ (Gconfig) ?
I will be interested in writing a such one...Quoted 5 lines
Quoted 1 line
roms
Yes please :)
GTK+ is probably the most common (decent) toolkit out there - nearly any system with X has it installed, from what I've seen.
Quoted 6 lines
Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?Dave
I didn't mention a preference, just that GTK+ is more common. Besides, The original poster didn't say he wanted to *replace* the existing qconfig.
Quoted 3 lines · Dr. David Alan Gilbert
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?
Maybe, maybe not. Most, if not all of my boxes here don't have qt, and they're not going to get qt any time soon. qt has a long list of dependencies which gtk doesn't have, which, imho is an overriding factor for why we should have a gtk implementation.
Not that I used the old xconfig often anyway. 8)
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
On Sat, Nov 02, 2002 at 09:07:24PM +0000, Russell King scribbled:
Quoted 9 lines · Dr. David Alan Gilbert
Quoted 3 lines
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?
Maybe, maybe not. Most, if not all of my boxes here don't have qt, and they're not going to get qt any time soon. qt has a long list of dependencies which gtk doesn't have, which, imho is an overriding factor for why we should have a gtk implementation.
Exactly. On Debian the qt2 devel stuff is 17MB (!). Yesterday I was trying to compile 2.5.45 just to see that even doing make menuconfig (which I always use) breaks because of missing qt. It turned out that the problem is in the scripts/kconfig/Makefile which executes the $(obj)/.tmp_qtcheck no matter which configuration interface is used [1]. Adding '-' in front of the rule served as a temporary work-around, but I got a bit shocked on finding out that I'd have to dload 17MB of the Qt devel packages.
Quoted 1 line
Not that I used the old xconfig often anyway. 8)
Neither, but since it's here, it better work on any box :)
marek
[1] That's why I'm CCing this message to Roman Zippel, forgot to send a but report yesterday :>
Quoted 3 lines · Marek Habersack
Exactly. On Debian the qt2 devel stuff is 17MB (!). Yesterday I was trying to compile 2.5.45 just to see that even doing make menuconfig (which I always use) breaks because of missing qt.
This is properly fixed in Linus's tree.
Sam
Quoted 7 lines · Dr. David Alan Gilbert
Quoted 3 lines
Yes please :)
GTK+ is probably the most common (decent) toolkit out there - nearly any system with X has it installed, from what I've seen.Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?
Linus mentioned this a while ago. This kind of holy war is going to happen regardless of the library used. There's no reason that a GTK config tool would have to be merged anyway, it could live as a seperate project (as could the qt one really imo), outside the kernel sources.
Dave
Signature · 1 line
| Dave Jones. http://www.codemonkey.org.uk
Quoted 4 lines · Dr. David Alan Gilbert
Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?
Lota of installations have gtk but don't have qt.
Quoted 7 lines · Alan Cox
Quoted 4 lines · Dr. David Alan Gilbert
Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?Lota of installations have gtk but don't have qt.
And a lot of installations have QT but not GTK... This feels like a vi vs emacs discussion.
Personally, it makes no difference to me which library is used. I'm doubtful I'll use anything other than menuconfig unless it makes my life a *whole* lot easier. I'd say 'choose one and get on with it.'
Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu
http://dilbert.com/comics/dilbert/archive/images/dilbert2040637020924.gif
Quoted 3 lines · Patrick Finnegan
Personally, it makes no difference to me which library is used. I'm doubtful I'll use anything other than menuconfig unless it makes my life a *whole* lot easier. I'd say 'choose one and get on with it.'
Looking at my menuconfig patch (that's been mailed to lkml numerious times), the old Menuconfig script and checking mconf.c, it looks like mconf.c isn't checking for half the errors that the old Menuconfig script used to / would've been checking with my patch.
Oh, and another thing I've noticed is that mconf does nothing if it fails to execute lxdialog - it doesn't tell you _why_ it's doing nothing. It just says something like "Not saving configuration."
The last mailing of my patch was a while ago, so I'll reproduce it here:
| This patch fixes a failure case in menuconfig which can occur if a kernel | tree is configured on one architecture with menuconfig, and then attempted | to be reconfigured on another architecture. | | The kernel detects that the binary can't be run on the second architecture | and correctly returns the appropriate error code. However, the Menuconfig | script ignores this error and retries endlessly, appearing to hang. | | This patch makes menuconfig display a message and exit rather than | endlessly looping. | | scripts/Menuconfig | 20 ++++++++++++++++++++ | 1 files changed, 20 insertions | | diff -ur orig/scripts/Menuconfig linux/scripts/Menuconfig | --- orig/scripts/Menuconfig Sat Oct 12 10:02:17 2002 | +++ linux/scripts/Menuconfig Sat Oct 12 10:45:13 2002 | @@ -909,6 +909,26 @@ | cleanup | exit 139 | ;; | + 126|127) | + stty sane | + clear | + cat << EOM | + | +There seems to be a problem with the lxdialog companion utility which is | +built prior to running Menuconfig. lxdialog could not be found, or could | +not be executed. This can be caused when lxdialog has been built for a | +different architecture. | + | +You should rebuild lxdialog. This can be done by moving to the | +/usr/src/linux/scripts/lxdialog directory and issuing the "make clean all" | +command. | + | +If the problem persists, you may email the maintainer <[email protected]> or | +post a message to <[email protected]> for additional assistance. | + | +EOM | + cleanup | + exit 1 | esac | done | } |
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Hi,
Quoted 3 lines · Russell King
Oh, and another thing I've noticed is that mconf does nothing if it fails to execute lxdialog - it doesn't tell you _why_ it's doing nothing. It just says something like "Not saving configuration."
I know and I will extend the error handling there.
Quoted 3 lines
| +You should rebuild lxdialog. This can be done by moving to the | +/usr/src/linux/scripts/lxdialog directory and issuing the "make clean all" | +command.
$ cd /usr/src/linux/scripts/lxdialog -bash: cd: /usr/src/linux/scripts/lxdialog: No such file or directory $ cd scripts/lxdialog $ make clean Makefile:27: /Rules.make: No such file or directory make: *** No rule to make target `/Rules.make'. Stop.
bye, Roman
Quoted 12 lines · Roman Zippel
Quoted 3 lines · Russell King
Oh, and another thing I've noticed is that mconf does nothing if it fails to execute lxdialog - it doesn't tell you _why_ it's doing nothing. It just says something like "Not saving configuration."
I know and I will extend the error handling there.
Quoted 3 lines
| +You should rebuild lxdialog. This can be done by moving to the | +/usr/src/linux/scripts/lxdialog directory and issuing the "make clean all" | +command.
Quoted 6 lines
$ cd /usr/src/linux/scripts/lxdialog -bash: cd: /usr/src/linux/scripts/lxdialog: No such file or directory $ cd scripts/lxdialog $ make clean Makefile:27: /Rules.make: No such file or directory make: *** No rule to make target `/Rules.make'. Stop.
Well obviously it doesn't work now that kconfig removed Menuconfig!
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 2 lines · Russell King
Well obviously it doesn't work now that kconfig removed Menuconfig!
That's bad news for those of us who maintain kernels on remote machines.
Gerhard
--
Gerhard Mack
<>< As a computer I find your faith in technology amusing.
Quoted 10 lines · Roman Zippel
Quoted 3 lines
| +You should rebuild lxdialog. This can be done by moving to the | +/usr/src/linux/scripts/lxdialog directory and issuing the "make clean all" | +command.$ cd /usr/src/linux/scripts/lxdialog -bash: cd: /usr/src/linux/scripts/lxdialog: No such file or directory $ cd scripts/lxdialog $ make clean Makefile:27: /Rules.make: No such file or directory make: *** No rule to make target `/Rules.make'. Stop.
The proper way is to do the following:
$(Q)$(MAKE) -f scripts/Makefile.clean obj=scripts/lxdialog
But thats only OK within a kbuild makefile.
Is there any real need for an external make clean for lxdialog?
Sam
Hi,
Quoted 2 lines · Sam Ravnborg
But thats only OK within a kbuild makefile.
Is there any real need for an external make clean for lxdialog?
Not really (anymore), if one tries to configure a kernel tree under a different architecture, make will already fail to execute scripts/kconfig/mconf.
bye, Roman
Quoted 8 lines · Patrick Finnegan
Quoted 6 lines · Alan Cox
Quoted 4 lines · Dr. David Alan Gilbert
Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?
Quoted 4 lines
Quoted 1 line
Lota of installations have gtk but don't have qt.
And a lot of installations have QT but not GTK... This feels like a vi vs emacs discussion.
It sort of is. The difference being its "do I send you a vi macro or an emacs macro", and the obvious answer in this case being that if someone wants go write both then we all win.
Quoted 9 lines · Alan Cox
Quoted 8 lines · Patrick Finnegan
Quoted 6 lines · Alan Cox
Quoted 4 lines · Dr. David Alan Gilbert
Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Lota of installations have gtk but don't have qt.
And a lot of installations have QT but not GTK... This feels like a vi vs emacs discussion.
It sort of is. The difference being its "do I send you a vi macro or an emacs macro", and the obvious answer in this case being that if someone wants go write both then we all win.
I'll go ahead and agree with you there. I just don't want to see one being scrapped in favor of the other.
Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu
http://dilbert.com/comics/dilbert/archive/images/dilbert2040637020924.gif
Quoted 7 lines · Patrick Finnegan
Quoted 5 lines · Alan Cox
Quoted 4 lines · Dr. David Alan Gilbert
Quoted 2 lines
Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of
the
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
qt based one than write a new one just because you don't happen to
like
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
the library?
Lota of installations have gtk but don't have qt.
And a lot of installations have QT but not GTK... This feels like a vi
vs
Quoted 5 lines
Quoted 1 line
emacs discussion.
It sort of is. The difference being its "do I send you a vi macro or an emacs macro", and the obvious answer in this case being that if someone wants go write both then we all win.
I agree, Alan. And I would like to ask that someone improve the library search logic...
Matthew D. Pitts
Quoted 9 lines · Alan Cox
Quoted 8 lines · Patrick Finnegan
Quoted 6 lines · Alan Cox
Quoted 4 lines · Dr. David Alan Gilbert
Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Lota of installations have gtk but don't have qt.
And a lot of installations have QT but not GTK... This feels like a vi vs emacs discussion.
It sort of is. The difference being its "do I send you a vi macro or an emacs macro", and the obvious answer in this case being that if someone wants go write both then we all win.
It's definitely not. The current solution is simply a denial of service attack, at moment Qt is _required_ for a build, not an optional frontend:
[0]--(16:26:00)-(root@stefan)-(/.localvol000/src/kernel/x/linux-2.5.45)-> make oldconfig *
* Unable to find the QT installation. Please make sure that the
* QT development package is correctly installed and the QTDIR
* environment variable is set to the correct location.
*
make[1]: *** [scripts/kconfig/.tmp_qtcheck] Fehler 1
make: *** [scripts/kconfig/conf] Fehler 2 [2]--(16:26:05)-(root@stefan)-(/.localvol000/src/kernel/x/linux-2.5.45)->
This should not happen. Anyway, Roman did a good job.
Signature · 2 lines
ciao -
StefanQuoted 2 lines · Stefan Traby
It's definitely not. The current solution is simply a denial of service attack, at moment Qt is _required_ for a build, not an optional frontend:
That error is fixed in Linus's tree already.
Sam
Quoted 8 lines · * Patrick Finnegan ([email protected]) wrote:
Quoted 6 lines · Alan Cox
Quoted 4 lines · Dr. David Alan Gilbert
Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?
Quoted 8 lines
Quoted 1 line
Lota of installations have gtk but don't have qt.
And a lot of installations have QT but not GTK... This feels like a vi vs emacs discussion.
Personally, it makes no difference to me which library is used. I'm doubtful I'll use anything other than menuconfig unless it makes my life a *whole* lot easier. I'd say 'choose one and get on with it.'
Exactly my point. I just don't see the point in spending the neuron hours on both.
But you guys who are worried about space and dependencies always can:
1) use menuconfig
2) Write one in Tcl/Tk which is nice and small and portable and has few dependencies......oh we've been there.
Dave
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM, SPARC and HP-PA | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
Quoted 17 lines · Dr. David Alan Gilbert
Quoted 7 lines · * Patrick Finnegan ([email protected]) wrote:
Quoted 6 lines · Alan Cox
Quoted 4 lines · Dr. David Alan Gilbert
Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?Quoted 8 lines
Quoted 1 line
Lota of installations have gtk but don't have qt.
And a lot of installations have QT but not GTK... This feels like a vi vs emacs discussion.
Personally, it makes no difference to me which library is used. I'm doubtful I'll use anything other than menuconfig unless it makes my life a *whole* lot easier. I'd say 'choose one and get on with it.'
Quoted 5 lines
Exactly my point. I just don't see the point in spending the neuron hours on both.
But you guys who are worried about space and dependencies always can:
1) use menuconfig
OR, we could use the logical choice. GTK+ is on most systems, has hardly any dependancies, is relatively small (compared to Qt) and doesn't require a C++ compiler. Really, I think the only people being religious here are the ones voting for Qt, as it just doesn't make sense to use it for such a thing. If you absolutely hate GTK+, there is menuconfig, and IIRC KDE have their own [external] kernel configurator utility.
(and before anyone tries to jump on me for being a gtk zealot - I'm not. I run KDE as my primary desktop, so I'm quite fond of Qt. That doesn't mean it makes any more sense in a kernel however ;))
Hi,
Quoted 4 lines · Nero
OR, we could use the logical choice. GTK+ is on most systems, has hardly any dependancies, is relatively small (compared to Qt) and doesn't require a C++ compiler. Really, I think the only people being religious here are the ones voting for Qt, as it just doesn't make sense to use it for such a thing.
Show me the source and we can continue this discussion. Right now qconf is included as replacement for the old xconfig. It shouldn't take to much effort to package it seperately. As soon as someone is interested in doing this for a distribtion I'll add the few missing bits.
bye, Roman
Quoted 9 lines · On 2002.11.03 Roman Zippel wrote:
Hi,
Quoted 4 lines · Nero
OR, we could use the logical choice. GTK+ is on most systems, has hardly any dependancies, is relatively small (compared to Qt) and doesn't require a C++ compiler. Really, I think the only people being religious here are the ones voting for Qt, as it just doesn't make sense to use it for such a thing.
Quoted 5 lines
Show me the source and we can continue this discussion. Right now qconf is included as replacement for the old xconfig. It shouldn't take to much effort to package it seperately. As soon as someone is interested in doing this for a distribtion I'll add the few missing bits.
As I see it, the onle thing that should be included in a standard kernel would be something like a kconfig-xaw, that is sure to be on every box that has X, and could be a reference implementation.
And you could face one other religious war: qt2 or qt3 ? So as gtk1 or gtk2...
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 15 lines · J.A. Magallón
Quoted 9 lines · On 2002.11.03 Roman Zippel wrote:
Hi,
Quoted 5 lines · Nero
OR, we could use the logical choice. GTK+ is on most systems, has hardly any dependancies, is relatively small (compared to Qt) and doesn't require a C++ compiler. Really, I think the only people being religious here are the ones voting for Qt, as it just doesn't make sense to use it for such a thing.
Quoted 4 lines
Show me the source and we can continue this discussion. Right now qconf is included as replacement for the old xconfig. It shouldn't take to much effort to package it seperately. As soon as someone is interested in doing this for a distribtion I'll add the few missing bits.
Quoted 6 lines
As I see it, the onle thing that should be included in a standard kernel would be something like a kconfig-xaw, that is sure to be on every box that has X, and could be a reference implementation.
And you could face one other religious war: qt2 or qt3 ? So as gtk1 or gtk2...
Gtk1 is going to be around for quite a while because so many apps wont be ported over to Gtk2 at all [dropped projects], and Gtk2 is not yet as widespread as 1.x either, so using Gtk1 is obvious. Qt2 vs. Qt3 - people tend to have the latest KDE if they run it, which means the latest Qt. Nearly all of the major distros ship with KDE3 now too (debian is still on KDE2 for some annoying reason, and Xandros (major?) have a hacked-to-bits KDE2).
Quoted 3 lines · J.A. Magallón
As I see it, the onle thing that should be included in a standard kernel would be something like a kconfig-xaw, that is sure to be on every box that has X, and could be a reference implementation.
Lots of people no longer include Xaw either nowdays 8)
Probably the easiest way to do this would be to move the GUI tools out of the kernel (or maybe leave the common useful ones) and have make guiconfig do
if [ -f /usr/sbin/kernel-gui-config ] ; then
/usr/sbin/kernel-gui-config
elif got_qt() ; then
qt config
elif got_gtk() ; then
gtk_config
else
warnign message
make config
fi
Quoted 11 lines · Alan Cox
Quoted 3 lines · J.A. Magallón
As I see it, the onle thing that should be included in a standard kernel would be something like a kconfig-xaw, that is sure to be on every box that has X, and could be a reference implementation.
Lots of people no longer include Xaw either nowdays 8)
Probably the easiest way to do this would be to move the GUI tools out of the kernel (or maybe leave the common useful ones) and have make guiconfig do
Quoted 10 lines
if [ -f
/usr/sbin/kernel-gui-config] ; then
/usr/sbin/kernel-gui-config
elifgot_qt(); then
qt config
elifgot_gtk(); then
gtk_config
else
warnign message
make config
fi
Why does the kernel have to know about that tools at all? Just put them into $PATH and let people just call $FOOCONFIG. This works pretty well with mconfig on 2.2/2.4..
Quoted 23 lines · Christoph Hellwig
Quoted 11 lines · Alan Cox
Quoted 3 lines · J.A. Magallón
As I see it, the onle thing that should be included in a standard kernel would be something like a kconfig-xaw, that is sure to be on every box that has X, and could be a reference implementation.
Lots of people no longer include Xaw either nowdays 8)
Probably the easiest way to do this would be to move the GUI tools out of the kernel (or maybe leave the common useful ones) and have make guiconfig do
Quoted 10 lines
if [ -f
/usr/sbin/kernel-gui-config] ; then
/usr/sbin/kernel-gui-config
elifgot_qt(); then
qt config
elifgot_gtk(); then
gtk_config
else
warnign message
make config
fi
Quoted 3 lines
Why does the kernel have to know about that tools at all? Just put them into $PATH and let people just call $FOOCONFIG. This works pretty well with mconfig on 2.2/2.4..
Just call it kguiconfig. Since /usr/bin/kguiconfig would be a symbolic link to /etc/alternatives/kguiconfig on a Debian system, the sysadmin can choose which of the zillion different available GUI kernel config programs you'll actually run.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Quoted 4 lines · Geert Uytterhoeven
Just call it kguiconfig. Since
/usr/bin/kguiconfigwould be a symbolic link to/etc/alternatives/kguiconfigon a Debian system, the sysadmin can choose which of the zillion different available GUI kernel config programs you'll actually run.
Yeah, use kguiconfig for alternatives on debian and let everyone just directly call $RANDOMONFIGPROGGI :)
On 3 Nov 2002, Alan Cox wrote:
| On Sun, 2002-11-03 at 00:06, J.A. Magallón wrote: | > As I see it, the onle thing that should be included in a standard kernel | > would be something like a kconfig-xaw, that is sure to be on every box that | > has X, and could be a reference implementation. | | Lots of people no longer include Xaw either nowdays 8) | | Probably the easiest way to do this would be to move the GUI tools out | of the kernel (or maybe leave the common useful ones) and have make | guiconfig do | | if [ -f /usr/sbin/kernel-gui-config ] ; then | /usr/sbin/kernel-gui-config | elif got_qt() ; then | qt config | elif got_gtk() ; then | gtk_config | else | warnign message | make config make menuconfig || make oldconfig || make config
| fi
| -
Please don't stick us with 'make config'. :)
Signature · 1 line
~Randy
Quoted 31 lines · Nero
Quoted 17 lines · Dr. David Alan Gilbert
Quoted 7 lines · * Patrick Finnegan ([email protected]) wrote:
Quoted 6 lines · Alan Cox
Quoted 4 lines · Dr. David Alan Gilbert
Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?Quoted 8 lines
Quoted 1 line
Lota of installations have gtk but don't have qt.
And a lot of installations have QT but not GTK... This feels like a vi vs emacs discussion.
Personally, it makes no difference to me which library is used. I'm doubtful I'll use anything other than menuconfig unless it makes my life a *whole* lot easier. I'd say 'choose one and get on with it.'
Quoted 5 lines
Exactly my point. I just don't see the point in spending the neuron hours on both.
But you guys who are worried about space and dependencies always can:
1) use menuconfigOR, we could use the logical choice. GTK+ is on most systems, has hardly any dependancies, is relatively small (compared to Qt) and doesn't require a C++ compiler. Really, I think the only people being religious here are the ones voting for Qt, as it just doesn't make sense to use it for such a thing. If you absolutely hate GTK+, there is menuconfig, and IIRC KDE have their own [external] kernel configurator utility.
Quoted 3 lines
(and before anyone tries to jump on me for being a gtk zealot - I'm not. I run KDE as my primary desktop, so I'm quite fond of Qt. That doesn't mean it makes any more sense in a kernel however ;))
I would agree with that if no code was written for Qt. However, (as I understand it) there's a basically functional version for Qt. Keep what's there and works, and encourage one to be written for GTK by those who have the spare time, but don't scrap the Qt one just because some people don't like Qt.
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu
http://dilbert.com/comics/dilbert/archive/images/dilbert2040637020924.gif
Quoted 2 lines · Nero
thing. If you absolutely hate GTK+, there is menuconfig, and IIRC KDE have their own [external] kernel configurator utility.
Please contact myself and/or Malte Starostik (kcmlinuz author) regarding
the KDE kernel configurator. We have full intentions to support the new system once it is in widespread use. Support for the new system will not be in KDE 3.1 but it should be in KDE 3.2 if all goes as planned.
If anyone has some feedback regarding the design we would also be
interested in that.
Additionally, to those who complain about Qt's size and dependencies:
1) The 16MB Qt .gz (13MB .bz2) contains much more than just the library.
it contains Qt Designer, example code, full and complete documentation for the entire library, etc. That's not obscene in comparison with gtk+ and all accompanying RAD tools etc. If for some reason 16MB vs 8.5MB really hurts, contact Trolltech and ask them if they will split the package up for you.
2) Exactly what dependencies other than g++, yacc, and X11 devel libraries
are you concerned about? I'm not sure there are any others. If you're really afraid of C++, I can assure you that it's not so scary, and you don't even have to look at the C++ code. However if you must, there are tutorials available online.
Anyhow, I think it's great to see a kernel config system that can have a
GUI implemented with stdio, curses, Xlib, GTK and Qt. That's clearly the best plan and they should all be available to choose from.
Thanks
Signature · 1 line
George Staikos
Quoted 27 lines · George Staikos
Quoted 2 lines · Nero
thing. If you absolutely hate GTK+, there is menuconfig, and IIRC KDE have their own [external] kernel configurator utility.
Please contact myself and/or Malte Starostik (kcmlinuz author) regarding
the KDE kernel configurator. We have full intentions to support the new system once it is in widespread use. Support for the new system will not be in KDE 3.1 but it should be in KDE 3.2 if all goes as planned.If anyone has some feedback regarding the design we would also be
interested in that.Additionally, to those who complain about Qt's size and dependencies:
1) The 16MB Qt .gz (13MB .bz2) contains much more than just the library.
it contains Qt Designer, example code, full and complete documentation for the entire library, etc. That's not obscene in comparison with gtk+ and all accompanying RAD tools etc. If for some reason 16MB vs 8.5MB really hurts, contact Trolltech and ask them if they will split the package up for you.2) Exactly what dependencies other than g++, yacc, and X11 devel
libraries are you concerned about? I'm not sure there are any others. If you're really afraid of C++, I can assure you that it's not so scary, and you don't even have to look at the C++ code. However if you must, there are tutorials available online.
Quoted 5 lines
Anyhow, I think it's great to see a kernel config system that can have a
GUI implemented with stdio, curses, Xlib, GTK and Qt. That's clearly the best plan and they should all be available to choose from.Thanks
I'm not scared of C++. Reducing dependancies on the kernel is important though. If you're configuring a kernel, you already have a C compiler installed, but perhaps not a C++ compiler. This was the issue with CML2 as I understand it, depending on Python. Not exactly the same issue, but it is the same idea. Many people often ask me why make menuconfig doesn't work - it's always because they didn't know they needed the ncurses library for it to work (it's a common question on IRC). More dependancies != Good. Once again, the only reason I think Qt is not a good choice is because it (for the moment) is a large download, takes a long time to compile, requires C++, and is not as common as Gtk 1.x yet. (I also don't see a problem with shipping both, but I'd say Linus wont like that idea).
Quoted 4 lines · Patrick Finnegan
Quoted 1 line
Lota of installations have gtk but don't have qt.
And a lot of installations have QT but not GTK... This feels like a vi vs emacs discussion.
Was this just to cover the possibilities or do you know of such? I guess all system which build kernels have QT, it won't build without it :-( I know that's going to be fixed RSN.
Quoted 3 lines
Personally, it makes no difference to me which library is used. I'm doubtful I'll use anything other than menuconfig unless it makes my life a *whole* lot easier. I'd say 'choose one and get on with it.'
That's not likely, but perhaps all the groups which have or want a GUI could define a standard interface which could go in the kernel, and then any GIU could interpret the metadata from that and display it any way they want.
Just a thought, I have no axe to grind, menuconfig is the only thing reasonable to config remote machines. Any GUI over ssh over somewhat slow open net connections is vastly unproductive.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 14 lines · Bill Davidsen
Quoted 4 lines · Patrick Finnegan
Quoted 1 line
Lota of installations have gtk but don't have qt.
And a lot of installations have QT but not GTK... This feels like a vi vs emacs discussion.
Was this just to cover the possibilities or do you know of such? I guess all system which build kernels have QT, it won't build without it :-( I know that's going to be fixed RSN.
Quoted 3 lines
Personally, it makes no difference to me which library is used. I'm doubtful I'll use anything other than menuconfig unless it makes my life a *whole* lot easier. I'd say 'choose one and get on with it.'
Quoted 8 lines
That's not likely, but perhaps all the groups which have or want a GUI could define a standard interface which could go in the kernel, and then any GIU could interpret the metadata from that and display it any way they want.
Just a thought, I have no axe to grind, menuconfig is the only thing reasonable to config remote machines. Any GUI over ssh over somewhat slow open net connections is vastly unproductive.
You have to forgive me this joke. - Let's hang the guy who introduced QT into kernel and be friends again.
Signature · 1 line
Mariusz Zielinski
Quoted 3 lines · Dr. David Alan Gilbert
Quoted 2 lines · * Nero ([email protected]) wrote:
Romain Lievin wrote:
[snip]
Quoted 11 lines
Quoted 4 lines
Yes please :)
GTK+ is probably the most common (decent) toolkit out there - nearly any system with X has it installed, from what I've seen.Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?Dave
Why? I have a couple boxes that have GTK and don't have QT. A GTK-based configuration system would be most useful.
Diversity and choice are good things.
Quoted 4 lines · Jon Portnoy
Why? I have a couple boxes that have GTK and don't have QT. A GTK-based configuration system would be most useful.
Diversity and choice are good things.
Which is why we should strive to abstract xconfig from the kernel.
Signature · 2 lines
http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
Sat, 2 Nov 2002 20:36:08 +0000: Dr. David Alan Gilbert ("Dr. David Alan Gilbert" <[email protected]>):
Quoted 4 lines
Oh please....
Wouldn't it be more helpful to iron the (few) small glitches out of the qt based one than write a new one just because you don't happen to like the library?
Maybe; however, there's a big difference between gtk+ and qt- gtk 1.2 take about 5 minutes to compile. The last time I compiled qt, it took about 3 hours on my duron 800.
GTK is a lot smaller of a platform, and a lot of users prefer to use it instead. If someone is willing to write (and maintain) a GTK+ (especially if it's ait gtk+-1.2.x. gtk-2.0 is getting a bit more bloaty) version of it, I know quite a few people who would gladly use it instead of the QT.
If people are willing to support both a QT and a GTK version, then there should be no real problems.
Signature · 3 lines
< There is a light that shines on the frontier > < And maybe someday, We're gonna be there. > < Rando Christensen / [email protected] >