[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Getting rid of section "base" ?

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

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

 >  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    <ydirson@altern.org> |    Why make M$-Bill richer & richer ?
debian-email:   <dirson@debian.org> |   Support Debian GNU/Linux:
                                    | Cheaper, more Powerful, more Stable !
http://www.altern.org/ydirson/      | Check <http://www.debian.org/>

Reply to: