Inkscape Wiki - User contributions [en]

User:Pajarico

2019-06-02T23:35:18Z

Pajarico: /* [DONE] Spray tool */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

=== Setting up django ===
1. Create a SSH key.
2. Add it to launchpad
3. Run putty.exe and add the key
4. Goto bzr and execute 'bzr launchpad-login <username>'.
5. First 'cd' to the checkout folder and run this command:

<nowiki>python manage.py runserver</nowiki>

6. If django complains about docutils not being installed, follow the instructions here: [http://docutils.sourceforge.net/README.html#windows]

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==
=== UI ===
==== Filters/Extensions ====
Navigating Filters and Extensions menus takes too long. The list are very long and many of them have submenus. Suggestions:

* Filter gallery.
* Docked filters and extensions: a dockable windows with the current filters and extensions presented as a list (like a directory listing).
* Tear apart dialogs.
* Custom toolbars [https://bugs.launchpad.net/inkscape/+bug/170146 #170146].

=== Clipping ===
Clipped objects hit region includes the area of clipped objects instead of being limited to the area of the clipping path, which IMHO is wrong.
This makes impossible to correctly edit two clipped objects placed side by side when the content of both (i.e. their respective clipped objects) would overlap if not clipped. The problem is this: when trying to edit the content of the lower clipped object (entering the group), whenever you try to hit the content, Inkscape thinks that you're clicling the upper clipped object, because its hit area is overlapping the lower clipped object.

=== Filters ===
When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

=== Spiro splines ===
Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

=== Color stuff ===
====Jon Cruz's Auto swatches====
:* Can't use an auto swatch as a gradient stop.
:* When transformed with the selector tool, Auto palette stops reflecting if the object is using one of the swatches.
:* No clear differentiation between usage of swatches in fill and stroke.
====Fill&Stroke dialog issues====
It is used for three things,
:* Object propierties (tabs Fill, Stroke and Stroke style).
:* Gradient stops editing.
:* Swatches editing.
...which results in misleading behaviour and an excess of UI elements (for instance, a gradient stop just have a color and alpha and it doesn't need two color tabs -Fill and Stroke- and a third one with nonsensical options -Stroke style-).

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now, is not possible to edit linestyles unless you use the XML editor:
* Not easily discoverable for new users.
* Not easy to use.
* The update is not immediate and the user has to fiddle a lot with values to get the expected design.

I propose adding some text input boxes to the ''Stroke style'' tab were the user can input several values like this:

|box 1|box 2|box 3| box 4|box 5|

So odd numbers add a stroke of that lenght, while even boxes add a space of that lenght.

I think 5 boxes would be enough to get complex patterns, but more boxes could be added if needed (the reference doesn't seem to have a limit about this).

=== [DONE] Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== [DONE] Composition Guides ===
[http://wiki.inkscape.org/wiki/index.php/CompositionGuides Composition Guides blueprint]

=== [DONE] Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===[DONE] Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2019-06-02T23:28:38Z

Pajarico: /* [TODO] Lens LPE */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

=== Setting up django ===
1. Create a SSH key.
2. Add it to launchpad
3. Run putty.exe and add the key
4. Goto bzr and execute 'bzr launchpad-login <username>'.
5. First 'cd' to the checkout folder and run this command:

<nowiki>python manage.py runserver</nowiki>

6. If django complains about docutils not being installed, follow the instructions here: [http://docutils.sourceforge.net/README.html#windows]

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==
=== UI ===
==== Filters/Extensions ====
Navigating Filters and Extensions menus takes too long. The list are very long and many of them have submenus. Suggestions:

* Filter gallery.
* Docked filters and extensions: a dockable windows with the current filters and extensions presented as a list (like a directory listing).
* Tear apart dialogs.
* Custom toolbars [https://bugs.launchpad.net/inkscape/+bug/170146 #170146].

=== Clipping ===
Clipped objects hit region includes the area of clipped objects instead of being limited to the area of the clipping path, which IMHO is wrong.
This makes impossible to correctly edit two clipped objects placed side by side when the content of both (i.e. their respective clipped objects) would overlap if not clipped. The problem is this: when trying to edit the content of the lower clipped object (entering the group), whenever you try to hit the content, Inkscape thinks that you're clicling the upper clipped object, because its hit area is overlapping the lower clipped object.

=== Filters ===
When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

=== Spiro splines ===
Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

=== Color stuff ===
====Jon Cruz's Auto swatches====
:* Can't use an auto swatch as a gradient stop.
:* When transformed with the selector tool, Auto palette stops reflecting if the object is using one of the swatches.
:* No clear differentiation between usage of swatches in fill and stroke.
====Fill&Stroke dialog issues====
It is used for three things,
:* Object propierties (tabs Fill, Stroke and Stroke style).
:* Gradient stops editing.
:* Swatches editing.
...which results in misleading behaviour and an excess of UI elements (for instance, a gradient stop just have a color and alpha and it doesn't need two color tabs -Fill and Stroke- and a third one with nonsensical options -Stroke style-).

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now, is not possible to edit linestyles unless you use the XML editor:
* Not easily discoverable for new users.
* Not easy to use.
* The update is not immediate and the user has to fiddle a lot with values to get the expected design.

I propose adding some text input boxes to the ''Stroke style'' tab were the user can input several values like this:

|box 1|box 2|box 3| box 4|box 5|

So odd numbers add a stroke of that lenght, while even boxes add a space of that lenght.

I think 5 boxes would be enough to get complex patterns, but more boxes could be added if needed (the reference doesn't seem to have a limit about this).

=== [DONE] Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== [DONE] Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===[DONE] Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2019-06-02T23:27:41Z

Pajarico: /* Lens LPE */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

=== Setting up django ===
1. Create a SSH key.
2. Add it to launchpad
3. Run putty.exe and add the key
4. Goto bzr and execute 'bzr launchpad-login <username>'.
5. First 'cd' to the checkout folder and run this command:

<nowiki>python manage.py runserver</nowiki>

6. If django complains about docutils not being installed, follow the instructions here: [http://docutils.sourceforge.net/README.html#windows]

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==
=== UI ===
==== Filters/Extensions ====
Navigating Filters and Extensions menus takes too long. The list are very long and many of them have submenus. Suggestions:

* Filter gallery.
* Docked filters and extensions: a dockable windows with the current filters and extensions presented as a list (like a directory listing).
* Tear apart dialogs.
* Custom toolbars [https://bugs.launchpad.net/inkscape/+bug/170146 #170146].

=== Clipping ===
Clipped objects hit region includes the area of clipped objects instead of being limited to the area of the clipping path, which IMHO is wrong.
This makes impossible to correctly edit two clipped objects placed side by side when the content of both (i.e. their respective clipped objects) would overlap if not clipped. The problem is this: when trying to edit the content of the lower clipped object (entering the group), whenever you try to hit the content, Inkscape thinks that you're clicling the upper clipped object, because its hit area is overlapping the lower clipped object.

=== Filters ===
When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

=== Spiro splines ===
Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

=== Color stuff ===
====Jon Cruz's Auto swatches====
:* Can't use an auto swatch as a gradient stop.
:* When transformed with the selector tool, Auto palette stops reflecting if the object is using one of the swatches.
:* No clear differentiation between usage of swatches in fill and stroke.
====Fill&Stroke dialog issues====
It is used for three things,
:* Object propierties (tabs Fill, Stroke and Stroke style).
:* Gradient stops editing.
:* Swatches editing.
...which results in misleading behaviour and an excess of UI elements (for instance, a gradient stop just have a color and alpha and it doesn't need two color tabs -Fill and Stroke- and a third one with nonsensical options -Stroke style-).

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now, is not possible to edit linestyles unless you use the XML editor:
* Not easily discoverable for new users.
* Not easy to use.
* The update is not immediate and the user has to fiddle a lot with values to get the expected design.

I propose adding some text input boxes to the ''Stroke style'' tab were the user can input several values like this:

|box 1|box 2|box 3| box 4|box 5|

So odd numbers add a stroke of that lenght, while even boxes add a space of that lenght.

I think 5 boxes would be enough to get complex patterns, but more boxes could be added if needed (the reference doesn't seem to have a limit about this).

=== [DONE] Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== [DONE] Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===[TODO] Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2019-06-02T23:27:21Z

Pajarico: /* Spray tool */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

=== Setting up django ===
1. Create a SSH key.
2. Add it to launchpad
3. Run putty.exe and add the key
4. Goto bzr and execute 'bzr launchpad-login <username>'.
5. First 'cd' to the checkout folder and run this command:

<nowiki>python manage.py runserver</nowiki>

6. If django complains about docutils not being installed, follow the instructions here: [http://docutils.sourceforge.net/README.html#windows]

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==
=== UI ===
==== Filters/Extensions ====
Navigating Filters and Extensions menus takes too long. The list are very long and many of them have submenus. Suggestions:

* Filter gallery.
* Docked filters and extensions: a dockable windows with the current filters and extensions presented as a list (like a directory listing).
* Tear apart dialogs.
* Custom toolbars [https://bugs.launchpad.net/inkscape/+bug/170146 #170146].

=== Clipping ===
Clipped objects hit region includes the area of clipped objects instead of being limited to the area of the clipping path, which IMHO is wrong.
This makes impossible to correctly edit two clipped objects placed side by side when the content of both (i.e. their respective clipped objects) would overlap if not clipped. The problem is this: when trying to edit the content of the lower clipped object (entering the group), whenever you try to hit the content, Inkscape thinks that you're clicling the upper clipped object, because its hit area is overlapping the lower clipped object.

=== Filters ===
When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

=== Spiro splines ===
Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

=== Color stuff ===
====Jon Cruz's Auto swatches====
:* Can't use an auto swatch as a gradient stop.
:* When transformed with the selector tool, Auto palette stops reflecting if the object is using one of the swatches.
:* No clear differentiation between usage of swatches in fill and stroke.
====Fill&Stroke dialog issues====
It is used for three things,
:* Object propierties (tabs Fill, Stroke and Stroke style).
:* Gradient stops editing.
:* Swatches editing.
...which results in misleading behaviour and an excess of UI elements (for instance, a gradient stop just have a color and alpha and it doesn't need two color tabs -Fill and Stroke- and a third one with nonsensical options -Stroke style-).

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now, is not possible to edit linestyles unless you use the XML editor:
* Not easily discoverable for new users.
* Not easy to use.
* The update is not immediate and the user has to fiddle a lot with values to get the expected design.

I propose adding some text input boxes to the ''Stroke style'' tab were the user can input several values like this:

|box 1|box 2|box 3| box 4|box 5|

So odd numbers add a stroke of that lenght, while even boxes add a space of that lenght.

I think 5 boxes would be enough to get complex patterns, but more boxes could be added if needed (the reference doesn't seem to have a limit about this).

=== [DONE] Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== [DONE] Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-02-15T02:11:15Z

Pajarico: /* Setting up django */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

=== Setting up django ===
1. Create a SSH key.
2. Add it to launchpad
3. Run putty.exe and add the key
4. Goto bzr and execute 'bzr launchpad-login <username>'.
5. First 'cd' to the checkout folder and run this command:

<nowiki>python manage.py runserver</nowiki>

6. If django complains about docutils not being installed, follow the instructions here: [http://docutils.sourceforge.net/README.html#windows]

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==
=== UI ===
==== Filters/Extensions ====
Navigating Filters and Extensions menus takes too long. The list are very long and many of them have submenus. Suggestions:

* Filter gallery.
* Docked filters and extensions: a dockable windows with the current filters and extensions presented as a list (like a directory listing).
* Tear apart dialogs.
* Custom toolbars [https://bugs.launchpad.net/inkscape/+bug/170146 #170146].

=== Clipping ===
Clipped objects hit region includes the area of clipped objects instead of being limited to the area of the clipping path, which IMHO is wrong.
This makes impossible to correctly edit two clipped objects placed side by side when the content of both (i.e. their respective clipped objects) would overlap if not clipped. The problem is this: when trying to edit the content of the lower clipped object (entering the group), whenever you try to hit the content, Inkscape thinks that you're clicling the upper clipped object, because its hit area is overlapping the lower clipped object.

=== Filters ===
When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

=== Spiro splines ===
Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

=== Color stuff ===
====Jon Cruz's Auto swatches====
:* Can't use an auto swatch as a gradient stop.
:* When transformed with the selector tool, Auto palette stops reflecting if the object is using one of the swatches.
:* No clear differentiation between usage of swatches in fill and stroke.
====Fill&Stroke dialog issues====
It is used for three things,
:* Object propierties (tabs Fill, Stroke and Stroke style).
:* Gradient stops editing.
:* Swatches editing.
...which results in misleading behaviour and an excess of UI elements (for instance, a gradient stop just have a color and alpha and it doesn't need two color tabs -Fill and Stroke- and a third one with nonsensical options -Stroke style-).

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now, is not possible to edit linestyles unless you use the XML editor:
* Not easily discoverable for new users.
* Not easy to use.
* The update is not immediate and the user has to fiddle a lot with values to get the expected design.

I propose adding some text input boxes to the ''Stroke style'' tab were the user can input several values like this:

|box 1|box 2|box 3| box 4|box 5|

So odd numbers add a stroke of that lenght, while even boxes add a space of that lenght.

I think 5 boxes would be enough to get complex patterns, but more boxes could be added if needed (the reference doesn't seem to have a limit about this).

=== [DONE] Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-02-15T02:01:16Z

Pajarico: /* Notes */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

=== Setting up django ===
First 'cd' to the checkout folder and run this command:

<nowiki>python manage.py runserver</nowiki>

If django complains about docutils not being installed, follow the instructions here: [http://docutils.sourceforge.net/README.html#windows]

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==
=== UI ===
==== Filters/Extensions ====
Navigating Filters and Extensions menus takes too long. The list are very long and many of them have submenus. Suggestions:

* Filter gallery.
* Docked filters and extensions: a dockable windows with the current filters and extensions presented as a list (like a directory listing).
* Tear apart dialogs.
* Custom toolbars [https://bugs.launchpad.net/inkscape/+bug/170146 #170146].

=== Clipping ===
Clipped objects hit region includes the area of clipped objects instead of being limited to the area of the clipping path, which IMHO is wrong.
This makes impossible to correctly edit two clipped objects placed side by side when the content of both (i.e. their respective clipped objects) would overlap if not clipped. The problem is this: when trying to edit the content of the lower clipped object (entering the group), whenever you try to hit the content, Inkscape thinks that you're clicling the upper clipped object, because its hit area is overlapping the lower clipped object.

=== Filters ===
When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

=== Spiro splines ===
Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

=== Color stuff ===
====Jon Cruz's Auto swatches====
:* Can't use an auto swatch as a gradient stop.
:* When transformed with the selector tool, Auto palette stops reflecting if the object is using one of the swatches.
:* No clear differentiation between usage of swatches in fill and stroke.
====Fill&Stroke dialog issues====
It is used for three things,
:* Object propierties (tabs Fill, Stroke and Stroke style).
:* Gradient stops editing.
:* Swatches editing.
...which results in misleading behaviour and an excess of UI elements (for instance, a gradient stop just have a color and alpha and it doesn't need two color tabs -Fill and Stroke- and a third one with nonsensical options -Stroke style-).

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now, is not possible to edit linestyles unless you use the XML editor:
* Not easily discoverable for new users.
* Not easy to use.
* The update is not immediate and the user has to fiddle a lot with values to get the expected design.

I propose adding some text input boxes to the ''Stroke style'' tab were the user can input several values like this:

|box 1|box 2|box 3| box 4|box 5|

So odd numbers add a stroke of that lenght, while even boxes add a space of that lenght.

I think 5 boxes would be enough to get complex patterns, but more boxes could be added if needed (the reference doesn't seem to have a limit about this).

=== [DONE] Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

SpecLongMenuAccessibility

2011-02-13T21:05:38Z

Pajarico: /* UI */

Launchpad Entry:
https://blueprints.launchpad.net/inkscape/+spec/long-menu-accessibility

== Summary ==
Menus like 'Filters' and 'Extensions' have become so crowded after many releases that navigating through them is tedious and confusing. This blueprint aims to solve this by presenting the menu items in a docked dialog with search (by name) capabilities.

== Release Note ==
== Rationale ==
Right now, Inkscape has too many elements in both ''Filters'' and ''Extensions'' menus. Some of the entries even have their own sub-menus. This causes several problems:
* The new user gets overwhelmed by the number of entries without knowing which one will be useful because the names sometimes are not descriptive enough and there is no visual representation of the effect.
* Even if you know which to use, navigating the menus is too cumbersome, caused by the large name of entries and the menu nature (top menus always close after you had selected an entry, so going back to already known entries recquires extra clicks).

of each menu entry is low because there is no visual representation of

Importance of good resource management

== Design ==

=== UI and usage ===
==== Main dockable window ====
Showing filters by categories (text only):

[[File:Dock-showing-filters.png]]

Showing filters by categories (text + visual representation):

==== Search function ====
Showing two modes for showing the search results:

[[File:Dock-showing-search.png‎]]

=== Usage ===

== TODO ==
== Discussion ==

SpecLongMenuAccessibility

2011-02-13T19:28:03Z

Pajarico: /* Rationale */

Launchpad Entry:
https://blueprints.launchpad.net/inkscape/+spec/long-menu-accessibility

== Summary ==
Menus like 'Filters' and 'Extensions' have become so crowded after many releases that navigating through them is tedious and confusing. This blueprint aims to solve this by presenting the menu items in a docked dialog with search (by name) capabilities.

== Release Note ==
== Rationale ==
Right now, Inkscape has too many elements in both ''Filters'' and ''Extensions'' menus. Some of the entries even have their own sub-menus. This causes several problems:
* The new user gets overwhelmed by the number of entries without knowing which one will be useful because the names sometimes are not descriptive enough and there is no visual representation of the effect.
* Even if you know which to use, navigating the menus is too cumbersome, caused by the large name of entries and the menu nature (top menus always close after you had selected an entry, so going back to already known entries recquires extra clicks).

of each menu entry is low because there is no visual representation of

Importance of good resource management

== Design ==

=== UI ===
[[File:Dock-showing-filters.png]] [[File:Dock-showing-search.png‎]]

=== Usage ===

== TODO ==
== Discussion ==

SpecLongMenuAccessibility

2011-02-13T18:32:04Z

Pajarico: /* Summary */

SpecLongMenuAccessibility

2011-02-13T18:25:10Z

Pajarico: /* UI */

Launchpad Entry:
https://blueprints.launchpad.net/inkscape/+spec/long-menu-accessibility

== Summary ==

== Release Note ==
== Rationale ==
== Design ==

=== UI ===
[[File:Dock-showing-filters.png]] [[File:Dock-showing-search.png‎]]

=== Usage ===

== TODO ==
== Discussion ==

File:Dock-showing-search.png

2011-02-13T18:23:03Z

Pajarico: uploaded a new version of "File:Dock-showing-search.png"

File:Dock-showing-search.png

2011-02-13T18:19:38Z

Pajarico: uploaded a new version of "File:Dock-showing-search.png"

File:Dock-showing-search.png

2011-02-13T18:12:33Z

Pajarico:

File:Dock-showing-filters.png

2011-02-13T18:11:37Z

Pajarico:

SpecLongMenuAccessibility

2011-02-13T18:00:54Z

Pajarico: Created page with 'Launchpad Entry: https://blueprints.launchpad.net/inkscape/+spec/long-menu-accessibility == Summary == == Release Note == == Rationale == == Design == === UI === === Usage ==...'

Launchpad Entry:
https://blueprints.launchpad.net/inkscape/+spec/long-menu-accessibility

== Summary ==

== Release Note ==
== Rationale ==
== Design ==

=== UI ===

=== Usage ===

== TODO ==
== Discussion ==

User:Pajarico

2011-01-26T13:27:29Z

Pajarico: /* UI */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==
=== UI ===
==== Filters/Extensions ====
Navigating Filters and Extensions menus takes too long. The list are very long and many of them have submenus. Suggestions:

* Filter gallery.
* Docked filters and extensions: a dockable windows with the current filters and extensions presented as a list (like a directory listing).
* Tear apart dialogs.
* Custom toolbars [https://bugs.launchpad.net/inkscape/+bug/170146 #170146].

=== Clipping ===
Clipped objects hit region includes the area of clipped objects instead of being limited to the area of the clipping path, which IMHO is wrong.
This makes impossible to correctly edit two clipped objects placed side by side when the content of both (i.e. their respective clipped objects) would overlap if not clipped. The problem is this: when trying to edit the content of the lower clipped object (entering the group), whenever you try to hit the content, Inkscape thinks that you're clicling the upper clipped object, because its hit area is overlapping the lower clipped object.

=== Filters ===
When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

=== Spiro splines ===
Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

=== Color stuff ===
====Jon Cruz's Auto swatches====
:* Can't use an auto swatch as a gradient stop.
:* When transformed with the selector tool, Auto palette stops reflecting if the object is using one of the swatches.
:* No clear differentiation between usage of swatches in fill and stroke.
====Fill&Stroke dialog issues====
It is used for three things,
:* Object propierties (tabs Fill, Stroke and Stroke style).
:* Gradient stops editing.
:* Swatches editing.
...which results in misleading behaviour and an excess of UI elements (for instance, a gradient stop just have a color and alpha and it doesn't need two color tabs -Fill and Stroke- and a third one with nonsensical options -Stroke style-).

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now, is not possible to edit linestyles unless you use the XML editor:
* Not easily discoverable for new users.
* Not easy to use.
* The update is not immediate and the user has to fiddle a lot with values to get the expected design.

I propose adding some text input boxes to the ''Stroke style'' tab were the user can input several values like this:

|box 1|box 2|box 3| box 4|box 5|

So odd numbers add a stroke of that lenght, while even boxes add a space of that lenght.

I think 5 boxes would be enough to get complex patterns, but more boxes could be added if needed (the reference doesn't seem to have a limit about this).

=== [DONE] Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-01-26T13:16:26Z

Pajarico: /* Clipping */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==
=== UI ===

=== Clipping ===
Clipped objects hit region includes the area of clipped objects instead of being limited to the area of the clipping path, which IMHO is wrong.
This makes impossible to correctly edit two clipped objects placed side by side when the content of both (i.e. their respective clipped objects) would overlap if not clipped. The problem is this: when trying to edit the content of the lower clipped object (entering the group), whenever you try to hit the content, Inkscape thinks that you're clicling the upper clipped object, because its hit area is overlapping the lower clipped object.

=== Filters ===
When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

=== Spiro splines ===
Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

=== Color stuff ===
====Jon Cruz's Auto swatches====
:* Can't use an auto swatch as a gradient stop.
:* When transformed with the selector tool, Auto palette stops reflecting if the object is using one of the swatches.
:* No clear differentiation between usage of swatches in fill and stroke.
====Fill&Stroke dialog issues====
It is used for three things,
:* Object propierties (tabs Fill, Stroke and Stroke style).
:* Gradient stops editing.
:* Swatches editing.
...which results in misleading behaviour and an excess of UI elements (for instance, a gradient stop just have a color and alpha and it doesn't need two color tabs -Fill and Stroke- and a third one with nonsensical options -Stroke style-).

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now, is not possible to edit linestyles unless you use the XML editor:
* Not easily discoverable for new users.
* Not easy to use.
* The update is not immediate and the user has to fiddle a lot with values to get the expected design.

I propose adding some text input boxes to the ''Stroke style'' tab were the user can input several values like this:

|box 1|box 2|box 3| box 4|box 5|

So odd numbers add a stroke of that lenght, while even boxes add a space of that lenght.

I think 5 boxes would be enough to get complex patterns, but more boxes could be added if needed (the reference doesn't seem to have a limit about this).

=== [DONE] Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

SpecGuidesImprovement

2011-01-25T12:57:49Z

Pajarico: /* Rationale */

Launchpad Entry:
https://blueprints.launchpad.net/inkscape/+spec/guides-improvement

== Summary ==

This specs provides a comprehensive way of managing guides and guidesets (which are groups of guides).

== Release Note ==
== Rationale ==
Guides are one of the stronger workhorses of any vector editing application. Inkscape has a powerful set of options but I feel the way to manage guides is mainly focused on a per-guide basis and has lagged a bit behind the overall quality of the software. My points for this argument are:
* The current dialog for manually setting guides properties is not as good as it should be since it tops the main window and the user has to pop-up the guides dialog for every editing, breaking the workflow. Also, is inconsistent with the way dock tabs work (much less obstructive).
* The user can't change the color on a per-guide basis.
* This spec adds basic managing operations such as add, remove, copy, visible/invisible and lock/unlock for guides.
** Lock /unlock lets the user specify if the guides should be selectable along the objects or not.
* It also deploys a complete UI framework for fitting the current types of guides (horizontal, vertical and angled) and adding other types of guides (see [https://blueprints.launchpad.net/inkscape/+spec/composition-guides composition guides], [https://bugs.launchpad.net/inkscape/+bug/171586 perspective guides] or others to come).
* This spec introduces the concept of a '''Guideset''' (or just '''Set'''). This is a bunch of guides that are grouped, having common managing options (copy, delete, visible/invisible, move and rotate).
** If the user selects a set, all of the guides inside it are edited homogeneously.
** Sets allows the user to arrange his guides in a comprehensive way (specially important when there are dozens of guides on the document).
* Right now, for angled guides, the user can edit the angle and center of the guide numerically but not on-canvas. I try to improve this too.

== Design ==
=== UI ===
Pretty self-explanatory...

[[Image:Guides-mockup.png|left]]

The guides shown inside the viewer contains from left to right: visible/invisible, ID (name), and icon for type.

Using the drop-down menu we can select the type of composition guide:

[[Image:Guides_selector.png]]

=== On-canvas editing ===
The guides can be edited on canvas with only mouse and some key modifiers. These modifiers try to mimic the current behavior when transforming objects (the first three actions are already implemented).

[[Image:Guide_editing_mockup.png]]

The rotation can be snapped as any other node to grids or other guides.

=== Usage ===
* The IDs of the newly created guides should have more meaningful names like ''guide001'', ''guide002'', ''guide003'', etc. More appropriate would be to have the names being "smart", i.e.: the name has some resemblance to the name of the guideset it is attached to. So if you have a guideset called ''left eye'' the guides are named ''left eye001'', ''left eye002'', etc. A guideset called ''right eye'' would have guides named ''right eye001'', ''right eye 002'', etc.

* '''How does lock/unlock work?''':
** A ''locked guide'' can be moved and rotated on-canvas the same as an ''unlocked guide''. However, the ''un''locked one '''is selectable along the objects''' with the selector tool (both dragging a square and touch selection), '''and moving and rotating the object does the same for the guides'''.

* '''Guidesets:'''
** This is an usage example: imagine you are working on the design of a complex drawing such as a book cover or a product label, you will end with many elements on the page: text, vector figures, lines, bitmaps... and grids, lots of grids. Till now, the guides are hard hard to tell apart when there are a lot of them. However, is quite probably that you can break them into groups so you would have '''sets''' and '''guides''' such as:
*** ''text guides''
**** ''main title''
**** ''subtitle''
**** ''name of the author''
*** ''barcode and copyright''
**** ''barcode bound1''
**** ''barcode bound2''
**** ''barcode bound3''
**** ''barcode bound4''
**** ''copyright text''
*** ''cover design''
**** ''guide1''
**** ''guideN''

Thus, and using different colors, the layout of the grids should be clearer and more usable.

=== SVG representation ===

== TODO ==

== Discussion ==
I'm unsure about these ideas. Please, discuss below.

* IDEA: Add '''snap''' option for every guide or every set, so the user is able to decide if snappable elements should snap to it or not.
* IDEA: Add '''attach''' option so a guide or guideset can be attached to an object, so selecting and transforming the object automatically moves and transforms the guides.

* REMINDER: '''Lock/unlock''' feature requires guides '''to be selectable along the objects''' (which I don't think they are right now). This is aimed to future developers.

* IDEA: Currently if a double click is done at the intersection of a guide and a path (being node edited) the guide will get the double click (0.46, 0.47). This means a user cannot use the double click to add a node to a path at the intersection of a guide and a path. My work style, and the style of some others, is to use the guide to place nodes but the guide gets the higher priority. To me, I would rather see the guide getting a lower priority for the double click so the path being node edited will create a new node. If guides were locked would the double click be ignored by the guide and allow the path to add a node? - Lawrence

* IDEA: Should guides be shapes on just another layer? The layer could be locked / unlocked the way other layers are currently being done. - Lawrence

* IDEA: When dragging an object currently in Inkscape pressing the spacebar will drop a copy in the current position. It would be great to do the same thing with guides as an easy way to create copies.

User:Pajarico

2011-01-16T14:42:17Z

Pajarico: /* Fill&Stroke dialog issues */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==
=== Clipping ===
Clipped objects hit region includes the area of clipped objects instead of being limited to the area of the clipping path, which IMHO is wrong.
This makes impossible to correctly edit two clipped objects placed side by side when the content of both (i.e. their respective clipped objects) would overlap if not clipped. The problem is this: when trying to edit the content of the lower clipped object (entering the group), whenever you try to hit the content, Inkscape thinks that you're clicling the upper clipped object, because its hit area is overlapping the lower clipped object.

=== Filters ===
When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

=== Spiro splines ===
Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

=== Color stuff ===
====Jon Cruz's Auto swatches====
:* Can't use an auto swatch as a gradient stop.
:* When transformed with the selector tool, Auto palette stops reflecting if the object is using one of the swatches.
:* No clear differentiation between usage of swatches in fill and stroke.
====Fill&Stroke dialog issues====
It is used for three things,
:* Object propierties (tabs Fill, Stroke and Stroke style).
:* Gradient stops editing.
:* Swatches editing.
...which results in misleading behaviour and an excess of UI elements (for instance, a gradient stop just have a color and alpha and it doesn't need two color tabs -Fill and Stroke- and a third one with nonsensical options -Stroke style-).

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now, is not possible to edit linestyles unless you use the XML editor:
* Not easily discoverable for new users.
* Not easy to use.
* The update is not immediate and the user has to fiddle a lot with values to get the expected design.

I propose adding some text input boxes to the ''Stroke style'' tab were the user can input several values like this:

|box 1|box 2|box 3| box 4|box 5|

So odd numbers add a stroke of that lenght, while even boxes add a space of that lenght.

I think 5 boxes would be enough to get complex patterns, but more boxes could be added if needed (the reference doesn't seem to have a limit about this).

=== [DONE] Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-01-16T14:12:39Z

Pajarico: /* What grinds my gears (small annoying bugs) */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==
=== Clipping ===
Clipped objects hit region includes the area of clipped objects instead of being limited to the area of the clipping path, which IMHO is wrong.
This makes impossible to correctly edit two clipped objects placed side by side when the content of both (i.e. their respective clipped objects) would overlap if not clipped. The problem is this: when trying to edit the content of the lower clipped object (entering the group), whenever you try to hit the content, Inkscape thinks that you're clicling the upper clipped object, because its hit area is overlapping the lower clipped object.

=== Filters ===
When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

=== Spiro splines ===
Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

=== Color stuff ===
====Jon Cruz's Auto swatches====
:* Can't use an auto swatch as a gradient stop.
:* When transformed with the selector tool, Auto palette stops reflecting if the object is using one of the swatches.
:* No clear differentiation between usage of swatches in fill and stroke.
====Fill&Stroke dialog issues====
:* It is used for three things,
::* Object propierties (tabs Fill, Stroke and Stroke style).
::* Gradient stops editing.
::* Swatches editing.
...which results in misleading behaviour and an excess of UI elements (for instance, a gradient stop just have a color and alpha and it doesn't need two color tabs -Fill and Stroke- and a third one with nonsensical options -Stroke style-).

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now, is not possible to edit linestyles unless you use the XML editor:
* Not easily discoverable for new users.
* Not easy to use.
* The update is not immediate and the user has to fiddle a lot with values to get the expected design.

I propose adding some text input boxes to the ''Stroke style'' tab were the user can input several values like this:

|box 1|box 2|box 3| box 4|box 5|

So odd numbers add a stroke of that lenght, while even boxes add a space of that lenght.

I think 5 boxes would be enough to get complex patterns, but more boxes could be added if needed (the reference doesn't seem to have a limit about this).

=== [DONE] Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-01-16T13:43:12Z

Pajarico: /* What grinds my gears (small annoying bugs) */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==
=== Filters ===
When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

=== Spiro splines ===
Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

=== Color stuff ===
====Jon Cruz's Auto swatches====
:* Can't use an auto swatch as a gradient stop.
:* When transformed with the selector tool, Auto palette stops reflecting if the object is using one of the swatches.
:* No clear differentiation between usage of swatches in fill and stroke.
====Fill&Stroke dialog issues====
:* It is used for three things,
::* Object propierties (tabs Fill, Stroke and Stroke style).
::* Gradient stops editing.
::* Swatches editing.
...which results in misleading behaviour and an excess of UI elements (for instance, a gradient stop just have a color and alpha and it doesn't need two color tabs -Fill and Stroke- and a third one with nonsensical options -Stroke style-).

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now, is not possible to edit linestyles unless you use the XML editor:
* Not easily discoverable for new users.
* Not easy to use.
* The update is not immediate and the user has to fiddle a lot with values to get the expected design.

I propose adding some text input boxes to the ''Stroke style'' tab were the user can input several values like this:

|box 1|box 2|box 3| box 4|box 5|

So odd numbers add a stroke of that lenght, while even boxes add a space of that lenght.

I think 5 boxes would be enough to get complex patterns, but more boxes could be added if needed (the reference doesn't seem to have a limit about this).

=== [DONE] Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-01-16T13:07:07Z

Pajarico: /* What grinds my gears (small annoying bugs) */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==

1. When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

2. Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

3. Color stuff.
:* Jon Cruz's Auto swatches:
::* Can't use an auto swatch as a gradient stop.
::* When transformed with the selector tool, Auto palette stops reflecting if the object is using one of the swatches.
::* No clear differentiation between usage of swatches in fill and stroke.
:* Fill&Stroke dialog issues:
::* It is used for three things,
:::* Object propierties (tabs Fill, Stroke and Stroke style).
:::* Gradient stops editing.
:::* Swatches editing.
...which results in misleading behaviour and an excess of UI elements (for instance, a gradient stop just have a color and alpha and it doesn't need two color tabs -Fill and Stroke- and a third one with nonsensical options -Stroke style-).

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now, is not possible to edit linestyles unless you use the XML editor:
* Not easily discoverable for new users.
* Not easy to use.
* The update is not immediate and the user has to fiddle a lot with values to get the expected design.

I propose adding some text input boxes to the ''Stroke style'' tab were the user can input several values like this:

|box 1|box 2|box 3| box 4|box 5|

So odd numbers add a stroke of that lenght, while even boxes add a space of that lenght.

I think 5 boxes would be enough to get complex patterns, but more boxes could be added if needed (the reference doesn't seem to have a limit about this).

=== [DONE] Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

SpecInformativeUI

2011-01-16T12:34:00Z

Pajarico: /* Examples in other software */

Launchpad Entry:
https://blueprints.launchpad.net/inkscape/+spec/informative-ui

== Summary ==
The UI could benefit from hyperlink-like shortcuts seamlessly placed on the statusbar text. These shortcuts open often used editing dialogs. Other places could get the same treatment.

== Release Note ==
== Rationale ==
'''Advantages:'''
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

'''Disadvantages:'''
# Might not be doable in GTK+ (unsure).

== Design ==

Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

=== Extending this concept to other parts of the UI ===
This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.
Tips like the one appearing when

=== Examples in other software ===
<gallery>
Image:MirandaIM-example.png|MirandaIM uses this kind of shortcuts for quick accessing network and protocol settings.
Image:Win7-example.png|Windows 7 uses it to open another app showing help.
Image:Gimp27-example.png|Gimp uses it to access a external webpage.
</gallery>

== TODO ==
== Discussion ==

File:Gimp27-example.png

2011-01-16T11:48:47Z

Pajarico:

File:Win7-example.png

2011-01-16T11:47:30Z

Pajarico:

SpecInformativeUI

2011-01-16T02:37:36Z

Pajarico: /* Examples in other software */

SpecInformativeUI

2011-01-16T02:25:46Z

Pajarico: /* Extending this concept to other parts of the UI */

Launchpad Entry:
https://blueprints.launchpad.net/inkscape/+spec/informative-ui

== Summary ==
The UI could benefit from hyperlink-like shortcuts seamlessly placed on the statusbar text. These shortcuts open often used editing dialogs. Other places could get the same treatment.

== Release Note ==
== Rationale ==
'''Advantages:'''
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

'''Disadvantages:'''
# Might not be doable in GTK+ (unsure).

== Design ==

Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

=== Extending this concept to other parts of the UI ===
This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.
Tips like the one appearing when

=== Examples in other software ===
<gallery>
Image:MirandaIM-example.png|MirandaIM uses this kind of shortcuts for quick accessing account settings.
</gallery>

== TODO ==
== Discussion ==

File:MirandaIM-example.png

2011-01-16T02:03:29Z

Pajarico: uploaded a new version of "File:MirandaIM-example.png"

File:MirandaIM-example.png

2011-01-16T01:43:05Z

Pajarico:

Diffusion Curves

2011-01-15T23:11:19Z

Pajarico: /* Questions/Problems */

[http://artis.imag.fr/Publications/2008/OBWBTS08/ Diffusion Curves] are a way of specifying very free form gradients. It works by letting colors diffuse from curves, seeding the colors along both sides of the curves using gradients (along the curves). Additionally a varying amount of blur can be applied along the curves. This makes diffusion curves extremely flexible and very interesting to have in Inkscape.

==Representation==
The links at the bottom define various features that can be useful for Diffusion Curves. Here the following features are considered:

* Colors at nodes / gradients defined on paths (on one or both sides of the curve)

* Diffusion across boundaries

Diffusion curves could be represented by paths with gradients attached to them, along with an enclosing group that says that the colors should be diffused within that group. For example (don't mind the exact attributes):

<g diffuse="true">
<path d="M 0,0 L 190,190"
leftBoundary="#F00 #00F" rightBoundary="#00F #F00" boundaryBlur="5" />
</g>

Or:

<g diffuse="true">
<path d="M 0,0 L 190,190"
leftBoundary="url(#redToBlue)" rightBoundary="url(#blueToRed)" boundaryBlur="5" />
</g>

Assuming that the two gradients are made to go from #F00 to #00F and vice versa this would roughly look like this (note that this is just a rough approximation):

[[Image:DiffusionCurveSimulation.png]]

Note that with diffusion curves the blur itself can also vary along the path, which could be used in the above image to let the edge be sharper in some areas. This is useful for depth of field effects for example.

Normally diffusion curves will have infinite extent, but this can be controlled when needed by surrounding a set of curves with a closed path that has an outside boundary which is fully transparent. Or by simply treating diffusion curves as yet another paint server.

Instead of defining a group that gets diffused it may also make sense to use subpaths and diffuse those:

<path d="M 0,0 L 190,190 M 500,500 L 150,0"
leftBoundary="#F00 #00F #F70 #7F0" rightBoundary="#00F #F00 #0F7 #07F"
boundaryBlur="5" diffuse="true" />

Or (only a single color per point on the path and no blur):

<diffusionGradient id="gradient">
<stop ...>
...
</diffusionGradient>
<path d="M 0,0 L 190,190 M 500,500 L 150,0"
fill="url(#gradient)" />

This could lead to an on-canvas interface (using an extended gradient tool) that looks a bit like this:

[[Image:fudgedDiffCurve.png]]

Here the "gradient stops" are (necessarily) positioned on the path and represented by the circles. The color inside the circles shows the stop color.

==Mathematical Definition==
Diffusion curves are defined as the solution to a Laplace equation (the sum of second partial derivatives is zero) with boundary conditions (the colors on the curves). This is done for both the colors and the blur and then a spatially varying blur is applied to the diffused colors using the diffused blur values.

Alternatively diffusion curves can be seen as minimizing the integral (over the entire image) of the squared gradient magnitude, with color constraints at certain points. This is convenient when using a representation based on triangles with barycentric interpolation (as this yields a piecewise linear function the Laplacian is zero everywhere, except on the boundaries).

It might also be convenient to use an alternative method for incorporating blur, as simulating a spatially varying blur is not easy. One method might be to use an equation based on the heat equation which can be used for doing a spatially varying blur (<math>C</math> represents the color constraints):

<math>\begin{align}
\gamma\frac{\partial}{\partial t}y&=\nabla\cdot(\beta\nabla y)
\\\gamma(f-C)&=\nabla\cdot(\beta\nabla f)
\\0&=\nabla\cdot(\beta\nabla f)+\gamma(C-f)
\\f&=\arg\min_f \int_{\mathbb{R}^2}\frac{1}{2}\|\beta^{1/2}\nabla f\|^2+(C-\frac{1}{2}f)\gamma f\,dx
\end{align}</math>

Or else the color constraints could be applied using the derivative of the colors over each edge in combination with ''the'' color on the edge (which would be the average of the colors on either side). When blurring an edge the derivative would get smaller (by a factor of <math>1/blurRadius</math> for example).

==Converting to SVG==
There would be several possible avenues for converting diffusion curves to SVG:
*Bitmap rendering.
**+ High quality at a specific resolution.
**- Low quality on zooming in.
**- Also large for simple images (although it's not too bad, the gradients compress ''very'' well).
*Using filters (for example, it should be possible to [[Spatially Varying Blur|simulate spatially varying blur]] by doing multiple blurs and combining the results using weights).
**+ Very low (almost fixed) storage requirements.
**- Diffusion difficult to implement efficiently (fast solvers on grids generally use multigrid methods or kernels of spatially varying size).
**- Spatially varying blur is difficult to implement with good quality.
*By solving the Laplace equations on a (Delaunay) triangulation, using barycentric interpolation between the vertices.
**+ Good quality at any resolution.
**+ Storage scales directly with the complexity of the image.
**- Storage can be quite bad for curved geometries (because of the number of triangles needed to approximate the curve).
**- Needs "add" (and "in") compositing, which is only available in filters in SVG 1.1 (it is also available in [http://www.w3.org/TR/SVGCompositing/ SVG Compositing]).
**- A mesh is apparently hard to render in a high quality manner on existing renderers (at least Batik has problems with rendering the triangles precisely).
**Note that other interpolation/approximation schemes can give a higher quality result but are also harder to use in the solver (as well as in the resulting SVG).
*It might be possible to use the result of a boundary element computation directly and just combine basis functions.

==Questions/Problems==
*If diffusion curves are indeed represented by paths inside a group, what happens with subgroups or shapes without having gradients defined along their edges?
*What should happen with 2D objects (filled shapes and strokes) in diffusion groups?
**It might actually be interesting to not only set colors and blur values (heat capacity?) along the sides of edges (1D), but also for surfaces (2D). This shouldn't complicate things much. In fact, it might even be slightly easier to handle the 2D case properly (as it is easier to discretize for example).
*It might be interesting to redefine them in some way that unifies the color diffusion and blurring. E.g. currently colors are either to be met exactly or not at all, is it possible to reformulate the problem in such a way that we can restrict colors to varying degrees?
*Could a diffusion curve have a stop which is not completely opaque? I would find this useful for creating lighting effects over surfaces. --[[User:Pajarico|Pajarico]] 23:11, 15 January 2011 (UTC)

==Links==
*Original paper: http://artis.imag.fr/Publications/2008/OBWBTS08/
*PhD thesis (including a method for vectorizing Diffusion Curves): http://artis.imag.fr/Publications/2009/Orz09/
*Diffusion constraints: http://artis.inrialpes.fr/Publications/2010/BEDT10/
*Faster/better solver: http://www.cg.tuwien.ac.at/research/publications/2009/jeschke-09-solver/
*Application of diffusion curves to texture rendering: http://www.cg.tuwien.ac.at/research/publications/2009/jeschke-09-rendering/
*An initial implementation: https://code.launchpad.net/~jaspervdg/+junk/diffuselib
*More references: http://www.citeulike.org/user/jaspervdg/tag/diffusion_curves

SpecInformativeUI

2011-01-10T20:40:26Z

Pajarico: /* Design */

SpecInformativeUI

2011-01-10T20:39:37Z

Pajarico: /* Design */

SpecInformativeUI

2011-01-10T20:38:57Z

Pajarico: /* Rationale */

SpecInformativeUI

2011-01-10T20:37:56Z

Pajarico: /* Summary */

SpecInformativeUI

2011-01-10T20:27:20Z

Pajarico: initial edit, bare bones

Launchpad Entry:
https://blueprints.launchpad.net/inkscape/+spec/informative-ui

== Summary ==

== Release Note ==
== Rationale ==
== Design ==

=== UI ===

=== Usage ===

== TODO ==
== Discussion ==

User:Pajarico

2011-01-09T19:47:08Z

Pajarico: /* Tweak tool addition */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==

1. When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

2. Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now, is not possible to edit linestyles unless you use the XML editor:
* Not easily discoverable for new users.
* Not easy to use.
* The update is not immediate and the user has to fiddle a lot with values to get the expected design.

I propose adding some text input boxes to the ''Stroke style'' tab were the user can input several values like this:

|box 1|box 2|box 3| box 4|box 5|

So odd numbers add a stroke of that lenght, while even boxes add a space of that lenght.

I think 5 boxes would be enough to get complex patterns, but more boxes could be added if needed (the reference doesn't seem to have a limit about this).

=== [DONE] Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-01-09T19:02:24Z

Pajarico: /* Better linestyle edition */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==

1. When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

2. Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now, is not possible to edit linestyles unless you use the XML editor:
* Not easily discoverable for new users.
* Not easy to use.
* The update is not immediate and the user has to fiddle a lot with values to get the expected design.

I propose adding some text input boxes to the ''Stroke style'' tab were the user can input several values like this:

|box 1|box 2|box 3| box 4|box 5|

So odd numbers add a stroke of that lenght, while even boxes add a space of that lenght.

I think 5 boxes would be enough to get complex patterns, but more boxes could be added if needed (the reference doesn't seem to have a limit about this).

=== Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects). '''DONE'''

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-01-09T18:48:21Z

Pajarico: /* Better markers edition */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==

1. When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

2. Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now

=== Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects). '''DONE'''

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-01-09T18:46:13Z

Pajarico: /* Tweak tool addition */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==

1. When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

2. Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Better markers edition ===
Markers have several propierties (see [http://www.w3.org/TR/SVG/painting.html#Markers| SVG reference]) that should be exposed to the user:
* Size (markerWidth, markerHeight).
* Rotation (orient).
* Offset from the normal position (refX, refY).
* Transformations relative to... (markerUnits):
:* ...to stroke width (strokeWidth).
:* ...to object's coordinates (userSpaceOnUse). [I'm unsure]
* Colour: Inherit from stroke or user selected (see bug [https://bugs.launchpad.net/inkscape/+bug/165865|#165865]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

=== Better linestyle edition ===
Right now

=== Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects). '''DONE'''

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-01-09T16:13:50Z

Pajarico: /* Informative UI (hyperlink-like shortcuts on UI) */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==

1. When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

2. Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.
Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-01-09T16:05:34Z

Pajarico: /* Informative UI */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==

1. When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

2. Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI (hyperlink-like shortcuts on UI) ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect'': This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-01-09T16:01:59Z

Pajarico: /* What grinds my gears (small annoying bugs) */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==

1. When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

2. Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect''): This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-01-09T02:41:07Z

Pajarico: /* What grinds my gears (small annoying bugs) */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==

# When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

# Editing Spiro splines could be improved.
:* The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.
::* Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).
:* Nodes cannot be added clicking on the spiro path.
:* The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
:* Many of the options on the toolbar do not apply for spiros:
::* Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
::* Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect''): This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-01-09T01:44:57Z

Pajarico: /* Interesting projects by other people */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

== What grinds my gears (small annoying bugs) ==

# When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.
:'''Expected:''' blur should be added to the other filter.
:'''Workaround:''' group the object and ''then'' apply blur.

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect''): This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-01-09T00:49:01Z

Pajarico: /* Informative UI */

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''. [Rest cut for this example]

In other words:

* '''Type of object''' (N nodes, path effect: name_of_path_effect); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

* '''Type of object''' (N nodes, ''path effect: name_of_path_effect''); ''filtered (name_of_filter)'', in layer '''name_of_layer'''.

:* ''path effect: name_of_path_effect''): This shortcuts to the LPE editor dialog.

:* ''filtered (name_of_filter)'': This shortcuts to the filter editor dialog.

Additionally, '''name_of_layer''' could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a ''Read more...'' link to a tutorial would help. Tooltips could have a link to specific tutorials too.

Advantages:
# Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
# The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
# Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
# It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:
# Might not be doable in GTK+ (unsure).

=== Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:Pajarico

2011-01-08T21:40:14Z

Pajarico: /* Blueprints */ adding an idea for the UI

== Notes ==
Command to revert to an older SVN revision:

<nowiki>svn update -r 19664</nowiki>

== Interesting projects by other people ==
[http://people.happycoders.org/kamih/wordpress/?page_id=46 LazyNezumi]

[http://hci.uwaterloo.ca/Publications/Papers/uist222-fung.pdf Kinematic Templates],
[http://www.nabble.com/Kinematic-Templates-td23451540.html 2]

[http://www.digitalartsonline.co.uk/tutorials/index.cfm?featureid=1675 Patterns in Illustrator]

==Blueprints==
[[User:Pajarico/BlueprintTemplate|Blueprint template]]

[[User:Pajarico/UserOrientedDebugAndReport|User oriented debug and report]]

=== Informative UI ===
Right now the status bar has information displayed as this:
* '''Path''' (21 nodes, path effect: Spiro spline); ''filtered (Evanescence)'', in layer '''color'''.

=== Tweak tool addition ===
A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

=== Spray tool ===
Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:
* Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
* Size of the "brush".
* Random size variations.
* Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
* Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):
* The paint pours from dense zones (areas where in a click and hold action get too many "paint").

===Drop Shadow LPE===
http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

===Bevel/Extrusion/Emboss LPE===
Bevel/Extrusion/Emboss on CorelDraw X3:
http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

===Tesselation LPE===
http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

===Lens LPE===
Synfig lens:
http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:
* The helper of this LPE should be a circumference which is the effect area.
* The lenses can be concave or convex, meaning a different deformation happens.
* The user controls:
** Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
* I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

===Sketch===
Improve it by adding the sketch effect to the fill instead of only to the stroke.

===Revision Control===
http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a ''Site uploading'' feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

===Extensions Repository===
Ideas:
* Searchable content based on tags, categories, descriptions, name, etc.
* Downloadable content ready to use.
* See description and screenshot before downloading.
* Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:
* Security issues when dealing with external files/apps.
* Trusting of the extension/author.
* Current extensions are not sandboxed.
* Portability on scenarios where the architecture may play a role.

[https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions/ Current extensions in SVN]

[http://wiki.inkscape.org/wiki/index.php/ExtensionArchitectureProposals ExtensionArchitectureProposals]

[http://wiki.inkscape.org/wiki/index.php/ExtensionsSystem ExtensionsSystem]

<pre>
<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] ï»¿KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] ï»¿Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] ï»¿Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] ï»¿Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] ï»¿Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] ï»¿Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] ï»¿Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] ï»¿BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] ï»¿Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] ï»¿BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] ï»¿Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] ï»¿BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] ï»¿Pajarico: probably
<^-> [JonCruz] ï»¿BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] ï»¿BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] ï»¿Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] ï»¿Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] ï»¿wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] ï»¿wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] ï»¿Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows. :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> ï»¿Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go. As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is. A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs. XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected
</pre>

User:~suv

2009-10-26T19:21:55Z

Pajarico: /* objects / attributes / actions */

== scratch pad ==
:test ;-)

== bug tracker: tags ==

* inkscape-devel thread: "[http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/31517 bug tracker: Guideslines for tags?]"
* where to keep an updated list of used inkscape bug tracker (launchpad) tags?
* tags-list <strike>2009-09-22</strike> <https://bugs.edge.launchpad.net/inkscape>:
* tags-list 2009-10-12 <https://bugs.edge.launchpad.net/inkscape>:

2geom
3d
3dbox
64-bit
accessibility
<strike>aim</strike>
all-platforms
<strike>alpha</strike>
amd64
<strike>angle</strike>
<strike>angular</strike>
apport-bug
apport-collected
apport-crash
<strike>arabic</strike>
<strike>automation</strike>
autosave
<strike>axonometric</strike>
bezier
bidi
bitmap
blur
bounding
box
bsd
build
build-compile-code-design
cairo
calligraphy
cdr
<strike>centre</strike>
<strike>chameleon</strike>
clipboard
clipping
<strike>clipping-path</strike>
<strike>clone</strike>
clones
<strike>closepath</strike>
color
<strike>compiz</strike>
<strike>cone</strike>
<strike>conic</strike>
connectors
<strike>content</strike>
<strike>coordinates</strike>
<strike>copy</strike>
<strike>copy-paste</strike>
<strike>craah</strike>
crash
<strike>creating</strike>
css
<strike>cyrillic</strike>
<strike>declaration</strike>
<strike>defs</strike>
desktop-integration
dia
dialogs
<strike>displaced</strike>
display
<strike>distort</strike>
<strike>document-properties</strike>
documentation
dxf
<strike>effects</strike>
emf
eps
<strike>erase</strike>
eraser
<strike>evince</strike>
<strike>expand</strike>
export
exporting
<strike>extension</strike>
extensions
extensions-plugins
<strike>feature</strike>
fill
filters-svg
<strike>fit</strike>
<strike>fit-page-to-selection</strike>
<strike>focus</strike>
<strike>font</strike>
fonts
<strike>free</strike>
freehand
<strike>freeze</strike>
<strike>full</strike>
fullscreen
<strike>gamma</strike>
<strike>gnome</strike>
gnuplot
gradient
<strike>grid</strike>
grids
<strike>group</strike>
<strike>grouped</strike>
<strike>grouping</strike>
gsoc2009-color
guides
<strike>hand</strike>
<strike>help</strike>
<strike>history</strike>
<strike>href</strike>
<strike>http</strike>
<strike>icons</strike>
<strike>image</strike>
<strike>imagemagick</strike>
<strike>import</strike>
import-export
importing
inkboard
inkscape
installer
<strike>internet</strike>
<strike>invisible-layer</strike>
java
javafx
<strike>kern</strike>
kerning
<strike>keyboard</strike>
keys
<strike>landscape</strike>
latex
<strike>layer</strike>
layers
licence
ligature
ligatures
line-height
link
linux
<strike>list</strike>
livepatheffects
<strike>load</strike>
<strike>localisation</strike>
<strike>locking</strike>
logo
<strike>lpe</strike>
<strike>mac</strike>
macosx
<strike>management</strike>
<strike>marker</strike>
markers
<strike>maximize</strike>
<strike>maximum</strike>
<strike>memory</strike>
<strike>menu</strike>
metadata
<strike>motif</strike>
<strike>mouse</strike>
needs-confirm-on-svn-head
<strike>netbook</strike>
<strike>node</strike>
node-editing
<strike>nodes</strike>
<strike>non-grouped</strike>
<strike>object</strike>
object-shape
object-text
<strike>object-to-pattern</strike>
objects
objects-freehand-calligraphic
objects-gradients
objects-markers
objects-nodes
objects-pattern
odg
<strike>on</strike>
<strike>opacity</strike>
openclipart
<strike>orientation</strike>
<strike>ornemantal</strike>
osx
other
<strike>oversampling</strike>
packaging
<strike>page</strike>
<strike>paper</strike>
<strike>paste</strike>
patch
path
pattern
pdf
<strike>pdf-import</strike>
pencil
performance
perspective
<strike>planes</strike>
png
poppler
<strike>portable</strike>
<strike>position</strike>
<strike>positioning</strike>
<strike>preview</strike>
<strike>print</strike>
printing
<strike>problem</strike>
<strike>process</strike>
<strike>proxy</strike>
ps
psfrag
python
<strike>quality</strike>
<strike>radial-gradient-fill</strike>
<strike>radialgradient</strike>
<strike>reference</strike>
regression
<strike>remember</strike>
<strike>remove</strike>
<strike>render</strike>
renderer
<strike>request</strike>
<strike>resize</strike>
<strike>restore</strike>
<strike>romanian</strike>
<strike>rotation</strike>
rulers
<strike>save</strike>
saving
script
<strike>scripts</strike>
<strike>select</strike>
<strike>selection</strike>
<strike>serbian</strike>
shape-editing
<strike>single-dots</strike>
size
<strike>slider</strike>
<strike>slovenian</strike>
snapping
<strike>snapshot</strike>
soc-2008-juca
solaris
<strike>solarize</strike>
<strike>sparse</strike>
<strike>spiral</strike>
<strike>spiro</strike>
<strike>stamp</strike>
stroke
<strike>stroke-width</strike>
style
styles
svg
svg-xml
<strike>symmetry</strike>
tablet
text
<strike>text-tool</strike>
<strike>tiled-clones</strike>
<strike>tool</strike>
<strike>tools</strike>
transformations
translation
<strike>translation-geometry</strike>
<strike>transparency</strike>
tutorials
<strike>ubuntu</strike>
ui
ui-dialogs-toolbars
ui-guide-grid-ruler
ui-palette-color
ui-preferences
ui-preview
ui-selection-group-layer
ui-shortcuts
ui-text
ui-xml
undo
<strike>unexpected-error</strike>
ungroup
usability
<strike>usb</strike>
<strike>value</strike>
<strike>version</strike>
<strike>vertical</strike>
viewbox
<strike>vista</strike>
vml
<strike>website</strike>
wiki
win32
win32-vista
window
wishlist
<strike>with</strike>
wmf
x11
xaml
<strike>xlink</strike>
xmleditor
zoom

=== Status info? ===
Currently there is no method available (or in reach of my limited skills?) to extract used tags from the launchpad bug tracker. Bug tracker notifications per e-mail contain a X-header field (X-Launchpad-Bug-Tags) that lists the current tags of a bug report and any changes to the tags is listed as part of the message body.
:list of [[ extracted bug tags ]] from the mbox since I joined the bug team ''( last update: Mon, 26 Oct 2009 09:57:36 CET)''

=== Categories for tags in use? ===
how to categorize & consolidate above list of (existing/in-use) tags on launchpad?
:Issue: Launchpad UI only allows search for tags with exact match (i.e. a full text search can only be limited by known tags)
:TODO: compare with [[Inkscape glossary]] ?
:Note: this is not a proposal - just trying to keep track of status-quo
==== objects / attributes / actions ====
'''-- objects'''
*object-shape
*object-text
*objects
*objects-freehand-calligraphic
*objects-gradients
*objects-markers
*objects-nodes
*objects-pattern
*path
*text

'''-- attributes'''
*alpha
*color
*fill
*gradient
*<strike>kerning</strike> not used anymore
*line-height
*opacity
*<strike>style</strike> not used anymore
*styles
*stroke
*transparency

'''-- actions''' (verbs?)
*blur
*clipping
*eraser
*groups
*livepatheffects
*locking
*node-editing
*shape-editing
*snapping
*transformations
*undo
*<strike>ungroup</strike> not used anymore
*zoom

'''-- svg?'''
*bitmap
*clones
*css
*defs
*gradient
*grids
*guides
*layers
*link
*markers
*pattern
*viewbox
*window

==== tools ====
*3dbox
*bezier
*calligraphy
*connectors
*eraser
*freehand
*gradient
*pencil
*perspective
*text
*xmleditor

==== modules ====
*svg
*svg-xml
*css/styles
*filters-svg
*livepatheffects
*text/fonts
-
*2geom
-
*renderer
*cairo
*poppler
-
*inkboard
*extensions
*extensions-plugins
*plugins
*python
-
*x11

==== user interface ====
'''-- graphical'''
*autosave
*clipboard
*desktop-integration
*icons
*fullscreen
*rulers
*ui
*ui-dialogs-toolbars
*ui-guide-grid-ruler
*ui-palette-color
*ui-preferences
*ui-preview
*ui-selection-group-layer
*ui-shortcuts
*ui-text
*ui-xml

'''-- keys'''

'''-- cli'''

'''-- verbs'''
*exporting
*importing
*printing
*saving

==== build ====
*build-compile-code-design
*configure
*build
*packaging
*installer

==== export-import formats ====
*cdr
*dia
*dxf
*emf
*eps
*gnuplot
*javafx
*latex
*odg
*pdf
*png
*ps
*vml
*wmf
*xaml

==== platforms ====
*all-platforms
*bsd
*linux
*osx
*solaris
*win32
*win32-vista

==== documentation ====
*doumentation
*licence
*logo
*metadata
*tutorials
*translation
*website
*wiki

==== triage ====
*blocker
*needs-confirm-on-svn-head
*regression

==== other ====
*accessibility
*gsoc2009-color
*ocal (Open Clipart Library)
*other
*soc-2008-juca
*usability
*wishlist

== debug extension ==
; tool to display info about extension system, loaded modules, versions... : Bug [https://bugs.edge.launchpad.net/inkscape/+bug/448285 #448285] “lxml version bundled with Inkscape is old”

User:~suv

2009-10-26T19:19:07Z

Pajarico: /* objects / attributes / actions */

== scratch pad ==
:test ;-)

== bug tracker: tags ==

* inkscape-devel thread: "[http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/31517 bug tracker: Guideslines for tags?]"
* where to keep an updated list of used inkscape bug tracker (launchpad) tags?
* tags-list <strike>2009-09-22</strike> <https://bugs.edge.launchpad.net/inkscape>:
* tags-list 2009-10-12 <https://bugs.edge.launchpad.net/inkscape>:

2geom
3d
3dbox
64-bit
accessibility
<strike>aim</strike>
all-platforms
<strike>alpha</strike>
amd64
<strike>angle</strike>
<strike>angular</strike>
apport-bug
apport-collected
apport-crash
<strike>arabic</strike>
<strike>automation</strike>
autosave
<strike>axonometric</strike>
bezier
bidi
bitmap
blur
bounding
box
bsd
build
build-compile-code-design
cairo
calligraphy
cdr
<strike>centre</strike>
<strike>chameleon</strike>
clipboard
clipping
<strike>clipping-path</strike>
<strike>clone</strike>
clones
<strike>closepath</strike>
color
<strike>compiz</strike>
<strike>cone</strike>
<strike>conic</strike>
connectors
<strike>content</strike>
<strike>coordinates</strike>
<strike>copy</strike>
<strike>copy-paste</strike>
<strike>craah</strike>
crash
<strike>creating</strike>
css
<strike>cyrillic</strike>
<strike>declaration</strike>
<strike>defs</strike>
desktop-integration
dia
dialogs
<strike>displaced</strike>
display
<strike>distort</strike>
<strike>document-properties</strike>
documentation
dxf
<strike>effects</strike>
emf
eps
<strike>erase</strike>
eraser
<strike>evince</strike>
<strike>expand</strike>
export
exporting
<strike>extension</strike>
extensions
extensions-plugins
<strike>feature</strike>
fill
filters-svg
<strike>fit</strike>
<strike>fit-page-to-selection</strike>
<strike>focus</strike>
<strike>font</strike>
fonts
<strike>free</strike>
freehand
<strike>freeze</strike>
<strike>full</strike>
fullscreen
<strike>gamma</strike>
<strike>gnome</strike>
gnuplot
gradient
<strike>grid</strike>
grids
<strike>group</strike>
<strike>grouped</strike>
<strike>grouping</strike>
gsoc2009-color
guides
<strike>hand</strike>
<strike>help</strike>
<strike>history</strike>
<strike>href</strike>
<strike>http</strike>
<strike>icons</strike>
<strike>image</strike>
<strike>imagemagick</strike>
<strike>import</strike>
import-export
importing
inkboard
inkscape
installer
<strike>internet</strike>
<strike>invisible-layer</strike>
java
javafx
<strike>kern</strike>
kerning
<strike>keyboard</strike>
keys
<strike>landscape</strike>
latex
<strike>layer</strike>
layers
licence
ligature
ligatures
line-height
link
linux
<strike>list</strike>
livepatheffects
<strike>load</strike>
<strike>localisation</strike>
<strike>locking</strike>
logo
<strike>lpe</strike>
<strike>mac</strike>
macosx
<strike>management</strike>
<strike>marker</strike>
markers
<strike>maximize</strike>
<strike>maximum</strike>
<strike>memory</strike>
<strike>menu</strike>
metadata
<strike>motif</strike>
<strike>mouse</strike>
needs-confirm-on-svn-head
<strike>netbook</strike>
<strike>node</strike>
node-editing
<strike>nodes</strike>
<strike>non-grouped</strike>
<strike>object</strike>
object-shape
object-text
<strike>object-to-pattern</strike>
objects
objects-freehand-calligraphic
objects-gradients
objects-markers
objects-nodes
objects-pattern
odg
<strike>on</strike>
<strike>opacity</strike>
openclipart
<strike>orientation</strike>
<strike>ornemantal</strike>
osx
other
<strike>oversampling</strike>
packaging
<strike>page</strike>
<strike>paper</strike>
<strike>paste</strike>
patch
path
pattern
pdf
<strike>pdf-import</strike>
pencil
performance
perspective
<strike>planes</strike>
png
poppler
<strike>portable</strike>
<strike>position</strike>
<strike>positioning</strike>
<strike>preview</strike>
<strike>print</strike>
printing
<strike>problem</strike>
<strike>process</strike>
<strike>proxy</strike>
ps
psfrag
python
<strike>quality</strike>
<strike>radial-gradient-fill</strike>
<strike>radialgradient</strike>
<strike>reference</strike>
regression
<strike>remember</strike>
<strike>remove</strike>
<strike>render</strike>
renderer
<strike>request</strike>
<strike>resize</strike>
<strike>restore</strike>
<strike>romanian</strike>
<strike>rotation</strike>
rulers
<strike>save</strike>
saving
script
<strike>scripts</strike>
<strike>select</strike>
<strike>selection</strike>
<strike>serbian</strike>
shape-editing
<strike>single-dots</strike>
size
<strike>slider</strike>
<strike>slovenian</strike>
snapping
<strike>snapshot</strike>
soc-2008-juca
solaris
<strike>solarize</strike>
<strike>sparse</strike>
<strike>spiral</strike>
<strike>spiro</strike>
<strike>stamp</strike>
stroke
<strike>stroke-width</strike>
style
styles
svg
svg-xml
<strike>symmetry</strike>
tablet
text
<strike>text-tool</strike>
<strike>tiled-clones</strike>
<strike>tool</strike>
<strike>tools</strike>
transformations
translation
<strike>translation-geometry</strike>
<strike>transparency</strike>
tutorials
<strike>ubuntu</strike>
ui
ui-dialogs-toolbars
ui-guide-grid-ruler
ui-palette-color
ui-preferences
ui-preview
ui-selection-group-layer
ui-shortcuts
ui-text
ui-xml
undo
<strike>unexpected-error</strike>
ungroup
usability
<strike>usb</strike>
<strike>value</strike>
<strike>version</strike>
<strike>vertical</strike>
viewbox
<strike>vista</strike>
vml
<strike>website</strike>
wiki
win32
win32-vista
window
wishlist
<strike>with</strike>
wmf
x11
xaml
<strike>xlink</strike>
xmleditor
zoom

=== Status info? ===
Currently there is no method available (or in reach of my limited skills?) to extract used tags from the launchpad bug tracker. Bug tracker notifications per e-mail contain a X-header field (X-Launchpad-Bug-Tags) that lists the current tags of a bug report and any changes to the tags is listed as part of the message body.
:list of [[ extracted bug tags ]] from the mbox since I joined the bug team ''( last update: Mon, 26 Oct 2009 09:57:36 CET)''

=== Categories for tags in use? ===
how to categorize & consolidate above list of (existing/in-use) tags on launchpad?
:Issue: Launchpad UI only allows search for tags with exact match (i.e. a full text search can only be limited by known tags)
:TODO: compare with [[Inkscape glossary]] ?
:Note: this is not a proposal - just trying to keep track of status-quo
==== objects / attributes / actions ====
'''-- objects'''
*object-shape
*object-text
*objects
*objects-freehand-calligraphic
*objects-gradients
*objects-markers
*objects-nodes
*objects-pattern
*path
*text

'''-- attributes'''
*alpha
*color
*fill
*gradient
<strike>*kerning</strike> not used anymore
*line-height
*opacity
<strike>*style</strike> not used anymore
*styles
*stroke
*transparency

'''-- actions''' (verbs?)
*blur
*clipping
*eraser
*livepatheffects
*locking
*node-editing
*shape-editing
*snapping
*transformations
*undo
<strike>*ungroup</strike> not used anymore
*zoom

'''-- svg?'''
*bitmap
*clones
*css
*defs
*gradient
*grids
*guides
*layers
*link
*markers
*pattern
*viewbox
*window

==== tools ====
*3dbox
*bezier
*calligraphy
*connectors
*eraser
*freehand
*gradient
*pencil
*perspective
*text
*xmleditor

==== modules ====
*svg
*svg-xml
*css/styles
*filters-svg
*livepatheffects
*text/fonts
-
*2geom
-
*renderer
*cairo
*poppler
-
*inkboard
*extensions
*extensions-plugins
*plugins
*python
-
*x11

==== user interface ====
'''-- graphical'''
*autosave
*clipboard
*desktop-integration
*icons
*fullscreen
*rulers
*ui
*ui-dialogs-toolbars
*ui-guide-grid-ruler
*ui-palette-color
*ui-preferences
*ui-preview
*ui-selection-group-layer
*ui-shortcuts
*ui-text
*ui-xml

'''-- keys'''

'''-- cli'''

'''-- verbs'''
*exporting
*importing
*printing
*saving

==== build ====
*build-compile-code-design
*configure
*build
*packaging
*installer

==== export-import formats ====
*cdr
*dia
*dxf
*emf
*eps
*gnuplot
*javafx
*latex
*odg
*pdf
*png
*ps
*vml
*wmf
*xaml

==== platforms ====
*all-platforms
*bsd
*linux
*osx
*solaris
*win32
*win32-vista

==== documentation ====
*doumentation
*licence
*logo
*metadata
*tutorials
*translation
*website
*wiki

==== triage ====
*blocker
*needs-confirm-on-svn-head
*regression

==== other ====
*accessibility
*gsoc2009-color
*ocal (Open Clipart Library)
*other
*soc-2008-juca
*usability
*wishlist

== debug extension ==
; tool to display info about extension system, loaded modules, versions... : Bug [https://bugs.edge.launchpad.net/inkscape/+bug/448285 #448285] “lxml version bundled with Inkscape is old”

User:~suv

2009-10-26T19:13:46Z

Pajarico: /* objects / attributes / actions */ I removed these two in favor of 'text'+'fonts'

== scratch pad ==
:test ;-)

== bug tracker: tags ==

* inkscape-devel thread: "[http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/31517 bug tracker: Guideslines for tags?]"
* where to keep an updated list of used inkscape bug tracker (launchpad) tags?
* tags-list <strike>2009-09-22</strike> <https://bugs.edge.launchpad.net/inkscape>:
* tags-list 2009-10-12 <https://bugs.edge.launchpad.net/inkscape>:

2geom
3d
3dbox
64-bit
accessibility
<strike>aim</strike>
all-platforms
<strike>alpha</strike>
amd64
<strike>angle</strike>
<strike>angular</strike>
apport-bug
apport-collected
apport-crash
<strike>arabic</strike>
<strike>automation</strike>
autosave
<strike>axonometric</strike>
bezier
bidi
bitmap
blur
bounding
box
bsd
build
build-compile-code-design
cairo
calligraphy
cdr
<strike>centre</strike>
<strike>chameleon</strike>
clipboard
clipping
<strike>clipping-path</strike>
<strike>clone</strike>
clones
<strike>closepath</strike>
color
<strike>compiz</strike>
<strike>cone</strike>
<strike>conic</strike>
connectors
<strike>content</strike>
<strike>coordinates</strike>
<strike>copy</strike>
<strike>copy-paste</strike>
<strike>craah</strike>
crash
<strike>creating</strike>
css
<strike>cyrillic</strike>
<strike>declaration</strike>
<strike>defs</strike>
desktop-integration
dia
dialogs
<strike>displaced</strike>
display
<strike>distort</strike>
<strike>document-properties</strike>
documentation
dxf
<strike>effects</strike>
emf
eps
<strike>erase</strike>
eraser
<strike>evince</strike>
<strike>expand</strike>
export
exporting
<strike>extension</strike>
extensions
extensions-plugins
<strike>feature</strike>
fill
filters-svg
<strike>fit</strike>
<strike>fit-page-to-selection</strike>
<strike>focus</strike>
<strike>font</strike>
fonts
<strike>free</strike>
freehand
<strike>freeze</strike>
<strike>full</strike>
fullscreen
<strike>gamma</strike>
<strike>gnome</strike>
gnuplot
gradient
<strike>grid</strike>
grids
<strike>group</strike>
<strike>grouped</strike>
<strike>grouping</strike>
gsoc2009-color
guides
<strike>hand</strike>
<strike>help</strike>
<strike>history</strike>
<strike>href</strike>
<strike>http</strike>
<strike>icons</strike>
<strike>image</strike>
<strike>imagemagick</strike>
<strike>import</strike>
import-export
importing
inkboard
inkscape
installer
<strike>internet</strike>
<strike>invisible-layer</strike>
java
javafx
<strike>kern</strike>
kerning
<strike>keyboard</strike>
keys
<strike>landscape</strike>
latex
<strike>layer</strike>
layers
licence
ligature
ligatures
line-height
link
linux
<strike>list</strike>
livepatheffects
<strike>load</strike>
<strike>localisation</strike>
<strike>locking</strike>
logo
<strike>lpe</strike>
<strike>mac</strike>
macosx
<strike>management</strike>
<strike>marker</strike>
markers
<strike>maximize</strike>
<strike>maximum</strike>
<strike>memory</strike>
<strike>menu</strike>
metadata
<strike>motif</strike>
<strike>mouse</strike>
needs-confirm-on-svn-head
<strike>netbook</strike>
<strike>node</strike>
node-editing
<strike>nodes</strike>
<strike>non-grouped</strike>
<strike>object</strike>
object-shape
object-text
<strike>object-to-pattern</strike>
objects
objects-freehand-calligraphic
objects-gradients
objects-markers
objects-nodes
objects-pattern
odg
<strike>on</strike>
<strike>opacity</strike>
openclipart
<strike>orientation</strike>
<strike>ornemantal</strike>
osx
other
<strike>oversampling</strike>
packaging
<strike>page</strike>
<strike>paper</strike>
<strike>paste</strike>
patch
path
pattern
pdf
<strike>pdf-import</strike>
pencil
performance
perspective
<strike>planes</strike>
png
poppler
<strike>portable</strike>
<strike>position</strike>
<strike>positioning</strike>
<strike>preview</strike>
<strike>print</strike>
printing
<strike>problem</strike>
<strike>process</strike>
<strike>proxy</strike>
ps
psfrag
python
<strike>quality</strike>
<strike>radial-gradient-fill</strike>
<strike>radialgradient</strike>
<strike>reference</strike>
regression
<strike>remember</strike>
<strike>remove</strike>
<strike>render</strike>
renderer
<strike>request</strike>
<strike>resize</strike>
<strike>restore</strike>
<strike>romanian</strike>
<strike>rotation</strike>
rulers
<strike>save</strike>
saving
script
<strike>scripts</strike>
<strike>select</strike>
<strike>selection</strike>
<strike>serbian</strike>
shape-editing
<strike>single-dots</strike>
size
<strike>slider</strike>
<strike>slovenian</strike>
snapping
<strike>snapshot</strike>
soc-2008-juca
solaris
<strike>solarize</strike>
<strike>sparse</strike>
<strike>spiral</strike>
<strike>spiro</strike>
<strike>stamp</strike>
stroke
<strike>stroke-width</strike>
style
styles
svg
svg-xml
<strike>symmetry</strike>
tablet
text
<strike>text-tool</strike>
<strike>tiled-clones</strike>
<strike>tool</strike>
<strike>tools</strike>
transformations
translation
<strike>translation-geometry</strike>
<strike>transparency</strike>
tutorials
<strike>ubuntu</strike>
ui
ui-dialogs-toolbars
ui-guide-grid-ruler
ui-palette-color
ui-preferences
ui-preview
ui-selection-group-layer
ui-shortcuts
ui-text
ui-xml
undo
<strike>unexpected-error</strike>
ungroup
usability
<strike>usb</strike>
<strike>value</strike>
<strike>version</strike>
<strike>vertical</strike>
viewbox
<strike>vista</strike>
vml
<strike>website</strike>
wiki
win32
win32-vista
window
wishlist
<strike>with</strike>
wmf
x11
xaml
<strike>xlink</strike>
xmleditor
zoom

=== Status info? ===
Currently there is no method available (or in reach of my limited skills?) to extract used tags from the launchpad bug tracker. Bug tracker notifications per e-mail contain a X-header field (X-Launchpad-Bug-Tags) that lists the current tags of a bug report and any changes to the tags is listed as part of the message body.
:list of [[ extracted bug tags ]] from the mbox since I joined the bug team ''( last update: Mon, 26 Oct 2009 09:57:36 CET)''

=== Categories for tags in use? ===
how to categorize & consolidate above list of (existing/in-use) tags on launchpad?
:Issue: Launchpad UI only allows search for tags with exact match (i.e. a full text search can only be limited by known tags)
:TODO: compare with [[Inkscape glossary]] ?
:Note: this is not a proposal - just trying to keep track of status-quo
==== objects / attributes / actions ====
'''-- objects'''
*object-shape
*object-text
*objects
*objects-freehand-calligraphic
*objects-gradients
*objects-markers
*objects-nodes
*objects-pattern
*path
*text

'''-- attributes'''
*alpha
*color
*fill
*gradient
*kerning
*line-height
*opacity
*style
*styles
*stroke
*transparency

'''-- actions''' (verbs?)
*blur
*clipping
*erase
*livepatheffects
*locking
*node-editing
*shape-editing
*snapping
*transformations
*undo
*ungroup
*zoom

'''-- svg?'''
*bitmap
*clones
*css
*defs
*gradient
*grids
*guides
*layers
*link
*markers
*pattern
*viewbox
*window

==== tools ====
*3dbox
*bezier
*calligraphy
*connectors
*eraser
*freehand
*gradient
*pencil
*perspective
*text
*xmleditor

==== modules ====
*svg
*svg-xml
*css/styles
*filters-svg
*livepatheffects
*text/fonts
-
*2geom
-
*renderer
*cairo
*poppler
-
*inkboard
*extensions
*extensions-plugins
*plugins
*python
-
*x11

==== user interface ====
'''-- graphical'''
*autosave
*clipboard
*desktop-integration
*icons
*fullscreen
*rulers
*ui
*ui-dialogs-toolbars
*ui-guide-grid-ruler
*ui-palette-color
*ui-preferences
*ui-preview
*ui-selection-group-layer
*ui-shortcuts
*ui-text
*ui-xml

'''-- keys'''

'''-- cli'''

'''-- verbs'''
*exporting
*importing
*printing
*saving

==== build ====
*build-compile-code-design
*configure
*build
*packaging
*installer

==== export-import formats ====
*cdr
*dia
*dxf
*emf
*eps
*gnuplot
*javafx
*latex
*odg
*pdf
*png
*ps
*vml
*wmf
*xaml

==== platforms ====
*all-platforms
*bsd
*linux
*osx
*solaris
*win32
*win32-vista

==== documentation ====
*doumentation
*licence
*logo
*metadata
*tutorials
*translation
*website
*wiki

==== triage ====
*blocker
*needs-confirm-on-svn-head
*regression

==== other ====
*accessibility
*gsoc2009-color
*ocal (Open Clipart Library)
*other
*soc-2008-juca
*usability
*wishlist

== debug extension ==
; tool to display info about extension system, loaded modules, versions... : Bug [https://bugs.edge.launchpad.net/inkscape/+bug/448285 #448285] “lxml version bundled with Inkscape is old”

User:~suv

2009-10-26T19:12:22Z

Pajarico: /* documentation */

== scratch pad ==
:test ;-)

== bug tracker: tags ==

* inkscape-devel thread: "[http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/31517 bug tracker: Guideslines for tags?]"
* where to keep an updated list of used inkscape bug tracker (launchpad) tags?
* tags-list <strike>2009-09-22</strike> <https://bugs.edge.launchpad.net/inkscape>:
* tags-list 2009-10-12 <https://bugs.edge.launchpad.net/inkscape>:

2geom
3d
3dbox
64-bit
accessibility
<strike>aim</strike>
all-platforms
<strike>alpha</strike>
amd64
<strike>angle</strike>
<strike>angular</strike>
apport-bug
apport-collected
apport-crash
<strike>arabic</strike>
<strike>automation</strike>
autosave
<strike>axonometric</strike>
bezier
bidi
bitmap
blur
bounding
box
bsd
build
build-compile-code-design
cairo
calligraphy
cdr
<strike>centre</strike>
<strike>chameleon</strike>
clipboard
clipping
<strike>clipping-path</strike>
<strike>clone</strike>
clones
<strike>closepath</strike>
color
<strike>compiz</strike>
<strike>cone</strike>
<strike>conic</strike>
connectors
<strike>content</strike>
<strike>coordinates</strike>
<strike>copy</strike>
<strike>copy-paste</strike>
<strike>craah</strike>
crash
<strike>creating</strike>
css
<strike>cyrillic</strike>
<strike>declaration</strike>
<strike>defs</strike>
desktop-integration
dia
dialogs
<strike>displaced</strike>
display
<strike>distort</strike>
<strike>document-properties</strike>
documentation
dxf
<strike>effects</strike>
emf
eps
<strike>erase</strike>
eraser
<strike>evince</strike>
<strike>expand</strike>
export
exporting
<strike>extension</strike>
extensions
extensions-plugins
<strike>feature</strike>
fill
filters-svg
<strike>fit</strike>
<strike>fit-page-to-selection</strike>
<strike>focus</strike>
<strike>font</strike>
fonts
<strike>free</strike>
freehand
<strike>freeze</strike>
<strike>full</strike>
fullscreen
<strike>gamma</strike>
<strike>gnome</strike>
gnuplot
gradient
<strike>grid</strike>
grids
<strike>group</strike>
<strike>grouped</strike>
<strike>grouping</strike>
gsoc2009-color
guides
<strike>hand</strike>
<strike>help</strike>
<strike>history</strike>
<strike>href</strike>
<strike>http</strike>
<strike>icons</strike>
<strike>image</strike>
<strike>imagemagick</strike>
<strike>import</strike>
import-export
importing
inkboard
inkscape
installer
<strike>internet</strike>
<strike>invisible-layer</strike>
java
javafx
<strike>kern</strike>
kerning
<strike>keyboard</strike>
keys
<strike>landscape</strike>
latex
<strike>layer</strike>
layers
licence
ligature
ligatures
line-height
link
linux
<strike>list</strike>
livepatheffects
<strike>load</strike>
<strike>localisation</strike>
<strike>locking</strike>
logo
<strike>lpe</strike>
<strike>mac</strike>
macosx
<strike>management</strike>
<strike>marker</strike>
markers
<strike>maximize</strike>
<strike>maximum</strike>
<strike>memory</strike>
<strike>menu</strike>
metadata
<strike>motif</strike>
<strike>mouse</strike>
needs-confirm-on-svn-head
<strike>netbook</strike>
<strike>node</strike>
node-editing
<strike>nodes</strike>
<strike>non-grouped</strike>
<strike>object</strike>
object-shape
object-text
<strike>object-to-pattern</strike>
objects
objects-freehand-calligraphic
objects-gradients
objects-markers
objects-nodes
objects-pattern
odg
<strike>on</strike>
<strike>opacity</strike>
openclipart
<strike>orientation</strike>
<strike>ornemantal</strike>
osx
other
<strike>oversampling</strike>
packaging
<strike>page</strike>
<strike>paper</strike>
<strike>paste</strike>
patch
path
pattern
pdf
<strike>pdf-import</strike>
pencil
performance
perspective
<strike>planes</strike>
png
poppler
<strike>portable</strike>
<strike>position</strike>
<strike>positioning</strike>
<strike>preview</strike>
<strike>print</strike>
printing
<strike>problem</strike>
<strike>process</strike>
<strike>proxy</strike>
ps
psfrag
python
<strike>quality</strike>
<strike>radial-gradient-fill</strike>
<strike>radialgradient</strike>
<strike>reference</strike>
regression
<strike>remember</strike>
<strike>remove</strike>
<strike>render</strike>
renderer
<strike>request</strike>
<strike>resize</strike>
<strike>restore</strike>
<strike>romanian</strike>
<strike>rotation</strike>
rulers
<strike>save</strike>
saving
script
<strike>scripts</strike>
<strike>select</strike>
<strike>selection</strike>
<strike>serbian</strike>
shape-editing
<strike>single-dots</strike>
size
<strike>slider</strike>
<strike>slovenian</strike>
snapping
<strike>snapshot</strike>
soc-2008-juca
solaris
<strike>solarize</strike>
<strike>sparse</strike>
<strike>spiral</strike>
<strike>spiro</strike>
<strike>stamp</strike>
stroke
<strike>stroke-width</strike>
style
styles
svg
svg-xml
<strike>symmetry</strike>
tablet
text
<strike>text-tool</strike>
<strike>tiled-clones</strike>
<strike>tool</strike>
<strike>tools</strike>
transformations
translation
<strike>translation-geometry</strike>
<strike>transparency</strike>
tutorials
<strike>ubuntu</strike>
ui
ui-dialogs-toolbars
ui-guide-grid-ruler
ui-palette-color
ui-preferences
ui-preview
ui-selection-group-layer
ui-shortcuts
ui-text
ui-xml
undo
<strike>unexpected-error</strike>
ungroup
usability
<strike>usb</strike>
<strike>value</strike>
<strike>version</strike>
<strike>vertical</strike>
viewbox
<strike>vista</strike>
vml
<strike>website</strike>
wiki
win32
win32-vista
window
wishlist
<strike>with</strike>
wmf
x11
xaml
<strike>xlink</strike>
xmleditor
zoom

=== Status info? ===
Currently there is no method available (or in reach of my limited skills?) to extract used tags from the launchpad bug tracker. Bug tracker notifications per e-mail contain a X-header field (X-Launchpad-Bug-Tags) that lists the current tags of a bug report and any changes to the tags is listed as part of the message body.
:list of [[ extracted bug tags ]] from the mbox since I joined the bug team ''( last update: Mon, 26 Oct 2009 09:57:36 CET)''

=== Categories for tags in use? ===
how to categorize & consolidate above list of (existing/in-use) tags on launchpad?
:Issue: Launchpad UI only allows search for tags with exact match (i.e. a full text search can only be limited by known tags)
:TODO: compare with [[Inkscape glossary]] ?
:Note: this is not a proposal - just trying to keep track of status-quo
==== objects / attributes / actions ====
'''-- objects'''
*object-shape
*object-text
*objects
*objects-freehand-calligraphic
*objects-gradients
*objects-markers
*objects-nodes
*objects-pattern
*path
*text

'''-- attributes'''
*alpha
*color
*fill
*gradient
*kerning
*ligature
*ligatures
*line-height
*opacity
*style
*styles
*stroke
*transparency

'''-- actions''' (verbs?)
*blur
*clipping
*erase
*livepatheffects
*locking
*node-editing
*shape-editing
*snapping
*transformations
*undo
*ungroup
*zoom

'''-- svg?'''
*bitmap
*clones
*css
*defs
*gradient
*grids
*guides
*layers
*link
*markers
*pattern
*viewbox
*window

==== tools ====
*3dbox
*bezier
*calligraphy
*connectors
*eraser
*freehand
*gradient
*pencil
*perspective
*text
*xmleditor

==== modules ====
*svg
*svg-xml
*css/styles
*filters-svg
*livepatheffects
*text/fonts
-
*2geom
-
*renderer
*cairo
*poppler
-
*inkboard
*extensions
*extensions-plugins
*plugins
*python
-
*x11

==== user interface ====
'''-- graphical'''
*autosave
*clipboard
*desktop-integration
*icons
*fullscreen
*rulers
*ui
*ui-dialogs-toolbars
*ui-guide-grid-ruler
*ui-palette-color
*ui-preferences
*ui-preview
*ui-selection-group-layer
*ui-shortcuts
*ui-text
*ui-xml

'''-- keys'''

'''-- cli'''

'''-- verbs'''
*exporting
*importing
*printing
*saving

==== build ====
*build-compile-code-design
*configure
*build
*packaging
*installer

==== export-import formats ====
*cdr
*dia
*dxf
*emf
*eps
*gnuplot
*javafx
*latex
*odg
*pdf
*png
*ps
*vml
*wmf
*xaml

==== platforms ====
*all-platforms
*bsd
*linux
*osx
*solaris
*win32
*win32-vista

==== documentation ====
*doumentation
*licence
*logo
*metadata
*tutorials
*translation
*website
*wiki

==== triage ====
*blocker
*needs-confirm-on-svn-head
*regression

==== other ====
*accessibility
*gsoc2009-color
*ocal (Open Clipart Library)
*other
*soc-2008-juca
*usability
*wishlist

== debug extension ==
; tool to display info about extension system, loaded modules, versions... : Bug [https://bugs.edge.launchpad.net/inkscape/+bug/448285 #448285] “lxml version bundled with Inkscape is old”