PowerTeam
Open Letter To Be
1 - Introduction
We, as members of the PowerTeam, want to let you know our ideas and feelings about BeOs and a bunch
of other related issues.
The PowerTeam is composed by well known BeOS European Developers, all authors of awarded BeOS
Software (Kftp, Felix, PowerPulsar, Mail-It, BIC, TManager, Raytime, etc....) We have been BeOS
developers and users since the very (VERY !) beginning, and thus we have several considerations
about BeOS we have been thinking of for a very long time.
All the remarks that we are writing to all of you are applicable to BeOS DR9 PR as well as PR2.
But many of these issues were present in the BeOS from the beginning and were
never corrected, so these are not just 'first contact' remarks.
We know what you are thinking about this text right now. Without reading it any further, you will
consider it as
yet another boring mail from upset developers. Be sure this is not the case. We like the BeOS and we
have always tried to make our best to help Be as well as BeEurope. We use to come to European
shows to bring an extended help and every time we do spent our free time or our vacations to do so
-- we wouldn't do it if we didn't believed in BeOS. But we don't have a
blind faith in BeOS. We want it to be successful, we want you to be successful, and the only
way for this to happen is to keep up the good work, accept the positive criticism when things that are cool
can suddently turn in to even cooler things.
We spent a lot of time to write this down, organize it and make it clear. Please carefully read
it all and then re-read it again and again. Don't try to argue on every item, don't try to convince you
or us or anybody else that this is wrong or that is good -- this is not a religious war.
Just keep up the good work : you are very smart guys (you already proved it to us) so we believe you
are clever enough to find out what features are obviously useful and prioritize by yourselves.
A last word : this mail was started some weeks ago. It is the result of our independant meetings and debates
about what is good and what should be better and it took a serious amount of time to build it up. Nobody from Be
nor BeEurope was involved in the making of this mail : it's all build up from our independant views to help you
make a successful OS.
May the force Be with you ;-)
2 - Content Table
- Introduction
- Content Table
- Look and feel of BeOS
- Appearance & Global User Interface
- System-wide services
- Tracker Improvements
- Media Kit
- Kernel
- Net Server
- App Server & Interface Kit
- Hardware support
- Storage Kit
- Evangelism
For an HTML, more easily readable, of this mail, go to
http://www.guerilla.com/powerteam/powertexte.html
For an ASCII version of this mail, go to
http://www.guerilla.com/powerteam/powertexte.txt
3 - Look and feel of BeOS
3.1 - Appearance & Global User Interface
There are two kinds of users for an OS : end-users and developers. Sometimes people just fit in the
two categories at the same time, because one can humbly develop on an OS only if he really uses it and
knows it very well.
These two kinds of users don't see the OS in the same way. An end-user just want to make real things,
like playing with some amazing stuff or using boring spreadsheets. The end-user sees "chrome" in the
user interface as a must, he wants sounds and a nice effects everywhere. A developer wants to
have a nice and efficient API to play with. Intermeditate, novice developers want to have a simply
way to develop clever applications and just ignore chrome in the interface because they can only see
chrome in the API... This is silly, you cannot just make the best GUI of the world and the Universe, nor
you can make things that are right to everybody at the same time. This means that the first characteristic
of a GUI is that it must be customizable. But not too much or not too easily, else you're going to loose
novice people with lots of messy options. And you must not forget that the most obviously
unimportant features are the ones that do get people attention.
The idiomatic expression "chrome" refers precisely to
these features that don't make thing more efficient, just more attractive -- and the more attractive one
computer is, the more productive people are. Preferences are the Good Thing [tm]. Themes are set of
preset preferences that will bring people from a flashy and noisy world to the simplicity of silence
-- just in a mouse click.
We know this is already on your wish list. All we want is to make sure it gets a higher priority.
Below is our wish list on this topic.
Important Features
-
Appearance Manager
Have a look at MacOS 8, Kaleidoscope and Aaron, Copland, Windows 95 and others.
An appearance manager (or call it a window manager if you like) is higly needed in order for the end user
to change the look of the interface. But beside few minor modifications (like changing a color theme)
there is also need for a more generally customizable user interface.
-
The BeOS should make use of replacable widgets (see the app server section, below), and it should be
mandatory to program customizable settings for every widget, and of course in a uniform manner.
-
Widgets should handle settings changes on the fly, be able to save their settings (such as their font
face and size) and so on.
Useful Features
-
Possibility to change the number of workspaces into the application workspace.
The easiest is to add a menu (context menu or menubar) to the window like in DR8.
-
An easy trick : BViews should have a concept of current mouse cursor, and switch it by themselves.
-
Transparent icons during drag and drop of icons should be nice.
These already existed before, in the earlier Hobbit versions, and the time synchronizer on the Intel
box features a transparent drag'n'drop icon.
-
The current implementation of window minimize is a hack.
Use your own GUI concept here. It is important to have a correct "minimize" theme here, which one is an option
you choose. See the optional feature below.
Optional Features
-
Currently the menu can be navigated via the keyboard using the "menu" key of Windowished keyboards.
Make it customizable through a control panel : let the user choose so that people with a Mac or PC-101
keyboard be able to use it.
-
Possibility to have transparent BWindows.
-
Make the window minimize customizable.
There should be a preference panel to let the user choose between three methods : collapsing windows
by double clicking their title bar, collapsing as Windows 95 into the DeskBar (i.e. the window really
vanishes, it's not being hidden by the Tracker), or iconized onto the desktop as a small icon (like
X-window)
3.2 - System-wide services
Important Features
-
The BeOS About Box is back with PR2 !! Yahoo !! Thanks !
-
Automated management system for fonts (live queries on font folders, including automatic update when
replacing an existing font, etc...)
-
Standard widgets
- Screen mode selector
- font selector
- a nice, multi-purpose, efficient and precise color picker (look at MacOs 8 color chooser)
- true file selector
- a possiblity to record sounds in a sound panel
Useful Features
-
A "help system", easy to use by every application via a system-wide API.
For a good example of an existing application that do that and also supports Windows Help
(questionable) file format, see Quickhelp (www.altura.com).
Ideally a good compromize for you is to publish a fixed API that let applications request contextual help
and application-wide help with some search features. You can provide a full descripbed lib that applications
link against. This lib can call a "help" application by scripting. Then the deal is that third-parties can
replace the app and possibly extend the system but at least there is some stable base.
-
There is a requirement to incorporate a standard way to manage installation and uninstall of software
packages. The OS must track the count of the components. The installer/uninstaller can be a third-party
app that uses a system-wide API.
-
User feedback : visual & audio feedback for user interface events.
This needs some architecture to make it customizable (program API plus preference panel),
visual effects can be as simple as flashes and sound feedback needs to be customizable (selection of sound)
and it must be possible to enable/disable the whole thing.
Registering audio with UI events is one of those unecessary but impressive things (aka chrome). Even users
whom will promptly shut it off expect it to be there !
-
Audio support in the system QT player ! (this issue should not belong to NetPositive).
-
Support for color network printing (LaserWriter, Canon, Lexmark, Efi [which board includes JLG]),
as well as direct color printing using serial, parallel or USB ports : this is a Media OS !
Also need for a better PostScript support (try to print a Japanese document, the font is not downloaded !) plus
support for typesets fonts in PS Type 1 or TrueType.
Optional Features
-
Support for autoplay of audio CD (thru preference panel to enable/disable it)
-
Support for autorun of CD-Roms (execute a "startup.sh" script if any, and have a preference panel
to enable/disable it)
-
Standard control panel that lists the machine capabilities (CPU number & usage, memory used [virtual + really
used, since users considerably mix them !], hard disk [sizes, number, indexes : a fixed snapshoot from DriveSetup],
loaded drivers + drivers configs if available [drivers *should* be able to publish a settings BView]).
-
USB support for the BeOS for Intel.
3.3 - Tracker Improvements
Important Features
-
Full scripting support
-
Desktop Image
Use a pref panel to insert a desktop image in the Tracker.
Even a drag and drop method from the Tracker will do it.
Should use the Datatypes to load the image, not a proprietary format.
(Unfortunately one cannot write a replicant to display an image on the desktop background
because Tracker icons go *behind* replicants)
Useful Features
-
Icons in the Tracker should handle :
- animated icons
- 24 bits icons
- icons read thru datatypes (vectors, sounds, etc...)
- Live reorganisation of icons in a tracker window while resizing the window.
- vectorized icons
-
Lack of keyboard shortcuts for Tracker drag and drop files operations or context menu items. The
drag cursor must reflect the option selected by the keyboard modifier.
-
Lack of options available into a tracker contextual menu for Add-ons.
There must be a possibility for tracker add-ons to add custom menu items in the context menu
depending on the selected files.
Optional Features
A note about animated icons ; this isn't really silly :
- You can have icons that are animated when first drawn (i.e. when a Tracker window opens ;
needs to be asychronous),
- or animated when the mouse passes and stays over the icon for a small amount of time (this is a very
cool way to have an icon show something, it can even replace small tips or help-bubbles),
- or you can have icons that are always animated,
- and the user needs to be able to disable or enable this as he wishes.
- You can implement icons to be read by the Tracker via an extended Datatype library that supports
things like vectorized or animated icons. It's just a matter of API and add-ons. This way anything can
be imagined : icons can also contain a sound that will be played when the icon is draw ! (this requires
that the Tracker send events.)
4 - Media Kit
There should have been a full appendix below on the audio layer of the Media Kit below. But good things are
happening, PR2 headers show up some new classes. So this is no longer the right place for a detailed criticism.
Private mails are better for that. Here is a bunch of more generic feature requests :
Important Features
-
A real audio/video architecture with synchronised messages between medias.
-
Quicktime layer license (Quicktime encoding, Quicktime MPEG, quicktime VR, Quickdraw 3D)
plus an AVI/Direct Movie layer (using codecs that can be extended)
-
A true 2D/3D acceleration layer (the 2D layer should also benefit to the app server)
Useful Features
-
Datatype-like API for soundfiles manipulations
-
True MIDI Kit build in into the Media Kit, support for opcode Midi Interfaces.
-
The Game Kit lacks some really useful features :
- Easily get the list of available video cards in the machine (without having to go and figure what
is plugged into the PCI buses and load drivers by hand -- which is basically what PowerPulsar currently
does for the second Matrox card),
- The ability to start the Game Kit on a given card (not only the BeOS current video card, that
must be more easy to do than add multi-card support to the app server),
- A better link from an open BWindowScreen object to the adequate video driver structures (currently, it is
not possible to get the card vendor from BWindowScreen),
- A "GetBoardCaps" function that really describes what the card is capable of : a list of *all* the supported
video modes, the planes mode (ARGB, BGRA, 8, 15, 16, 24 bpp, 1555 or 565, etc., so that a game can format these
information and let the user choose a mode.
- Game Kit support for A/V cards -- this is easy as soon as the driver to be used can be easily choosed and if
the game kit can use a custom screen size and resolution.
-
Need for a BAudioCD class that can list the detected Audio CD devices, and select one to control it (play, stop,
inquire stats, etc...)
Optional Features
- An easy way for apps to play/acquire sounds, for example being
able to use a subset (?) of the sound layer to specify a circular audio buffer and easily update
and ask for it to be played from a given position.
This can be the job of an utility library that provides simple services over a full sound API ;
the way the final output is mixed is a system-depend issue.
- a play_sound() like function that can use both memory or a file and have add-ons decode sounds formats (mod,
mp3, aiff, wav, adpcm, etc.)
-
Raw access to keyboard and mouse for games and emulators. This might not be limited to apps using a full game kit
screen. Maybe it can be simply a service to talk directly to the corresponding driver via ioctl's.
5 - Kernel
Important Features
- an _O_R_B_, an Object Request Broker !!
An ORB, as the discussions in BeDevTalk before DR8 proved it, would :
- bring an object model independant from the language,
- solve the FBC issue,
- allow distributed computing because an ORB like DSOM can work over the network
You know that a CORBA compliant ORB would be definitely cool, while COM/DCOM would be
the definitely bad thing to use since it doesn't fix the FBC problem and also depends on
the Microsoft dark strategies !
- Possibility to safely kill a thread, since the issue still seems to be touchy when dealing to
the appserver or the netserver threads (especially for those blocked in sockets calls).
-
PEF support : the PEF uses causes a lot of troubles since the format is patented by Apple. This forbid
developers from doing things like a linker (see Fred Fish problems with gcc) as well as anti-virus
software and some other stuff like compilers and linkers.
ELF or XCOFF seems to be a reasonable counterpart for the PowerPC world, while ELF also can be used on Intel
boxes (instead of the Windows/PE format used on preliminary versions of BeOS for Intel ;-)).
6 - Net Server
Important Features
-
Appletalk driver and Internet connection at the same time ?
If you tried this under PR, you had all the chances to crash the netserver.
-
Working on modem connection on a web site.
Delay when establishing connections are much too long.
There is too much latency, data bandwith is not exactly what it could be, long connections hang the
server, there is nothing impresive herein.
-
Standard BSocket and BAsyncSocket classes for sockets are highly neeed so that any app can use them.
(Is some sample code available ? Let's integrate it !)
Useful Features
-
Some useful features are still missing :
-
IP Masquerading
-
Multicast
-
UDP Sockets that work correctly
-
Out of band data in IP sockets is not implemented
Have a look at the netatalk package of Linux, it does all what you need !
IP Masquerading and IP Firewalling are both linked AFAweK.
-
Applications should have the possibility to handle the network/ppp connection operations (start, stop,
get state & stats, etc... possibly via the scripting architecture)
-
NetPositive
- Java integrated into NetPositive, how, when ? (we reached the first anniversary of this announcement)
- Plug-in architecture of Be NetPositive (shockwave, flash, videolive, real audio, quicktime VR, etc...)
- Port of Netscape Navigator's (questionable) Javascript
Find out an Amiga lover and ask him to show you Voyager. This shareware Web Browser surclasses
NetPositive everywhere. It's mainly efficient and features a full HTML 3.2 support. No more than this.
Optional Features
-
Support of IPX
Especially on BeOS for Intel to uses games in PC networks.
-
Pluggable network protocols : in order for you not to invest in implementation of every protocol, let
third parties do it. Well, that's almost but not exactly linked to the net-FS API. It seems you already
have an add-on API for network protocols : document it or at least release some sources !
7 - App Server & Interface Kit
App server issues and Interface kit issues are mixed here. This shouldn't be the case but actually represents
the current state of the corresponding APIs.
Important Features
- Widgets must be separated from drawing primitives operations
- At the design level, Interface Kit classes currently mix low (graphics rendering) and high level
operations (event handling) in a messy way.
- At the implementation level libbe.so embeds some widgets (those provided by Be), which should be
properly isolated (and replacable !)
-
Graphics performances are poor
Possilby due to the absence of some useful 2D accelerations as well as a strange ARGB/BGRA handling depending
on the OS or the cards. 8 bpp is correct, 32 bpp is really slow. 16 bpp simply doesn't exist while it is the
exact compromise between bandwidth and color use.
-
Redraws are bad - BeOS prodided widgets are too slow because of vector drawings and heavy redraws
-
Resizing is not correctly handled.
(Resizing a window has two major problems : constraints in H or V are poorly usable and this generates two
much messaging/redrawing and the application can dificultly handle it gracefully).
Useful Features
-
Mouse cursor bugs when switching graphic mode
-
Double-click handling is odd
2 clicks at different locations into the same BWindow generates a double click at the second clicked
location.
-
Windows should be able to implement the save_under feature. This uses lots more memory but equaly saves lots
of CPU in case of complex redrawing. This can be incompatible with windows containing animated stuff.
-
Get the font metrics information out of the font render, let apps use these metrics for precisely drawing
on the screen.
Optional Features
-
More drawing attributes : arrows for lines, fill using a BBitmap, Bezier curves drawing.
-
Animated and colour-enabled mouse cursors : why using Mac-like 16x16 monochrome cursors ?
-
Are BBitmaps ARGB or BGRA ? Why aren't they both, plus 8, 15/16, 24 and 32 bpp enabled ? In grey or in color ?
The dithering is currently an option of the BBitmaps, could also be a system-wide service for non-BBitmap buffers
(a service working directly in the client memory space, without a spurious area usage).
8 - Hardware support
We know you can't produce drivers for every card in the world, because this takes time and you don't have
all the needed information. Nethertheless...
Important Features
-
Foreign, unhandled PCI cards should not hang the OS at startup when if they can't be driven.
-
True Graphics accelerations thru true optimized drivers. Example : a more complete set of 2D
accelerated hooks in the driver.
-
Support for 3D acceleration
Useful Features
-
A/V Cards support : ATI (low cost), MIRO, Media 100 (professionnal video editing)
-
Support for Philips Tri Media (AC-3, THX, MPEG)
-
Native 3D cards drivers (Better 3D FX, OPEN GL Cards, ...)
Optional Features
-
SCSI cards : Adaptec support for Mac and Intel
-
Sound cards : will be automatically added for the BeOS for Intel support
-
Support for MPEG hardware acceleration as well as Quicktime acceleration
9 - Storage Kit
Important Features
-
Redundant operations in the API and concepts between various ways to work on files (BPath, entry_ref,
BEntry), some operations exist on some types and not others, endless need to convert from one to another
to be able to perform a given operation, calls that perform the same operation in those different
classes work in some of them, not in others.
(Maybe it's a question of habit, people can get correctly used to this if you document it enough.)
-
Multi-user support : we know you plan to add it later. But there will be malformed apps to fail
because they will use fixed path (which is encouraged by BPath and the way links work). The sooner is
the better ? :-)
At least you can be clear on the directory usage. There have been quite a lot of variations on the
issue of path in a multi-user environement on BeDevTalk, even for solving problems like application
licenses usable on a per-computer or on a per-user basis.
Useful Features
-
Long names support for Windows/MS-DOS disk and diskettes
-
Integrate the mtools 3.8 (available from Marco Nelissen home page)
Optional Features
-
Documentation for the Be FS -- we know it's coming :-)
-
Could we have the api for FS add-ons ?
-
We expect BeOS for Intel to support Fat16, Fat32, NTFS and ext2fs.
You can get other developpers do these add-ons for you.
10 - Evangelism
Lack of Evangelism
-
Corporate evangelism : spend as much money as for shows and exhibitions to go and get independent
software developers who have interesting stuff to develop/port for BeOS.
-
We would like to have a true European developer support (not user support) available by telephone
and e-mail.
-
Expand the idea of the bug (or feature request) database on your web site !
Let users/developers vote for the one they prefer and use this to prioritize your choices !
Always feel free to make the final choice by yourself, you guess right most of the time since after
all you're smart guys !
-
A very simple but efficient thing : distribute BeOS stickers !
And innovate : distribute small BeOS metal plates with the BeOS for Intel release ! -- You know which plates,
the same you used for the BeBoxes !
Another silly idea : two small stickers with the BeOS logo to put on Windows keyboards to replace the two Windows
key logos ! (the actually thing makes me prefer a 101 keyboard !)
Lack of Evangelism
-
We all really think you've been really honest and most of the Be guys are very active on the list and on the
newsgroups. But what we've been missing lately is one of those speech telling us what are the exact future
directions of the OS.
(Rumors can only exist when there are many unpredictable choices -- fill the gap by yourselves !)
Developer Program
-
The developer program by itself actually just makes no difference at all from end-users.
- Etablish a real statement for BeOs developpers :
NDAs for regular applications developpers, prereleases
and regular versions of BeOs vaialable for download on
secret (loggued) ftp adresses.
- Etablish a price to receive a full printed documentation
and all the documents available describing Apis not
present on the web.
- Etablish a list of developpers interested in doing things
into some technologies : If a developper has a 3D
engine or real 3D capaibilities, why can't he test or HELP
Be engineers. Also how can applications emerge if the
technologies are not described and maintained by engineers
and tested or used by developpers ?
-
Some real developers really need a printed copy of the BeBook. Others prefer HTML. Give them the choice. But do both !
-
We would like to be able to download very regular updates of BeOS parts
(drivers, technologies, documentations, etc...)
and we would like to be
informed by specific mailing lists available for BeOS developers only (mentionning URLS of web pages or
FTP with Dev ID and password). The directory exists en Be.com ftp server but it
has never been used. Do It ! Your first customers are your
developppers : you are mixing them with "normal" customers and
disapointing them in this way.
Communication Lacks
There are a couple of points that need to be clarified :
-
No MacOS emulator after 2 years !
But we are happy that you've heard our (speaking for all BeOs users) request that Be helps European
developers by modifying the BeOS Kernel.
-
No Windows emulator after 2 years
And that after 2 years that PCI cards with Hardware emulation exist ; JLG spoke, during the public
presentation of the Bebox, of an hardware 'friend' manufacturer possibly doing some card to be plugged
into a BeBox... (bury this with the fake annoucement of a four 620 BeBox machine for unlimited & uncompressed
digital video editing.)
Why Hiring ?
Be wants to innovate by promoting Internet-based software distribution.
Why not trying to promote also Web-based remote work ?
You want to hire that and that skill for your internal use. You already have this skill available
somewhere around the planet. Look at BeDevTalk, there are quite interesting guys there and there !
Why not asking the available people -- people that have some time to spend to work for you but not at
full time or that cannot move to Menlo -- why not giving them the opportunity to work for you, just
by asking them to handle a little part of the OS ? You just need to make a deal with these people,
sign a bunch of NDA's, they work for you on their spare time in respect of some commonly predefined
schedule and they give you back sources that you integrate after checking them.
That's mainly how Linux was build. The commercial point in less.
This text was written on a BeBox using BeIDE as HTML editor and NetPositive
as a viewer.
People who are badly implicated in this silly project :
Raphael Moll | raphael.moll@inforoute.cgs.fr |
Jean-Marc Ouvre | jm@guerilla.com |
Benoit Triquet | btriquet@club-internet.fr |
Laurent Pontier | pontier@mail.club-internet.fr |
Xavier Ducrohet | ducrohet@club-internet.fr |
Sebastien Bouchex | bouchex@iname.com |
Marc Abramson | redrakam@planete.net |
Hubert Figuiere | hubert.figuiere@teaser.fr |
People who were enthusiast enough to submit interesting ideas :
Thijs Stalenhoef Yann Kieffer
Mathias Agopian
Pascal Lauly
Sander Stoks
Trey Boudreau
List of recipients in Europe :
jcalmon@be.com
droulers@be.com
List of recipients in US :
jlg@be.com
heidi@be.com
valerie@be.com
erich@be.com
pierre@be.com
benoit@be.com
wadams@be.com
steve@be.com
marc@be.com
dug@be.com
dbg@be.com
geb@be.com
First version by JMO, RM, BT, LP, XD.
Revision 0.7 by RM, Paris, 16 November 1997.