2011/7/16 Enrico Schröder <enni.schroe...@gmail.com>:
> Ok, I will define the defines ;-) Should the common ones be declared in
> gimpunitentries.h or should each class/file define them themselves when
Put them in gimpunitentries.h for now. Later we will move
gimpunitentries away from libgimpwidgets anyway until we have a
GimpUnitEntries interface we believe in.
> The function automatically adds a preview label to the table, showing the
> value of the entries with id1 and id2 in the given unit. I noticed that the
> new image dialog (and a couple of others) were using a kind of preview label
> (provided by GimpPropWidgets), so I thought it was nice to have for other
> use-cases as well. Since GimpUnitEntries is a convenience class, I wanted to
> provide an easy way to create such a preview label. Maybe some plugin could
> use it someday. Since it's already there and working, why remove it? It
> doesn't harm anybody, and we don't have to use it in the standard gimp
> dialogs. If we keep it, we'd need a better name though, e.g.
Ok let's keep it, but don't add such a label where there wasn't one
(like in the New Layer Dialog).
> Makes sense, I will implement that. GimpEevl even provides the position at
> which an error occurred, don't know how accurate it is though. I will look
> into maybe providing a little better error indication than just painting
> everything read.
Sounds good. I would like to remind again though about that our main
focus right now is to get a basic GimpUnitEntry to work and integrate
it in GIMP, so unless you don't have other things to do, don't work on
> I must say separating the entry-management from creating the UI-container
> sounds a bit cleaner than it is now. But you had your concerns with that,
Don't know yet :) Let me get back on that.
My GIMP Blog:
"GIMP 2.8 schedule on tasktaste.com"
Gimp-developer mailing list