- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] extract node subset??
by Valerie 03 Apr '12

03 Apr '12

You'll probably have to duplicate everything and delete the parts you don't need... On this occasion, I realized that "inverting" the selection won't select nodes on other, non-joined segments, so you'll have to select them the hard way. I see what you mean though. Right now, if you have a combined path and select+copy one part, pasting would paste the whole combined path rather than that one section. I guess the issue here is that nodes aren't free-floating objects to copy/paste, so if you copy/paste non-continuous nodes then it wouldn't make sense. It could be an interesting feature though: - If you select several nodes on a continuous path and copy/paste them, you get a new continuous path with those same nodes (but without the uncopied nodes) and the same handle values (?) as those nodes. - The process repeats for all segments of paths selected - If for one continuous path, only a single node is selected, then nothing happens. It could be called "paste segment" or the likes.

2 1

pdf importing
by Alexandre Prokoudine 02 Apr '12

02 Apr '12

Hi, Just FYI, poppler 0.19.x supports color management via LittleCMS v2. Didn't we want color managed PDF importing at some point? :) Alexandre Prokoudine http://libregraphicsworld.org

6 8

GSoC Mentors
by Josh Andler 02 Apr '12

02 Apr '12

Hey All, Anyone wishing to be a mentor for this year's GSoC should either login to melange or sign up and request to be a mentor. Note, if you do not have familiarity with the codebase and are not a code contributor, you do not qualify. http://google-melange.appspot.com/gsoc/org/google/gsoc2012/inkscape Cheers, Josh

1 0

Re: [Inkscape-devel] Google Summer of Code 2012
by Yevgeny Lezhnin 02 Apr '12

02 Apr '12

Hello, I'm Yevgeny Lezhnin. I wish to submit to inkscape in gsoc 2012. I know c++ and can work with gtk+. I think I know how to make 'new from template' dialog: I can change menu entries in menus-skeleton.h verbs.cpp gdl-dock-bar.c gdl-switcher.c , and add new dialog source to dialogs folder. But I'm also interested in better svg standard coverage. I used inkscape for drawing diagrams in svg format, but there was some compatibility problems in firefox browser. And another thing: is there any good bug for gtk+ interface developer?

3 8

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 01 Apr '12

01 Apr '12

> For me, this is beginning to feel natural. Sounds like a start, at least! > I think to some degree Josh's comment still applies. There are at least > two different toolbars and some dialogs. As a start I think it should be > possible to eliminate the edit mode toolbar. True, now that I look at it, my current toolbar is empty enough to combine the two. Previously I had separate toolbars because each guide type had guide-specific options (like arc guides for radial tiling, and numerical fields). And yes, I should add an unclump. As things stand I think I'll just leave all the numericals inputs to the Transform and Edit Paths tools. And snapping. Users can just snap to something if they need. Instead, here's how I propose the tiling tool to work. On-canvas, by default you will have a render frame with a base tile: - When using the tiling mode, you can click on the center tile to make handles appear, and from there, modify the handles (who become invisible when not using the tiling tool). - Clicking and dragging the corners of the frame with the tiling tool will add frames to it. You can also shift-drag so new tiles will be created on edges you drag over, or ctrl-shift-drag to delete. - You cannot resize, rotate or move the center tile or the render frame with the tiling tool, but you Can do so with the Transform tool. You can't do those operations from the circle or spiral tools either, so interface-wise the users should be able to get used to it. - As with circles and spirals, double-clicking a center tile or render frame opens up the tiling tool anyway. I was also thinking of imposing some limitations: 1. No skewing for the center tile, even though P1 and P2 allows for those. The reason is that this would allow users to more easily switch to other symmetries with rectangular tiles. Even if the user's tile design is a skewed rectangle, it's not like they need the base tile to be one anyway. 2. I'm thinking of eliminating the rotation centers and force the users to directly choose say... a P3 guide if that's what he wants. Some handle options may still be available outside of the rectangle guides, but the general shape cannot be changed. The reasoning is: just how desperately does one need to change from P1 to P3 anyway? It may be fun to experiment but it will get confusing fast, and designs for very differently shaped tiles will probably be different too. > This sounds like a good idea. If I understand correctly your idea is to > allow transforming a single tile and then "propagating" that transform > to other tiles in such a way that starting from the original/central tile > there is a gradual change in the transformation. I had typed a long list of questions regarding interpolation with some cluttered thoughts regarding the interface, then I saw Veronika's suggestion: > I wonder if the dynamics could be considered as something separate > from cloned tiles and could be applied to any selection of objects. Somehow I think this is simpler too. :S Any objections to treating the features separately? > Oh, btw, make sure that "in the end", there is a blueprint or something > on your proposal (which can link to the Wiki page for example), as it > might take some time to come to an implementation, and it would > be ashame if it was "forgotten". No problem. I always did intend to make one. But I wanted to make sure that I got to a point where people browsing the blueprints section wouldn't be wondering why said blueprint is redone from scratch every few weeks (as in, at the very least, the general concept should be stable). And yes, I'm thinking of implementation order too. The pity about the current design is that it isn't as modular as my previous one, but oh well. > Tenacity is worth ten times more than smarts, we can get to the > best practical design through discussion and the great critiques. It also feels like it's taking ten times longer, and I'm starting to miss my other hobbies, but thanks for the encouragement. x)

7 12

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 31 Mar '12

31 Mar '12

I'm a bit confused about the title now... Are the "New dynamics interface proposal" discussions about a completely different tool, or about the dynamics for the tiling tool? By the way, Veronika, I keep losing the link to your list of tilings picture (because I delete nearly everything and copy entire new chunks of description each time I update with a completely new version) Could you perhaps upload it to the Inkscape wiki? Anyway, I updated the wiki with the latest iteration for the tiling tool: http://wiki.inkscape.org/wiki/index.php/Tiling_tool I've also added the "implementation steps." At this point, can everybody take a look and see if they agree with the "core" interface (meaning base tile + render frame at least, dynamics are still wip)? If so, I can already put up the page as a blueprint so anybody interested can get started (a lot of steps are still needed before reaching on-canvas dynamics editing...) Should I add a table to note what parts of the feature are accepted designs, what parts are still under discussion? Back to dynamics: > http://www.tomlechner.com/randompics/finishing.png I was confused for a while, but after a better look I do really like the interface! The term "wubwub" made me laugh. There should be a way to choose and see which wubwub does what, and a way to set the value back to zero. Double-click to add a corresponding wub-wub? (since users are unlikely to need jittering Everything at the same time) Of course the problem is still how all this will be programmed. Since you made that awesome alignment tool, I've no doubt that someone like you can pull off a tool like this, but I'm not sure the average volunteer student for inkscape could program this type of interface. And we also face the problem of how to integrate this with the existing mechanism. Now, I know nothing about programming. Has anyone looked at the tiling dialogue code yet to see how hard it'd be to mess around a bit with it? Possibilities to add extra stops etc. even? Replacing the opacity/blur/color mechanism with a gradient-like approach? Right now the two possibilities for on-canvas tile editing are still: 1. Drag a tile, all the other tiles get updated dynamically 2. Drag a tile, a ghost copy gets created, but the other tiles stay in place (Tom's proposal, and probably easier to handle than an interface where All the tiles are jumping around, preview value or not) I'd kind of like it if we can decided once and for all whether to use the first or second approach though. So, any opinions?

1 0

Google Summer of Code 2012 [C++ification]
by zcgucas 30 Mar '12

30 Mar '12

Hi, guys, I am Cheng Zhang, a student from graduate university of Chinese Academy of Sciences. I'd like to apply inkscape's project for GSOC 2012. I have been do some works following the instruction of inkscape's wiki page for GSOC 2012. And I have fixed two easy-fix bugs and attached my patches to the comment(Bug #561503 , Bug #941597 ). I am very glad one of them is already been applied. I am interesting in doing the C++ification job as my proposal for GSOC 2012. Actually I have already understand how important this work is deeply during these days' work on bug fixing. At first, I downloaded some very old codes of inkscape from sourceforge which may stop maintain for one year or more. Though I managed to compile and get it run on my system, I find it too hard to understand. That's why I have spent almost two days to locate lines that lead Bug #941597. In that version of source code, those lines lead the bug are in a file named "nr-arena-glyph.cpp" which is a c/c++ mixed style code file. Though it is easy to know those lines are in this file, I totally lost my direction while I want to understand how those "render"/"update" stuffs work. What's worse, if I want to know how they work, I need to know how the "arena item's" parent to get rendered or updated. But these codes are written mostly in C style and use a tricky way to enable code could work just like C++ codes do. I have to say the tricky is very hard to understand even I have already understand it now. Later on, I learned to download the newest code from bzr and found "nr-arena-glyph.cpp" already disappeared and turned into "drawing-text.cpp" which is a standard C++ code file that is very easy to understand. That is also the reason why I could fix the second bug in half a day. This experience makes me understand that to make code more easy to understand is one of those important reasons to do C++ification work. I have went through the whole code files of the project and made a rough list about those files are still in c style which could do c++ification work. This is such a long list. As a gsoc proposal, I see it couldn't be to big especially for a guy who get in touch with inkscape for less than a week. So I may choose to do the SP context related C++ification work as my proposal. I know there may be something I don't see here in do C++ification work. So I am very glad to here any advice from you guys! Thanks! zcgucas

1 0

gsoc2012, Designing SVG fonts using styles
by Mikalaj Parafeniuk 30 Mar '12

30 Mar '12

Hello! My name is Mikalaj Parafeniuk. I'm a third-year computer science student of Belarussian State University of Informatics and Radioelectronics and I am rather confident with C++. I am interested in applying to google summer of code with project, which can be found here: https://blueprints.launchpad.net/inkscape/+spec/designing-svg-fonts-using-s…. But I have a set of questions: 1) Is the idea still actual and what priority does it has? 2) The proposed idea is rather raw, could someone give me more details? 3) Could you give me some starting points? I'm going to checkout inkscape sources. To what part of code should i pay attention?

2 1

clean development surroundings
by Drechsel Wolf 30 Mar '12

30 Mar '12

Hi everybody I tried again compiling inkscape aqua on Mac OS X - one minor goal was to update the wiki on that topic. I made some mistakes which led to compiling errors. Now I wanted to give it a new go - but ended up with errors again allthough the environment should be o.k. I made a 'make clean' in the sources dir - but that seems not to clean up the environment enough. What elso should I do a ensure that I really have a fresh set of sources which will do the job? Thanks and greetings, Wolf

2 1

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 30 Mar '12

30 Mar '12

> I'm not sure that it makes sense to have the transformations symmetrical > around the base tile. The reason is because it's easy to just extend the frame in just one direction, but a pain to have to have to make identical handles in all directions. It's for designs where the user wants something to fade in all directions, for example. ... tiling of gradients? D: > As for the interface for actually adjusting the transforms (as well > as opacity and such). Is it necessary to do it with "tiles" shown > on screen, or would it suffice to allow transforming actual tiled > clones? Hm... actually, live preview of just the tiles could work? In that case, the handle will have to be the tiles themselves. (option 1 of my three suggestions). You have a point about jitters. I don't think small amount of jitters would affect things much, but it's true that some users may want to make larger amounts of jitters. > In general, I think the system is very interesting, but I would be > interested in making it a bit "leaner". After all, someone has to > implement it, and (more importantly), a lot of someone's have to learn > it. So the more we can leverage existing tools/infrastructure/concepts, > the better. True. Adding handles and having the transformation fan out in all directions are also features not allowed by the current interface, but that doesn't mean I can't leave them in there as features that could be implemented eventually. I do plan to decompose this into smaller tasks once everyone agrees on the general interface. For example, the bare-bones version of this feature would only feature normal clones (no fuse mode) with wallpaper tiling (no radial, no lines). Instead of on-canvas dynamics control, users just click on defined target tiles to pop-up a modified version of the current interface, and input values manually. etc. To be honest, I'm not even completely sure how Inkscape's current interface works. That's why I started a re-design. Once you've looked into the current design, it'd be helpful if you could tell us what's actually going on...

1 0

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 30 Mar '12

30 Mar '12

It's the guy who made the fancy alignment tool! :D I hope it gets ported over one day! In fact, it turns out that Jasper's suggestion of an "interpolation gradient" was genius! Here's the current setup: http://postimage.org/image/velcy91a9/ You can add linear, grid or radial interpolation gradients. The example shown here is a grid gradient. This interpolation tool can eventually be ported to be applied to just about any group of objects (but let's just stick to tiling for now...) Veronika, I didn't see your mail before I finished the current mock-ups. I do think what you're proposing could be quite useful for a general interpolation tool. :) We could start thinking about it separately from the tiling tool. Anyway, here's how the interpolation gradient would work with tiling (grid example): - Here, you have to define a Row stop and a Column stop. - By default, applying a grid interpolation gradient will place the stops on the tiles neighbouring the base tile. - You can drag that extremity to other tiles. - You can add Multiple stops! Just like a gradient! The other tiles aren't updated, this saves some processing power and avoids some clutter. Now the handle form is where it gets a bit trickier. I think the best would be to have a specialized handle of some sort. Anybody can think of a design? For blur and opacity, now that we have a few free controllers (maybe), we could maybe assign Ctrl to Opacity and Shift to Blur. The user just drags over the frame. Also hold down Alt to add/remove jitter values. For HLS interpolation: by default the ghost tile or handle is without fill, but fill etc. can be added like with any normal object to launch HLS interpolation. In fact, the user can switch to the eyedropper tool and take the values of a target object. Alt-click with the eyedropper to take a second set of values as jitter reference? So, the "optimal" work flow is to create sets of two coloured dots beforehand to set select color interpolation and jitter values. Of course you can also open up the full editor. To answer a few questions by Tom: 1. Yes, I've also decided that just Normal and Fuse modes are enough. 2. I want a separate Radial tiling because it's more intuitive for angle control. In the case of the render frames, you can manually set a start and end point, and snap to full circle (and maybe specify if you want more than 1 circle). When it's snapped to full circle: when editing the angle of the base tile, it will automatically take values to make a full circle. Small stuff like that. 3. The thing about guide points and guide segments is that others have noted the usefulness of placing them elsewhere than on the tile sides. 4. Skew will be allowed for P1 and P2. If you drag the handles in certains ways, they will automatically become upright. 5. The problem with live preview is that these tiles take potentially a long time to render. :S Since you're here, I don't suppose you'd have an idea as to the form of the handle for interpolation gradients, would you? :)

