Mike Hearn wrote:
On Sun, 2004-01-11 at 22:48, Nathan Hurst wrote:
Actually the main reason to not use gtkmm was that it was an incomplete wrapper - it didn't cover several things that people wanted to use.
Which parts are missing? Given that they are going onto wrap GTK 2.4 etc if there are missing bits it might be worth filing bugs on them, if you haven't already.
Good question. Mental?
Your suggestion is a good one (although to those of us that use Debian the dependencies don't seem a bit deal :) perhaps you could start the effort by setting up autopackage with inkscape anyway in such a way as it can be turned off.
I'm not sure what you mean by that. Any changes to the inkscape code (probably not needed anyway) would not be specific to autopackage but just for increased binary portability.
autopackage itself works like RPM or debian packaging, there is simply a specfile.
Ok, even easier.
We can then ship with it and get reports of failure, but are then able to say, didn't work for you? Ok, what machine ... and turn autopackage off and we have a happy customer and a data point for you.
You make it sound like you think it will not work. Certainly, the odd brokenness of various distros never ceases to amaze us but so far we've been able to cope fairly well.
No, I'm giving you the opportunity to test your software in a non-release critical manner. That is, we can get people to try it on all those weird systems out there and find out what the problems might be _before_ we actually need gtkmm. If someone you'd never heard of came to you and said "you know that problem you were having? Well I have the ultimate solution!" you might be a bit cautious about deploying it? :) I'd rather fix the problems before they prevent inkscape from installing.
I'm quite ready to believe that autopackage works as well for package management as autoconf works for configuration.
njh