- Inkscape Devel - Inkscape Mailman

Inkscape tiling interface redesign proposal
by Valerie 05 Feb '12

05 Feb '12

Ah well, I have no idea if the wiki image upload issue will be fixed, so I just made everything into an image and uploaded it somewhere else: http://postimage.org/image/7f9ms5kw3/ As you can see, central concepts include: 1. Transformations separated into groups that people other than tile mathematicians understand 2. And moved to a dedicated dialogue. Basically: - One-time filters -> floating boxes - Properties that may need future editing -> side-dialogues By the way, radial transformations to use polar coordinates. 3. Top level interface to address most common use cases, while more advanced options (clutter) are moved to an extra button that you can access. 4. Guides can be edited on canvas... 5. ...and locked or unlocked to objects, so you can create half a vase, stick a symmetry on it, then move the whole thing around as though it were one object. 6. Stacking symmetries or tilings as you would LPEs I'm probably missing a lot of things, but it doesn't hurt to make a few proposals to see what people's thoughts are. :) So what do the rest of you think? Is this a direction you think can lead somewhere, or do you think the interface should be taken in a completely different direction?

5 12

support multiple extension locations
by Tim Cuthbertson 05 Feb '12

05 Feb '12

I was looking into how one might provide inkscape extensions using 0install[1], which basically amounts to adding extensions _without_ touching any well-known paths, typically using environment variables. I've done the same thing for gnome-shell, by essentially adding each extension's location to $XDG_DATA_DIRS. So for example to run gnome-shell with the shellshape extension[2], $XDG_DATA_DIRS might contain the following dir: /home/tim/.cache/0install.net/implementations/sha256=2437376cd245ee4f09b0738e1cc7392a04750a9cec4b0875bf71606703d9ee01/xdg which contains a `gnome-shell` directory with the files you would normally put in /usr/share/gnome-shell if you were installing them system-wide. I wondered if this would work for inkscape as well, but after having a look at the source, it doesn't seem likely. Based on the `profile_path` function in inkscape.cpp: - inkscape seems to assume that there will be at most one folder for each of (user, system) level preferences - it assumes preferences and extensions will all live in the same location. These both go against the XDG spec[3], which recommends that config and data live in different locations and should be able to be looked up in a cascading fashion (i.e supporting multiple paths in $XDG_DATA_DIRS). These restrictions also make it very difficult to use 0install to distribute extensions since that would require: - readonly `extensions` directories - all 0install implementation directories must be read-only as they can be shared between users (among other reasons) - cascading lookup of extensions in _all_ paths in $XDG_DATA_DIRS - adding or removing plugins must be possible by affecting what is in XDG_DATA_DIRS, rather than modifying folders in the filesystem. So, I guess my questions are: - am I wrong about my conclusions here? I've looked at the source, but may have missed something. - is there any interest in extending the extension loading mechanism to support loading extensions across all $XDG_DATA_DIRS? Presumably this would be implemented for _all_ data types (gradients, icons, etc) as well as just extensions. Cheers, - Tim. [1]: http://0install.net/ [2]: http://gfxmonk.net/dist/0install/shellshape.xml [3]: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

3 3

Inkscape with OpenMP support on OS X Lion: First attempt at build script (WIP)
by ~suv 04 Feb '12

04 Feb '12

