Go to the FreeLists Home Page Home Signup Help Login
 



[openbeos] || [Date Prev] [01-2005 Date Index] [Date Next] || [Thread Prev] [01-2005 Thread Index] [Thread Next]

[openbeos] Re: kernel mime_table module

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sun, 09 Jan 2005 18:13:26 +0100 CET
Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> I wouldn't object to something like a 
> BNodeInfo::GuessMimeType(BMimeType 
> *), which would take the file name into account, if the data-based 
> sniffing 
> is inconclusive (just like the entry_ref version of 
> BMimeType::GuessMimeType()).

Shouldn't it go the other way around? Ie. test the name first, and then 
look for the contents?
BTW BNodeInfo::GuessMimeType(BMimeType *) should have a second 
parameter like "filenameOnly = false" or "sniffData = true" - that way 
it could directly be used by things like Tracker to get a rough guess 
of the file type as fast as possible (it then would just show the 
generic file type icon for those where this fails, and could do a 
deeper test for the data asynchronously).
The advantage of this approach is that all file types where the suffix 
is sufficient are determined immediately with no visual delay for the 
user. Since this is only important for non-BFS volumes anyway, the 
chance that the suffix is sufficient is a very good one, too.

For mimetype enabled volumes, BNodeInfo::GuessMimeType() should 
probably store the type, too - it doesn't make a lot of sense to lose 
it again then.

Anyway, the most important thing to get right is BRoster::Launch() 
anyway, since it's quite annoying for the user (while the missing icon 
is just unfortunate).

Bye,
   Axel.






[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.