2 1

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 29 Mar '12

29 Mar '12

> The unclump option is already in the align and distribute dialog. So... should I add it or not? > This might give some problems when used with the fuse cut method > (with or without borders). In principle the user can obviously create a > design based on a rectangular tile, but this might not be the most natural. You mean edge scenarios right? It shouldn't be a problem for inner tiles, since you can just duplicate the pattern to fill the missing part, and Inkscape will still cut it more or less correctly. How about this? You can skew, but if you mess with the handles, the tile snaps to 90 degrees angle again. It becomes skewed again if you go back to P1 or P2. (I don't envy the person who wants to try to program the tiles...) > This reasoning is partly correct, and I agree that this would definitely not > be a "must". On the other hand, I think that some changes might be quite > logical, so at some point it might be nice to have the option. Hmm... I'll leave it in the design as a "really low priority feature", and we can just wait and see if anybody actually requests the feature one day. > Partially. One of the things that would make interpolation work really > well with tiled clones is that they are conceptually laid out in a grid True. Leaving dynamics out made the design conception much easier, but I realized that having to go back and add dynamics separately would be annoying in the end. Here's what I propose: http://postimage.org/image/4235075wd/ The solution is that little dot thing in the corner of each frame. Initially I was worried that it'd get in the way, but then I realized that until rendering is done, those frames are empty anyway. They're also invisible outside of the render mode. Each dot offers a visual representation of opacity, blur and HLS. Mouse-over gives exact values. Double-click to define exact values. At this point I hope the programing folks can answer a few questions about interpolation: 1. It is possible to define interpolation over both rows And columns using just a start tile and a reference tile (example: a base tile at the upper-left and a reference tile and the bottom-right). The current tiling dialogue forces you to define changes for both Rows and Columns. Though, in that scenario, maybe Inkscape just divides the values over Rows and Columns (I still need to make sure though that users don't need to choose two reference tiles besides the base tile). 2. Could each render tile in fact be considered more or less like an independent tile? Like, should we have the option to allows the user to break a tile apart and drag it around independently? (internally, Inkscape would still keep track of their row and column value, so users could still use some mechanism to select a whole row for example)

3 3

Re: [Inkscape-devel] Circular Arrangement
by Valerie 29 Mar '12

29 Mar '12

> You're right, the arrows are indeed a little bit confusing. As an > alternative I could use the iconless buttons like in the blueprint. As > an alternative I could put icons that somewhat resemble a bounding box. > Example: http://www.pasteall.org/pic/show.php?id=28549 Personally I really like your alternative icons! I wonder if the others agree? Don't worry about those other possible features I mentioned, they're just questions I happened to have on my mind. I wasn't trying to imply that you actually had to code them. Good luck with the project!

4 5

tracing bitmap images using bucket tool
by francesco fantoni 29 Mar '12

29 Mar '12

hi everyone, I used to selectively trace bitmap images using bucket tool, and I think it is a great feature and a wonderful trick in my workflow. Now I've compiled a fresh source from bzr, and tracing bitmaps this way seems not working anymore, I get only a message of non-closed surface or something similar. has this feature been removed on purpose, or am I somehow facing a bug? best to all, francesco

2 1

Re: [Inkscape-devel] Google Summer of Code 2012
by Yevgeny Lezhnin 29 Mar '12

29 Mar '12

