[openbeos] Re: Tracker icons
- From: "Simon Taylor" <simontaylor1@xxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sat, 23 Jul 2005 10:14:06 +0100 BST
I thought we were on the way to decision. I agree the fully flexible
thing suggested by Andre has enough drawbacks that it needs much more
discussion and is not and R1 thing. The discussion here into the pros
and cons of it is misplaced, I agree on that too.
However, R1 will almost certainly have a new icon set, from Axel's
comments at least. Michael, you and all of us want to use R1 as soon as
possible - therefore it makes sense to tell icon designers what the
requirements are for the R1 icons as soon as possible so that a release
is not waiting on the designers.
R1 will likely be fixed to 32x32 and 16x16, I'm perfectly happy with
that. The only varible left is color space. It seems that the standard
BEOS[...]_ICON attributes could be used but simply write in more data
and in that way support 32 bit icons. No API change is necessary but it
would mean that R1 could use a smooth, modern-looking icon set whilst
retaining compatibility with old BeOS apps.
It would make R1 screenshots truly look like an "updated R5", a potent
metaphor for the changes that have occured under the surface.
Simon
ps: I'm completely in agreement on the wisdom of keeping features in R1
close to R5. All the problems you talk so proudly of avoiding are
simply lying in wait to pounce on R2 though. The summary of the ideas
that you posted on GE a while back actually made me stop following the
progress of Haiku for a couple of weeks and consider abandoning the
whole BeOS thang and just living with windows. That's not feature-
creep, that's feature-long-jump. Simply putting any feature ideas
suggested onto the R2 list has actually made the feature-creep issue a
lot worse than it might be otherwise IMHO, and without a very firm hand
on the tree post-R1 I really fear what Haiku will grow in to.
> 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:
