On Sun, Jan 06, 2008 at 12:29:46PM +0100, Stefan Richter wrote:
> Adrian Bunk wrote:
> > On Sun, Jan 06, 2008 at 01:35:21AM +0100, Stefan Richter wrote:
> >> instead work on better UIs if you have got
> >> trouble with the complexities of the dependencies graph. The graphic
> >> UIs including menuconfig currently work best for tree-like dependencies,
> >> but the graph isn't a tree. Think about how to present this properly in
> >> an UI. The Kconfig files are the wrong place to attack this problem.
> >> ...
> >
> > Duplicating the structure in each UI should be an improvement?
> >
> > Hardly.
>
> What do you mean?
>
> We have dependency data in the Kconfig files. We have a few different
> UIs to them. Why there are different UIs is easy (oldconfig vs.
> xconfig) or not so easy (gconfig vs. xconfig) to explain. Anyway; IMO
> we should keep data and presentation separate for at least two reasons:
> - to allow us to have specialized task-oriented UIs (oldconfig,
> randconfig et cetera)
> - because different people have different approaches to kernel
> configuration (the guy who sets up a new box vs. the guy who bought
> a new gadget vs. the guy who updates his kernel vs. the control
> freak vs. the kernel tester vs...)
>...
You said:
"The graphic UIs including menuconfig currently work best for tree-like
dependencies"
That's true.
And the dependency graph can't be a tree.
Currently, defining the ordered tree the UIs present to the user is done
_once_ in kconfig.
Our UIs either show this tree as a tree or go through the tree
depth-first and present the options in this order to the user.
And I think your main misunderstanding is that you think the
dependencies alone would carry enough information for allowing an UI to
present the options in a way not worse than it's currently done - that's
simply not true.
> Stefan Richter
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
