[openbeos] Re: Tracker icons
- From: Michael Phipps <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx, glasselevator-talk@xxxxxxxxxxxxx
- Date: Fri, 22 Jul 2005 23:19:04 -0400
I have been watching this thread with quite a smile on my face. Why, you might
ask? Because this thread is a perfect proof of why R1 shouldn't have new
features. 20 or so emails have gone by. Can you imagine if people weren't
coding because a decision hadn't been made? :-O
Not to pick on anyone (and I know that I have said this before), but the AROS
project had this problem way back when. A group of Amigans decided to do with
Amiga OS what we are doing with BeOS. And they, according to their website)
argued for 3 years without writing any significant code, about what it should
be. Then a few people got sick of it and just started cloning AmigaOS 3.1. They
now have a whole lot done.
It would *seem* like just changing something simple like adding colors or
resolution to an icon would be an easy thing to fix. Honestly, it isn't, and I
think that *some* of the reasons have been made clear here. There are so many
questions:
1) Bigger bitmaps? SVG? Other vectors? Anything?
2) Store them in the attributes? Icon cache?
3) Change the API? Try to make it backward compatible?
4) Keep "legacy" icons?
5) Use translators or not?
6) Expand disk blocks to enable bigger/better icons
7) Performance implications of any/all of the above?
And probably more...
Change is a good thing. And BeOS R5 could use a liberal dose of it. But
creeping featuritis is a bad disease. Again, not to pick on anyone, but the
concept that without any one feature, Haiku is *DOOMED* is, honestly, sort of
silly. There are lots and lots of things that we would all like. And one man's
critical feature is another man's useless eye candy. Therein lies the wisdom of
picking one point, aiming at it and executing it. I don't think that anyone
will doubt that R1 is an amazing accomplishment. There are very few operating
systems (and even fewer OSS operating systems) that are ever brought to a
"real" release.
This conversation really should move to GE - that is the place for it - to work
out these issues and prepare suggestions for R2. There are a lot of people on
this list who want to keep this list strictly about R1 and things that will
happen; that is why we made the GE list. I look forward to pitching in on this
thread over there. :-)
On 2005-07-22 at 14:23:40 [-0400], André Braga wrote:
> 2005/7/22, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> > With lookup, I actually mean "is the attribute there?" I don't mean "read
> > it" (which inherently includes a lookup, too).
>
> Is it that slow? Won't the VFS vnode cache (assuming there is one!) have all
> the atributes in RAM by then?
>
> > You don't know that it only has a legacy icon, first you try the cached
> > icon, then the new style icon, and finally the legacy icon - that makes
> > 3 lookups, no matter how you describe it.
>
> Again, is it that slow? I suppose a failed attempt to extract an icon is much
> worse than just testing for its presence. Again, assuming that the VFS caches
> the vnode.
>
> > True. Actually, when you said "icon cache" I didn't know you meant "cached
> > on-disk icon".
>
> As opposed to what? Now I got a little lost =/
>
> > Why not? There are even use cases of this on BeBits (SVG clock via icon).
>
> In this case, the application would better write straight to the icon cache.
>
> > I did, but I can't see how this makes this argument less of a problem - if
> > there is enough space in the small_data section, it will place the data
> > there, if not, it will be put to a separate file; BFS only prefers system
> > attributes over others, it has no understanding of user defined attributes
> > (like what MDR is doing).
>
> In this case, all that's needed is making the icon cache a system attribute?
>
> > Simplicity should restrict us to certain formats.
>
> IMHO simplicity would be reusing the existing data translators infrastructure
> and, because of that, get considerable flexibility for free.
>
> > And "because we can" was never a good reason for me :-)
>
> Showing off the OS' capabilities is always great :)
>
> Isn't reusing code the whole point of having an OO API after all?
>
> > Exactly, we should agree on those, and restrict the support to these types
> > - that's the only way to make sure that only those formats will show up in
> > icons. If we see the need, we could easily add some other types over time.
>
> I still like my "blessing of a couple official formats but allowing users to
> do as they see fit" better. ;)
>
> > And that got me confused. Sure, neither PNG nor SVG icons will fit into the
> > small_data section in most cases.
>
> Which is why I proposed an internal format Tracker would render the icons
> into and potentially store into the small_data section. I called it the "icon
> cache". See?
>
> > Now it's my attitude? That's great - I'm just trying to have a reasonable
> > discussion, really.
>
> I'm really sorry, then. In your first reply to my post I thought your
> language was a little rude. Which is not your regular attitude at all. So
> this had upset me a little bit =/
>
> > The reason for that maybe not so well
> > fitting comment was that I completely misunderstood you. If you like,
> > please reread your previous mail with "cache == living system that runs in
> > the background"
>
> ?! o_O ?!
>
> w00t?!
>
> I'm so confused by this that I even got curious on what (the hell!) were you
> thinking :D Care to explain a little more?
>
> > in mind (unlike your "write rendered images to
> > disk"). Maybe I missed something, too, but I don't think that my attitude
> > was a problem if you read it that way :-)
>
> I'll try to answer that if I eventually grasp what you had thought before ;)
>
> > Yes, but you always have to check for custom icons, even if they are absent
> > - and 3 lookups are just too much for this, as you have to do this with
> > every file;
>
> But it's only for the first time you ever access that file, and that's the
> absolutely worst case. Then you'd just do a single lookup for the rest of the
> file's life, on it's icon cache. You could even just copy the legacy icon to
> the icon cache for kicks...
>
> > the "no special icon" case is the most common, so
> > you definitely have to optimize for that case first, and only then look
> > into the other performance bottlenecks.
>
> That's what the MIME database is for, no? And in this case having the icons
> on RAM is a better solution.
>
> > No, that's not obvious, that's wrong. You still have to look, you just
> > won't find anything.
>
> By your definition of lookup, yes. I meant something different by "lookup".
>
> > Having differently sized icon attributes is also already a bit more
> > inefficient, because you have to lookup first once to get the size.
>
> As opposed to what, rendering it JIT? Sorry, but I disagree.
>
> > Definitely, though it didn't change my mind :-)
>
> I always knew your opinions are hard to bend :D :D
>
>
> Cheers,
> A.
Other related posts:
