Olivier's attention required [was: compile problems...]
edscott at prodigy.net.mx
Fri Jul 23 03:52:45 CEST 2004
El jue, 22-07-2004 a las 14:53, Brian J. Tarricone escribió:
> unless you're assuming that xffm is going to be used heavily without
> xfce, this is really irrelevant. libxfcegui4 will already be in memory,
> and, as a shared library, will not need to be reopened when you dlopen()
Yea, you have a good point here. Do we want to make libxfcegui4 larger?
> uhh... there is a very strong precedent for using stub libraries to
> dynamically load optional dependencies at runtime. my way is most
> definitely not a hack, and you certainly don't know me well enough to
> assume that i "like hacks". nothing could be further from the truth. i
> conceed that hacks do have their place, but they're no replacement for a
> thorough design process. your arbitrary acts here, without any sort of
> discussion, does not fit the definition of "thorough" in the slightest.
I might have worded some crazy ideas (viewed in retrospect) about
libxfcegui4 and libxfceutil4, but I *never* did any arbitrary acts with
them. For Pete's sake, if you look my recent commits you will see that I
rather did a cut and paste to customize both buttons of the confirm
dialog rather than doing any arbitrary acts, like modify the code in a
way which might not suit Jasper.
> again, you're attributing beliefs and attitudes to me that you simply
> know nothing about. i'm fine with new ideas, if they are based on sound
> design principles. moving all public header files out of their owning
> package gives xfce as a whole nothing. maybe it makes a couple things
> easier for xffm and a few of the smaller utilities, but now the panel,
> xfdesktop, the mcs manager, and xfwm4 would need to depend on an extra,
> unneeded package for required functionality.
Yea that was an incorrect (nearsighted) idea. It just slipped from my
fingers while I typed. Just forget I ever typed libxfcegui4/libxfceutil4
and focus on the real issue: xfce4-modules.
Notwithstanding, in order to retain the behaviour of xfce4-modules (as
before all this .config/.cache stuff), it was necessary to separate the
header files. See other options below.
> what you're describing is a highly unlikely use case that is, IMO, a
> waste of time to plan for. for one thing, i can't see anyone wanting to
> do that - either you want the modules or you don't. if you forget about
> them and need to recompile, it's not a big deal. on the other side,
> most people don't compile their own software, and those do usually do so
> through some kind of source-based package manager, where all
> dependencies are handled ahead of time (certainly, the binary distros
> will make this choice for the user well in advance). if libdbh and
> xfce4-modules were huge, lumbering, bloated dependencies, i might -
> _might_ - ignore all that and try to make it more modular, but in this
> case it just isn't worth it.
I beg to differ in opinion. Xfce is small, fast and powerful. Planning
for that is not waste of time, it is a priority.
Did you know that the sum of 1/n goes to infinity, eventhough the terms
go to zero as n increases? Get a sufficient number of small libraries
and you can bring any system to its knees.
Anyways, this ain't a democracy. Comrade Olivier is chairman and
responsible for the decisions. These are the options I see (feel free to
add any others):
1- Separate xfce4-module headers (as shown in CVS)
2- Put the module headers back to where they were and add a dependency
for xfce-utils (that's real easy).
3- Put the headers into libxfcegui4 or libxfceutil and keep
4- Put both modules and headers into libxfcegui4 or libxfceutil.
5- Incorporate the xfce4-modules code directly into one of the two above
6- send xfce4-modules and all code that depends on it to Gulag-19.
7- none of the above.
8- all of the above.
Olivier? Are you reading?
The option I prefer is the one already committed to CVS. Easier to show
than tell. People always seem to get angry when I write words at them.
I'm sure I got on your nerves, Brian.
More information about the Xfce4-dev