Sven Neumann writes:
> Create an SDI manager widget
> Do we really want to ask someone to waste his/her time with this? It
> is in my opinion not implementable in a sane way and we would likely
> not accept the results then. If this is supposed to be kept on the
> list then we need to agree first that we really want such a thing.
Another possible approach which might be more generally useful is
tabbed image windows (suggested in bug 121087), combined with moving
the toolbox menus into the image window. Then people could dock the
toolbox and do everything in one window if they so chose, while
others could keep the current separate-windows model.
> Additional file format plug-ins
> Shouldn't this perhaps be titled "Improve MNG support"?
There are a few other file format plug-ins I've seen discussed
here recently, such as GeoTIFF and improved PSD support.
> On-canvas text editing
> Nice, but pretty much depends on the port of the display code to
> Cairo. Perhaps concentrate more on rich text support instead of
> focusing on the on-canvas editing?
Rich text support would be a very useful and fun SOC project.
It might require architectural agreement on how the rich text would
be stored in the XCF (which might not be backward compatible).
Is that a problem? Or is there already a model for that?
> Search-based menu browser
> Nice and probably even reasonably well specified. The student should
> perhaps do some usability work on this him/herself (with the help
> of an expert).
Peter says this sounds like "flagging usability defeat" and I
understand why he says that, but I don't agree. Consider it a type
of online documentation. Realistically, any program that offers as
many different unconnected functions as GIMP does cannot organize
them in a way that will be immediately intuitive to everyone,
especially someone who doesn't understand conceptually what the
functions do. Consider the person who's following an online
tutorial. The tutorial says "Step 12: run HSV Noise." The user
may not understand what HSV noise is or why it's needed at this
step; they just need to find something matching the name "HSV Noise."
> Redesign and reimplementation of Save and Export in GIMP.
> We really need to do this, finally.
When I saw the header I was hoping this covered things like
remembering settings from the various save plug-ins (like, always
show JPEG preview, always save exif, never save thumbnail).
Turns out that's not covered -- but it would make a nice SOC project
that would be very widely useful.
> Meta-data plug-in
> I would love to see the metadata plug-in finished and the framework
> used from other file plug-ins. This is crucial for 2.6. Probably up to
> Raphael to decide if making it a SoC project can help to make this happen.
I think lots of people would like to see this, but everyone is
afraid to touch it because the comments in the bug make it clear
that Raphael owns the problem and it's presented as a big
complicated project. It would be great to see it separated into
smaller pieces so other people could attack it.
If a general metadata plug-in is too ambitious, how about a
straightforward EXIF and Comment editor? Then if the more general
metadata thing ever gets finished, it could replace the simpler one.
There's an old exif plug-in on the registry (written by Bill)
that might offer a start, though it doesn't currently allow for
editing or viewing.
--
...Akkana
"Beginning GIMP: From Novice to Professional": http://gimpbook.com
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