Josh Andler писал 28.03.2012 02:44: > One thing to take into account when coming up with a proposal is if > you have many other plans for the summer. Are there other work or > travel plans that will be time consuming? Chances are that GSoC will > be much more time consuming than you may be expecting (especially if > you have not participated before). > > Cheers, >Josh I have a programming job in my university, but it should not take too much time in summer (0-5 hours per day), I'm not participated to gsoc before. I'm only participated to co.de-in 2010

2 1

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 28 Mar '12

28 Mar '12

You guys are killing me. D: Hopefully this... 7th iteration or so is the lucky one (at least approach-wise)? It still needs a lot of work, but the Youtube video and the extra comment on guides were eye-openers, so thanks for that! Alright, here's the deal: so far the design has either concentrated on dialogue, or on the "base tile", and such. This new design changes the approach (again): this new tiling tool proposal is centered directly on a render frame (with one tile serving as "base" tile). http://postimage.org/image/vinwmlp6d/ http://postimage.org/image/81v4l35p3/ Now as you can see, it should be somehow possible to fit the Dynamics onto the top-level as well. Unfortunately, I'm not as smart as the guy who made that Youtube video, so right now I can't think of a fancy approach to handle it all. The basic idea is that for some dynamics at least, (namely involving position, angle, skew, size and maybe opacity and blur), it should be possible to define them on-canvas through some trick involving the distribution or interpolation of the various frames. Suggestions please?

3 2

Libraries for 0.49
by john Culleton 28 Mar '12

28 Mar '12

Are the library requirements for compiling 0.49 the same as for 0.48.2? I have just gone through the agony of adding all the Inkscape libraries needed for compiling/running 48.2 on Slackware Linux. -- John Culleton Free list of books for self-publishers: http://wexfordpress.net/shortlist.html Police Procedural and Expose: "Death Wore Black" "Create Book Covers with Scribus" http://www.booklocker.com/books/4055.html

3 3

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 28 Mar '12

28 Mar '12

And another iteration: http://wiki.inkscape.org/wiki/index.php/Tiling_tool Is it me, or is the mail-archive not showing all mails in a timely manner? It took two days for one of mine to show up. Anyway, to answer a few questions: > Changing the selected wallpaper group is something the user will do a few > times and there are a fixed, small number of choices. Yes it would be very > nice to show the user that many of the groups are similar and to make the > user aware of the differences. However, I think there may be other ways to > do this and they may even be more clear. Yes, that's why there's a drop-down there. If you want to choose a tiling type immediately, then you use the drop-down. Also, the tile type can only be changed in tile edit mode. Users probably won't spend a lot of time in that mode. > In contrast, changing the size, orientation, in some cases angle of the base > tile with respect to the group being tiled is something the user will need > fine control over. The tiles behave like objects, so you can transform them with the F1 transform tool, and you can snap them to other guides. For radial and line tiling guides, you can also input numerical values in tile edit mode. I'm not sure what to do with the wallpaper tile though, since there are so many different shapes. A possibility is to define the coordinate of the first center of rotation + the length of 2 sides (only one is used if all sides are equal length). Now to answer Jasper: > 1. Inkscape's current tiling approach doesn't actually generate the > tilings it says it does. It /can/, but by default it doesn't (you need > to tweak the parameters to make sure the tiling actually matches the > chosen tiling group). Ah yes, I noticed the hard way that P2 tilings behaved weirdly... (i.e. I was trying to understand what it does by actually trying to render it) > Forget about tiles. Seriously. The problem with focusing on the > actual base tile are two-fold. First of all, if you define the base tile > together with what rotation centers/reflection axes are on its edges and > at what positions, then it is often non-obvious what the actual base > tile is. But the base tile is still the most intuitive guidelines one has for wallpaper tilings... Also, you need to know where the edges are to create seamless tiles. Or do you mean that the extra stuff gets in the way? The handles etc. aren't visible outside tile edit mode. Since the default tile is a simple P1 tile, and you need to bother double-clicking the tile to enter the tile edit mode and change what it does, I think we can assume that the user won't be too surprised if the output is no longer a simple P1. > Even worse, take a p2 tiling and put a 180-degree rotation > center on its "translational" edges (I'm referring to the diagram drawn > by veronika(?)), what you end up with is another p2 tiling with a > different base tile... Huh? It's still the same tile, just flipped. That's how wallpaper tilings work. > Another reason is that users might want to put guide points somewhere > else than on a tile boundary. So I think it is more important to focus on > the transformations involved, rather than on the base tile, and I think > this can even help to make things make MORE sense. I'm not sure what interface you're proposing. I know nothing about tilings, and the only thing I care about for tiling is that when I click the "apply" button, I get a pretty result (and a seamless output would qualify for the "pretty" factor). The specific transformations don't actually matter at all to users like me. :S

