- Inkscape Devel - Inkscape Mailman

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

Release of binaries
by Johan Engelen 23 Mar '12

23 Mar '12

Hi all, Apparently, there is a policy to release binaries at the same time, instead of simply uploading them to Sourceforge whenever they become available. I would like to see this changed to the latter option. I see no point in why people on one platform would have to wait for binaries becoming available on the other. Thanks for your consideration, Johan

5 6

QR code request.
by john Culleton 23 Mar '12

23 Mar '12

I note that Inkscape offers the Datamatrix bar code as an option. However another 2d bar code is now in common use, the QR code which can be read by many handheld devices. I wonder if a QR generator could be added to Inkscape, perhaps as a GSOC project. -- 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 2