On 03/02/2012 23:03, ~suv wrote: > >> due to license restrictions in MacOs X, there are problems with compile >> Inkscape with OpenMP support. > > The underlying issue is the rather old version of GCC Apple provides > with Xcode [1] . Due to license changes in GCC, Apple will never upgrade > to a later GCC version than 4.2.1, and eventually drop GCC completely in > favor of CLANG. Building Inkscape with a custom-installed newer GCC > version doesn't work out-of-the-box due to ABI conflicts in linked > C++interface libraries [2]. > > Update: Since the time I had discussed the details impeding OpenMP > support on Mac OS X with Kris on irc, I did manage to produce stable > builds of 0.48.2, 0.48.x and current trunk with full OpenMP support > (64bit builds with GCC 4.6.2 (MacPorts) on OS X 10.7.2 Lion). I'm > currently working on a shell script as 'proof-of-concept' and to allow > easier testing of the build setup on other systems. The script does not > create a bundled osx application yet (this might be added later on). > > [1] <http://article.gmane.org/gmane.comp.graphics.inkscape.devel/36355> > [2] <http://wiki.inkscape.org/wiki/index.php/FAQ#On_Linux.2C_Inkscape_crashes_wi…> > quoted from <https://bugs.launchpad.net/inkscape/+bug/200415> Attached is an initial attempt (WIP) of a build script which allows to compile the following Inkscape versions on OS X 10.7.2 Lion in 64bit with OpenMP support (using GCC 4.6.2): - Inkscape 0.48.2 (from tar ball) - Inkscape 0.48.x (from lp:inkscape/0.48.x) - Inkscape trunk (from lp:inkscape) with cairo devel 1.11.2 - Inkscape mesh (from lp:~tavmjong-free/inkscape/mesh) with cairo master What the script basically does: ------------------------------- - rebuilds all C++ interfaces outside of MacPorts with GCC 4.6.2 (libsigc++, glibmm, atkmm, cairomm, pangomm, gtkmm) - builds cairo-devel (+ cairomm, pangomm, gtkmm) for trunk - builds cairo-master (+ cairomm, pangomm, gtkmm) for mesh branch - builds inkscape with GCC 4.6.2, linking to the new libs What it does not (yet): ----------------------- - create universal binaries or - create an osx application bundle - build with Quartz backend of GTK+ - fancy error handling: if something fails and you can't figure out how to fix it, you might simply delete $localSRC and $inkPREFIX and try again (or use './osx-build-inkgcc46.sh del_all) - optimize to the max (ATM everything is compiled with -02) - ... Prerequisites are: ================== - OS X Lion (tested on 10.7.2 with Xcode 4.2.1) - MacPorts (up-to-date), gtk2 with X11 backend (!) - port 'inkscape' installed in MacPorts (for all dependencies) - ports autoconf, automake and dbus-glib installed in MacPorts - port 'gcc46' installed in MacPorts (for the compiler) - $PATH is set up accordingly for MacPorts (the script does not override nor try to verify it in any way) How to use it: ============== 1a) edit the script file and adjust the paths for: LIBPREFIX (MacPorts install prefix) localSRC (directory to unpack the sources and compile) inkPREFIX (top-level dir for installation of inkscape+dependents) 1b) optionally reuse (clone or branch) local repos for inkscape 0.48.x, trunk, pixman, cairo and / or inkscape mesh branch (see script) 2) use a build target as command line argument: release | branch | trunk | mesh for example: $ ./osx-build-inkgcc46.sh trunk 3) grab a cup of coffee and wait for the build to finish 4) launch the inkscape binary with its full path name Note: DYLD_LIBRARY_PATH is needed for trunk and mesh (as displayed in a note if the installation was successful), for example: $ DYLD_LIBRARY_PATH=$inkPREFIX/cairo-devel/lib $inkPREFIX/trunk/bin/inkscape 5) updating local source trees of inkscape branch, trunk and mesh: you can update from parent branch and rebuild by rerunning the script with the same target. The script ought to test and detect already installed libs as well as the local repo, pull new revisions and rebuild as needed. Alternatively, you can cd into '$localSRC/inkscape-trunk/build' (or '$localSRC/inkscape-mesh/build'), and use 'bzr pull', 'make && make install' as usual. Note: you can install multiple targets without changing $inkRPEFIX (the builds install into different sub-directories) Feedback, comments, improvements, test and bug reports about the script (to me personally, or here on the list - not in the bug tracker) would be welcome :) ** (inkscape:79650): WARNING **: the script is unstable and buggy in its current state - use at your own risk ;-). It was _not_ written with regular Mac users in mind - ideally it would be improved/reworked and extended to allow to create precompiled osx application bundles of trunk (and experimental feature branches), which then could be uploaded and shared for testing. ~suv

1 0

Re: [Inkscape-devel] Mesh gradient status
by Valerie 03 Feb '12

03 Feb '12

Speaking of the mesh gradients, can someone describe to me different types of mesh gradients and how they're supposed to be edited so I can try to design a toolbar for it? I have no idea how to compile it, and I don't want to risk breaking my system dependencies again either (if it involves that)... That said, I'm not sure what functions should go into the toolbar and what guides could be edited by the other editing tools. For example, can tweak tools be used to edit the meshes? I'm adding mesh gradient to the list of tools I'm doing at the same time as thoughts on toolbar rework. Since I plan to add a few toolbar suggestions for a few other tools at the same time, I might as well do one for mesh gradients too.

1 0

Mesh gradient status
by Tavmjong Bah 02 Feb '12

02 Feb '12

