Roman Zippel wrote:
>>But the fact that xconfig depends on QT is going to make some people hate
>>it.
>>
>>
>This should be rather easily fixable, but it has to be done by someone who
>is more familiar with whatever prefered toolkit. I'm familiar with QT and
>it's absolutely great to get quickly reasonable results, if someone wants
>something else I gladly will help, but I can't do it myself.
>The interface to the back end is quite simple so it should be no real
>problem to add a different user interface.
>
This is a difficult one. GUI's toolkits are a bit of religion
(fundamentalist types too).
I like and use GNOME. KDE looks good too but I steered away from it in
the early days due to the Qt licensing. I've heard rumors that the new
license is GPL compatible but I get the feeling that it is still not
squeeky clean. A lot of people don't like the larger resources for
these desktop environments.
The most common GUI toolkits used in Linux would be GTK, Qt,
Lesstif/Motif and Xaw (I've probably missed some). Xaw will work on
just about every platform I think, not sure about the others on non
linux platforms apart from lesstiff.
I personally believe in cross platform GUI toolkits and use wxWindows
for this. I really like wxpython (GTK and MSW only) for quick
development. I believe there are python wrappers to most toolkits (Qt,
GTK, etc).
As you can see there are soooooo many guis to choose/use and everyone
has there favourite. I suggest that the real work be done outside of
the GUI program. ie. seperate GUI and application guts as much as
possible. I would use python as the main language but C or even C++
could be used instead as a lot of people hate interpreters, or hate
python (prefer perl, php or something else).
I'm pretty sure there is no one solution and it comes down to the
politics and preferences of the final decision makers up the heirarchy.
Good luck,
Brendan Simon.
On Thu, 10 Oct 2002, Brendan J Simon wrote:
| Roman Zippel wrote:
|
| >>But the fact that xconfig depends on QT is going to make some people hate
| >>it.
| >>
| >>
| >This should be rather easily fixable, but it has to be done by someone who
| >is more familiar with whatever prefered toolkit. I'm familiar with QT and
| >it's absolutely great to get quickly reasonable results, if someone wants
| >something else I gladly will help, but I can't do it myself.
| >The interface to the back end is quite simple so it should be no real
| >problem to add a different user interface.
| >
|
| This is a difficult one. GUI's toolkits are a bit of religion
| (fundamentalist types too).
|
[good descriptions snipped]
|
| I'm pretty sure there is no one solution and it comes down to the
| politics and preferences of the final decision makers up the heirarchy.
|
| Good luck,
stick with TCL/TK, like xconfig currently uses ?
or is it not sufficient? or just too ugly?
--
~Randy
"In general, avoiding problems is better than solving them."
-- from "#ifdef Considered Harmful", Spencer & Collyer, USENIX 1992.
Hi,
On Thu, 10 Oct 2002, Brendan J Simon wrote:
> As you can see there are soooooo many guis to choose/use and everyone
> has there favourite. I suggest that the real work be done outside of
> the GUI program. ie. seperate GUI and application guts as much as
> possible. I would use python as the main language but C or even C++
> could be used instead as a lot of people hate interpreters, or hate
> python (prefer perl, php or something else).
>
> I'm pretty sure there is no one solution and it comes down to the
> politics and preferences of the final decision makers up the heirarchy.
Because of this I'm planning to make the config backend available as
shared library, so it can be loaded by external programs. My QT app then
would be basically just the reference implementation.
I also want to add a SWIG interface file, so you can even access the
config database with your preferred script language.
bye, Roman
On 2002.10.09 Randy.Dunlap wrote:
>On Thu, 10 Oct 2002, Brendan J Simon wrote:
>
>| Roman Zippel wrote:
>|
>| >>But the fact that xconfig depends on QT is going to make some people hate
>| >>it.
>| >>
...
>| This is a difficult one. GUI's toolkits are a bit of religion
>| (fundamentalist types too).
>|
...
>
>stick with TCL/TK, like xconfig currently uses ?
>or is it not sufficient? or just too ugly?
>
What is linux kernel conf written in ?
- perl: use perl-gtk (I think there is also a perl-qt)
- python: use py-gtk...
Use whatever the language gives. I never undestook why use tcl/tk
on a perl/python config system.
--
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-pre10-jam1 (gcc 3.2 (Mandrake Linux 9.0 3.2-2mdk))
On Wed, 9 Oct 2002, Randy.Dunlap wrote:
>
> stick with TCL/TK, like xconfig currently uses ?
Too ugly. I actually think QT is a fine choice, I just suspect that it's
going to cause political issues.
My favourite approach by far is to actually not ship anything graphical
with the kernel at all, and just hope that the config language syntax is
stable enough that different groups can do their own as external packages.
The kernel would ship with just the text-based "reference implementation"
(if even that - we could just have a few "supporting packages").
The only thing I personally really care about is the Config language,
since that _has_ to ship with the kernel.
Linus
PS. And while we're talking about the language - I'd actually prefer the
syntax "depends on" or "requires" instead of "depends", to make it
grammatically more correct. And those help-texts should be separated some
way so that they don't blend in quite as badly with the "command section".
Maybe something really syntactic like just replacing the "help" keyword
with a "---help---" keyword.
Hi,
On Wed, 9 Oct 2002, J.A. Magallon wrote:
> >stick with TCL/TK, like xconfig currently uses ?
> >or is it not sufficient? or just too ugly?
> >
>
> What is linux kernel conf written in ?
> - perl: use perl-gtk (I think there is also a perl-qt)
> - python: use py-gtk...
>
> Use whatever the language gives. I never undestook why use tcl/tk
> on a perl/python config system.
With the exception of the X interface everything is in C, what makes it
difficult to use script languages, one always needs some extra development
package installed. That's the main reason for creating a library backend,
a lot can already be packaged by distributions and only the library needs
to be built from the current kernel.
bye, Roman
On Wed, 9 Oct 2002, Linus Torvalds wrote:
| On Wed, 9 Oct 2002, Randy.Dunlap wrote:
| >
| > stick with TCL/TK, like xconfig currently uses ?
|
| Too ugly. I actually think QT is a fine choice, I just suspect that it's
| going to cause political issues.
|
| My favourite approach by far is to actually not ship anything graphical
| with the kernel at all, and just hope that the config language syntax is
| stable enough that different groups can do their own as external packages.
Good. I was this -><- close to suggesting "no GUI" -- just didn't
send that part of the message.
| The kernel would ship with just the text-based "reference implementation"
| (if even that - we could just have a few "supporting packages").
|
| The only thing I personally really care about is the Config language,
| since that _has_ to ship with the kernel.
So I think that you and Roman are close to agreement, when Roman
has the library backend ready. Of course someone needs to do a
"reference implementation" with it also, but it doesn't need to
ship with the kernel.
| Linus
|
| PS. And while we're talking about the language - I'd actually prefer the
| syntax "depends on" or "requires" instead of "depends", to make it
| grammatically more correct. And those help-texts should be separated some
| way so that they don't blend in quite as badly with the "command section".
| Maybe something really syntactic like just replacing the "help" keyword
| with a "---help---" keyword.
--
~Randy
"In general, avoiding problems is better than solving them."
-- from "#ifdef Considered Harmful", Spencer & Collyer, USENIX 1992.
Hi,
On Wed, 9 Oct 2002, Randy.Dunlap wrote:
> So I think that you and Roman are close to agreement, when Roman
> has the library backend ready. Of course someone needs to do a
> "reference implementation" with it also, but it doesn't need to
> ship with the kernel.
We ship BK documentation, so shipping a small QT app can't be that
problematic. :)
Creating the library isn't that difficult (kbuild is currently my
problem here) and I'll still have to write some API documentation for it
and some glue code to load the library.
bye, Roman
On Wed, Oct 09, 2002 at 06:29:03PM +0200, Roman Zippel wrote:
> Hi,
>
> On Wed, 9 Oct 2002, Randy.Dunlap wrote:
>
> > So I think that you and Roman are close to agreement, when Roman
> > has the library backend ready. Of course someone needs to do a
> > "reference implementation" with it also, but it doesn't need to
> > ship with the kernel.
>
> We ship BK documentation, so shipping a small QT app can't be that
> problematic. :)
> Creating the library isn't that difficult (kbuild is currently my
> problem here) and I'll still have to write some API documentation for it
> and some glue code to load the library.
Why don't you just separate the library from the kernel at all, making
it a similar package. We depend on a few external, kernel-specific
packages anyway, and depending on libkconfig wouldn't make the situation
worse. Instead people could keep their tools build one time around in
/usr/{local/,}bin (especially important with qt-monsters :)) and if
there is a change in the language Documentation/Changes would get
updated to the new required version and people had to update it,
similar to the gcc situation for a new development kernel.
Hi,
On Wed, 9 Oct 2002, Christoph Hellwig wrote:
> Why don't you just separate the library from the kernel at all, making
> it a similar package. We depend on a few external, kernel-specific
> packages anyway, and depending on libkconfig wouldn't make the situation
> worse.
The problem is that the config syntax will continue to evolve and
currently I prefer to keep the library close to the matching config
files.
I think I can keep the basic structure constant, but new options will be
added, so IMO it's more likely that a front end works with a newer
library than that a library can understand a newer syntax.
bye, Roman
[Roman Zippel]
> The problem is that the config syntax will continue to evolve and
> currently I prefer to keep the library close to the matching config
> files.
> I think I can keep the basic structure constant, but new options will be
> added, so IMO it's more likely that a front end works with a newer
> library than that a library can understand a newer syntax.
Besides which, I think it is ridiculous that one would have to download
and install a "kernel configurator" just to build a kernel. Current
minimum requirements for compiling the thing are gcc, binutils and GNU
make. The kernel can't very well ship a copy of any of those, because
(a) they're huge and (b) they're useful for many things other than
building kernels. Roman's library is neither.
(And no, "modutils" isn't a counterexample - you can build, install and
run a kernel without it.)
Peter
On Wed, 9 Oct 2002, Peter Samuelson wrote:
| [Roman Zippel]
| > The problem is that the config syntax will continue to evolve and
| > currently I prefer to keep the library close to the matching config
| > files.
| > I think I can keep the basic structure constant, but new options will be
| > added, so IMO it's more likely that a front end works with a newer
| > library than that a library can understand a newer syntax.
|
| Besides which, I think it is ridiculous that one would have to download
| and install a "kernel configurator" just to build a kernel. Current
| minimum requirements for compiling the thing are gcc, binutils and GNU
| make. The kernel can't very well ship a copy of any of those, because
| (a) they're huge and (b) they're useful for many things other than
| building kernels. Roman's library is neither.
Well, we all find some things more ridiculous than others, but...
The kernel would still have the text-mode configurator.
This only applies to the GUI kernel config.
So you wouldn't have to download the kernel config unless you just
wanted that oh-so-pretty GUI to config it.
[rhetorical question:]
So should it be shipped with a full Qt development environment, e.g.?
| (And no, "modutils" isn't a counterexample - you can build, install and
| run a kernel without it.)
--
~Randy
"In general, avoiding problems is better than solving them."
-- from "#ifdef Considered Harmful", Spencer & Collyer, USENIX 1992.
On Wed, Oct 09, 2002 at 12:28:44PM -0700, Randy.Dunlap wrote:
>
> The kernel would still have the text-mode configurator.
The way I read the original post by Christoph Hellwig - nope.
If the kernel config library is outside the kernel then the
text-mode versions will fail as well.
Recall that the text-mode version are no longer shell scripts,
but based on a nice YACC grammar and coded in C.
I do not want to go somewhere for special tools just to configure
the kernel.
Basic stuff such as make and gcc is ok to locate elsewhere - in
specific versions as well. But not some basic kernel only configurator.
Sam
On Wed, 9 Oct 2002, Sam Ravnborg wrote:
| On Wed, Oct 09, 2002 at 12:28:44PM -0700, Randy.Dunlap wrote:
| >
| > The kernel would still have the text-mode configurator.
| The way I read the original post by Christoph Hellwig - nope.
| If the kernel config library is outside the kernel then the
| text-mode versions will fail as well.
| Recall that the text-mode version are no longer shell scripts,
| but based on a nice YACC grammar and coded in C.
OK, I missed that. Sorry.
In that case I might fall into the "ridiculous" camp. :)
| I do not want to go somewhere for special tools just to configure
| the kernel.
| Basic stuff such as make and gcc is ok to locate elsewhere - in
| specific versions as well. But not some basic kernel only configurator.
--
~Randy
"In general, avoiding problems is better than solving them."
-- from "#ifdef Considered Harmful", Spencer & Collyer, USENIX 1992.