- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Using gtkmm in inkscape
by bulia byak 13 Jan '04

13 Jan '04

>done." This means that if a decision is between more users or easier for >developers, I say we take the easier for developers option. Choices of this kind are fortunately rare. Normally we can all focus on our areas of interest (e.g. the usability for me or program internals for you) without stepping on each other's toes. >In this case it means using gtkmm _despite_ it not being available in large >quantities. I'm no expert but I got the impression that gtkmm availability is being resolved, so the point is moot. > In this case it means not holding back a feature because it makes the >windows port hard. Can you give an example of such a feature? >In this case it means throwing away a large chunk of UI code because it was >clumsy. Are you referring to the spiral tool? If so, what's so clumsy about it? >Otherwise we will decend to the point where all we are doing is minor >tweaks to the about box... :-) _Someone_ must do these tweaks, too. _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjo…

2 1

gtkmm in MacOS X Fink, maybe
by unknown＠example.com 13 Jan '04

13 Jan '04

This might be what you need. I think someone added it yesterday: http://fink.sourceforge.net/pdb/package.php/gtkmm2 Murray Cumming www.murrayc.com murrayc@...167...

1 0

RE: [Inkscape-devel] Using gtkmm in inkscape
by unknown＠example.com 13 Jan '04

13 Jan '04

> However, freshrpms does have a 9.0 package that installs on 8.0. But > again, it's a bit problematic for those individuals and companies who > haven't stayed on the cutting edge. Fedora.us has gtkmm rpms, so you should use them instead, because they are official. They are basically the same as the fedora.us gtkmm rpms for Fedora Core 1. Murray Cumming www.murrayc.com murrayc@...167...

1 0

Using gtkmm in inkscape
by unknown＠example.com 13 Jan '04

13 Jan '04

Hi, someone pointed this status page out to me: http://www.inkscape.org/status/status_20031231.php So I thought I would offer some advice, quoting that page: > A second and much more critical issue has been raised regarding Gtkmm. > As planned since early in the project, we began incorporating Gtkmm > into Inkscape following the 0.36 release. Quickly it became evident > that this introduced severe dependency issues. > Gtkmm 2.x is not available commonly on most Linux distros. It is easily available for debian and RedHat/Fedora, from official distro sources: http://www.gtkmm.org/download.shtml A Mandrake developer assured me that they would ship it, but I don't have a Mandrake installation and I don't know how to check that. I'm fairly sure that it's easily available for Gentoo. SUSE have no public bug tracking or feedback system that I know of, but hopefully that will get better. With no contributions system, you will have difficult installing Inkscape on SUSE whether or not you need gtkmm. What other distros are you interested in? > On Windows it adds to the DLL download weight. I'm not sure what significance the download size has these days. By the way, gtkmm is easily installable on Windows: http://www.gtkmm.org/download.shtml > Most distressingly, it isn't yet ported to OSX. It builds, and works, and Julian Missig built a darwinports package: http://mail.gnome.org/archives/gtkmm-list/2003-December/msg00122.html I don't know much about MacOS X these days, but I suspect that you want it as a Fink package. That should not be at all difficult to do. Please tell ask on the gtkmm-list if you need help with that. I would appreciate being CCed on any communication with the Fink people. Murray Cumming www.murrayc.com murrayc@...167...

5 5

RE: [Inkscape-devel] Using gtkmm in inkscape
by unknown＠example.com 12 Jan '04

12 Jan '04

> 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...

6 5

RE: [Inkscape-devel] Using gtkmm in inkscape
by unknown＠example.com 12 Jan '04

12 Jan '04

> Of course it is available. The question is, "Is it already > there?" The average blue-haired old lady might be puzzled a > bit by a dialog: "You must have gtkmm-2.4-x.rpm installed for > Inkscape to work" 'RPM Hell' is becoming a major part of the > Download Factor. But, on sane systems such as debian's apt and RedHat/Fedora's new thingy, and others, you will just install Inkscape and it will take care of the rest. People will not even know, or care, that you use gtkmm. > >>On Windows it adds to the DLL download weight. > >> > >> > > > >I'm not sure what significance the download size has these > days. By the > >way, gtkmm is easily installable on Windows: > >http://www.gtkmm.org/download.shtml > > > > > > This is the other major part. Every little bit hurts. If > we need it, > include it. Using, or not using, gtkmm is not the sort of major decision that should hinge on a little bit of download size. And as someone else said in another thread, people are quite used to enormous Windows downloads, because everyone has to ship all of MFC, CommonDialogs, yadda yadda in every application installer. Murray Cumming www.murrayc.com murrayc@...167...

3 2

RE: [Inkscape-devel] Using gtkmm in inkscape
by unknown＠example.com 12 Jan '04

12 Jan '04

> 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? libsigc++ does not depend on GTK+ or glib. gtkmm 2.2 can build with GTK+ 2.2 and glib 2.2, and with later API/ABI-compatible versions such as GTK+ 2.3/2.4. gtkmm 2.4 requires GTK+ 2.4 (2.3 will become 2.4). Gtkmm 2.4 installs in parallel with gtkmm 2.2, so you can have both: http://www.gtkmm.org/ > It would be good if we could limit the wildcards of > the distro to only those two libs. glibmm is now a separate module, for gtkmm 2.4. Murray Cumming www.murrayc.com murrayc@...167...

1 0

Rendering Plugin: GtkMathView
by Felix Breuer 12 Jan '04

12 Jan '04

Hello Inkscape Hackers! I have a couple of questions: In general: Does the planned plugin architechture of Inkscape allow for rendering plugins, i.e. plugins that render new/custom/other tags in the SVG document (embedded via the foreignObject tag)? More specifically: I would really like a MathML rendering plugin. Does your (planned) plugin architechture allow for such a thing? If it does, my suggestion is the following: GtkMathView [1] is a very mature MathML rendering engine which provides a) a GTK rendering widget, b) a C++ interface for rendering MathML and, most importantly, a Bonobo component. For details see [1]. It might be possible to use this to render MathML formulas inside pictures/diagramms created with Inkscape without too much implementation effort (?). Rationale: Currently there is no modern visual software to create mathematical/technical drawings. The free software user who needs such drawings (i.e. drawings that contain formulas) is forced to use programms like Xfig or to hand-code these drawings in LaTeX. Neither approach suits me and most of the mathematicians I know rather stick to pen and paper because of that. Hence, I think there is a not-too-small community of people who would be interested in this feature. If you think this is feasible with regard to Inkscape's plugin architechture, I might well take to the task of implementing the actual plugin. Please tell me what you think. Regards, Felix

5 6

Dependencies, GTKmm, Windows and autopackage
by Mike Hearn 12 Jan '04

12 Jan '04