3 2

freehand tool in Python for comparison to Inkscape tool?
by lloyd konneker 27 Mar '12

27 Mar '12

This *might* be of interest to some. I am not familiar with the Inkscape freehand tool. I wrote a freehand drawing tool using Qt, PySide, Python. See https://github.com/bootchk/freehandTool Uses algorithms from potrace. Its readable, understandable, easy to prototype, and FOSS.

1 0

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 26 Mar '12

26 Mar '12

Alright, I haven't made a full diagram of guide transformations using handles, but looking at the different tiling types, I am now convinced at least that it is at least possible. So, with that in mind, I bring you YATTIP (Yet Another Tiling Tool Interface Proposal): http://postimage.org/image/nhwdn9x29/ http://postimage.org/image/m1lvj06sn/ By popular (?) demand, this is now a tool again! (with a possible extra dialogue for extra options). The "handles" approach actually resolves a number of things. In fact, when choosing a guide, you now simple start with the following defaults: - P1 for wallpaper - Simple-rotation and scaling for radial tiling - Simple translation for line tiling (but all Frieze types are available) Double-clicking a "tile" changes the toolbar into the tile edit mode. Using either the handle or a drop-down in the toolbar, you can then change the tiling type. Since for wallpapers, most people will be using P1 anyway, this approach should be satisfactory. Other features I had proposed are still there: - Guide points and other guide types - Excluding parts of a tile's exterior and fusing all the tiles - Tile stacking should be still possible from a dialogue Any major comments before I completely redo the wiki content again?

2 1

Some clipboard functions
by Romain de Bossoreille 24 Mar '12

24 Mar '12

Hi, A 200% code question, thanks to the one (or two, or three... !) who will give me an answer! I'm looking very closely to the clipboard implementation to follow understanding its behaviour (cf. http://wiki.inkscape.org/wiki/index.php/Clipboard), an amazing work have been done but I've a question (in src/ui/clipboard.cpp): Inkscape::XML::Node *ClipboardManagerImpl::_copyNode(Inkscape::XML::Node *node, Inkscape::XML::Document *target_doc, Inkscape::XML::Node *parent) void ClipboardManagerImpl::_pasteDocument(SPDesktop *desktop, SPDocument *clipdoc, bool in_place) void ClipboardManagerImpl::_pasteDefs(SPDesktop *desktop, SPDocument *clipdoc) SPCSSAttr *ClipboardManagerImpl::_parseColor(const Glib::ustring &text) On my understanding, those functions should not be implemented in the Clipboard class because 1) they are not using any functions dedicated to the Clipboard and so 2) they are codes that could be needed for other puposes than clipboard (and I wonder whether some are duplicated elsewhere in the project). If my opinion/understanding is confirmed, implementing them in a more global namespace should be a better way to avoid dupplicated functions (now or in the future) and provide better code hierarchy ('util' functions?). Or at least setting them as static to show they are not dedicated only to the clipboard management. Does any "Inkscape developper expert" have an opinion on it? -- *Romain de Bossoreille*

2 2

Powerstroke rounded joins
by Johan Engelen 24 Mar '12

24 Mar '12

Hi all, After busting my brain for two evenings, I've succeeded in creating properly rounded joins for powerstroked paths... The quick explanation: - for constant stroke width paths: looks like SVG rounded joins (circular arc) - for non-constant width paths, it is not possible to round with a circle and keep the curve smooth (tangents will not match). So the rounding is done with an elliptical arc, for which the tangents *do* match. There are many possible ellipses, and I decided for the one with minimum eccentricity. This converges to a circle for constant stroke width. Please test and tell me if it is bugged. (bzr rev 11111) Cheers, Johan

2 4

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 24 Mar '12

24 Mar '12