Hi, I've gotten a number of queries as to when mesh gradients will be available in Inkscape. Some people seem to think that it is a project that is close to being ready... it is not. There is still a lot of work to do and several major issues to be resolved. So I though I would give a status report: At the moment, you can create, edit, save, read in both Coons Patch meshes and tensor meshes (the latter have not been approved by the SVG working group). There are a few nice editing features available: Conical gradients, sampling color from beneath the mesh, toggling between straight edges and curves, etc. However, the code is very buggy. Expect frequent crashes. Save often. Undo does not work for most things. Revert is a poor person's substitute. Before the mesh code can be merged with trunk the following issues MUST be resolved: 1. Meshes have been approved for SVG 2 but the syntax has not been finalized and will not likely be finalized for some time. For meshes to be included in Inkscape we will need to keep them in the Inkscape namespace for the moment and include a fallback mechanism. (Note, there are quite a few nice SVG 2.0 features that we could adopt quickly if we had a way of handling fallbacks: markers that inherit stroke color, solid colors that will eliminate the need for the one-stop gradient hack for creating a palette, etc.). 2. Meshes rely on Cairo trunk. We need an official Cairo release with the mesh rendering code. The last new Cairo release was in Sept of 2010. Who knows when a new release will be made. 3. My code is a hack. There are multiple issues that need to be resolved. The most important one is how do meshes fit into the Private/Vector structure used by linear and radial gradients (Inkscape gradients are broken up into two gradient elements, one that handles the geometric layout and the other that handles the color vector. This allows reuse of the same gradient to be applied to multiple objects. It may not make sense for meshes.) Of course all the crashes must be eliminated. 4. GUI: How should meshes fit into the GUI? Should meshes have their own tool bar? The gradient chooser is not really applicable for meshes and meshes will have lots of their own options: * Mesh creation: * Mesh type: Normal, conical, ? * Number of rows/columns. * Mesh editing: * Show/hide handles. * Make handle smooth/symmetric. 5. Saving to PDF/PostScript needs to be implemented. (Export to PNG works.) I am sure I've missed some. Issues that would be nice to address: 1. Node editing. Gradients implement their own dragger code. It would be nice to be able to use the code from path editing. This would enable things like editing the paths by dragging or selecting a group of nodes and rotate/scale/etc. them together. 2. Auto generating an initial grid based on path shape. 3. Auto fitting. It would be the nice to be able to layout a rough mesh and have Inkscape adjust the mesh to match an underlying drawing. My branch can already set the mesh corner colors by sampling the image underneath which is a real time saver. 4. Auto smoothing of patch boundaries. I have an initial implementation that attempts to make color transitions across patch boundaries smooth. This can certainly be improved. Tav

4 4

Question about tool control bars
by Valerie 02 Feb '12

02 Feb '12

To my understanding, a limitation with tool control bars right now is that they aren't too dynamic. For example, when I draw lines: - I'd like dotted lines and markers to appear in the tool control bar for lines without shapes - But with the "from clipboard" option, I'd like width, repeat style etc. to appear there instead. But without introducing new interface features, the tool control bar is pretty much static right now, so we face all-or-nothing situations. Is it possible to have two layers of tool selection instead? Explanation: Right now: [tool control bar] [t o o l b a r] Proposal: [subtools] | [subtool control bar] [t o o l b a r] I'm asking this because it'd allow for several things: - Consolidate the shapes tools into one button in the toolbar. Instead, sub-shapes appear in the subtools bar. - If more 3D shapes are added, they can similarly be grouped into a single button in the toolbar, while allowing each shape to have its own controls. - When tech-drawing becomes available, they could be accessed from the top-level instead of as LPEs - unshaped line, "from clipboard" line, powerstroke line and maybe other line effects (sketch?) can be treated as separate sub-tools with their own top-level control bars (so you don't need to open the LPE dialogue) - transformation options such as perspective, envelop and envelop deform can become available as sub-tools of the transform tool - composition guides, maybe common on-canvas tiling options (symmetry, radial and normal tiling - anything more advanced must be accessed from a separate panel) become available from top-level - extra mode in text tool for controlling flowing text into shapes? (for graphs and such) Of course, it it's not possible, then that's that. It seemed like a possibility worth asking.

3 4

Re: [Inkscape-devel] Inkscape-devel Digest, Vol 69, Issue 3
by Rosa Alonso Garcia 02 Feb '12

02 Feb '12

