- Inkscape Devel - Inkscape Mailman

Mingw-gcc 4.2.1
by Bob Jamison 09 Aug '07

09 Aug '07

Hi, everyone, I just noticed that Danny Smith uploaded test versions of gcc-4.2.1 built for Mingw32. These are a bit more "official" than the builds that I uploaded, so anyone having trouble currently (like relocatability) might want to try these. https://sourceforge.net/project/showfiles.php?group_id=2435 Look for "GCC Version 4," and we are currently using the "setjump/longjump" exception model (sjlj), so you would want these: http://downloads.sourceforge.net/mingw/gcc-core-4.2.1-sjlj-1.tar.gz2 http://downloads.sourceforge.net/mingw/gcc-g%2B%2B-4.2.1-sjlj-1.tar.gz2 Hopefully Danny will soon let the Dwarf (dw) model be the default, but all of our libraries are built with sjlj, so if you use dw now, it won't link. bob

1 0

updating filters
by Felipe Sanches 09 Aug '07

09 Aug '07

hi, Nicholas! for some reason, some controls doesnt update automatically when applied to imported images. But they update on other kinds of objects. See for example, feColorMatrix. Juca PS: colormatrix values should be stored for each of the possible types. It is not good to store all of them in a single variable. It would be much better if the user could adjust the value for one type, then change type and readjust value, and then change its mind again (maybe feeling that the previous type and value were better) and when he selects back the previous type he should see the respective old value still there.

2 1

Scheme Scripting Console
by Glimmer Labs 08 Aug '07

08 Aug '07

We have developed a feature which allows Scheme Scripting from a console inside of Inkscape. We chose to implement a Scheme interpreter inside Inkscape because we felt higher-order programming and other functional paradigm ideas of Scheme would apply very nicely to a vector-based program such as Inkscape. The tar file included at the directory below contains a README with directions to aid in the process of installing the patch contained in the tar file. The README also has instructions on running the console. http://www.cs.grin.edu/~dangelod/scheme-patch.tar.gz Please let us know what you think of it. This patch was tested with revision 15458. If there is a better place to submit this patch since it is pretty large, let us know. Thanks, David D'Angelo and Soren Berg glimmer07@...400...

4 11

Let's talk about text
by Ted Gould 08 Aug '07

08 Aug '07

Hey, I don't know how many people saw this, but I thought it might be of general interest as it seems text is always an issue. Apparently there was a "text summit" in Glasgow as a part of aKademy. A report from the KDE folks: http://dot.kde.org/1186422013/ Which sounds interesting, but I hope we'll never have to directly deal with "languages not yet in Unicode." And, I think that Pango will do most of it for us. One of the links that I found interesting was to Fontima -- which is looking to define a font manager and widgets for the free desktop. Dealing with all the naming nastyness we've discussed before. http://eyegene.ophthy.med.umich.edu/interview/fontima.php I'm not sure how real it is, but it might have some interesting ideas in it. --Ted

1 0

Alt-mouse - an RFC
by Thomas Worthington 08 Aug '07

08 Aug '07

Okay, I've checked the source code out and had a quick look at it with an eye to doing something about the Alt-mouse issue on Linux. There are currently only 50 hardwired references to GDK_MOD1_MASK in the whole source tree (over 21 .ccp and .h files). Two options spring to mind: 1 Define a new global, ALT_KEY_MASK (say) and default it at run-time to the value of GDK_MOD1_MASK unless the user sets it to another value in their shortcut file, then do a simple search and replace for all occurances of GDK_MOD1_MASK. This would mean that the user's choice to treat something else as Alt (presumably Meta) would be global and not only for the mouse combinations. This would at least be consistant for that user and also for developers who would simply use the new global ALT_KEY_MASK everywhere they would previously have used GDK_MOD1_MASK. 2 Alternatively we could be more selective about the replacement so that only mouse combinations would be affected. This would mean that developers working on items not involved in the question of Alt+mouse need never bother about it but it would mean that a user who opted to change the Alt key would be faced with some functions where it was still Alt and others where it was now whatever they had picked instead. There's also the issue of the hint text. In the former case there is some justification for not altering it and just letting a user who's made the decision to change live with the fact that the hint text still says "Alt", but in the second case the functions modified would really have to be changed (and changed back if they undo the key mapping). At the moment I'm enjoying being able to easily use node sculpting using Meta-mouse and am very happy to continue on to impliment option 1 but obviously it affects more files which might make others unhappy. This is a list of the files GDK_MOD1_MASK appears in (and the number of occurances in each): ./src/dialogs/xml-tree.cpp:1 ./src/helper/window.cpp:1 ./src/ui/dialog/dialog.cpp:1 ./src/ui/view/edit-widget.cpp:1 ./src/box3d-context.cpp:1 ./src/gradient-context.cpp:2 ./src/flood-context.cpp:1 ./src/dropper-context.cpp:1 ./src/gradient-drag.cpp:3 ./src/connector-context.cpp:1 ./src/seltrans.cpp:3 ./src/event-context.cpp:1 ./src/select-context.cpp:8 ./src/rect-context.cpp:1 ./src/dyna-draw-context.cpp:3 ./src/object-edit.cpp:7 ./src/context-fns.cpp:1 ./src/nodepath.cpp:4 ./src/node-context.cpp:2 ./src/macros.h:4 ./src/modifier-fns.h:4 What does everyone think? This would shift the responsibility for how to cope with the mouse squarly onto the user's shoulders. S/he would have the option to stick with the "official" shortcuts and modify their WM or to consciously select a different keyboard mod value. Developers can then forget about the issue. Now the caveat: I'm not a C++ programmer, although I've been programming for 29 years so I'm not a newbie. Be that as it may, I might be totally misunderstanding how deeply this change would affect the project so more experienced heads need to tell me if I'm barking up the wrong tree before I start chopping it down. And on that mixed metaphor I shall conclude. Thanks, Thomas Worthington

