Kconfig (qt) -> Gconfig (gtk)

Kconfig (qt) -> Gconfig (gtk)

[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
-- 
Romain Lievin, aka 'roms'  	<roms@lpg.ticalc.org>
Web site 			<http://lpg.ticalc.org/prj_tilp>
"Linux, y'a moins bien mais c'est plus cher !"

Re: Kconfig (qt) -> Gconfig (gtk)

[Nero]

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.

Re: Kconfig (qt) -> Gconfig (gtk)

[Jon Portnoy]

On Sat, 2 Nov 2002, Dr. David Alan Gilbert wrote:

> * Nero (neroz@iinet.net.au) 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.

Re: Kconfig (qt) -> Gconfig (gtk)

[Nero]

On Sun, 3 Nov 2002 07:36 am, Dr. David Alan Gilbert wrote:
> * Nero (neroz@iinet.net.au) 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.

Re: Kconfig (qt) -> Gconfig (gtk)

[Dr. David Alan Gilbert]

* Nero (neroz@iinet.net.au) 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   |_______/

Re: Kconfig (qt) -> Gconfig (gtk)

[Xavier Bestel]

Le sam 02/11/2002 à 21:36, Dr. David Alan Gilbert a écrit :
> * Nero (neroz@iinet.net.au) 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 ...

Re: Kconfig (qt) -> Gconfig (gtk)

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Kconfig (qt) -> Gconfig (gtk)

[David B. Stevens]

Xavier Bestel intoned:

> Le sam 02/11/2002 à 21:36, Dr. David Alan Gilbert a écrit :
> 
>>* Nero (neroz@iinet.net.au) 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

Re: Kconfig (qt) -> Gconfig (gtk)

[Dave Jones]

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

Re: Kconfig (qt) -> Gconfig (gtk)

[Patrick Finnegan]

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

Re: Kconfig (qt) -> Gconfig (gtk)

[Alan Cox]

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.

Re: Kconfig (qt) -> Gconfig (gtk)

[Russell King]

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 <mec@shout.net> or
| +post a message to <linux-kernel@vger.kernel.org> for additional assistance. 
| +
| +EOM
| +			cleanup
| +			exit 1
|  		esac
|  	done
|  }
| 

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Kconfig (qt) -> Gconfig (gtk)

[bert hubert]

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

Re: Kconfig (qt) -> Gconfig (gtk)

[Roman Zippel]

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

Re: Kconfig (qt) -> Gconfig (gtk)

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Kconfig (qt) -> Gconfig (gtk)

[Nero]

On Sun, 3 Nov 2002 10:28 am, Dr. David Alan Gilbert wrote:
> * Patrick Finnegan (pat@purdueriots.com) 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 ;))

Re: Kconfig (qt) -> Gconfig (gtk)

[Marek Habersack]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

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 :>

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Kconfig (qt) -> Gconfig (gtk)

[Sam Ravnborg]

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

Re: Kconfig (qt) -> Gconfig (gtk)

[Sam Ravnborg]

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

Re: Kconfig (qt) -> Gconfig (gtk)

[Alan Cox]

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.

Re: Kconfig (qt) -> Gconfig (gtk)

[Roman Zippel]

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

Re: Kconfig (qt) -> Gconfig (gtk)

[Patrick Finnegan]

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

Re: Kconfig (qt) -> Gconfig (gtk)

[Nero]

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).

Re: Kconfig (qt) -> Gconfig (gtk)

[Dr. David Alan Gilbert]

* Patrick Finnegan (pat@purdueriots.com) 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   |_______/

Re: Kconfig (qt) -> Gconfig (gtk)

[Roman Zippel]

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

Re: Kconfig (qt) -> Gconfig (gtk)

[J.A. Magallón]

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 <jamagallon@able.es>      \                 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))

Re: Kconfig (qt) -> Gconfig (gtk)

[Patrick Finnegan]

On Sun, 3 Nov 2002, Nero wrote:

> On Sun, 3 Nov 2002 10:28 am, Dr. David Alan Gilbert wrote:
> > * Patrick Finnegan (pat@purdueriots.com) 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

Re: Kconfig (qt) -> Gconfig (gtk)

[Rando Christensen]

Sat, 2 Nov 2002 20:36:08 +0000: Dr. David Alan Gilbert ("Dr. David Alan
Gilbert" <gilbertd@treblig.org>):

> 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 / rando@babblica.net    >

Re: Kconfig (qt) -> Gconfig (gtk)

[Alan Cox]

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

Re: Kconfig (qt) -> Gconfig (gtk)

[Christoph Hellwig]

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..

Re: Kconfig (qt) -> Gconfig (gtk)

[Gerhard Mack]

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

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: Kconfig (qt) -> Gconfig (gtk)

[George Staikos]

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

Re: Kconfig (qt) -> Gconfig (gtk)

[Matthew D. Pitts]

> 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

Re: Kconfig (qt) -> Gconfig (gtk)

[Randy.Dunlap]

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

Re: Kconfig (qt) -> Gconfig (gtk)

[Nero]

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).

Re: Kconfig (qt) -> Gconfig (gtk)

[Geert Uytterhoeven]

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 -- geert@linux-m68k.org

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

Re: Kconfig (qt) -> Gconfig (gtk)

[Christoph Hellwig]

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 :)

Re: Kconfig (qt) -> Gconfig (gtk)

[Stefan Traby]

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

Re: Kconfig (qt) -> Gconfig (gtk)

[Sam Ravnborg]

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

Re: Kconfig (qt) -> Gconfig (gtk)

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Kconfig (qt) -> Gconfig (gtk)

[Mariusz Zielinski]

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

Re: Kconfig (qt) -> Gconfig (gtk+)

[Roman Zippel]

Hi,

On Sat, 2 Nov 2002, Romain Lievin wrote:

> > I'm not planning to do it myself, so go ahead. If you have any questions, 
> > just ask.
> 
> ok, let's go !
> BTW, is there any doc about your library ?

Not really (yet), but you have several examples and most functions should 
be self-explanatory.

bye, Roman

Re: Kconfig (qt) -> Gconfig (gtk+)

[Romain Lievin]

Hi,

On Sat, Nov 02, 2002 at 12:59:22PM +0100, Roman Zippel wrote:
> Hi,
> 
> On Wed, 26 Jun 2002, Romain Lievin wrote:
> 
> > I noticed there is a new configuration tool written in qt for replacing the tcl/tk one.
> > 
> > Is there any plan to write a similar configuration tool in GTK+ ? 
> > I will be interested in writing a such one...
> 
> I'm not planning to do it myself, so go ahead. If you have any questions, 
> just ask.

ok, let's go !
BTW, is there any doc about your library ?

> 
> bye, Roman
> 
> 

regards, roms.
-- 
Romain Lievin, aka 'roms'  	<roms@lpg.ticalc.org>
Web site 			<http://lpg.ticalc.org/prj_tilp>
"Linux, y'a moins bien mais c'est plus cher !"