[openbeosstorage] Re: BNodeInfo::GetTrackerIcon()
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Wed, 10 Mar 2004 12:01:39 +0100 (MET)
On Wed, 10 Mar 2004, Axel Dörfler wrote:
> "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
> > "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
> > > First, the generic MIME type is also defined as a constant,
> > > but it shouldn't be taken for all files. Instead, it should be
> > > differentiated by file type. I.e. it should take "application/x-
> > > vnd.Be-directory"
> > > for directories, "application/x-vnd.Be-volume" for volumes, etc.
> > BTW if you don't mind I could do these changes, because I need them
> > at
> > another place (BeMail), too. Would that be okay for you?
>
> I've added an updated version of it to BeMail, and I get aware of the
> fact, that you rarely send folders/volumes/symlinks/etc. as an
> attachment.
> IOW I didn't need to make these changes. Instead, I now let it search
> for the super types icon if the MIME type itself didn't have any -
> works great.
> If you would be very disappointed, I could still make the changes,
> though :)
I would be grateful, if you do (and also adjust the unit tests
accordingly :-).
> > Which brings me to suggesting a:
> >
> > static status_t BNodeInfo::GetTrackerIcon(const char *fileType,
> > BBitmap
> > *icon, icon_size which = B_LARGE_ICON);
> >
> > What do you think?
>
> Bad, it should be:
> status_t BMimeType::GetTrackerIcon(BBitmap *icon, icon_size which);
Yep, that sounds better. Personally I wouldn't mind, if you added it. But
it's more a question of whether you can bend the general policy not to add
features with a clear conscience. ;-)
If you do, please also add a unit test and an entry in
docs/develop/storage/Annotations. And don't forget to document that using
the method will break an app's R5 compatibility.
> Hope you don't mind me talking to myself :)
Not at all, it's quite entertaining. ;-)
CU, Ingo
Other related posts:
