[haiku-3rdparty-dev] Re: Vector-based UI
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-3rdparty-dev@xxxxxxxxxxxxx
- Date: Wed, 30 Jan 2013 08:52:34 +0100
Am 30.01.2013 um 08:24 schrieb ciprian.nedisan@xxxxxxxxxxxx:
> First of all, this topic doesn't belong here, but I hope it doesn't
> harm.
>
> I was thinking about UI of beos and somehow I think that the spirit
> of beos was to be on top when it comes to the UI and to the
> graphical
> (and multimedia in general) representation.
> What would be the UI of beos today? I guess not the same UI of the
> 90s.
> And perhaps to be consistent with the beos-spirit, perhaps at a
> later
> point Haiku should try to be innovative (if not revolutionary) in
> the
> domain of UI.
> If you imagine, that in the next years, the retina-displays are
> going
> to be more popular, and the screen resolution in general will
> increase,
> then you can imagine how haiku will look on such a display.
> Thinking about that, a natural idea could for the future, to rewrite
> the user interface of haiku to be based on vector graphics.
> It's for sure too early to even think too much about that subject,
> but since it's something important for the future, it could be
> beneficial to to keep the idea in your mind, and let it grow over
> the
> years, when perhaps it will become inevitable to do something in
> that
> domain.
>
First of all, I don't think looking to BeOS is of any help here. It was not "on
top" in any way in this particular subject.
Second, the UI already *is* vector based.
The problem with retina displays is completely different. It's the bitmaps that
are the headache. And any UI will always have bitmaps. You can supply vector
icons for tool bars at OS level, but there will still be bitmaps somewhere.
Apple is solving this problem by forcing application developers to supply a
bitmap in multiple resolutions. It means they abstract the bitmap object from
its storage. And as a developer, you have to supply storage in different sizes.
Consider the use-case where you have two monitors attached to your computer and
only one of them is "retina". And then you have an application window
positioned such that half of it is on one screen, and half of it is on the
other. And right there is a bitmap being rendered by the application partially
on each screen. The MacOS API allows for just that use-case.
The next problem is the meaning of coordinates that are passed to the drawing
APIs. In Haiku (and BeOS) these coordinates refer to pixels. In MacOS and other
APIs like Java Swing, the coordinates refer to "points". There is a global
device dependent scaling factor that converts between points and pixels. In
practice, both meanings are actually useful, it depends on the situation.
In any case, I completely agree that this stuff is worth investing time in and
solving.
Best regards,
-Stephan
Other related posts:
