[openbeos] Re: Open BeOS
- From: "Ithamar R. Adema" <ithamar@xxxxxxxxx>
- To: "Eugenia Loli-Queru" <eloli@xxxxxxxxxxx>
- Date: Sat, 25 Aug 2001 23:15:35 +0200
At 13:48 25-8-2001 -0700, you wrote:
>Ithamar, if you would be so kind to also forward this email to the list.
Copying this email to the list again, and it includes you message in full,
so I assume you'll find this sufficient (the load on the list is already
pretty high and I do not want to press text over the line too much for
people with 56K modem connections :))
> > I was thinking of using an existing journalled filesystem already, is
>there
> > a reason for prefering XFS over ReiserFS (besides Dominic, which is a good
> > point :))?
>
>I am preparing a set of interviews for next week on osnews.com with reiserfs
>guys, xfs and even jfs. The clear winner so far is XFS. :)
Hmmm cannot wait to see it, and on another note, great to see you still in
the OS "business" :)
> > Personally I was thinking about something like libart in combination with
> > freetype, as it is used in GNOME.... But this is all very theoretical for
> > me, I must say....
>
>QT is by definition C++ though, and its coding philosophy is so closer to
>BeOS that any of the plain C Gnome stuff.
>Also, QT runs on the framebuffer just fine (which means that for the first
>versions of openbeos in VESA, it would work perfectly). It is almost an OS
>inside the OS.
>It can integrate Freetype in it, and also supports way more things than GTK.
Ah, I'll explain myself a bit more. I thought I was being too short, but I
was answering lots of openbeos mail, so my fingers moved to send a bit
quicker then otherwise the case :) libart was a library developed by one of
the Ghostscript (commercial) maintainers, with (AFAIK) the thought it would
one day replace the current libgs.a (Ghostscript imaging library) as a
thread-safe, fast, imaging module. It supports most of the Postscript Level
3 stuff and is implemented for raw speed and quality. The most important
part of this library was made LGPL so it could be used in GNOME (as basis
for GNOME canvas, I believe). That is the only connection to GNOME it has.
For the URL, see http://www.levien.com/libart/. I was _not_ planning
dragging the whole of GTK into this :)
libart will only give us the "canvas" level stuff, ie the drawing ops we
need as a basis to be able to draw the actual windows with and content of
the windows. But having used libart several times in pretty critical
projects I must say I _really_ _really_ like it.... The code is clean,
sensible, and _fast_.
You're QT suggestion would (IMHO) give us more then we bargained for, in
the sense that we get desktop management, windows, etc, all for free, but
in QT style. I just ran KDE on a 64Mb machine (RH7.1) and it was dog-slow
(due to swapping).... That isn't what we're envisioning with openbeos....
Please correct me if I'm mistaking, and give me ptrs to docs that'll show
usage statistics for QT using in the kind of environment we're talking
about (i.e. on a framebuffer, no OS GUI layer under it) and I'll gladly
appologise for being short-sighted and try to use it.....
> > LoL, you're not the only one who felt that way :) BTW, it might be more
> > interesting (and soon linked to http://open-beos.sourceforge.net) to take
> > a look at http://www.obedn.com/ which seems to be the new site for the
> > project...
>
>I saw it afterwards...
>It is amazing that Phyte has copied my osnews website's colors and code...
>:P
Ah right, is that why it looked so familiar :) But how could he have access
to _your_ code? Is it open-source already? (I saw the thread on osnews.com
in which you talk about opensourcing it....)
>Thanks,
>Eugenia
Thank you for your quick response :)
Ithamar R. Adema
Information Engineering Associates Ltd
http://www.ieadev.com
Other related posts:
