On 24 February 2013 09:23, Alexandre Prokoudine <alexandre.prokoudine@xxxxxxxxx> 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@xxxxxxxxx > https://mail.gnome.org/mailman/listinfo/gimp-developer-list _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gimp-developer-list
