GNOME.org
 

Re: [Gimp-user] Funding new features in gimp - what features would you choose?



On Fri, Dec 20, 2013, at 09:14 PM, Joao S. O. Bueno wrote:

Interesting -

I've thought about some of these, worked on some others,
and yet some others would be trivial to implement
via scripting -
let's see:

On 17 December 2013 00:50, akovia <akovia1 eml cc> wrote:



I would love to see more bug and functionality fixes than new tools
personally. Being more of an editor than a creator, I seem to use gimp
in a different way than the core team is aiming for, as is expressed by
the 2.10 Unified transformation tool. That doesn't mean I'm not looking
forward to trying it. I still use gimp almost every day for hours on
end, so core functionality is paramount.

My biggest request would be fixing the new cairo based path engine. I've
considered moving back to 2.6 many times as the new engine has many
bugs,
(http://gimp.1065349.n5.nabble.com/Path-Tool-Problems-td40365.html#a40411)
and really slows me down from what I was used to. Also having the new on
canvas text options window follow the view when zooming and panning
instead of locked in place to the top left of the text. These come to
mind the most.

As far as new features...


These first are related to the path tool ,
and would require tweaking it

True path intersections (combine without overlaps)

This could easily be scripted to transparently "convert to selection,
combine selections, convert back
to path" - would that work for you?


I'm not certain I follow, but if the end result is a selection I can use
that combines all the overlaps, count me in. Would this covert back to
the original paths, or use the (not so accurate) selection to path
algorithm? I really don't see a need to convert back to path anyway as
long as the original is untouched. I just need the selection overlaps
combined. Not merging the paths at intersections would also leave the
door open to be able to break apart paths to layers in the future.


Any implementation to select multiple path nodes.



Option to merge paths to new path while leaving originals untouched.
(Modifier key)

So - this one is easy to implement in a python-script as well.


I thought this might be easily scriptable, but I still think this should
be a core function. I'd love to see this work like the add new layer
modifier but would need an icon to do it. (ie. click merge paths for
current functionality, shift-click merge paths to retain originals.) But
I would happily settle for a plugin to do it for sure!


Path transformations without having to use path to selection.


What do you mean by this? Path transforms simply work; all transform
tools
dohave a "path" mode. (I've read your other e-mail expanding on some of
these
topics  - but yet could not understand what is missing)


Hmm, sorry if I wasn't clear or missing something myself. Maybe this
will clear it up.
https://dl.dropboxusercontent.com/u/93550827/path%20transrmorms.ogv
Notice how just transforming the path without first selecting it grabs
the entire canvas and not just the path object.



Rotatable guides.

I've actually worked on these until a working state, several years back -
but found no user support or sound use case to clean up the code
enough to commit point.
Do you care to expand on the use cases for them?


I'm an admin over at fanart.tv. We need to recreate text and other
shapes accurately to match original logos. When an original font can't
be located, we need to recreate these from scratch. Recreating slanted
text would be my personal #1 use case, but there are many other uses
indeed. Right now I fire up inkscape when I run into these, but I'd much
rather stay in gimp if I could. Sometimes I'll even create a diagonal
path line and drag it around to manually match my angles so I don't have
to fire up inkscape, but of course there is still no snapping.


Drop layers on tab thumbs.

+1
We really should get this done before 2.10


Tab ordering via Drag & Drop

The same


Gui or folder based system to arrange scripts and plugins into the menu.

Hmm...thought one - as currently the menu location for these is hardcoded
in the script/plug-in source code.
But a "customizable menu" one could drag actions too (just like assiging
keyboard shortcuts), maybe is feasible.


I realize these are hard coded as I have manually rewritten most of
mine. I'm not sure what the easiest implementation would involve, but I
was thinking the hardcoded menu statements could just be ignored in
newer versions and we could use a folder structure it would read from. I
realize it's not so simple as scripts and plugins co-exist but are
handled differently, but doing something here to organize this huge
library of "addons" into a user friendly structure would be pinnacle.


Layer styles

What would these be?


A layer style is one or more effects applied to a layer or layer group.
We have the layer effects plugin which is nice, but it needs expanded
functionality and be built into the core.


Remember all popup window positions (tools, scripts, etc..)
Built in resource manager that remembers brush tags

Yes that one could be improved. Also, there is no way to manage tags
from plug-ins.


I'd rather it not use a plugin and have support for brush groups in the
core so people with large brush collections didn't have to load every
brush/gradient/pattern every time to be able to use the new tagging
feature.
I am not an artist per se, and I still use a lot of brushes and other
resources. I can't imagine how many resources a professional might use.
Having to load these huge collections every time you load gimp seems
wasteful and time consuming. It's the reason that resource manager
plugins exist in the first place.


Scaling an image keeps text data. (Or at least a way to know what the
font was before text info discarded. (Append font name to layer-name?))
Dockable Script-Fu and Python-Fu consoles
many more..... :P


I would be thrilled to see any of these implemented, but honing what we
already have is even more important IMO. I realize a lot of these
features have been discussed in detail before and will never be
implemented, but this is a "Wish" list.

Regardless, I hope your endeavor takes off and encourages more of the
same. It would help development of gimp pick up pace substantially.
Thank you for taking the plunge.


  akovia
--


Thank you for taking the time to address these things. I am thrilled
that somebody actually took an interest. Anything I can do within my
ability to further the development of any of these will be my pleasure.

-- 
  akovia

-- 
http://www.fastmail.fm - IMAP accessible web-mail
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]