That's a bit of a mouthful of a subject line, isn't it? Let me introduce myself. I'm the maintainer of the autopackage project (http://autopackage.org/) which is focussed on making software installation on Linux as easy as it is on other platforms. There are several parts to that mission, but autopackage is one of the first - it's a way of building packages that can be installed on any distribution *with* dependency handling. The idea is that maintainers of applications and libraries build a binary package at the same time as releasing source code packages, so ensuring that end users need not compile from the source. A few things that autopackage is: - A framework for building distro-neutral installers - A system that checks the OS directly for any dependencies required, so you don't have to use autopackage to install dependencies: it will detect their presence regardless of whether RPM, source code or simply copying binaries from another machine was used. - Currently experimental. We're about to release 0.4. All packages built until we release 1.0 are classed as experimental too. - Distributed: autopackage does not depend on having large repositories of packages built from it. The idea is that maintainers host packages themselves, and packages know where to go and find them to resolve dependencies. A few things autopackage is not: - It's not a distro. The idea is not that we package everything - far from it, all the packages we produce currently (there are only a few) are for testing purposes only. - It's not a replacement for RPM. For version 0.6/0.7 we want to integrate support for using native RPMs/DEBs/ebuilds where they exist, and utilising the native dep resolver when possible. Why is this relevant to Inkscape? I noticed on your last status report that you were considering delaying the introduction of GTKmm because it was not widely spread enough amongst distros. This is problematic, as the reason it's not installed by default in most distros is the lack of popular apps using it. One of the reasons people are reluctant to use it, is the lack of distros which include it. Clearly this is a catch-22 situation. So what is the answer? autopackage 0.4, which features network dependency retrieval, is going to be released soon. After that comes 0.5, in which we don't really want to add new features but instead concentrate on packaging a reasonably complex real world application. Up until now we've been using Gaim, which works OK but the Gaim maintainers have been less than co-operative so we're scouting around for something else (which preferably uses language bindings) to package instead. Programs that use language bindings are primary targets for us, because the dependency problems caused by them often discourage people from using them. This is not good, because language bindings have the potential to dramatically increase the productivity of free software developers by letting us get away from C. Therefore, I want people to use them, therefore I want people to depend on them. I have a proposal: If you go ahead with your original plans to make full use of GTKmm and all the useful things it provides, for 0.5 we will package Inkscape and GTKmm together in a distro-neutral fashion. You can link to these packages from your website, as well as providing packages in any other form you like. If up to date RPMs, DEBs etc are not available for the users distro, they can try the .package (autopackage) files. They will scan the system for GTKmm and other deps, and download and install them if not found. Here is a quick attempt to address some questions I expect you have. Q: But there are other reasons we are wary of GTKmm! A: Yes. The maintainer of GTKmm is not aware of any building problems on MacOS X however - being standard C++ and given that Apple use gcc, it's hard to imagine where potential problems might come from. Certainly, it would not be hard to port if there were issues. I'm not sure this is a valid reason to avoid GTKmm: if people want to use Inkscape on MacOS then any issues (if there are any) will be worked out. Murray Cumming can comment more on this. DLL bloat: all I can say here is that many, many win32 applications ship with MFC or ATL DLLs so this is hardly a problem unique to ported applications. Certainly the benefits of a good C++ wrapper outweigh the additional download size IMHO. Q: Isn't Linux binary portability really bad? A: Well, yes and no. A part of the work we do for autopackage is R&D into Linux binary portability. You're almost certainly aware of the C++ ABI break, about which we can do nothing. Fortunately gcc 2.95 is several years old now and *all* modern distros are compiled with gcc 3.2, so this is not so problematic (though autopackage can detect and deal with it nonetheless). There are other issues, of course. We have some simple drop-in build tools to control glibc symbol versions, the package build program scans all ELF binaries to locate common mistakes, and so on. In order to improve the binary portability between Linux distros, minor changes to the build system and/or source may be necessary. They should not affect the functionality of the program in any way. Q: Where does Windows come into this? A: You want a Win32 port. As you have already discovered ..... http://sourceforge.net/tracker/index.php?func=detail&aid=841633&group_id=93… .... Win32 binaries are always binary relocatable, whereas Linux binaries often are not. Inkscape is typical in that it contains constructs of the form: open_file( INKSCAPE_GLADE_DIR "/foo.png" ) or whatever, ie the path to the binary is constructed at compile time, not runtime. In other words, it's source but not binary relocatable. A minimum requirement of software packaged using autopackage is that it must be binary relocatable. There are several use cases for why this is good - from people who want to install to their home directory (autopackage allows them to do this automatically), to people who ran out of space on / and added a new harddisk, to admins installing to network mountpoints. This is not so trivial on Linux because there is no equivalent to the Win32 GetModuleFileName() call. Fortunately, as part of developing autopackage we have written a simple C file that can be dropped into any program or library and used to determine the prefix at runtime. This file is Linux specific (it reads /proc) but it can be switched on/off automatically in the configure script. Ports to other platforms will be added as time goes by. binreloc, as we call it, is really easy to use. It redefines the standard macros, so you can replace: open( DATA_DIR "/foo.png" ); with open( DATA_DIR("/foo.png") ); That's it! TLS slots are used to ensure there are no memory leaks. You already need to remove hard-coded prefixes like that from the code for the Win32 port to be really robust. At the same time, it can be done for Linux. If you aren't wanting to do this straight away, I might be able to write a patch to do it using binreloc. I also hack on Wine (my other project) so hopefully making it work for Win32 as well wouldn't be too hard. Q: But GTKmm is already packaged for Fedora and Debian. Users will want to use them, not the autopackage versions! A: Sure, we know that. At the moment autopackage can only fulfil missing dependencies using its own packages. In the 0.6/0.7 timeframe we want to add support for at minimum apt, and probably also yum and maybe urpmi so users will get the packages designed specifically for their distro instead of the generic ones. Q: What about GTK 2.2 vs GTK 2.0? A: Yeah, maybe. We're kind of reluctant to package GTK itself as that's really the distributors job - GTK is a core OS component these days. Linux is moving so fast at the moment that to be able to use new software I think it's reasonable to expect people to be upgrading their distros. Supporting one previous version is probably OK, supporting a year old distro is pushing things a bit. Still, there's no theoretical reason why we can't build GTK autopackages if the demand is there. Most people would want to at least wait until we integrate better with RPM before upgrading their system like that. If you have other questions about autopackage specifically, then see the autopackage FAQ: http://www.autopackage.org/faq.html In summary, my proposal is simple: * You continue the original plan of using GTKmm and reap the productivity benefits. Murray is chatting to the fink guys, so hopefully MacOS X worries should soon be dealt with. * We build Linux distro-neutral packages of Inkscape and GTKmm for the autopackage 0.5 milestone. We host them on our servers. * You link to them from your website. This lets people who don't have GTKmm packages available natively for their distro install Inkscape binaries anyway. * We maintain them until autopackage reaches version 1. At this point we don't want to maintain packages anymore, and will be pushing out all the specfiles we were testing with to the community and maintainers. At this point you can decide whether the test packages were popular enough to warrant continuing with autopackage. Apologies for the overlong email, but I wanted you guys to have some context. What do you think? thanks -mike

3 7

Request breaking CVS lock
by Peter Moulder 12 Jan '04

12 Jan '04

A cvs -d ':ext:pjrm@...54...:/cvsroot/inkscape' admin -ko many-files... command segfaulted, apparently leaving locks in place. According to *see (cvs)Concurrency: If a lock seems to stick around for an undue amount of time, find the person holding the lock and ask them about the cvs command they are running. If they aren't running a cvs command, look in the repository directory mentioned in the message and remove files which they own whose names start with `#cvs.rfl', `#cvs.wfl', or `#cvs.lock'. Can you please remove all such files owned by pjrm (me) in inkscape's CVS repository? Thanks, pjrm.

1 1