On 01/07/06, jiho <jo.irisson@...400...> wrote:
On 01 Jul 2006, at 18:06 , Ben Fowler wrote:
> On 01/07/06, jiho <jo.irisson@...400...> wrote:
>> On 01 Jul 2006, at 14:38 , jiho wrote:
>[ snip ]
> it would be hard to make them coexist without getting in the way of
> other packages... It would mean making an entire second tree of
> everything gnome-based, ultimately. Better to upgrade what we've got,
> it will just take a little planning.
so it seems that even if one of us provides packages for gtk, there
will be an enormous additional work from the fink team to get all
other gtk-depending packages working. In addition, given that we do
not even provide an up-to-date fink package for Inkscape itself, ...
I had always imagined that we provide the source, and the fink team
could create their X11 (Gnome or KDE) packages as .deb if they wished.
They know their methods ...
I am afraid providing packages for GTK will be difficult ;-)
... It doesn't sound at all viable, more that just 'difficult'.
> If nothing is done then we might end up having to label some of
> libraries as 'fourth party' (fink being the third party) and install
> them in /inkscape perhaps needing to place these versions in our svn.
I don't think that adding all gtk in svn will be acceptable.
Why not? This is what the Firefox people do with third party libraries
such as svg and cairo.
They don't use any fink libraries, and the nearest thing that I can
think of is a 'Shared Menus' framework which builders need to copy to
one of their 'Library' folders.
We could do that. Provide either a pre-built gtk/gtlmm/sigcc+ set of
frameworks (or the XCode projects to create them), and have builders
install those. The build process for Inkscape would copy these
Frameworks into the .app bundle.
possibility IMHO, if 2.8 is really needed and that Fink does not
provide it, is to get the few people compiling Inkscape for OS X to
install it separately (we should be 3 or 4 max) and ship inkscape
only as dmg packages (i.e. there won't be a new fink package until
fink updates GTK but there is no up to date package currently anyway).
I hope that this doesn't come across the wrong way, but I don't think
any of that is quite consistent with what we have been saying.
1. The question of which version of Gtk to require cannot be taken by
either of us. The team as a whole or the leaders need to state whether
a version later than 2.6 is required, if the answer is 'Yes", then it
is up to us to solve the problems in some way. Even if the answer
isn't a definite "Yes', then we are only putting off the evil moment,
because I can't see that the fink project is going to overtake us
anytime soon. It is obvious to me (though I might be wrong) that a
project like Inkscape really does require recent code with the fixes
and interface ideas. If you really want to be a 'a last ditcher', then
the best that I can see would be to defer up-rating the requirement
until this Autumn and then go straight to 2.10 .
2. I really don't want to speak of only a handful of people actually
compiling Inkscape. We are a community and there is no reason why Mac
users in large numbers should not be compiling it. Part of the raison
d'être of any open software project is to offer training, and support
in collaboration with other developers and working with a large
codebase. Telling our community to accept .dmg is not in any shape or
form an attractive option! This would detrimental both to bug fixing
and working with new features.
3. The sourceforge statistics show the Mac deliverables being
downloaded in large numbers - now I think that this is because the
label for the Universal.dmg makes it look as though it is a combined
Mac/Windows/Linux thingy, and I suspect that many people who do
download it have to come back to download the Windows version that
they actually wanted. Even so we should be encouraging people to get
invoved with development, not creating a charmed circle or clique for
people who have mastered the art.
4. It only makes sense if we knew that there will be a fink set of
libraries in the medium term, and I think that the reverse applies! We
would do better waiting to see which libraries Apple ship with
> What about Universal Binaries?
(I'm talking past you here, sorry). What I meant was: Is it not the
case that the fink libraries have no support for Universal Binaries?
If so, I think that we have to take a decision to cut adrift from the
fink project (as an interim measure) this summer, that is, as of now;
because I thnk that we do need a one-step way of building Universal
Note that I don't have strong feeling concerning the 'what' of what we
do, but I do feel that the 'how' of how do we move on from 0.44 to
0.45 is important!