Re: [Gimp-developer] unified transform tool

["Joao S. O. Bueno" <gwidion mpc com br>]

On 24 February 2013 09:23, Alexandre Prokoudine
<alexandre prokoudine gmail com> wrote:
> On Sun, Feb 24, 2013 at 4:09 PM, peter sikking wrote:
>
> > meanwhile, I am looking for a new small design project
> > to put before my students in a months time. any ideas.
>
> It seems that folks who create textures for 3D projects really want us
> to build advanced features on top of the new save/export model.
>
> One such feature is mentioned in the GSoC2013 page: being able to
> export/overwrite from sets of layers.
>
> Quoting an artist:
>
> "It's quite common for texture artists to work with multiple parts of
> a texture in the same file. They may for instance have diffuse, spec
> and bump all in one xcf or psd file, then they change the visibility
> settings of the different layers or layer groups, to save out each
> texture type. Being able to define sets, and give them a path and file
> format to save to would be quite handy, as once that is set up, you
> could literally write out all the different parts of you texture at
> the push of a button."
>
> I've heard this request from 2 or 3 people. That is not a significant
> sampling, but the feature will be handy to at least two more groups of
> users:
>
> - web designers (keep design variations in a single file, export all)
> - photographers (use global mask for different processing variations,
> export all variations to different files)


This kind of things can be imploemented as a Python script -which makes it
fast to implement - however, scritps are limited in the way they can
interact with the program.

(They can't for example, add features to the layer dialog other than
menu entries to the right-click context menu).

While it is possible to use existing features in the plug-in: for example
I had a script to simulate layer groups before they where implemented
that made use of the "linked" property of layers to allow one to select
which would be in a group.

Besides being easier to code, attending such a feature in form of
a plug-in has the advantage of it being available immediatly  to
the requesters - *(i.e. they won't have to wait GIMP 2.10)
But it does imply in severe constraints for the UI design team.

> Alexandre Prokoudine
> http://libregraphicsworld.org
> _______________________________________________
> gimp-developer-list mailing list
> gimp-developer-list gnome org
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list