- Inkscape Devel - Inkscape Mailman

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