|
|
| (73 intermediate revisions by 7 users not shown) |
| Line 1: |
Line 1: |
| ==Documentation==
| | [[Category:Voyager]] |
| ===IBM Redbooks===
| |
| * SG24-4630-00 OS/2 Warp (PowerPC Edition) A First Look
| |
| * SG24-4639-00 OS/2 Warp (PowerPC Edition) Graphical Subsystem
| |
|
| |
|
| We do have the first one digitaly, but not the second one. In case anyone finds that, let us know.
| | Please ignore this pages for the moment, this is old content about Voyager and we will replace that soon by some serious stuff :) |
| | [[User:Ktk|Ktk]] 13:39, 10 November 2008 (CET) |
|
| |
|
| ===Darwin Documentation===
| | We currently discuss about the design on Voyager. This is separated into the following parts: |
| There is plenty of documentation available about Darwin, a good start is [http://developer.apple.com/documentation/Darwin/Kernel-date.html Kernel Programming], which gives a nice overview about the design of the kernel.
| |
|
| |
|
| ==Technologies to study==
| |
|
| |
|
| *[http://www.opengl.org/ OpenGL], [http://freeglut.sourceforge.net/index.php FreeGLUT], [http://www.mathies.com/cpw/about.html CPW] (Application framework for windows, menus etc.). Here's a [http://www.mathies.com/cpw/textfiles/Cpw.txt Readme text]. | | * [[Voyager_Discussion|Voyager Discussion]] - contains the ideas which evolved from quite some discussions |
| * [http://www.freedesktop.org/wiki/Software_2fglitz glitz] - OpenGL interface for Cairo, so one could run Cairo directly on OpenGL, see [http://www.freedesktop.org/wiki/Xegl Xegl] for a diagram.
| |
| * [http://www.usenix.org/events/usenix04/tech/freenix/nilsson.html Glitz: Hardware Accelerated Image Compositing Using OpenGL] and as [http://www.cs.umu.se/~c99drn/opengl_freenix04.pdf PDF]
| |
| * [http://dri.freedesktop.org/~jonsmirl/graphics.html The State of Linux Graphics], [http://lwn.net/Articles/149917 comments] and more [http://groups.google.com/group/linux.kernel/browse_frm/thread/c2f4978ce450ed9a/2d8842acb180b581 comments]
| |
| * [http://people.redhat.com/mclasen/Usenix04/notes.pdf Current gtk+ development]- among other topics about cairo integration and a new theme system
| |
| * [http://www.gtk.org/plan/ GTK+ Planning] - a more recent plan of GTK+ development
| |
| * [http://people.freedesktop.org/~ajax/ddc2005.pdf X on GL] states very clearly, what has still to be done
| |
| * [http://www.directfb.org DirectFB] with [http://www.directfb.org/index.php?path=Development/Projects/XDirectFB rootless XServer], [http://www.directfb.org/index.php?path=Development/Projects/DirectFBGL hardware accelerated OpenGL], [http://www.directfb.org/index.php?path=Development/Projects/GTK%2B GTK+ backend], [http://www.directfb.org/index.php/viewcvs.cgi/cairodfb an experimental Cairo backend], Qt backend, DirectVNC, SDL backend
| |
| * [http://enlightenment.org/Main/Home/index.html Enlightenment] and its support libs. Here's a [http://www.elivecd.org/ Live CD].
| |
| ** Why Englightenment? So far I just knew it as a fancy desktop, what makes it special? [[User:Ktk|Ktk]] 15:39, 30 October 2005 (CET)
| |
| ** Cinc: it's more than just a fancy desktop. It offers quite some libs e.g. HW accelerated canvas on top of OpenGL, libs for alphachannel blending of pics, antialiased text, imlib and quite some more.
| |
| * [http://www.gnustep.org/ GNUstep.org]
| |
|
| |
|
| == Design Decisions ==
| | * [[Voyager_API_Basics|The Voyager API Basics]] - contains the basic ideas for the Voyager API |
| Creating a binary compatible OS/2 clone may be tempting but is not strictly necessary. Important is the user experience. Which toolkit should be used for primary development?
| |
|
| |
|
| ===Graphics Drivers===
| | * [[Voyager_API_Design|The Voyager API Design]] - contains the design/coverage of the upcoming Voyager specific API |
| * [http://x.org X11] | | ** [[Desktop_class_list|Preliminary list of desktop classes]] - contains a separate (yet incomplete!) list of Desktop Classes |
| * [http://www.khronos.org/opengles OpenGL ES] (an OpenGL only desktop) | |
| * [http://directfb.org DirectFB]
| |
| * [http://www.scitechsoft.com/products/ent/snap_linux.html SciTech Snap Graphics]
| |
|
| |
|
| These graphics engines can be emulated vice-versa: You can run X11, OpenGL, and DirectFB programs on the same graphics driver.
| | * [[Voyager_API_Design_Guide|The Voyager API Design and Implementation Guide]] - contains the methods and rules for implementing the Voyager API |
| We should have a look at HW support when chosing the driver system. For example I've read OpenGL drivers are not that common
| |
| (often they're not HW accelerated). A viable idea may be to just use OpenGL as the core API on top of something else. There're quite a lot OpenGL implementations
| |
| running on different low level drivers or even Mesa.
| |
|
| |
|
| ===2D API===
| | * [[Voyager_API_Roadmap|The Voyager API Roadmap]] - contains a list of issues/todos |
| * [http://cairographics.org Cairo]. Cairo has a PDF-like engine which seems to be inspired by Quartz of MacOS X.
| |
| * Cairo runs on almost everything, including OS/2 and X but also directly on OpenGL hardware with Glitz. So one could use it as a complete GPI replacement without the need of X one day.
| |
| * To make things easier 24Bit screens should be the primary target. Hell it's 2005 today...
| |
| | |
| It seems there are many possiblities here!
| |
| * [http://www.ggi-project.org General Graphics Interface]
| |
| * [http://www.cairographics.org Cairo] (used by GTK+)
| |
| * [http://www.enlightenment.org/Libraries/Evas Evas] (used by Enlightenment) | |
| * [http://www.levien.com/libart libart] (used by Gnome)
| |
| * [http://antigrain.com Anti-Grain Geometry]
| |
| * [http://www.libsdl.org Simple DirectMedia Layer]
| |
| * [http://doc.trolltech.com/4.0/qt4-arthur.html Arthur] (used by KDE)
| |
| | |
| We will have to use more than one. KDE programs use Arthur, GTK+ ones use Cairo, and so on ...
| |
| These libraries are (mostly) used for display and printing. So we won't have a consistent graphical subsystem with this multitude.
| |
| | |
| All these libraries have several backends, e.g. X11, DirectFB, OpenGL, OS/2, ...
| |
| | |
| Even if we do have to use more than one we should focus on a library that is widly supported, at the moment my impression is that Cairo will win the race. Mozilla is using it for new versions, OOo will use it and GTK+ is migrating into it as well. Also projects like Glitz will dramatically speedup the rendering in the Cairo engine. See some [http://www.osnews.com/story.php?news_id=9609 comments] of one of the GTK+ developers.
| |
| | |
| === CMD ===
| |
| | |
| * full capabilities of current CMD.EXE concerning
| |
| ** usage of system messages and error codes
| |
| ** nested io redirection
| |
| ** grouping commands with round brackets
| |
| ** &, && |, and || operators
| |
| ** correct wildcard matching for files with multiple extensions
| |
| ** PROMPT command
| |
| ** keep UPPERCASE environment variable names only ! (unlike 32-bit Command Interpreter from Jonathan de Boyne Pollard)
| |
| * proper implementation of EXTPROC command (fix errors with exptproc scripts not residing in current
| |
| directory)
| |
| * new general features
| |
| ** support extended command set of Win NT CMD.EXE
| |
| *** at least include string functions with extended SET command
| |
| ** extend IF clause with new conditions
| |
| *** os version match
| |
| *** free space on a drive
| |
| *** is drive removeable
| |
| *** is drive USB mass storage
| |
| *** more ?
| |
| ** support PATHEXT variable
| |
| *** start files with their associated program
| |
| ** automatic environment vars
| |
| *** DATE, DATE_SORTED, TIME, TIME_SORTED, WEEKDAY, DAY, MONTH, YEAR, YEARDAY
| |
| *** CMDLINE, ERRORLEVEL
| |
| *** OS, OSVER
| |
| *** BOOTDRIVE
| |
| ** support filename completion
| |
| * new internal or extended commands
| |
| ** INITVIOCMD determines a command being executed when initialized as a VIO session
| |
| ** INITPMCMD determines a command being executed when initialized as a PM session
| |
| ** SET allows to include equal signs in value of environment var
| |
| ** SET /P retrieves value of environment var from keyboard
| |
| ** SHIFT xx shifts parameter by positive number
| |
| ** ECHO /N does not append CRLF to output
| |
| ** CDD command changes directory and drive
| |
| ** TIMER command starts, stops or displays the value of a timer
| |
| ** SLEEP n waits for n secs
| |
| ** PAUSE n waits for n secs
| |
| ** implement START command with all features of DosStartSession, among others implement
| |
| *** /WAIT (synchronous start)
| |
| *** /NC (NoAutoClose)
| |
| *** /DOS[:settings.dat] (if DOS-Box still available)
| |
| *** /POS:x,y,x1,y1 (initial window position)
| |
| *** /ICON:icon.ico (system menu icon)
| |
| ** MOVE files with implicit copy/delete across partitions
| |
| ** exlicit UNLOCK command
| |
| ** implicit unlock with COPY, DEL, REN, MOVE (very usefull, but also dangerous ?)
| |
| ** macro support with ALIAS command
| |
| * new batch handling or batch commands
| |
| ** %* specifies all parameters (like %1, %2 etc)
| |
| ** in for loops support %%a%f, %%a%p, %%a%d and more for specifying filename, path and driveletter of matching file
| |
| ** GOSUB - executes a subroutine
| |
| ** RETURN [xx] - exits a batchfile or subroutine [with errorlevel]
| |
| ** CANCEL (ends batch processing, but does not close window as EXIT does)
| |
| * Integration of any REXX replacement like with current CMD.EXE
| |
| ** call of REXX Scripts with CMD
| |
| ** usage of exit handlers
| |
| ** manipulation of environment vars within REXX (changes remain after end of script, unless setlocal/endlocal() is called), including BEGINLIBPATH and ENDLIBPATH
| |
| ** readonly access to the LIBPATH value as an environment variable
| |
| | |
| === MM ===
| |
| * The concept of IO procedures should be retained at least for file IO and format converting.
| |
| | |
| ===Toolkits===
| |
| | |
| *GTK+
| |
| *GnuStep (look at Apples programs to see what's possible. Yes I know Apple uses Cocoa not Gnustep)
| |
| *other?
| |
| | |
| ===SOM===
| |
| | |
| Dropping SOM for something better? Creating a poor mans SOM kernel isn't too difficult (Cinc: there's already a working prototype for the basic functionality).
| |
| | |
| If SOM is dropped, no binary compatibility for old WPS enhancements is given. This may break a considerable amount of OS/2 apps. This may not be an issue if applications have to be recompiled anyway for a new plattform. Cinc: I don't see many OS/2-apps which are worth to be supported no matter how much work it needs. Binary compatibility is out
| |
| of sight IMHO. Nobody really needs it (anyone really using OD nowadays?).
| |
| | |
| === WPS ===
| |
| * The WPS should be designed with REXX scriptability in mind (like WPS-wizard addon)
| |
| | |
| === REXX ===
| |
| * REXX should be implemented like AppleScript so controlling of applications from other apps is possible (commands not tied to one process).
| |
| * [http://regina-rexx.sourceforge.net/ Regina] may be used as an interpreter.
| |
| * any REXX replacement should implement the following
| |
| ** true CMD integration like under OS/2
| |
| *** access to environment vars of the calling interpreter. Cinc: ???
| |
| ** support of the full REXX C API or an equivalent concept (macro space control, app handlers, WPS object access API etc). Most of this is supported by Regina AFAIK.
| |
| ** complete reimplementation of REXXUTIL ! I seem to remember having seen such a project for Windows and Unix.
| |
| * It should be possible to write GUI based apps with REXX, a bit [http://www.edm2.com/0601/drdialog.html Dr.Dialog] like
| |
| | |
| === Backward Compatibility ===
| |
| The question about backward compatibility is indeed a good one, it's risky to break with the current OS/2 API for religious reasons but one should have a look at that more from a technical point of view. The OS/2 API is not really modern anymore, programming directly on PM is much more work than using a modern toolkit like GTK+.
| |
| | |
| At the moment it's unfortunately unlikely that PM and WPS source get released by IBM.
| |
| | |
| Options:
| |
| | |
| * implement parts of PM and GPI on top of the new 2D API and try to integrate it with the toolkit choosen (same look & feel, clipboard support, D&D, etc. That's a lot of work, the question is if this is really necessary. We would have to do the same for supporting other toolkits like qt (which is a requirement).
| |
| * Implement only some crucial parts to ease source code migration. For example message queues, concept of object windows (often used to comunicate with background threads).
| |
| * Map often used PM-functions to counterparts of the chosen toolkit.
| |
| * Use a VM and run OS/2 or eCS inside the VM. There are very promising opensource VMs like
| |
| ** [http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ XEN]
| |
| ** [http://fabrice.bellard.free.fr/qemu/ QEMU]
| |
| | |
| XEN seems to be the most promising one at the moment because it will support dual core CPUs in the future so one can run the guest OS on a separate CPU core. So far one had to alter the guest OS in sourcecode but that changes at the moment because they integrate parts of QEMU sourcecode inside XEN to emulate those parts (memory allocation and such stuff).
| |
| | |
| == Questions==
| |
| * the Xegl diagram mentioned above only shows the path of the graphics; the path of e.g. mouse and keyboard input is missing; that's not as trivial as it sounds (it has been [http://lwn.net/Articles/149783 missing in Xegl], when that was stopped); will we use OS/2-like driver model or wait for x.org 7.0 (currently RC1!) and take out the input system from there? Other sources (hotplug, ...)?
| |
| * one good thing about OS/2 are the fast interactions when you click somewhere, like opening a folder or getting the focus on a window. Why is that like this? We should try to keep that stuff fast.
| |
| * do we want the traditional window manager<->application scheme? With the Gnome/KDE interfaces? Then we are deep in X again ...
| |
| ** the question is if we can incooperate the WM functionality in GTK somehow. As far as I remember [http://fresco.org/ Fresco] implemented GTK API as well so one might have a look at that.
| |
| ** IMO GTK runs on top of a WM. The WM just gives GTK a surface to work with but manages where on screen this surface will be painted. Even OS/2 has something like a WM managing the windows for us.
| |