| Re: [AD] update/properties |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> Instead, I noticed that all the code was very similar anyway,
> so I made it a separate routine. One liners are still one
> liners, thankfully.
Ok, returning a new datafile makes sense, as well as providing a helper to
construct the object (I think I'll change the name of the routine to
datedit_construct_datafile or something like that). But I don't like the
'prev' datafile very much: we don't need to pass a previous datafile, only
the properties we want the new one to use.
Is this good enough for you? If so, I'll make the modifications when merging
the patch.
> > [Btw, can't we get rid of 'depth' too?]
>
> I wanted to, but the only way to do it would be to turn it
> into a property, and it's not one at the moment. Since it can
> be passed as a command line parameter to the dat utility, I'm
> not sure I have the "right" to add a "DPTH" property to all
> objects of type BMP, RLE, etc, though it would clearly be
> better to do so. If you have an idea, tell me.
Yes, this is certainly problematic. On the other end, passing 'depth' to an
audio plugin clearly makes no sense so we should devise a solution.
> The x/y/w/h being passed through properties, I also added the
> ability to pass any property via the dat command line.
Looks sensible.
> Also, since things like XCRP and friends are hardly generic,
> I added the ability for a plugin to "declare" properties it
> owns (several plugins can own the same properties), to know
> which ones to discard when stripping. Menu plugins can do so
> as well.
Likewise.
> While there, datitype.c did not set the modified flag when
> converting color depth, so I've added that too.
Right, well spotted!
--
Eric Botcazou