Alright, I've had the time to take a better look at Veronika's diagrams. They're really well-done, I feel like I finally understand what's going on! (quite a feat considering the headaches I've amassed from trying to figure out what's happening from several other sites) It's easier to see how handles would work thanks to those. Here's an example toggling between P1, P2, PM and PMM. http://www.freeimagehosting.net/kouh5 (hopefully you can tell the pair, symmetry and rotation handles) With an additional handle for glide reflection, it should be possible to connect all shapes with rectangular base tiles. I'm not sure how to fit in P3 and P4 though. What's more, it may be possible to convert between most of the triangle tiles by clicking on a corner, and dragging around to choose the number of tiles in that corner (3, 4, 6, 8 or 12). The shape of the tile would have to be updated automatically. The problem is that the users may then be tempted to drag other handles around to convert between pair, symmetry and rotate to play around, but the resulting output may not correspond to a tillable symmetry. There should be a method of warning in that case. Also, to make things less confusing, it may be possible to force one corner to be a "primary rotation corner" (the corner with the largest amount of tiles touching it) and a "secondary rotation corner." Does anyone feel up to trying to make a diagram with all 17 tilings as well as conversion methods between them? If you somehow manage to do that, I'll try to make a new tiling GUI proposal around it.

1 0

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 24 Mar '12

24 Mar '12

Ah-hah! People keep telling me about draggable handles, but I never was able to figure out what they meant (it's just me being clueless, not other people's faults). I think I'm beginning to see what people are talking about. Simple example: - Base tile: Rectangle for P1. At the side of each edge, you see a handle. The ones on the left and right are the same, the ones on the top and bottom are the same. Maybe parallel arrows. They symbolize "translation" (though I am going to go with another name, like "pair handle", because one side forms a pair with another) - By either dragging the handle or doing some other operation, the "pair" handle becomes say... a symmetry handle. So now the default behavior of that side is symmetry (also breaking the "pair" behavior of the other side). It can also be changed into anti- symmetry (using the center of the side). In the same way, there are edge handles. By manipulating it, the rectangle corner can become say... a triangle corner (and this is why I used "pair" rather than "translation": a pair behavior can be maintained). Alright, the main "issue" here is that I'm the one who doesn't know how to handle such behavior (since, as I've already explained, I'm pretty clueless about wallpaper tiling actually). Can someone more familiar with wallpaper tiling look into how feasible it is to transform from one tiling to another without erratic behavior? Is it possible to transform from one type to any other? If it's feasible, then I'll have to redo the whole thing proposal again. xD This time probably re-integrating guides and the actual tiling into one interface... ----- Original Message ----- From: Mark Schafer <mschafer@...2596...> To: Valerie <valerie_vk@...36...> Cc: Sent: Saturday, March 24, 2012 6:05 AM Subject: Re: [Inkscape-devel] New tiling interface proposal I can see that a set of thumbnail pics showing the principle tiling layouts is useful for initial selection of a specific tiling. And your approach looks very good. But ideally that would create the interactive draggable handles on the canvas for users to interact with - and ideally modifiable to create all tilings simply from these widgets. That way a new user can select a tiling style to being to operate with (or see many choices) - and an advanced user can simply begin and manipulate the tiling to their desired outcome. This approach would argue for a simple UI where initial selection (or toggling of selection) can start/modify the current tiling on canvas. So not taking up alot of room on the UI seems preferable. Perhaps a drop down image selection ? I would add that the initial tile and its handles could be in 'bold' and the reflections etc be drawn 'weaker' and so the effect of handle manipulation can be more clearly adjusted interactively. A weaker 'reflection' also allows you an excuse to operate with simpler proxy copies of the original - which could be replaced with proper curves etc on handle release. To further control the amount of drawing, a "preview generations" numeric field could indicate how many of the tiling 'reflections' to actually draw. E.g. 1 would show only the first level 'reflections' of the tile, and a 2 would show a further level. 1 or 2 would probably suffice in most cases to visually see the effect of the tiling at a useful scale for design. Then - similar to the preview button on existing extensions - making it could then extend out to some kind of boundary. As you say a rectangle, or perhaps a clipping region of some kind, or a defined number of 'reflections' of the tile operator. Ideally the tile generator would be a widget which could be modified at any time - similar to existing tools like the box. Just my 2 cents. Thanks for having a go at this - its coming along very well - I'm very much looking forward to the result. Mark... On 3/24/2012 6:10 AM, Valerie wrote: >> http://i.imgur.com/DMCvU.png > Oh phew, thank you so much for making that! I was trying to make something like that too but a bit different, and some of those symmetries were starting to make me feel Very cross-eyed. > > Basically I was thinking that a table for all the tiling types > (both wallpaper and Frieze) with the following visual guides would > be useful: > 1. The base tile guide with no transformation indicators > 2. The base tile guide with indicators (use can toggle indicators > on and off) > 3. The preview when creating the guide (either what you did here, > or Thorsten's previews) > 4. An outline preview of extra tiles (can be toggled on and off, > shows basically the outline of those extra tiles as you've made here) > 5. My idea was to also make base tile guides that show you which > tile side ends up reflected on which side. This is meant to help > a person who wants to program the "guide points" feature: > - Two "corresponding" sides will be represented by dotted lines of > the same colours. (example: for simple translation, the left and > right sides would be dotted lines of one colour, and the up and > down sides of another colour). An arrow marks the "direction" of > each side. > - Each side that transforms onto itself is represented by a full > line. It is marked either by a single arrow (if the transformation > is in the same direction) or two arrows in opposite directions (if the tile is flipped) > 6. Base tiles again, this time with examples of guide points > and guide segments. > > (yeah, that makes a lot...) > >> I do have to throw out there at this point, the proposed UI >> for tiling at http://wiki.inkscape.org/wiki/index.php/Tiling_tool is incredibly complex. One of the benefits to a dedicated tool is actually being able to manipulate parameters on-canvas. > Are you reading the latest version (there were many versions...)? > Because all the things that can be manipulated on canvas Are manipulated on-canvas... The dialogue is only choosing options > (there are a lot of options... much more than your average LPE, > even), the number of copies, and hitting "apply" (none of which > are really on-canvas interactions). > > I've thought of the use of tile shadow outlines to help users see > what will be rendered. The problem is dynamics. They make the > tile outlines unpredictable in the first place... That's why I came up > with extra render "target" options, so users can choose to render > over a specific, non-rectangular area, or even better, to render > as a target's pattern (if .svg allows that), so users can then > manually control any offsets with the pattern tool. > > Now, I was actually thinking about on-canvas handles for > manipulating dynamics, but that's a whole other can of worms... > (and given the time needed to render dynamic tiles, I'm not so > sure it's such a good idea to have them updated live...) > > I'm open to suggestions though. I've made a number of mock-ups > proposals for tilings until now, and this is just the latest iteration > (the... fifth I think? If I count the few ideas I first had a few years > ago). If someone has a general direction in mind (beyond "it has > to be a tool"), I can try to see if I can work out something. > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

