- Inkscape Devel - Inkscape Mailman

Problem with the GTK file selector in KDE
by Arpad Biro 26 Apr '04

26 Apr '04

Hi, I noticed the following problem when using Inkscape in KDE: if you open a file selector dialog (Open, Save As, ...) and switch to another task without closing this dialog, then you will not be able to switch back to this Inkscape instance, so you will sooner or later need to kill it. The same happens if you move the file selector dialog to another virtual desktop: you will not see the dialog again, so you will not be able to close it. This does not happen in GNOME, nor does it happen with other Inkscape dialogs under KDE. Other GTK apps I tested (Gedit, Gnumeric, GnoZip) do not have this problem even under KDE. My versions are: GTK 2.2.4, Qt 3.2.3, GNOME 2.4, KDE 3.2 Arpad Biro __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25� http://photos.yahoo.com/ph/print_splash

2 1

Clones tamed
by bulia byak 26 Apr '04

26 Apr '04

I just checked in a change to the clones code which allows you to select how a clone reacts when its original is moved. In the Inkscape Preferences dialog, Misc tab, you can choose between: - Moves in parallel: Clone is translated by the same vector as its original. - Stays unmoved: Clone preserves its position when its original is moved. - Moves according to transform: Clone moves according to the value of its transform= attribute. For example, a rotated clone will move in a different direction than its original. Until now, the last of the three options was the only possible one. Now the default is the "moves in parallel" option. This makes handling clones much more intuitive and convenient in design. _________________________________________________________________ Watch LIVE baseball games on your computer with MLB.TV, included with MSN Premium! http://join.msn.com/?page=features/mlb&pgmarket=en-us/go/onm00200439ave/dir…

1 0

pangoization
by MenTaLguY 25 Apr '04

25 Apr '04

Well, while this release cycle is supposed to be focused on pangoization, we've not really done much work on that yet, so I've been thinking about where to start... At this point I think the plan looks like this: 1. C++ify libnrtype (completely) 2. Introduce a pango libnrtype backend 3. get the pango backend debugged on all platforms and switch to using it exclusively 4. refactor libnrtype away, bringing pango "to the surface" 5. Investigate using Pango in other areas, like <text> layout One motivation for the C++ification is because, while it's a significant project in its own right, it is much easier to create and refactor C++ classes than GObject/NRObject ones. Another advantage is that it'll get everyone involved more familiar with the code. So, anyway ... Nathan's already done some of the preliminary work on libnrtype. I think the next step switching from aggregation to C++ inheritance. (which simply means that this: struct NRSomething { NRSomethingBase base; ... }; becomes this: struct NRSomething : public NRSomethingBase { ... }; ...and no other changes should be necessary at that step) Any volunteers? I'll start hitting this myself once I get through with the SPSelection cleanup. -mental

2 2

RE: [Inkscape-devel] Problem with the GTK file selector in KDE
by bulia byak 25 Apr '04

25 Apr '04

>This does not happen in GNOME, nor does it happen with other Inkscape >dialogs under KDE. It also does not happen in KDE 3.1.3 which is why I did not catch it. See discussion here: http://sourceforge.net/tracker/index.php?func=detail&aid=938123&group_id=93… Please try the solution discussed there and report your results in a comment. _________________________________________________________________ STOP MORE SPAM with the MSN Premium and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

selection NULLness
by Carl Hetherington 25 Apr '04

25 Apr '04

Hi, While doing some SPSelection OO-ification I have noticed that there seems to be some confusion in the code about whether desktop->selection is ever NULL in normal operation. Anyone got any clues? Basically I think this dictates whether desktop->selection should be g_assert()ed non-NULL or assumed empty if it's NULL. The same confusion arises in other places where a SPSelection* is held. Personally, I'd favour the convention that all SPSelection* in structs are assumed to be non-NULL. Thanks Carl

2 2

CVS file permissions
by Arpad Biro 24 Apr '04

24 Apr '04

Hi, I committed a new file (tutorial-basic.fr.svg) to the CVS, but after committing I realized that the file permissions only allow root to read the file: -rw------- 1 root root 230925 apr 23 21:20 tutorial-basic.fr.svg So my question is: after a chmod + commit, will the permissions of the file in CVS change appropriately? Arpad Biro __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25� http://photos.yahoo.com/ph/print_splash

