Goswin Brederlow writes:
> Of cause main guis should be mentioned, but something like gnome woult
> be x11/gnome and the first two level would be exactly spezified and
> relevant. But the third level specifying what subtype of a gui is used
> is probably irrelevant to the user and could be optional or left to
> the maintainer (of the gui) to specify.
Sure, "gnome" would be sufficient (for now) to derive
"x11/gtk/gnome". But dropping the first 2 levels would prevent people
to request eg. "only Gtk apps".
And as for the "3rd level", I don't think we should label it as "3rd"
- there may be a number of items on the stack - what if someone comes
with an extension to GNOME, leading to x11/gtk/gnome/foobar ? I'd
think it would in a first time go into .../gnome/other or
.../gnome/misc.
Proposal: we could have a skeleton tree including "major" UIs, defined
by policy, and any new UI/sub-UI is put in <something>/other until it
becomes necessary to add a new entry.
I'm not sure how to avoid potential chaos otherwise.
> For example tcl/tk should have its versions as subtypes, since they
> are mostly incompatible. A Package stating that it runs on Interface
> tcl/tk without version subtype could mean all version.
AFAIK Tcl is not an interface. I'd classify programs using perl/tk
and tcl/tk both under "x11/tk" (or just "tk" ? It is portable I think ?).
> > * I don't really want to have my precious 64Mb RAM wasted by 10
> > different Xt-derived toolkits.
>
> What do you mean with that? Don´t install them. The depends would also
> tell you that a package needs some special gui.
Hm... maybe. But I'd think of a frontend which would hide libs (and
hence UI underlying a package) to the user. In such a frontend the
user would not be able both to let the frontend handle libraries all
by itself _and_ to filter unwanted GUIs (unless using an other
mechanism, of course).
> > > A major thing is fb, whereas X11 may be a subset of fb as can be
> > > berlin or ggi. I don´t now if there are any pure fb prorams except the
> > > XServer and the ggi fb traget, but might be worth keeping in mind.
> >
> > I'm not sure what you're suggesting here... fb/X11 ? That one would
> > erroneous, and would caracterize a superset, not a subset (as Xt is a
> > superset of X11), which would not be true as well.
> >
> > Could you please explain your point further ?
>
> Most graphics interfaces work on a Framebuffer with the exception of
> svgalib. Also ggi runs on fb, svgalib, aalib,...
Yes and no (AFAIK plain XF86 uses its own drivers directly accessing
graphics harware, although there is a fbdev-based server), but they do
not provide the FB API as part of their API. In that, I would not
write "x11" as "fb/x11". Extending a UI with more elements, and
implementing a full UI as a layer hiding another one are quite
different.
> I think the help texts given for
> the gui selection in frontends should point out that certain programs
> will be under different interfaces but will still work on this
> interface via a target library (e.g. ggi will say that all X programms
> can be run in the ggi X-server or the fb will tell that you can use
> X11 or ggi stuff).
This could be used using (what I'd call) a "language/translator" or
"language/virtual machine" model. That is apps would declare a "UI
language" (eg. ggi), and the X11 ggi backend would declare itself as a
"UI translator" from "ggi language" to "X11 language".
[Somewhat off-topic note: I already try to introduce a similar model
to handle emulators (eg. Wine translates a "MS-win language" into a
"Linux language") and documentation autoconversion (mapping is more
diret here), but with little success - I think my mail to deb-dev had
something like "virtual machine" in the subject]
> More than 1000 Files in a directory will be a problem. Even more than
> 100 Files are not the nicest when looking for something.
Yes, but that's an implementation detail - I don't think we should
care about that. Eg, the pool proposals I saw mentionned splitting
big dirs using eg. .../em/emacs... which solves the problem.
> Some structure is needed on the archive and the nature seems in my
> eyes be the most usefull to people looking through the archive without
> the frontend.
Maybe. But if we have to find a compromise between these 2 issues,
I'd rather not give up to much to the "people manually looking through
the archive" if it impairs the flexibility of the frontends.
In other words, I don't think we want to support "manually using the
archive" as much as "using frontends".
--
Yann Dirson <[EMAIL PROTECTED]> | Why make M$-Bill richer & richer ?
debian-email: <[EMAIL PROTECTED]> | Support Debian GNU/Linux:
| Cheaper, more Powerful, more Stable !
http://www.altern.org/ydirson/ | Check <http://www.debian.org/>
