- Inkscape Devel - Inkscape Mailman

Apply LPE to clone
by Johan Engelen 08 Apr '12

08 Apr '12

Hi all, I have added functionality to the LPE dialog. When you select a clone, the "add effect" button is enabled and when clicked will convert the clone to a normal path and add the clone original path LPE (without showing the LPE selection dialog) . Please see for yourself what I mean :) My question is: is this desired behavior? Or... do we want to pop-up the LPE selection dialog, and then afterwards apply the *stack* of LPEs: clone original LPE + selected LPE. This option is more work so I did not do it yet. But there is a better reason not to do this: perhaps the user does not want to apply an (extra) LPE on top of the clone original LPE at all! Why? Because using the clone original LPE, you can get clones that have a different style than its original path :-) :-) I hope someone with more UI awareness can change the LPE dialog text when a clone is selected. It now reads: "Click add button to convert clone", and I guess that can be improved. Cheers, Johan

1 0

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

04 Apr '12

Thanks a lot! Would I be correct to interpret it this way: 1. Basically, the current code would not allow "multiple stops." 2. But it'd still be possible to have a one-stop on-canvas handle (maybe two, for rows and columns), that basically converts the end values into percentage values to feed into the current system 3. Since Inkscape doesn't store tiling values right now, changing the tiling mechanism completely (to allow interpolations) would not break any backward compatibility or something like that (not that changing the mechanism is an easy task) So, the possible way to implement the tiling tool is: 1. First create a separate a "render frame" object (with a central tile), and make it output values (to feed into the tiling system). It'd basically be a separate file that can be tested independently. Also, you can't add or delete tiles individually at this point, just rows and columns, since the tiling system only handles a "rows and column" entry at this point. 2. Once it is considered "stable", it is made to call upon the tiling system, to which it inputs appropriate values. On-canvas dynamics would require adding to the code for the render frame object, not the current tiling system. What it'd do is generate percentage values that are then fed into the tiling system as well. So, for a "basic" tiling tool, the tiling system would not need to be changed much. However, adding both the fuse mode and multi- node interpolation tiling would requiring significant changes to the system. Is that more or less correct? ________________________________ From: Jasper van de Gronde <th.v.d.gronde@...528...> To: Valerie <valerie_vk@...36...> Sent: Wednesday, April 4, 2012 1:24 AM Subject: Re: [Inkscape-devel] New tiling interface proposal On 2012-03-31 16:20, Valerie wrote: 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? > I'm afraid I haven't been able to keep up over the last few days, but I have had a look at the code. For those interested, all the code is in src/ui/dialog/clonetiler.cpp. The main function is CloneTiler::clonetiler_get_transform. This function essentially gets all info, as well as a row and column index. It then computes all the transforms required for that position and combines them. As far as I can tell it combines them in such a way that first a scaling is applied, then a rotation and finally a translation. If you select a different symmetry group then the translation can become a more complicated transform. The scheme we talked about earlier that would interpolate transforms is not necessarily compatible. This is because in the latter the case the entire transform would be interpolated, while what Inkscape does is essentially interpolating per kind of transform. That this is not the same can be seen by realizing that rotate(50)translate(1)rotate(50)translate(1) is not the same as rotate(100)translate(2). The former is more or less what we talked about (or at least what I had in mind during that discussion), the latter is what Inkscape does. However, Inkscape currently seems to store almost nothing about the tiling in the file. So it would be relatively benign to change behaviour. Existing files would not be affected in any way, users would only be affected when trying to change a tiling or create a new one. (This is not to say that it's necessarily a good idea to make it impossible to achieve the current behaviour, just that if we cannot reconcile the two, there is some room for change.) Note that it would be possible to emulate Inkscape's current behaviour through interpolation of transforms, but only if we would allow "stacking" transforms. I'm not sure how this would have to be supported UI-wise though.

1 0

GSoC 2012 Student Application Deadline approaching
by Josh Andler 03 Apr '12

03 Apr '12

Hi, If you're a student who is going to be applying for Summer of Code with Inkscape, this is a reminder that your applications/proposals should be submitted as soon as possible. The deadline is April 6 19:00 UTC. It is recommended to submit sooner rather than later so we can try to help refine your proposals if necessary. Good luck! Cheers, Josh

1 0

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

03 Apr '12

On 03.04.2012 20:12, Tavmjong Bah wrote: > Your background information looks good. It seems that you have lots of > experience. I would like to see the proposal developed a little more. > For example, what bugs are users suffering from? What features could > you add (some people would kill for underlining). I found one bug #960046, that has opinion about whole text realization in inkscape, it has idea of merging text function. Also searching bugs with 'text' tag in it gives 229 results. I've listed this features: hyphens, indentation, underlining and merging. > How would you treat flowed text? Have you looked at the draft CSS > exclusions and regions specifications to see how they could be applied > to Inkscape? (An Inkscape implementation would really help push this > forward for SVG2.) Time is short. How deeply should I understand css specification at the moment? From what should I start? > Note, Firefox is known to be bad at rendering SVG text. This is > something they are working on. Yes, I see it now. Then I was working with diagram, there was bad support of svg text in firefox. So it is not inkscape's fault.

1 0

Inkscape-docs list admin
by unknown＠example.com 03 Apr '12

03 Apr '12

Hello inkscape-docs list has been silent for months and it appears that message are pending. I'm one of the admin but we all (poor admins) can't log to the admin panel of the list. Does anyone have the rights to do that and reset the configuration ? pygmee

2 1

extract node subset??
by Bric 03 Apr '12

03 Apr '12

If I have a path with, say, 100 nodes, 30 of which constitute a separate, continuous "subpath" -- discontinous from the other 70, and I can easily highlight these 30 nodes -- how can I extract/cut or copy these nodes and "paste" them as a separate path?? Or, in other words, "break away" this part of the big path and convert it into a distinct path. It's already possible to DELETE these 30 nodes (or whatever nodes one has selected, discretely or not). This seems like it should be relatively trivial for inkscape (given the powers it already has), but I can't find a way to do this. Is it perhaps in the filters? In the extensions? It's like there should be an extensions submenu called "selected nodes..." with options in that submenu including: extract selected nodes as distinct path (to be pasted) rotate selected nodes scale selected nodes.. ... etc., etc.

3 3

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