August 2007 - Inkscape Devel - Inkscape Mailman

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

Additions to node creation
by Pierre-Luc Auclair 07 Aug '07

07 Aug '07

Hi, These are features I've been wanting since I've switched from Illustrator. I call this feature set "non-linear node creation". Here they are: - Ctrl-click on nodes and node handles like in editing to change the node type - Moving nodes and node handles after they've been created - Moving nodes while click-creating new nodes. Explanation: When you click to make a node and drag the handles, you would press a key to drag the node center. This is behaviour copied from Illustrator's If it might accommodate any of you, I'd be ready to give a small bounty for it I was thinking about something like 50 - 70 euros. Don't know if it's realistic -- I'm probably gonna pass as a tightwad but that's all I can manage right now. Any suggestion, comments, just reply on the list. Thanks! Pierre-Luc

2 2

Bug in node editing
by Pierre-Luc Auclair 06 Aug '07

06 Aug '07

I've found a bug in the node editing, when you ctrl-click on a node handle to remove it it leaves something that looks like a corner node, but when you move the remaining handle it switches back to a curve. Vidcap: http://www.heliosmulti.com/corner-bug.mpeg Pierre-Luc

1 0

revision 15670 bug
by Felipe Sanches 06 Aug '07

06 Aug '07

revision 15670 introduced a bug: When you open inkscape you can se a little blue square. I have compiled both 15669 and 15670 to verify that it is indeed 15670 that introduces this issue. JucaBlues

2 1

TinyScheme and GIMP
by Ted Gould 06 Aug '07

06 Aug '07

Hello, On the Inkscape project we received a patch from the folks at Glimmer labs which adds Scheme functionality. It uses the TinyScheme interpreter which looks like it's also being used by GIMP. From what I can tell, it seems that GIMP is including TinyScheme in the source tree. Is that your long term plan? Do you expect TinyScheme to be an external library at some point? If we were using it in Inkscape also, would that change the answer? Is your TinyScheme patched for UTF-8? Thanks, Ted

1 0

Re: [Inkscape-devel] Window Manager Modifiers
by jiho 06 Aug '07

06 Aug '07

On 2007-August-05 , at 00:13 , Carsten Haitzler (The Rasterman) wrote: > On Sat, 4 Aug 2007 18:51:10 +0200 jiho <jo.irisson@...400...> babbled: >> First of all, it was not my intention to start a flame war or >> anything. It is just my personal opinion that what lacks the more >> cruelly to Linux desktop currently is consistency and keybindings is >> one particularly clear example. I hoped that mentioning it on this >> list, where the problem is regularly brought up, would get the ball >> rolling to the correct people (be they freedesktop or someone else). >> Anyway, I happily use Mac OS X (where keybindings are quite >> consistent and can be edited easily anyway) and won't "fight" for >> linux to get better... I just hope it will, because I like the >> development model more ;-) > > here's the problem. in windows or OSX - you have no CHOICE. you get > your "wm" > with the bindings it comes with - and that's it. sure - some of > these bindings > can be changed - and that is no different to x11 and window > managers -the > difference being there is not just 1 wm. there are many - with many > many many > different features, ideas and design goals. they will all probably > have > different needs for bindings based on these features. asking every > wm to NOT > use some modifier or to all use exactly the same isn't going to > happen - Actually, this is what I hope will happen ;) I don't think everything can work with everything else if there is not at least a little planning done ahead. This kind of planning is done for each program but currently independently because most are managed by different teams. It would be good to have this done at a little higher level, for the purpose of unification. I think this can be compared with document formats: of course every word processing software could work with its own, custom made format but wouldn't it be better if all used odt? I think it would. Of course the point is not to force every WM to do change its keybindings but I think it wouldn't hurt to have a standard defined, for interoperability and best usability, and then projects who care can adopt it. FreeDektop seems to be the right organization to define such a standard and, in my opinion, this standard should be "use META, and combinations of META with other modifiers, for all WM/ desktop level keyboard shortcuts" for the reasons I explained in my previous email. JiHO --- http://jo.irisson.free.fr/

1 0

Window Manager Modifiers
by Ted Gould 05 Aug '07

05 Aug '07

Hello all, In the Inkscape project we're constantly butting up against the problem where there simply aren't enough modifiers for everything we'd like to implement. This means for most of our tools there is a constant battle to figure out how we can fit everything into Alt, Ctrl and Shift. We manage. But, many window managers are using alt click to drag windows which takes 1/3 of our options away. There are lots of solutions to this, I'm curious which way makes sense to people. - Applications could start using the "Meta" key. I don't like this because it seems to be something that is rather machine specific. I don't think applications should be using this modifier. - There is some Freedesktop spec that says Window Managers should only use the meta modifier for their actions. - Somewhere there is a spec that allows a window manager hint to be set by applications to say "I'd really like Alt, please!!!" - Some users don't get functionality out of some apps unless they reconfigure the apps or their desktop. My personal favorite here is "2" -- I think that the Meta key could be turned into the "desktop" key where other desktop actions could be assigned to it also. --Ted

6 8

Adding more tags to svg files
by Kent Tenney 04 Aug '07

04 Aug '07

Howdy, A bit of fiddling leads me to believe that it's ok to add tags to Inkscape's top level <svg> tag. Inkscape seems to assign them an id and then ignore them. Is this correct? Is there danger of other svg applications discarding unknown tags, or Inkscape doing this in the future? Thanks, Kent

2 1

Re: [Inkscape-devel] [Inkscape-cvs] SF.net SVN: inkscape: [15640] inkscape/trunk/src
by MenTaLguY 04 Aug '07

04 Aug '07

Hi, this commit broke the trunk build, as some required files were not added. Please also commit src/display/nr-filter-component-transfer.cpp src/display/nr-filter-component-transfer.h (and anything else missing) as soon as possible! Thanks, -mental On Fri, 2007-08-03 at 21:18 -0700, jucablues@...58... wrote: > Revision: 15640 > http://inkscape.svn.sourceforge.net/inkscape/?rev=15640&view=rev > Author: jucablues > Date: 2007-08-03 21:18:36 -0700 (Fri, 03 Aug 2007) > > Log Message: > ----------- > boilerplate code for the remaining filters. My next commits will > probably deal with setting default attribute values for these filters > > Modified Paths: > -------------- > inkscape/trunk/src/display/Makefile_insert > inkscape/trunk/src/display/nr-filter.cpp > inkscape/trunk/src/sp-fecolormatrix.cpp > inkscape/trunk/src/sp-fecolormatrix.h > inkscape/trunk/src/sp-feflood.cpp > inkscape/trunk/src/sp-feflood.h > inkscape/trunk/src/sp-femorphology.cpp > inkscape/trunk/src/sp-femorphology.h > > Added Paths: > ----------- > inkscape/trunk/src/display/nr-filter-colormatrix.cpp > inkscape/trunk/src/display/nr-filter-colormatrix.h > inkscape/trunk/src/display/nr-filter-flood.cpp > inkscape/trunk/src/display/nr-filter-flood.h > inkscape/trunk/src/display/nr-filter-morphology.cpp > inkscape/trunk/src/display/nr-filter-morphology.h > > > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Inkscape-cvs mailing list > Inkscape-cvs(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-cvs

1 0