2 3

file saving broken?
by bulia byak 08 Aug '07

08 Aug '07

After the recent OCAL commit, I cannot save a newly created file: ** (inkscape:15918): WARNING **: Could not find the temp saving. ** (inkscape:15918): WARNING **: Error: Could not save file '/home/bb/aaa.svg' with VFS Please fix this ASAP, and please better test before you commit! -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 3

Help with makefile troubles
by Johan Engelen 08 Aug '07

08 Aug '07

Hello 'scapers, I have been fiddling with a problem way too long now, I am hoping one of you can help. :-( I want to get a local copy of 2geom in the inkscape directory, and use that to build. This is now committed to the live-path-effects branch. It builds fine on windows, however I cannot get it to build on Linux. The 2geom directory is compiled (I see .o files) and the library is also created ('lib2geom.a'). But... for some reason, the linker cannot locate some 2geom symbols. For example I get the build error: /home/johan/inkscapelpe/src/./2geom/path.h:344: undefined reference to `Geom::Path::delete_range(__gnu_cxx::__normal_iterator<Geom::Curve**, std::vector<Geom::Curve*, std::allocator<Geom::Curve*> > >, __gnu_cxx::__normal_iterator<Geom::Curve**, std::vector<Geom::Curve*, std::allocator<Geom::Curve*> > >)' When I run: nm ./src/2geom/lib2geom.a -C -g --defined-only I do get : 00000150 T Geom::Path::delete_range(__gnu_cxx::__normal_iterator<Geom::Curve**, std::vector<Geom::Curve*, std::allocator<Geom::Curve*> > >, __gnu_cxx::__normal_iterator<Geom::Curve**, std::vector<Geom::Curve*, std::allocator<Geom::Curve*> > >) The link command = g++ -Wall -Wformat-security -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -D_FORTIFY_SOURCE=2 -Wno-unused-parameter -g -O2 -o inkscape --export-dynamic main.o libinkpre.a 2geom/lib2geom.a application/libinkapp.a ui/dialog/libuidialog.a .... etcetera So it includes the lib with the symbol in it. Still it gives that error. Possible pointer to a solution: for some reason, 2geom is mentioned twice in /src/Makefile causing some warnings about overriding the old commands. I do not see why 2geom is put twice into this file. Could someone please have a look at building my branch on Linux? Thank you very very much, Johan

1 0

Tweak Tool
by Josh Andler 08 Aug '07

08 Aug '07

Bulia, As always, there was silence before the storm. ;-) Great new tool! I have a couple Qs. 1) Do you have plans for pressure/tilt support? If not, would you be opposed to toggles like the calligraphy tool? I know that I would personally find it to be greatly useful to have that interaction. 2) Are there plans for any other modes currently? If not, is there opposition to others adding them? I'm just thinking along the lines of a couple of the tools AI has, such as the twirl one. And, also as always... once I have more than a quick demo session to go on, more praise will follow. :-) -Josh

1 0

fedisplacementmap render
by Felipe Sanches 08 Aug '07

08 Aug '07