1 0

Re: [Inkscape-devel] New tiling interface proposal
by Valerie 23 Mar '12

23 Mar '12

> http://i.imgur.com/DMCvU.png Oh phew, thank you so much for making that! I was trying to make something like that too but a bit different, and some of those symmetries were starting to make me feel Very cross-eyed. Basically I was thinking that a table for all the tiling types (both wallpaper and Frieze) with the following visual guides would be useful: 1. The base tile guide with no transformation indicators 2. The base tile guide with indicators (use can toggle indicators on and off) 3. The preview when creating the guide (either what you did here, or Thorsten's previews) 4. An outline preview of extra tiles (can be toggled on and off, shows basically the outline of those extra tiles as you've made here) 5. My idea was to also make base tile guides that show you which tile side ends up reflected on which side. This is meant to help a person who wants to program the "guide points" feature: - Two "corresponding" sides will be represented by dotted lines of the same colours. (example: for simple translation, the left and right sides would be dotted lines of one colour, and the up and down sides of another colour). An arrow marks the "direction" of each side. - Each side that transforms onto itself is represented by a full line. It is marked either by a single arrow (if the transformation is in the same direction) or two arrows in opposite directions (if the tile is flipped) 6. Base tiles again, this time with examples of guide points and guide segments. (yeah, that makes a lot...) > I do have to throw out there at this point, the proposed UI > for tiling at http://wiki.inkscape.org/wiki/index.php/Tiling_tool > is incredibly complex. One of the benefits to a dedicated tool > is actually being able to manipulate parameters on-canvas. Are you reading the latest version (there were many versions...)? Because all the things that can be manipulated on canvas Are manipulated on-canvas... The dialogue is only choosing options (there are a lot of options... much more than your average LPE, even), the number of copies, and hitting "apply" (none of which are really on-canvas interactions). I've thought of the use of tile shadow outlines to help users see what will be rendered. The problem is dynamics. They make the tile outlines unpredictable in the first place... That's why I came up with extra render "target" options, so users can choose to render over a specific, non-rectangular area, or even better, to render as a target's pattern (if .svg allows that), so users can then manually control any offsets with the pattern tool. Now, I was actually thinking about on-canvas handles for manipulating dynamics, but that's a whole other can of worms... (and given the time needed to render dynamic tiles, I'm not so sure it's such a good idea to have them updated live...) I'm open to suggestions though. I've made a number of mock-ups proposals for tilings until now, and this is just the latest iteration (the... fifth I think? If I count the few ideas I first had a few years ago). If someone has a general direction in mind (beyond "it has to be a tool"), I can try to see if I can work out something.

2 1