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 <akov...@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?

> 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.

> 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)


> 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?

> 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.

> Layer styles
What would these be?

> 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.

> 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
>
> --
> http://www.fastmail.fm - Same, same, but different...
>
> _______________________________________________
> gimp-user-list mailing list
> List address:    gimp-user-list@gnome.org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
_______________________________________________
gimp-user-list mailing list
List address:    gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list

Reply via email to