2 1

Adding a new tutorial
by Arpad Biro 24 Apr '04

24 Apr '04

Hi, Now that tutorial-basic.fr.svg is added, does share/tutorials/Makefile.am need to be modified? Arpad Biro __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25� http://photos.yahoo.com/ph/print_splash

2 2

Re: [Inkscape-devel] Re: Clone command
by bulia byak 24 Apr '04

24 Apr '04

>Yes that would make sense as default, but there should still be a key for >producing duplicates instead of clones (like when you want to copy a draft >that you want to change in different ways) Yes. >Is this behavior optional? I could think of many use cases where one only >wants the shape to be in sync, not the placement. It's not optional in SVG, but we can try to work around that. I will look into it. >But maybe a user could put the originals on a special layer that is locked >and invisible and thus have the same functionality? That would prevent you from changing the original's shape too. SVG has no provisions for linking shape and not linking position. _________________________________________________________________ Add photos to your e-mail with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

3 2

ill2svg.pl
by Ted Gould 24 Apr '04

24 Apr '04

Hey, I think someone modified this script a while ago - I can't figure out who because it has been moved in CVS :( So, I'm just posting a general message. I think that the goal was to remove the platform specific line endings method that is used. Unfortunately, that didn't work for Illustrator files created on a Mac. I backed out the changes and applied a patch that was posted to the Sodipodi list which does text. I've also attached a Mac Illustrator file to the RFE for this feature. If the mystery person who tried to fix this before could fix it again that would be really cool :) http://sourceforge.net/tracker/?func=detail&aid=895489&group_id=93438&atid=… --Ted

1 0

non-recursive makefile: last chance for objections
by Peter Moulder 24 Apr '04

24 Apr '04

Proposal: Switch to a single makefile in src/ that includes all the stuff previously in src/**/Makefile.am. Top-level makefile continues to be recursive make. This simplifies data installation, and the benefits of changing aren't much for directories outside of src/**. Use automake's `include' directive on blah/Makefile_insert. Most existing blah/Makefile.am content goes to blah/Makefile_insert, e.g. blah_libblah_a_{CPPFLAGS,SOURCES,LDFLAGS,LDADD}. Some "global" variable definitions move to src/Makefile.am: noinst_LIBRARIES, DISTCLEANFILES, EXTRA_DIST, EXTRA_PROGRAMS, TESTS, check_PROGRAMS. INCLUDES/AM_CPPFLAGS become e.g. blah_libblah_a_CPPFLAGS (i.e. per-target instead of per-directory). "Local" variable definitions (e.g. used for conditional compilation, e.g. win32_sources) go in src/blah/Makefile_insert, and acquire a `blah_' prefix. (The win32_sources variable from src/Makefile.am goes to src/Makefile_insert with no added prefix.) src/Makefile.am contains: + include blah/Makefile_insert + Definitions for the aforementioned "global" variables. + dist-hook rule. Advantages: + Can depend on things from other directories. E.g. some files in display/ depend on helper/sp-marshal.h having been built, and various */*-test programs depend on libraries in other directories (previously hacked with a `check-recursive: all-recursive' dependency in src/Makefile.am). + Compilation is expected to be faster: - Fewer invocations of automake and make. - Better parallelization is possible with make -j / make -l (e.g. when using distcc). However, making CPPFLAGS per-target means much longer generated Makefile content. I haven't yet done timing tests (underway). Disadvantages: + All files mentioned in the makefile fragments need to specify their directory. E.g. if blah/Makefile.am used to contain libblah_a_SOURCES = \ foo.cpp foo.h then blah/Makefile_insert will now contain blah_libblah_a_SOURCES = \ blah/foo.cpp \ blah/foo.h Any other advantages/disadvantages? Checks to be done before switching: + `make install' creates same directory tree. - Done. Some differences in the inkscape/inkview executable files, all other files bytewise-identical. + `make check' works. - Done. Works. Hmm, haven't checked that all expected checks are getting run. + `make check' works immediately after `make clean'. - Not yet checked. + `make distcheck' works. - Not yet checked. Any other checks to be done? pjrm.

4 8