Good Morning, Thanks Jason and other people of this equipment. In this link I can solve error. http://sourceforge.net/projects/inkscape/files/inkscape/0.46/Inkscape-0.46-… I'm grateful your fast answer. Sincerely Rosa M. Alonso Garcia Il.lustradora gràfica http://rosailustradora.com http://rosailustradora.blogspot.com >________________________________ > De: "inkscape-devel-request(a)lists.sourceforge.net" <inkscape-devel-request(a)lists.sourceforge.net> >Para: inkscape-devel(a)lists.sourceforge.net >Enviado: Miércoles 1 de febrero de 2012 21:46 >Asunto: Inkscape-devel Digest, Vol 69, Issue 3 > >Send Inkscape-devel mailing list submissions to > inkscape-devel(a)lists.sourceforge.net > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >or, via email, send a message with subject or body 'help' to > inkscape-devel-request(a)lists.sourceforge.net > >You can reach the person managing the list at > inkscape-devel-owner(a)lists.sourceforge.net > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Inkscape-devel digest..." > > >Today's Topics: > > 1. error inkscape runs first time! (Rosa Alonso Garcia) > 2. Re: error inkscape runs first time! (Jason Simanek) > 3. Re: error inkscape runs first time! (~suv) > 4. Inkscape tiling interface redesign proposal (Valerie) > 5. Re: Inkscape tiling interface redesign proposal > (Krzysztof Kosi?ski) > 6. Re: Inkscape tiling interface redesign proposal > (Tobias Ellinghaus) > 7. Re: Inkscape 0.48.3? (Krzysztof Kosi?ski) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Wed, 1 Feb 2012 11:32:41 +0000 (GMT) >From: Rosa Alonso Garcia <disenografica@...2758...> >Subject: [Inkscape-devel] error inkscape runs first time! >To: "Inkscape-devel(a)lists.sourceforge.net" > <Inkscape-devel(a)lists.sourceforge.net> >Message-ID: > <1328095961.19545.YahooMailNeo@...2769...> >Content-Type: text/plain; charset="iso-8859-1" > >I need to learn Inkscape, but I download app and add to Applications folder, and previous I have just installed X11, I can''t run program. >>>It opens 10 seconds, and close automatic. >>>I work with MACOS 10.4, Tiger. >>> >>> >>>It's urgent, please a solve! >>>? >>>Sincerely, > >? >Cordialmente, > >Rosa M. Alonso Garcia >Il.lustradora gr?fica >http://rosailustradora.com > >http://rosailustradora.blogspot.com >

1 0

Image uploading on Inkscape Wiki?
by Valerie 02 Feb '12

02 Feb '12

Recently I've been working on a UI redesign proposal for the Tiled Clones interface, and thought of creating a new page on the Inkscape Wiki to see if it's even plausible. However, when I tried to upload images, I get: The upload directory (public) is not writable by the webserver. A quick search only tells me that it's a permissions problem. I've also noticed that there were no new file uploads since July last year. Has there been a policy change? Any suggestions as to where else to upload them then? In case anybody's curious, major suggestions are: - On-canvas guides - Separation into Symmetries, Radial Clones, Rectangular tiles and Triangle tiles (basically dependent on the guide type) - Move from a floating box to a side-bar dialogue, where you can basically stack symmetries and tilings to a selected object (like with LPEs, so it's easy if you want to make a flower-shaped design then have it fill up the page as tiles, for example) - Top-level options are simple and intuitive to address the main use cases (I'm assuming most users just want to do some basic symmetrical or radial patterns...) - But more advanced options are available by clicking "advanced" and opening a separate box (to avoid cluttering the main dialogue. If the user wants jittery tiles distributed in an outward spiral that change colors and become transparent near the end, surely he can open an extra dialogue) - Presets are also available

4 4

Inkscape tiling interface redesign proposal
by daniele rossi 01 Feb '12

01 Feb '12

I do agree that tiling dialog today is a short way to headache... Daniele > ------------------------------ > > Message: 5 > Date: Wed, 1 Feb 2012 19:00:07 +0100 > From: Krzysztof Kosi?ski <tweenk.pl@...400...> > Subject: Re: [Inkscape-devel] Inkscape tiling interface redesign > proposal > To: Valerie <valerie_vk@...36...> > Cc: Inkscape-devel <inkscape-devel(a)lists.sourceforge.net> > Message-ID: > <CAFLw2WSOhagh1v-Qkn3cjDEBEG_QCwiNfCECkSDzYN49g3JFUg@...401...> > Content-Type: text/plain; charset=UTF-8 > > 2012/2/1 Valerie <valerie_vk@...36...>: >> Ah well, I have no idea if the wiki image upload issue will be >> fixed, so I just made everything into an image and uploaded >> it somewhere else: >> >> http://postimage.org/image/7f9ms5kw3/ >> >> >> As you can see, central concepts include: >> 1. Transformations separated into groups that people other >> than tile mathematicians understand >> 2. And moved to a dedicated dialogue. Basically: >> ?- One-time filters -> floating boxes >> ?- Properties that may need future editing -> side-dialogues >> By the way, radial transformations to use polar coordinates. > > I was thinking about the tiling thing for some time and I came to a > conclusion that usability-wise the tiling dialog is a cruel joke > (adjusting numbers by trial and error? seriously?).

1 0

inkscape.org in svg
by john Culleton 01 Feb '12

01 Feb '12

I am doing some experimenting with svg pages in lieu of html. Is there a reason why the inkscape.org front page is not done in svg? -- John Culleton Free list of books for self-publishers: http://wexfordpress.net/shortlist.html "Create Book Covers with Scribus" http://www.booklocker.com/books/4055.html

6 6