On Sat, 14 Dec 2002, Filip Spacek wrote: > On Sat, 14 Dec 2002, Martin Albert wrote: > > > Sorry, if you find i'm insisting or sth. like that. I feel that i have > > unsolved problems (some more?: eg. module-versioning). > > > > Tell me to shut up or to try to do more mindreading about authors > > reasons for those choices (am i not correct with: building up GGI, > > concentrating on writing fine libs for the project with easy names, ...) > > > > I think your statement is correct and valid. > > I think libggiwmh has it all: distinction, elegance, few chars to type. > > Neither variant seems to be able to make both of us happy. > > Either i'm confused or there are unsolved issues that confuse (me). > > Decisions should be made before going further with release. Lay out a > > stable concept with v.2 giving developers a clear view of a stable GGI. > > > > Albert Einstein: Halte die Dinge so einfach wie moeglich, aber nicht > > einfacher. "Keep things as simple as possible, but not simpler!" > > If you don't take sth. upon yourself, somebody else _will have to_. > > > > greetings, martin (packaging gii, splitting x and really wondering / > > worrying about module-versions. libgii-target-x or libgii0-target-x is > > the question here, together with etc/ggi, lib/ggi all along). > > > Well, I suppose my comment was directed more to authors of various > extensions about the rather cryptic names of these extensions. Currently > there is libwmh, libxmi, libbse, libgic, libgpf, libblt, libbuf, libovl > in various stages of development. Maybe I'm just slower than most but > meanings of a lot of these don't seem obvious to me. IMHO, flagging them > as ggi extension by prepending their name with ggi is certainly a step > in the right direction.
libbse, libgic and libgpf are NO extensions. Thus, how should we mark ggi libs, which are NO extensions? IMO, extensions should be distinguishable from non-extensions by their (package-)names. > As far as packaging of gii goes, if I understand the issue correctly, it > boils down to binary compatibility between libgii and its input targets. > Currently if a binary incompatile change happens, the only way to keep > both versions installed would be to do some very fancy libgii.conf cruft > in order to make each of the version of libgii load the proper set of > input targets. But given that the loading of input targets is fully > under libgii control, I think it is safe to assume that if any such > change happens, libgii will provide a mechanism for loading the > different versions of input targets. Hence I would tend to think that > libgii-target-x should be the right choice. Ack. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