hi, kiirala, could you please take a look at this code? It is an attempt to fix the current displacement map render implementation. I am not sure whether I am dealing with the in and out buffers the proper way. The problem is that I need to handle buffers with different sizes. (dont know why, this code segfaults) Juca /* * feDisplacementMap filter primitive renderer * * Authors: * Felipe Corrêa da Silva Sanches <felipe.sanches@...400...> * * Copyright (C) 2007 authors * * Released under GNU GPL, read the file 'COPYING' for more information */ #include "display/nr-filter-displacement-map.h" #include "display/nr-filter-types.h" #include "libnr/nr-pixops.h" namespace NR { FilterDisplacementMap::FilterDisplacementMap() : scale(0), _input2(NR_FILTER_SLOT_NOT_SET), Xchannel(3), Ychannel(3) {} FilterPrimitive * FilterDisplacementMap::create() { return new FilterDisplacementMap(); } FilterDisplacementMap::~FilterDisplacementMap() {} int FilterDisplacementMap::render(FilterSlot &slot, Matrix const &trans) { g_warning("FIX-ME: FilterDisplacementMap::render method is still a bit buggy. Needs Love."); NRPixBlock *texture = slot.get(_input); NRPixBlock *map = slot.get(_input2); NRPixBlock *out = new NRPixBlock; // Bail out if either one of source images is missing if (!map || !texture) { g_warning("Missing source image for feDisplacementMap (map=%d texture=%d)", _input, _input2); return 1; } int x, y; int in_x0 = map->area.x0, in_y0 = map->area.x0; int in_x1 = map->area.x1, in_y1 = map->area.y1; int out_x0 = in_x0 + scale/2, out_y0 = in_y0 + scale/2; int out_x1 = in_x1 - scale/2, out_y1 = in_y1 - scale/2; int in_w = in_x1 - in_x0; int out_w = out_x1 - out_x0; double coordx, coordy; nr_pixblock_setup_fast(out, map->mode, out_x0, out_y0, out_x1, out_y1, true); unsigned char *map_data = NR_PIXBLOCK_PX(map); unsigned char *texture_data = NR_PIXBLOCK_PX(texture); unsigned char *out_data = NR_PIXBLOCK_PX(out); for (x = out_x0; x < out_x1; x++){ for (y = out_y0; y < out_y1; y++){ coordx = x-in_x0 + scale * ( ((double) map_data[4*((x-in_x0) + in_w*(y-in_y0)) + Xchannel])/255 - 0.5 ); coordy = y-in_y0 + scale * ( ((double) map_data[4*((x-in_x0) + in_w*(y-in_y0)) + Ychannel])/255 - 0.5 ); out_data[4*((x-out_x0) + out_w*(y-out_y0))] = texture_data[4*((int)coordx + ((int)coordy)*in_w)]; out_data[4*((x-out_x0) + out_w*(y-out_y0)) + 1] = texture_data[4*((int)coordx + ((int)coordy)*in_w) + 1]; out_data[4*((x-out_x0) + out_w*(y-out_y0)) + 2] = texture_data[4*((int)coordx + ((int)coordy)*in_w) + 2]; out_data[4*((x-out_x0) + out_w*(y-out_y0)) + 3] = texture_data[4*((int)coordx + ((int)coordy)*in_w) + 3]; } } out->empty = FALSE; slot.set(_output, out); return 0; } void FilterDisplacementMap::set_input(int slot) { _input = slot; } void FilterDisplacementMap::set_scale(double s) { scale = s; } void FilterDisplacementMap::set_input(int input, int slot) { if (input == 0) _input = slot; if (input == 1) _input2 = slot; } void FilterDisplacementMap::set_channel_selector(int s, int channel) { if (s == 0) Xchannel = channel; if (s == 1) Ychannel = channel; } void FilterDisplacementMap::area_enlarge(NRRectL &area, Matrix const &trans) { //I'm in doubt whether this affects all input buffers or only 'in' area.x0 -= (int)(scale/2); area.y0 -= (int)(scale/2); area.x1 += (int)(scale/2); area.y1 += (int)(scale/2); } } /* namespace NR */ /* Local Variables: mode:c++ c-file-style:"stroustrup" c-file-offsets:((innamespace . 0)(inline-open . 0)(case-label . +)) indent-tabs-mode:nil fill-column:99 End: */ // vim: filetype=cpp:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:encoding=utf-8:textwidth=99 :

1 0

filters UI
by bulia byak 08 Aug '07

08 Aug '07

The number of supported filters grows with every day, and I think we should rethink the UI a bit. The filters dialog developed by Nick is great and powerful, and of course must be there for those who know SVG and are comfortable with all the parameters. But for the rest of us, there must be a simpler way to access the filters. So far such a "simpler way" only exists for blur and blend modes, in the Fill and Stroke dialog. But of course we can't cram all filters there, nor do we need to, because most others are more obscure and less useful. So, what if we just add a whole new menu for SVG filters that would largely contain a list of preconfigured filters that can be applied by a single verb (command), without any setup dialog. These presets may include single filters with some meaningful parameters (perhaps depending on the selected object's properties in some way), perhaps even several different presets for a filter (e.g. Sharpen, Sharpen more, Sharpen a lot etc). Other presets may be often-used combinations of filters, such as Drop shadow. Each such command adds its filter(s) to the top of the filter stack on selected objects. This way the most common filters can be accessed quickly, and users will even be able to assign keyboard shortcuts to them. Apart from the presets, the menu would have commands "Remove last filter," "Remove all filters," and of course the command to open Nick's filters dialog which is where the parameters of the added filters can be adjusted if needed. What do you think? -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

12 30