Hi folks, Until yesterday I haven't had a chance to play with what you call effects. Because I believe this is a misleading terminology I want to propose an alternative:
Scripts ------- Scripts are little programs, written in interpreted language, that supply extended Inkscape functionality. They can work on objects, or even drav new objects on the canvas.
Both Blender and GIMP projects eventually came to a conclusion that it makes no sense to separate scripts form the core functionality in terms of interface. A script should be free to register anywhere in the menus, based on its functionality. Grouping them, creating yet another menu structure, just because they are written in a particular language is not helpful to the user.
Yes, it is pretty much what you call effects now.
Filters ------- Filters are operations on selected objects, on their bitmap renderings even. The result of the filter replaces the original object and cannot be easily changed in future. The resulting image is stored in the file upon save.
Effects ------- Effects are similar to filters, yet they are "dynamically" applied on a bitmap copy of the object at the target resolution. Only effect settings are stored in the file on save, and the effect needs to be recalculated (possibly some caching/preview voodoo needs to be applied to speed up preview).
cheers
Jakub Steiner wrote:
Until yesterday I haven't had a chance to play with what you call effects. Because I believe this is a misleading terminology I want to propose an alternative:
I agree we need some terminology to use for these features. Everyday I try to figure out how what I should call these things when talking to people with problems. Your suggestion is great because it looks at extensions from the users point of view. Currently we concentrate on implementation details when we talk about extensions. But for troubleshooting, implementation is very important. So I think we will need some words for that too.
You will notice that extensions already appear in the menus where they would be expected. Input extensions appear in the file open dialog. Likewise output extensions appear in the save dialog. Filter extensions, those that change the svg document inside of Inkscape, appear in the Effects menu. Your terminology is so far only concerned with filter extensions.
Depending on the implementation, each extension will also be one of External, Internal, and Plugin.
External extensions are often called scripts now, but can be written in any language, compiled or not. They are loosely coupled with inkscape and not able to make use of Inkscape's features. External extensions allow inkscape to use any program that can operate on svg from the command line even if it wasn't written especially for Inkscape's use, eg. commercial file conversion packages. External extensions are probably most appropriate for what you have called Scripts and Filters.
Internal extensions do not exist yet. They will be most analogous to what other programs like GIMP call scripts. They will use embedded interpreters. Because they will be more closely coupled with Inkscape they may be able to call some of Inkscapes features, eg boolean ops, or even External extensions.
Plugins are written in C++ and are the most closely coupled with Inkscape. For performance reasons this is probably the only implementation that is appropriate for what you call Effects.
We are quickly running out of words and there is some very confusing overlap between your description and the current description of implementation.
Thanks for bringing this up. Aaron Spike
Jakub Steiner wrote:
Hi folks, Until yesterday I haven't had a chance to play with what you call effects. Because I believe this is a misleading terminology I want to propose an alternative:
Having commonly understood terminology is good, but you should probably bear in mind that SVG, though not yet implement in inkscape, already has the concept of "Filter Effects" implemented through a <filter> element. These appear to correspond to your concept of effects rather than your filters.
See http://www.w3.org/TR/SVG/filters.html
Cheers,
John
Quoting Jakub Steiner <jimmac@...659...>:
Hi folks, Until yesterday I haven't had a chance to play with what you call effects. Because I believe this is a misleading terminology I want to propose an alternative:
Scripts
I'd prefer Scripts, myself.
"Effects" in the sense suggested should probably be reserved to refer to SVG Filter Effects[1].
-mental
mental@...3... wrote:
Quoting Jakub Steiner <jimmac@...659...>:
Hi folks, Until yesterday I haven't had a chance to play with what you call effects. Because I believe this is a misleading terminology I want to propose an alternative:
Scripts
I'd prefer Scripts, myself.
"Effects" in the sense suggested should probably be reserved to refer to SVG Filter Effects[1].
But don't forget that SVG can also have embeded Scripts.
Aaron Spike
On Wednesday 22 June 2005 18:14, aaron@...749... wrote:
mental@...3... wrote:
Quoting Jakub Steiner <jimmac@...659...>:
Hi folks, Until yesterday I haven't had a chance to play with what you call effects. Because I believe this is a misleading terminology I want to propose an alternative:
Scripts
I'd prefer Scripts, myself.
"Effects" in the sense suggested should probably be reserved to refer to SVG Filter Effects[1].
But don't forget that SVG can also have embeded Scripts.
How about Macros? (I know, bring about nasty feeling of embedded .scr, .xls or .doc macros, but anyway)
Craig
Quoting Craig Bradney
Sent: Wednesday, June 22, 2005 2:21 PM To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] terminology proposal
On Wednesday 22 June 2005 18:14, aaron@...749... wrote:
mental@...3... wrote:
Quoting Jakub Steiner <jimmac@...659...>:
Hi folks, Until yesterday I haven't had a chance to play with what you call effects. Because I believe this is a misleading terminology I want to propose an alternative:
Scripts
I'd prefer Scripts, myself.
"Effects" in the sense suggested should probably be reserved to refer to SVG Filter Effects[1].
But don't forget that SVG can also have embeded Scripts.
How about Macros? (I know, bring about nasty feeling of embedded .scr, .xls or .doc macros, but anyway)
I think that Macros is honestly an even worse term for it. Typically a macro system is something set up so that you can easily record and play back a series of steps (whether key presses, movements, menu selection, etc).
So, people that use Office apps as well as Adobe's suite for example would just be confused by calling them that. In addition, you can typically include what we currently call "Effects" in the macros that you record (in similar apps).
I dunno... I think the terminology stuff is pretty tough to decide on. In the SVG world, filter is a reserved term. Effects in graphics apps do typically tend to be a little more dynamic so that if you change original shapes it will update the effect. Perhaps script is the most appropriate even though it will be confusing to non-technical users. I dunno... just my .02 =/
-Josh
Joshua A. Andler wrote:
I dunno... I think the terminology stuff is pretty tough to decide on. In the SVG world, filter is a reserved term. Effects in graphics apps do typically tend to be a little more dynamic so that if you change original shapes it will update the effect. Perhaps script is the most appropriate even though it will be confusing to non-technical users. I dunno... just my .02 =/
And, we're already using the word "scripts" to describe something different. There is the functionality and the implementation:
Function Implementation ---------- ----------------
Input Script Output Internal Print Plug-in Effect
Any of those can be matched with the other. So, most of the stuff that Aaron has written are extensions that implement an effect with a script.
I think the real problem is that we're running out of words, so we should make up a new one. I'm voting "Equodes" -- we can tell people that it is a word in Esperanto, no one speaks it to tell them differently. :)
--Ted
I haven't followed this discussion, but one thing that bugs me is that the menu is called Effects, even though it provides access to what we call Extensions, and even though SVG has "effects" of its own. Do you think we should rename the menu to Extensions?
On 6/29/05, bulia byak <buliabyak@...400...> wrote:
I haven't followed this discussion, but one thing that bugs me is that the menu is called Effects, even though it provides access to what we call Extensions, and even though SVG has "effects" of its own. Do you think we should rename the menu to Extensions?
Would it be good to have two different Extensions and Effects menus then (as soon as Inkscape starts using Cairo, so that coding true SVG effects will be possible)? Note that GIMP devs merge all Script-Fu/Python-Fu/Tiny-Fu/Perl-Fu into one Effects menu in 2.3 branch.
Alexandre
bulia byak wrote:
I haven't followed this discussion, but one thing that bugs me is that the menu is called Effects, even though it provides access to what we call Extensions, and even though SVG has "effects" of its own. Do you think we should rename the menu to Extensions?
It is called Effects, because it provides access to the Extensions we call Effects. Effects act as a filter and change the document. There are also input and output Extensions that appear in the File Open and Save dialogs rather than this menu.
Aaron Spike
On Wed, 29 Jun 2005, bulia byak wrote:
Date: Wed, 29 Jun 2005 05:16:27 -0300 From: bulia byak <buliabyak@...400...> To: inkscape-devel@lists.sourceforge.net Cc: Ted Gould <ted@...11...> Subject: Re: [Inkscape-devel] terminology proposal
I haven't followed this discussion, but one thing that bugs me is that the menu is called Effects, even though it provides access to what we call Extensions, and even though SVG has "effects" of its own. Do you think we should rename the menu to Extensions?
No.
I'm not sure exactly what the exact reasoning is for naming top level menus but the word "Extensions" doesn't fit the pattern. (Extras might be an adequate choice.)
In the end it is the users that matter and the inconsistent technical meanings are largely irrelevant. It is harsh but exposing the users to the underlying implementation details is a really bad idea and it had to be said.
From the point of view of users familiar with other graphics applications
the only two most obvious and familiar choices for this menu are Filters and Effects. Filters has certain photography related connotations and as it is more specific it seems more incongruous in a Drawing Application.
Usability has a fancy name for taking a look at what everyone else does, so here's the competative analysis:
Xara X uses Extras. Adobe Illustrator uses both Filters and Effects. Macromedia uses/used the pretentiously mispelled Xtras. Corel Draw uses Effects and Extras.
(Your Milemage May Vary. This "research" was conducted quickly and with the help of Google Image Search [1].)
Extras is awfully vague and wouldn't be my first choice but if that is was people decided was best I wouldn't bother arguing over it. (The GIMP is reorganising and reconsidering their menu layout and naming scheme and may well have an Extras menu instead of Xtns by the time the next version arrives.)
There is also the possibility of adding a Tools menu. (I specifically do not mean a redundant Tools menu like that found in the GIMP and several of its imitators). I mean a Tools menu like the stucture used by Office programs, Mozilla and metric tonne of other applications and I would suggest using it in addition to whatever else you decide. Having a tools menu of this variety will give you a place for the kinds of plugins which are simply too odd to be in a Filters/Effects menu.
(Spent way too much time on this already, gotta go.)
Sincerely
Alan Horkan
Inkscape http://inkscape.org Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
[1] This comparsion of drawing applications provided screenshots of iGrafx, Illustrator, and Corel Draw but I haven't read it yet: http://www.ex-astris-scientia.org/misc/software_test.htm
Alan Horkan wrote:
Extras is awfully vague and wouldn't be my first choice but if that is was people decided was best I wouldn't bother arguing over it. (The GIMP is reorganising and reconsidering their menu layout and naming scheme and may well have an Extras menu instead of Xtns by the time the next version arrives.)
If GIMP in renaming the Xtns menu to Extras, I think consistency is a good argument for Inkscape to use the same terminology
On Thu, 30 Jun 2005, Nicu Buculei wrote:
Date: Thu, 30 Jun 2005 09:15:45 +0300 From: Nicu Buculei <nicu@...398...> To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] terminology proposal
Alan Horkan wrote:
Extras is awfully vague and wouldn't be my first choice but if that is was people decided was best I wouldn't bother arguing over it. (The GIMP is reorganising and reconsidering their menu layout and naming scheme and may well have an Extras menu instead of Xtns by the time the next version arrives.)
If GIMP in renaming the Xtns menu to Extras, I think consistency is a good argument for Inkscape to use the same terminology
Nothing is certain yet but any reorganisation that is going to happen will likely be within the next one or two unstable releases.
- Alan
Alan Horkan wrote:
On Thu, 30 Jun 2005, Nicu Buculei wrote:
Alan Horkan wrote:
Extras is awfully vague and wouldn't be my first choice but if that is was people decided was best I wouldn't bother arguing over it. (The GIMP is reorganising and reconsidering their menu layout and naming scheme and may well have an Extras menu instead of Xtns by the time the next version arrives.)
If GIMP in renaming the Xtns menu to Extras, I think consistency is a good argument for Inkscape to use the same terminology
Nothing is certain yet but any reorganisation that is going to happen will likely be within the next one or two unstable releases.
This looks to me like another argument for the benefit of the "create" project where we intend to establish a communication channel for coordinating such things.
On Wed, 22 Jun 2005, Jakub Steiner wrote:
Until yesterday I haven't had a chance to play with what you call effects. Because I believe this is a misleading terminology I want to propose an alternative:
Well, we've debated these names several times before... my only opinion on it is that I'm not changing the name in the codebase again -- I think we're already using two naming conventions in several places and I don't want to add another. I don't care as much about the GUI strings. Probably before we have this discussion this document should be read by everyone:
http://cvs.sourceforge.net/viewcvs.py/inkscape/inkscape/doc/extension_system...
Specifically "Terminology" and "Overview"
I'd also recommend looking at the effects "Grid" and "Blur Edge" which don't use an script to execute -- they are built into the codebase and written in C++.
--Ted
I'd also recommend looking at the effects "Grid" and "Blur Edge" which don't use an script to execute -- they are built into the codebase and written in C++.
And those are the effects that have never worked for me... they don't even pretend to do anything. Any ideas on that?
-Josh
Joshua A. Andler wrote:
I'd also recommend looking at the effects "Grid" and "Blur Edge" which don't use an script to execute -- they are built into the codebase and written in C++.
And those are the effects that have never worked for me... they don't even pretend to do anything. Any ideas on that?
No idea on grid, it should pretty much work all the time... blur edge is tricky because it only works on paths. So if you draw an object, you need to convert the object to a path first. I tried doing that automatically, but I haven't gotten that part working yet.
Try grid again, you might try removing the entries for it in your preferences file just incase you put something funny in there. Also, wait a little bit, it can create a large path that sometimes takes Inkscape a while to render.
--Ted
participants (11)
-
unknown＠example.com -
Aaron and Sarah Spike -
Alan Horkan -
Alexandre Prokoudine -
bulia byak -
Craig Bradney -
Jakub Steiner -
John Pybus -
Joshua A. Andler -
Nicu Buculei -
Ted Gould