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 1. Introduction 2. Content Table 3. Look and feel of BeOS 1. Appearance & Global User Interface 2. System-wide services 3. Tracker Improvements 4. Media Kit 5. Kernel 6. Net Server 7. App Server & Interface Kit 8. Hardware support 9. Storage Kit 10. Evangelism For an HTML, more easily readable, of this mail, go to : http://www.mygale.org/~ralf/powertexte/powertexte.html 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 * Desktop Image : Fast Desktop Image Changing. You can provide an easy way to change the desktop image right in the Tracker : in the context menu of a bitmap, place a "Set as desktop image" menu item. * When copying or moving files, if the destination already exists, the Tracker should popup a more complete dialog box, something like this : Replace toto - 49Ko last modified September 12th, 1997 version : 0.1.2 (if available) by toto - 63Ko last modified September 24th, 1997 version : 0.4.7 (if available) A simple dialog box is not informative enough to be able to fully decide whether a file should be replaced or not. Also the dialog should ideally feature a "Replace All" or "Skip All" buttons aside "Replace" or "Skip" when multiple items are moved or copied. 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 !) Marketing directions * 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.