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