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

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

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

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

Don't know yet :) Let me get back on that.

 / Martin


My GIMP Blog:
"GIMP 2.8 schedule on tasktaste.com"
Gimp-developer mailing list

Reply via email to