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
--
Romain Lievin, aka 'roms' <[email protected]>
Web site <http://lpg.ticalc.org/prj_tilp>
"Linux, y'a moins bien mais c'est plus cher !"
Romain Lievin wrote:
> 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.
* Nero ([email protected]) wrote:
> Romain Lievin wrote:
>
> >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.
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 |_______/
Le sam 02/11/2002 ? 21:36, Dr. David Alan Gilbert a ?crit :
> * 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 ...
On Sun, 3 Nov 2002 07:36 am, Dr. David Alan Gilbert wrote:
> * Nero ([email protected]) wrote:
> > Romain Lievin wrote:
> > >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.
>
> 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.
On Sat, Nov 02, 2002 at 08:36:08PM +0000, Dr. David Alan Gilbert wrote:
> 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)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Xavier Bestel intoned:
> Le sam 02/11/2002 ? 21:36, Dr. David Alan Gilbert a ?crit :
>
>>* 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 ...
Glowing is it? I await the 1130 sense switch implimentation or how about an 1800 version in Nutran.
Cheers,
Dave
On Sat, 2002-11-02 at 20:36, Dr. David Alan Gilbert wrote:
> 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.
On Sat, Nov 02, 2002 at 08:36:08PM +0000, Dr. David Alan Gilbert wrote:
> > 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
--
| Dave Jones. http://www.codemonkey.org.uk
On 2 Nov 2002, Alan Cox wrote:
> On Sat, 2002-11-02 at 20:36, Dr. David Alan Gilbert wrote:
> > 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
On Sat, Nov 02, 2002 at 04:57:31PM -0500, Patrick Finnegan wrote:
> 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
| }
|
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Sat, 2 Nov 2002, Dr. David Alan Gilbert wrote:
> * Nero ([email protected]) wrote:
> > Romain Lievin wrote:
> >
[snip]
> >
> > 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.
On Sat, Nov 02, 2002 at 12:00:50PM -0500, Jon Portnoy wrote:
> 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.
--
http://www.PowerDNS.com Versatile DNS Software & Services
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
On Sat, 2002-11-02 at 21:57, Patrick Finnegan wrote:
> On 2 Nov 2002, Alan Cox wrote:
>
> > On Sat, 2002-11-02 at 20:36, Dr. David Alan Gilbert wrote:
> > > 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.
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.
Hi,
On Sat, 2 Nov 2002, Russell King wrote:
> 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.
> | +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
On Sat, Nov 02, 2002 at 11:33:31PM +0100, Roman Zippel wrote:
> On Sat, 2 Nov 2002, Russell King wrote:
>
> > 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.
>
> > | +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.
Well obviously it doesn't work now that kconfig removed Menuconfig!
--
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:
> On Sat, Nov 02, 2002 at 08:36:08PM +0000, Dr. David Alan Gilbert wrote:
> > 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.
> 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 :>
On Sat, Nov 02, 2002 at 11:33:31PM +0100, Roman Zippel wrote:
> > | +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
On Sat, Nov 02, 2002 at 11:43:18PM +0100, Marek Habersack wrote:
> 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
On 2 Nov 2002, Alan Cox wrote:
> On Sat, 2002-11-02 at 21:57, Patrick Finnegan wrote:
> > On 2 Nov 2002, Alan Cox wrote:
> >
> > > On Sat, 2002-11-02 at 20:36, Dr. David Alan Gilbert wrote:
> > > > 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.
>
> 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
Hi,
On Sat, 2 Nov 2002, Sam Ravnborg wrote:
> 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
* Patrick Finnegan ([email protected]) wrote:
> On 2 Nov 2002, Alan Cox wrote:
>
> > On Sat, 2002-11-02 at 20:36, Dr. David Alan Gilbert wrote:
> > > 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.'
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 |_______/
On Sun, 3 Nov 2002 10:28 am, Dr. David Alan Gilbert wrote:
> * Patrick Finnegan ([email protected]) wrote:
> > On 2 Nov 2002, Alan Cox wrote:
> > > On Sat, 2002-11-02 at 20:36, Dr. David Alan Gilbert wrote:
> > > > 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.'
>
> 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,
On Sun, 3 Nov 2002, Nero wrote:
> 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
On Sun, 3 Nov 2002, Nero wrote:
> On Sun, 3 Nov 2002 10:28 am, Dr. David Alan Gilbert wrote:
> > * Patrick Finnegan ([email protected]) wrote:
> > > On 2 Nov 2002, Alan Cox wrote:
> > > > On Sat, 2002-11-02 at 20:36, Dr. David Alan Gilbert wrote:
> > > > > 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.'
> >
> > 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 ;))
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
On 2002.11.03 Roman Zippel wrote:
> Hi,
>
> On Sun, 3 Nov 2002, Nero wrote:
>
> > 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.
>
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...
--
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 Sun, 3 Nov 2002 11:06 am, J.A. Magall?n wrote:
> On 2002.11.03 Roman Zippel wrote:
> > Hi,
> >
> > On Sun, 3 Nov 2002, Nero wrote:
> > > 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.
>
> 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).
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
fi
Sat, 2 Nov 2002 20:36:08 +0000: Dr. David Alan Gilbert ("Dr. David Alan
Gilbert" <[email protected]>):
> 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.
--
< There is a light that shines on the frontier >
< And maybe someday, We're gonna be there. >
< Rando Christensen / [email protected] >
On Sun, Nov 03, 2002 at 01:30:09AM +0000, 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
> 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..
On Sat, 2 Nov 2002, Russell King wrote:
>
> 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
[email protected]
<>< As a computer I find your faith in technology amusing.
On November 2, 2002 17:43, Nero wrote:
> 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
--
George Staikos
> On Sat, 2002-11-02 at 21:57, Patrick Finnegan wrote:
> > On 2 Nov 2002, Alan Cox wrote:
> >
> > > On Sat, 2002-11-02 at 20:36, Dr. David Alan Gilbert wrote:
> > > > 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.
>
> 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
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'. :)
--
~Randy
On Sun, 3 Nov 2002, Christoph Hellwig wrote:
> On Sun, Nov 03, 2002 at 01:30:09AM +0000, 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
> > 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..
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
On Sun, 3 Nov 2002 02:53 pm, George Staikos wrote:
> On November 2, 2002 17:43, Nero wrote:
> > 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
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).
On Sun, Nov 03, 2002 at 10:47:05AM +0100, Geert Uytterhoeven wrote:
> 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.
Yeah, use kguiconfig for alternatives on debian and let everyone just
directly call $RANDOMONFIGPROGGI :)
On Sat, Nov 02, 2002 at 10:56:19PM +0000, Alan Cox wrote:
> On Sat, 2002-11-02 at 21:57, Patrick Finnegan wrote:
> > On 2 Nov 2002, Alan Cox wrote:
> >
> > > On Sat, 2002-11-02 at 20:36, Dr. David Alan Gilbert wrote:
> > > > 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.
>
> 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.
--
ciao -
Stefan
On Mon, Nov 04, 2002 at 05:57:52AM +0100, Stefan Traby wrote:
> 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
On Sat, 2 Nov 2002, Patrick Finnegan wrote:
> > 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.
> 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.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wednesday 06 of November 2002 01:45, Bill Davidsen wrote:
> On Sat, 2 Nov 2002, Patrick Finnegan wrote:
> > > 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.
>
> > 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.
You have to forgive me this joke. - Let's hang the guy who introduced QT into
kernel and be friends again.
--
Mariusz Zielinski
