RE: [Inkscape-devel] Using gtkmm in inkscape
We can't expect customers to have recent versions of anything,
If they can get your application, then they can get your application's dependencies. It has not always been easy to get either applicatins or their dependencies but it's getting better now that Fedora is official.
nor can we expect them to upgrade.
Why shouldn't they upgrade? If the dependencies have stable API and ABIs then there is no reason not to upgrade the depenencies.
Murray Cumming www.murrayc.com murrayc@...167...
Murray.Cumming@...166... wrote:
We can't expect customers to have recent versions of anything,
If they can get your application, then they can get your application's dependencies. It has not always been easy to get either applicatins or their dependencies but it's getting better now that Fedora is official.
nor can we expect them to upgrade.
Why shouldn't they upgrade? If the dependencies have stable API and ABIs then there is no reason not to upgrade the depenencies.
Like I said, because they're our customers. They tell US what to do.
Often in the Unix world, there are valid reasons why someone cannot upgrade. Sometimes in an institutional environment, the reason is simply because they cannot get the admin's permission to do so.
But, hey, I'm agreeing with you. ;-) If we can get around the dependencies for architecture X, then I think we can go ahead with gtkmm.
I have a question, something we were talking about a week ago. Is it possible to build recent versions of gtkmm and sigc++ with not-so-recent versions of Gtk, Glib, and the like? It would be good if we could limit the wildcards of the distro to only those two libs.
Murray.Cumming@...166... wrote:
nor can we expect them to upgrade.
Why shouldn't they upgrade? If the dependencies have stable API and ABIs then there is no reason not to upgrade the depenencies.
Remember...
In the corporate world, decisions are based on business, not logic. :-)
I was just skimming the fedora archives and it looks like there are admins out there who individually have hundreds of boxen on RH 8.0, as they just recently completed testing and upgrade cycles. They're stuck on 8.0 for now.
Jon A. Cruz wrote:
Murray.Cumming@...166... wrote:
nor can we expect them to upgrade.
Why shouldn't they upgrade? If the dependencies have stable API and ABIs then there is no reason not to upgrade the depenencies.
Remember...
In the corporate world, decisions are based on business, not logic. :-)
I was just skimming the fedora archives and it looks like there are admins out there who individually have hundreds of boxen on RH 8.0, as they just recently completed testing and upgrade cycles. They're stuck on 8.0 for now.
I'm not compelled by this argument. If they want to use older libraries then they could use sodipodi. We're not in the business of making compatible software, we're in the business of making good software.
http://www.inkscape.org/cgi-bin/wiki.pl?OtherGoals
If we make a good vector drawing program, then people will come (either they will learn how to support what we use on their platform, or someone else will then get motivated to fix the problem). We can include patches, but lets not start worrying about whether random deprecated platform XYZ will support our code. Everything we use is (l)GPLd, so there is no fundamental reason why it can't run on any platform.
njh
I'm in agreement with NJH on this one. It seems to reason that we are not developing legacy-support software, but are hoping to develop a tool that is beyond normal standards. We are still trying to sort out basic drawing tools and a great user interface so that we can get to where we want, which is to develop a more advanced drawing tool.
Already artists and developers are switching to use our tool. As we all know, SVG-usage is starting to ramp up in OSS. We really need to be in the best position by, lets say, when FedoraCore2 comes out in APRIL and when SUSE gets it together with NOVELL, and so forth. That is really about the beginning of JUNE.
We really need to get to a MAJOR-MAJOR milestone where we can call a certain release PRODUCTION-READY--so that people will use the tool to drive their workflow.
I say we use GTKMM if we need it. People who can't get access to GTKMM, we can encourage to use other releases we have under our belt that will still be available on sf.net.
Anymore thoughts developers? Bryce? Bulia?
Jon
On Mon, 2004-01-12 at 13:35, Nathan Hurst wrote:
Jon A. Cruz wrote:
Murray.Cumming@...166... wrote:
nor can we expect them to upgrade.
Why shouldn't they upgrade? If the dependencies have stable API and ABIs then there is no reason not to upgrade the depenencies.
Remember...
In the corporate world, decisions are based on business, not logic. :-)
I was just skimming the fedora archives and it looks like there are admins out there who individually have hundreds of boxen on RH 8.0, as they just recently completed testing and upgrade cycles. They're stuck on 8.0 for now.
I'm not compelled by this argument. If they want to use older libraries then they could use sodipodi. We're not in the business of making compatible software, we're in the business of making good software.
http://www.inkscape.org/cgi-bin/wiki.pl?OtherGoals
If we make a good vector drawing program, then people will come (either they will learn how to support what we use on their platform, or someone else will then get motivated to fix the problem). We can include patches, but lets not start worrying about whether random deprecated platform XYZ will support our code. Everything we use is (l)GPLd, so there is no fundamental reason why it can't run on any platform.
njh
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hello.
On Mon, 2004-01-12 at 16:03, Jonathan Phillips wrote: [...]
We really need to get to a MAJOR-MAJOR milestone where we can call a certain release PRODUCTION-READY--so that people will use the tool to drive their workflow. I say we use GTKMM if we need it. People who can't get access to GTKMM, we can encourage to use other releases we have under our belt that will still be available on sf.net.
Agree. Good software rises the baseline.
Maybe for the next release (february) it would be good to be non-GTKmm, and the one after that (say, by march) include already the GTKmm functionality.
But who am I to say, I'm not hacking code here!
Greetings.
Daniel Díaz yosoy@...31...
participants (6)
-
unknown＠example.com -
Bob Jamison -
Daniel Díaz -
Jon A. Cruz -
Jonathan Phillips -
Nathan Hurst