NEW: Live preview of extension effects optional
While the "Live preview" checkbox is useful for most effects, for some it just does not make sense. Now, you can add the attribute needs-live-preview="false" in the effect element in the .inx file of the effect to suppress this checkbox for your effect.
bulia byak kirjutas:
While the "Live preview" checkbox is useful for most effects, for some it just does not make sense. Now, you can add the attribute needs-live-preview="false" in the effect element in the .inx file of the effect to suppress this checkbox for your effect.
Would it make sense to have "Regenerate" button next to live preview checkbox? This would need similar attribute to make it optional.
This is what I usually do with some extensions which create random effect, Color -> Randomize for example. I decheck and check the live preview to get new color, until it pleases my eye. This makes two clicks and two redrawings of the object for one new color, also it feels like a workaround.
May God bless all of you Mattias
On Fri, 2008-04-18 at 09:35 +0300, Mattias wrote:
bulia byak kirjutas:
While the "Live preview" checkbox is useful for most effects, for some it just does not make sense. Now, you can add the attribute needs-live-preview="false" in the effect element in the .inx file of the effect to suppress this checkbox for your effect.
Would it make sense to have "Regenerate" button next to live preview checkbox? This would need similar attribute to make it optional.
I think that the real solution here is to make random numbers a parameter, similar to how they are with LPEs. That way you could just regen one parameter, and perhaps leave another with a random number you'd like.
Shouldn't be that hard to do if someone wanted to take that one.
--Ted
On Fri, Apr 18, 2008 at 12:41:14AM -0300, bulia byak wrote:
While the "Live preview" checkbox is useful for most effects, for some it just does not make sense. Now, you can add the attribute needs-live-preview="false" in the effect element in the .inx file of the effect to suppress this checkbox for your effect.
Cool. Added to the new Schema (RelaxNG) for the inx files (still work in progress, but almost there).
BTW. While on the subject, I was thinking, would it make sense to alter the structure a bit in terms of the menu. Currently we have:
<effects-menu>
and for help items there is <effects-menu hidden="true">
Should we perhaps make it a bit more generic to put
<menu name="effects"> <sub-menu _name="..."> </menu>
So for the help extensions we might do <menu name="help">
I know the help item solution is a bit of a 'hack' but perhaps this would make it a bit clearer. Obviously the menu name would have to map into an existing one (unlike the sub menu) but then perhaps it would be easy to allow for sub-menu grouping in Help as well (I am aware though with this solution issue of help menu "separators" arises, but this could be solved by something like <menu name=".." group="..."> and then groups could be separated.
Just my 0.02
Regards, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]
On Fri, 2008-04-18 at 10:46 +0200, Marcin Floryan wrote:
On Fri, Apr 18, 2008 at 12:41:14AM -0300, bulia byak wrote:
While the "Live preview" checkbox is useful for most effects, for some it just does not make sense. Now, you can add the attribute needs-live-preview="false" in the effect element in the .inx file of the effect to suppress this checkbox for your effect.
Cool. Added to the new Schema (RelaxNG) for the inx files (still work in progress, but almost there).
Great!
BTW. While on the subject, I was thinking, would it make sense to alter the structure a bit in terms of the menu. Currently we have:
<effects-menu>
and for help items there is
<effects-menu hidden="true">
Should we perhaps make it a bit more generic to put
<menu name="effects"> <sub-menu _name="..."> </menu>
So for the help extensions we might do
<menu name="help">
I guess when I did this originally my thought process was that it would only be used for those extensions that go under the Effects menu. The reason for this was so that extensions that were external to Inkscape, they'd show up somewhere that you can expect them. For effects that are included with Inkscape we can use the standard menu definition (in menu.xml you can put any effect ID to add it) and the keybinding definition (same with your hotkeys, you can grab extensions that way too).
So, while I'm not hard set on the syntax that we have, I'd like to take any changes into account through that filter.
--Ted
participants (4)
-
bulia byak -
Marcin Floryan -
Mattias -
Ted Gould