FreeLists / openbeos / [openbeos] Re: StyledEdit issues : text encodings, opentracker integration, etc.

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

"shatty" <shatty@xxxxxxxxxxxxx> wrote:
> * Issue 1: text encodings
> ...

I would say: just recreate what's already there - and it's better to 
improve the base (libtextencoding.so) than to improve every single app.

> I would prefer us to take an approach where we use add-ons to perform 
> encoding conversions.  Then new encodings can be added just by 
> putting 
> in a new add-on.  As part of this we should also have a way for 

Why add-ons? Just have some enumeration functions in libtextencoding.so 
and BFont, so that an application can get a list of all available 
encodings easily.
It's easier to always have the latest libtextencoding.so as to install 
5 different add-ons one after one (not counting bug-fixes and updates). 
At least, in whatever way it will be realized (through add-ons or not) 
the application using the library just shouldn't have to care at all.

> * Issue 2: opentracker integration
> ...

See my other mail about this topic; in short: import OT to let the 
thing compile, but don't make it part of OpenBeOS right now (maybe 
later).
libtracker.so is part of BeOS - you can't separate functionality from 
it without breaking compatibility with existing code. The unfortunate 
thing is that many other pieces of BeOS (and even MDR, shame on me) is 
using some classes that are exported as BPrivate and likely to change. 
We will have to work together very tight to not break anything by 
retaining the possibility for improvements.

At some point, I want to make the BNavMenu class public, but I have 
some improvements in mind which should be done before that point (which 
will break binary compatibility, because they didn't mind to add FBC 
protection to those private classes for R5 (shame on Be)...).

> * Issue 3: font sensitivity

You don't have to do much about it, just calculate the font height for 
your widgets, and use the various TextLength() methods and you have 
very simple font sensitivity (simple in the sense of the effort to get 
it, not in terms of usability).
Many Be applications are already doing this today - note that 
ResizeToPreferred() also works for many system classes; unfortunately 
not all.

> When opening a file our implementation seems slower than R5's.  It's 
> unclear what is the reason for this.  It'd be nice if someone could 
> look into it.

This could have many reasons, and as many people agree, optimization 
should come at last :-)

Adios...
   Axel.