NikiWiki - User contributions [en]

GpiEnableYInversion()

2006-04-12T12:47:17Z

ShadoW: effect on GPIPartialArc

Definition:

BOOL APIENTRY GpiEnableYInversion(HPS hps, LONG lHeight);

This function is exported by PMGPI.DLL as ordinal 723.
You can use this function by loading it dynamically when needed, for example by the following code. (The code assumes that the program uses other Gpi* functions so PMGPI.DLL is already attached to the process!)

static BOOL APIENTRY (*fnGpiEnableYInversion)(HPS hps, LONG lHeight) = NULL;

void GpiEnableYInversion(HPS hps, LONG lHeight)
{
HMODULE hmod;
int rc;

if (fnGpiEnableYInversion)
fnGpiEnableYInversion(hps, lHeight);
else
{
// Interesting, it doesn't work with DosQueryModuleHandle(), even
// though it returns the very same handle.
// [ rc = DosQueryModuleHandle("PMGPI", &hmod); ]

// I have to load and free the module instead...
rc = DosLoadModule(NULL, 0, "PMGPI", &hmod);
if (rc!=NO_ERROR)
return;
DosQueryProcAddr(hmod, 723, NULL, (PFN *)&fnGpiEnableYInversion);
DosFreeModule(hmod);
if (fnGpiEnableYInversion)
fnGpiEnableYInversion(hps, lHeight);
}
}

Or you can tell the linker to import it, by adding something like this to your *.def file:

IMPORTS
GpiEnableYInversion = PMGPI.723

Call the function with

lHeight = height - 1;
GpiEnableYInversion(hps, lHeight);

Notes:

I think it was introduced with the Open32 API (previously called DAPIE or DAX). It's purpose is to ease the porting of Windows applications to OS/2. Using this API for a given Presentation Space handle (HPS), all the Gpi functions will be inverted using the given lHeight value.

Please note that not only the coordinates will be top-left based, but the blitting and handling of bitmaps will also be inverted. For example, using the GpiDrawBits() API expects a pointer to a pixel array, which is bottom-up by default. Once this call is used on the target Presentation Space, you'll have to have the pixels top-up way in your buffer if you want to have your image to be shown correctly.

The current setting of Y-Inversion can be queried with the [[GpiQueryYInversion()]] API.

'''It seems the aptl[] parameter of GpiBitBlt does ''not'' get inverted! However, the bitmaps themselves ''do''!'''

'''The output of GPIPartialArc gets mirrored across the Y-axis - the rotational direction changes!'''

Voyager

2006-04-10T07:42:09Z

ShadoW:

==Discussion==

There is now a FAQ about the Voyager project [[Voyager FAQ|here]].

This document is already some kind of discussion, you can add your comments in here as well. For real discussion please consult the [[Mailinglists | mailinglist]] <tt>voyager-dev@netlabs.org</tt>, or use the [http://dir.gmane.org/gmane.org.netlabs.voyager.devel gmane.org web/news interface] to it.

==Documentation==
===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.

===Darwin Documentation===
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.

* [http://www.kernelthread.com/software/fslogger/ Filechange notification] in Mac OSX "Tiger".

==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].
* [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]
* [http://www.opensolaris.org/os/ OpenSolaris]
* [http://www.ogre3d.org/ Ogre 3D] The open source real time 3D rendering engine - for nice 3D effects on the Voyager desktop
* [http://slashdot.org/article.pl?sid=05/11/03/1744230&tid=190&tid=109 Microsoft Singularity] - interesting paper by Microsoft about a concept study of a new OS
* [http://arstechnica.com/reviews/os/macosx-10.4.ars/13 Quartz and Quartz extreme], nice article giving an overview
* [http://klik.atekon.de/ Klik]: application bundles for KDE.
* More about application bundles: [http://mozart.chat.net/~jeske/unsolicitedDave/app_wrappers_yet_again.html http://mozart.chat.net/~jeske/unsolicitedDave/app_wrappers_yet_again.html], [http://mozart.chat.net/~jeske/unsolicitedDave/next_wrapper_description.html http://mozart.chat.net/~jeske/unsolicitedDave/next_wrapper_description.html], [http://mozart.chat.net/~jeske/unsolicitedDave/kde_encap_ideas.html http://mozart.chat.net/~jeske/unsolicitedDave/kde_encap_ideas.html]
* [http://rox.sourceforge.net/phpwiki/index.php/HomePage Rox] a quite nice desktop environment with features we also seek to implement
* [http://www.symphonyos.com/ Symphony OS] - a desktop in XUL. We should integrate XUL as good as possible with Firefox
* [http://www.eyeos.org/ eyeOS] - web based OS
* [http://www.novell.com/linux/xglrelease/ Novell & Xgl] - some stuff Novell did for Xgl
* [http://wiki.x.org/wiki/XDevConf X Developer Conference] - some slides about the latest one, interesting stuff there!
* [http://chabada.sk/better-desktop/ 40+ Suggestions for a Better Desktop]

===Kernels===
* http://haiku-os.org - OpenBeOS successor

== Design Decisions ==
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===
* [http://x.org X11]
* [http://www.khronos.org/opengles OpenGL ES] (an OpenGL only desktop without X!)
* [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.
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===
* [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.

===Input Handling and Event Queue===
Between the 2D API and the window manager one layer is missing
* that cares for user input by mouse, keyboard, ...
* that knows the basics about windows and controls their behaviour (A window manager only modifies this behaviour!)
* a Session manager that manages the processes which want do to screen output
* a message architecture that connects everything and enables inter-client communication

Questions:
* Should we choose X for that? Quasi-standard, but old
* modify existing(?) systems
* port Presentation Manager -> access to source code needed
* code that ourselves?

* [http://xynth.org xynth] might be an option

=== Window Manager ===
To manage the windows we need some sort of window manager. So far most implementations are done for X, we need to abstract that directly on Cairo.

* [http://www.freedesktop.org/Standards/wm-spec Window Manager Specification Project]
* [http://tronche.com/gui/x/icccm/ Inter-Client Communication Conventions Manual] - Support this standard in order to let X applications run
* [http://www.freedesktop.org/wiki/Software_2fwaimea Waimea] - WM which is using Cairo for all rendering, they write it's for X so one would have to check if this can be separated from X as well.

==== Ideas for a new Window Manager ====
What features should a new windows manager have?

Cinc: Obviously these ideas are inspired by stuff usually found on X. The WM needed for this project isn't the kind of
WM X uses. I think WM is the wrong word for it anyway. What's needed is primarily a compositing engine which is in charge
of allocating surfaces, giving them to the app, the app draws into them and the compositor puts it on the screen.
Input support is probably needed for this layer, too, so the compositor may move and stack windows correctly.
The final appearance of the graphics drawn on the surfacces is up to the applications not the compositor. It must be
that way IMHO because no compositor coder can imagine what app developer will finally do with a given infrastructure.
E.g. creating close, maximize etc. widgets in the compositor/WM effectively prevents the application developer from
adding his own widgets or removing the given one. OTOH if there's a documented way to tinker with (per window) then it's ok.

The compositor/WM should be inspired by the Presentation manager (PM) found in OS/2. Granted it's old technology it's
unbelievable flexible. It's possible for the coder to alter the handling of every window/widget by subclassing the window procedures
provided by the system. For example the information area found in [http://www.os2world.com/cdwriting WPS-wizard] uses
this feature. PM is directed to order all the window areas differently (titlebar, close/maximize, client area) to give room for the
information area. The coders of PM never thought about the possibility to add such informations to windows back when they
did PM. It's not a hack and there's no need to change any WM code to get this to work.

Lexip: What about the common look and feel of all the headers of the client windows? I'd like to have a common theme for example, and all apps should have a header (with a little icon, and the close/minimize/... buttons) that paints according to that theme file.

Cinc: ACK. What I mean is the WM should not restrict the developer from adding/removing widgets, from modifying the way how things are done for a particular window (e.g. positioning of widgets). This also applies on how things are painted. If the developer decides to remove all widgets and use an ugly custom theme (which is bad) he should be free to do so.

===== Main Features =====
* Built i18n (internationoalization)
* .prestartup and .poststartup files
* Multiscreen support (with possibility of virtual desktops 1 being on physical screen 1, while having virtual desktop 4 on screen 2)
** Preview of desktop X on desktop Y. Like you have one desktop with the presentation on desktop X and on desktop Y (your main display for example) you see a resizable preview so you could have your script on the main display and still step through the slides
* Anti aliasing
* Virtual desktops (different layouts and number of desktops - 4x2, 3x3, ...)
* Storing sessions. Cinc: not sure the WM should do that
* 100% ewmh complient. Cinc: ???? if this is some X thingie it's probably not needed -> Lexip: yeah, it's X stuff, but if we want to support starting Xapps, and we should do that, then we gotta be ewmh complient with our WM/compositor
* Large desktops (scrolling and paging)
* Themes with possibility of associating a background image or pattern (i.e. blackbox)

===== Client Window Features =====
* Client window header can be top/bottom/right/left (with vertical text if necessary).
* Window manager keeps track of stacking order of all client windows
* Sticky windows - Possibility to show clients on all or few or just one virtual desktop
* Virtual desktops with resolutions different from the physical screen resolution.
* Ability to display multiple virtual desktops on one physical screen.
* Maximization:
** Maximize to given area
** Maximize to actual screen
** Maximize to more than one screen
** Maximize vertically only
** Maximize horizontally only
* Clients can influence their states:
** Maximized
** Stacking order
** Shading
** Stickiness
** Desktop(s)
* Window in Window handling for MDI applications
* Edge snapping while move- resizing a client window
* Client window shading
* Store client window properties per application (size, position, etc)
* Client window can drop shadow
* Application icons in client window headers
* Different focus models (click to focus, focus follows mouse, ...)

===== Docking Area Features =====
* Allow having multiple docking areas
* Docking areas can be hid (approaching mouse makes them appeare)
* Transparency
* Drop shadow

Cinc: The WM should not be in charge of this. The Dock (or whatever) is just an application and should be treated as one.

Lexip: question again about the theme. If the WM/compositor is not in charge of the docker, how can we set a common theme to it?

Cinc: The WM/OS should provide the default bitmaps for it (or better any app) which can be queried by the app. Changing the theme will automatically change these BMPs. For buttons and alike the OS should provide a default drawing function which will ensure every app which uses the default automatically has a similar look and feel.

===== Menu Features =====
* Dynamically filled menus (piped menus). Cinc: That's mostly up to the application IMHO with the exception of system menus.
* Menu configuration can be separated over several files, i.e. one file for each submenu section
* All the submenues can be called separatly (by key combination for example)
* Dockable menues (like blackbox)
* Transparency
* Drop shadow
* Icons for entries

Cinc: I think the WM/compositor should only provide the infrastructure to show menus. The final appearance/usability is up to the app.

Lexip: Here I'm talking about the system menu. The menu where you can start all you apps, or anything that you'd like to have in a menu. System menu is startable by right clicking on an empty spot on the background, or by keying-in some keyboard combination.

Cinc: IMHO such a system menu also should be a dedicated app (so it is replacable without tinkering with the WM). This app monitors the input queue and reacts when the configured message arrives (keyboard/mouse/whatever). Or alternatively the WM sends a message to tell this app to show the menu .

===== Configuration Features =====
* Configuration changes take effect withou restarting the wm
* Every single command is configurable to hava a certain keyboard or mouse click shortcut.
* Shortcuts are simple keyboard shortcuts (i.e. Ctrl+F1), or so called keychains known from Emacs editor (i.e. Alt+e+x)
* The wm allows mouse gestures, and keyboard mouse combined input (i.e. ctrl+mouse1 click, etc.)
* Single, double, or even tripple clicks call different actions (attention with patent from M$ in USA)
* Clicking the client window header is a different action than clicking the clients body for example. Cinc: can easily be done by treating those two as two coupled windows.

===== Extensibility =====
* Programming interface (every single command can be called from outside).
* Allow writing modules and applications that interact with the wm. Cinc: ah ok, addresses some of my concerns from above

===== Other =====
* Ability to play (opengl) games in fullscreen on virtual desktops instead of physical screens. (Today, if a game goes fullscreen, it'll either spread over all physical screens or the other screens are switched off... which is not nice if you would like to have the server stats/a map/whatever on the secondary screen).

Lexip: that sounds as a nice idea to me. we gotta do that

==== Started development on Neptune ====
I started the development of the window manager. The project is called '''neptune''', since this planet is one of those being observed by NASA's initial Voyager I mission.
Currently I'm developing under XOrg, and have the physical screens simulated by several Cairo Surfaces (the whole window manager will be based on the multi screen design).
Neptune has a to early state to publish anything. Currently I'm just experimenting with different architecture approaches, and am trying to figure out the best way to implement the multiscreen handling.
Once everything is done, it should be easy to "port" it to run without the X server, since all the painting is done through cairo. So it should be a matter of having glitz using a framebuffer GL backend instaed of the glx.

=== 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 ?
*** easy syncing/unmounting for usb mass storage devices
** 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?).

Cinc: Note for those with reading (well more with comprehension problems): I'm talking here about SOM and WPS programs, '''not''' OS/2 programs in general (maybe someone noticed the headline which says "SOM"). Anyone knows any widespread commercial WPS extension except ObjectDesktop??? I don't. I don't believe it's worth to support the almost not existant WPS integration of StarOffice5.xx. Geez, that thing is from the computer stoneage now. So before whining about missing WPS binary compatibility first try to find something needing it...
The remaining critics are invited to add binary compatibility if they want it. Nobody will hinder them. Quite the opposite, the toolkit comes with every eCS so just join the effort.

=== Desktop (WPS) ===

* The WPS should be designed with REXX scriptability in mind (like WPS-wizard addon)

Work is in progress. See the [[desktop]] page.

'''Note:''' Don't use the linked page for discussion. If you want to discuss use this section or the discussion page (hey that's what it was made for).

==== Spirit and Purpose of the WPS ====
The WPS only shows those parts of the computer system you have to deal with as a user.

Its objects are taken from the user's world of experience. The implementation details are hidden.

It is very intuitive to use. A Graphical GUI shows you, what is possible to do and what not. (Unlike a command line! The unix shell TAB key is a notable exception. But generally this can easier shown with graphics.)

The WPS is only for the user! Programs have DLLs and APIs of their own. (If not, then there is something missing on the system.)

Some WPS objects show or represent system details. That is, because daily administration tasks can also be regarded as "usage".

==== Security ====

Security should be a concern when creating the desktop application. GTK isn't secure by design so the desktop won't be either. Nevertheless we shouldn't open additional holes. The concept of the desktop allows arbitrary class and method replacement. So trojans can do whatever they want with it when they manage to get into the desktop app.

Ideas:

* Only allow signed/hashed classes to be loaded
* Maybe require that every author uses GnuPG to sign his/her class
* User has to allow loading any additional classes once
* "Save" classes will be listed in the users save class list
* The save class list is signed (GnuPG) to prevent altering

Is this sufficient?

=== 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

=== Network Transparency ===
It would be cool to execute applications remotely.

What we don't want is a distributed operating system like Amoeba or Inferno.

The network transport would be inside Cairo or between Cairo and OpenGL.
(Above Cairo makes no sense, because Cairo can also manipulate memory-stored images; below OpenGL is too much data overhead.)

When a user runs an application remotely, he wants to access devices on the client and the server. Examples for devices are
* printers
* mice, keyboard
* audio
* screens
* hard disks
* USB attached devices
* DVD burners

We need some kind of abstraction layer. It would be nice, if everything can be controlled by WPS objects:
* drag application on computer -> application gets executed there
* double-click (or also drag'n'drop) keyboard object -> this keyboard works for my console session

=== 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).

== Stuff ==
* With the advance of virtualization technologies like XEN, Vanderpool and multicore cpus it becomes more and more common to have a second, virtual computer running in a VM. It should be possible to map the virtual screen of the VM to a physically existing display. (The idea is to give the user the feeling that he actually has two different computers (with a shared set of input devices). It might even be possible to add another set of input devices, so that two users could work on one computer. (one or maybe even both using an emulated computer...)

Lexip: I think this should be no problem, since the WM will feature virtual desktops, which can be placed on any physical screen. Thus, if one places the virtual desktop holding the VM on a physical screen, you have what you want to. It will even be possible to split screens, and let several virtual desktops share one screen.

* [http://herpolhode.com/rob/ugly.pdf What's bad about Unix]. Nice reading
* [http://en.wikipedia.org/wiki/Plan_9_(operating_system) Plan 9]. The system the author of the reading above advocates to some degree. Not compatible enough, but interesting concepts.

== 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.
** I think the problem of current user interfaces is that they have a lot data dependencies. This increases the response time as they often have to wait for the data to become available before they can start to draw. Data dependencies mostly stem from an overdose of flexibility (I'm talking windows xp now).
*** XP's start menu: it is based on the directory structure in the startmenu folder. So in order to draw the menu it has to read from the hard disk several times as it needs to find out the structure and load the icons of the programs (they are mostly cached after the first time).
*** Drive windows, where the window needs to gather/update the drive information before it can be drawn the first time.
*** Explorer windows that display extended file info (eg id3 tags of mp3s) need to parse the files first. (in xp a corrupt media file can block the explorer, before you even get the chance to touch it)

Short:
Eyecandy and advanced/unnecessary features (even when switched off) waste cpu time.

* 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.

* As soon as we further expand the usage of WPS objects, the templates folder will grow and likewise the number of possible interactions and combinations of objects.
** How can the objects be sorted or structured so that the template folder won't scare of casual users? Answer: Just use the means of the WPS to do so. Override the right methods and use your programming brain. It's all documented int the WPS Programming Reference.
** How can we tell the users about interactions?
*** Example Drag'n'Drop: When the user starts dragging, display possible targets with arrows, colors, or other marks?

Or even let the objects come out of their hiding place, if they are not visible on the screen or in subfolders?
*** Example Creating of structures: XWorkplace has "Create new" in the context menu with the entries "Data File", "Folder", "Url Folder", "Program Object" as standard. The idea is good, but can be better. Take a strategy game you don't know and build up a base very fast. Now let an OS/2 newbie do the same with OS/2 objects. It is much more complicated. There is no way to see what objects fit into each other and you have to know that there is a templates folder and there is a system setup folder with palettes and themes. You could sum up these sentences as the demand for "Feedback for the Users".

== Implementation ==
You will find links to pages with some beef here later on. While the Voyager page is mainly for discussion and brainstorming the following pages go into detail and present the actual design decisions, roadmaps etc.

* Information about the [[desktop]] development.

== Press coverage ==
We slowly start to get some press:

* [http://slashdot.org/article.pl?sid=06/02/17/1423225 Slashdot - Keeping the OS/2 Flame Alive]
* [http://software.newsforge.com/software/06/01/30/192226.shtml?tid=150&tid=132&tid=16 And the original at Newsforge]

Developers Workshop 2006

2006-03-18T21:45:18Z

ShadoW: Everblue subitems

The OS/2 and eComStation Developers Workshop 2006 will take place the weekend of 8. and 9. April 2006 in Biel/Bienne, Switzerland.

===News Items===
23. February 2006    Added registration information & first overview of the topics 
21. January 2006    Added hotels and some information about Biel/Bienne. 
2. January 2006     Initial website online.

----

===Registration===
The registration is open at [http://www.mensys.net/DeveloperWorkshop2006/ Mensys] now, we provide the following tickets:

* netlabs.org Developers Workshop 2006, Saturday and Sunday: 45 Euro
* netlabs.org Developers Workshop 2006, one day: 25 Euro
* netlabs.org Developers Workshop 2006, students: Free

You can register at http://www.mensys.net/DeveloperWorkshop2006/
----

===Workshop Program===
There is no program yet but one of the main topics we will talk about is [[Voyager]], beside this we will for sure talk about current projects, like Genmac, ACPI, Everblue and so on. There will be quite some time for discussions, in a workshop form, also known as sitting around computers and hacking some code :)

We will provide enough space, wired or wireless network connection and a lot of bandwith.

====Schedule====

So far we plan to do the following presentations (details follow):

* Cairo
**General overview of Cairo, its structure and its API.
**Showing the Cairo API in live through a lot of examples.
* IOProc replacement
**Introduction to a new modular playback engine concept.
**Showing what's ready, what's to be done, what are the ideas.
**Discussing future possibilities (recording, transcoding...).
*The Voyager Object Model (was SOMH): The desktop will be built on an object model similar to SOM. The presentation details the reasons for an own object model and how it's implemented.
**Tour of the OS/2 desktop
**Why not using C++, Objective C, ...
**Implementation details
**Compatibility with SOM/DSOM
**Desktop development roadmap
**Using the object model for more
* Everblue
**Importance and Significance of Everblue (with and without Voyager)
**Current State and Problems
**Compiling and Running
**Demo of Working Applications
* Voyager - A coder overview about the project
** OpenGL as backend for Voyager - current options and problems
** Voyager components - where can you contribute
** OS/2 & PM compatibility - some crazy ideas worth discussing
* A WM based on Cairo
* Coding for WPS and Voyager
* netlabs.org Certificaton Program
* Translating Software

----

===Workshop Location===
Beside famous watch companies like Rolex, Omega and Swatch the city of Biel in Switzerland is the home of one more cool company: netlabs.org! This means that the Developers Workshop 2006 will take place in the city where netlabs.org was founded in 1997. I'm proud to do the hosting at the [http://www.hti.bfh.ch/ Berne University of Applied Sciences], the place where I did my studies and where I work now as a system administrator and teacher.

Biel is a small but cute city close to Bern, the capitol city. It's the boarder to the french speaking part of Switzerland so people in Biel speak german and french, at least most of them :-)
If you have some more spare time I recommend you to do a walk in the beautiful surroundings of Biel, for example the Jura mountains or around the lake. There is plenty to discover and with a bit of luck we will have a nice spring time in april.

Links:
* [http://www.drei-seen-land.ch Drei-Seen-Land] - a nice page with a lot of information about our region.
* [http://en.wikipedia.org/wiki/Biel/Bienne Biel/Bienne] at Wikipedia.org. Available in many languages.
* [http://ktk.netlabs.org/gallery/Altstadt-Biel-Bienne Old town of Biel] - some pics from the old town in my gallery

Hope to see you there!

Adrian Gschwend 
founder of netlabs.org
====Getting to Biel/Bienne====
Biel is the gate to the french speaking part of Switzerland, located in the western part of Switzerland. It is well connected to the railway system in Switzerland and easy to reach from about everywhere.

'''By train:''' 
There are night trains to Basel, called [http://www.citynightline.ch CityNightLine], this is mainly interesting if you want to get to Biel from Germany, Holland or Austria (it works from Denmark as well some days). You reach Biel within one hour from Basel by train.

For other train connections consult your local train office, if you have to travel to Biel from an airport check the homepage of [http://www.sbb.ch/ SBB], the railway company in Switzerland. For Geneva and Zurich you have to add ''Airport'' in the search field. For Basel and Bern Belp you need to take the local airport bus anyway.

'''By plane:''' 
There is no large airport close to Biel but in Switzerland almost everything is close anyway. So you can choose one of those airports if you want to get to Biel:

* Zurich (ZRH) - The biggest airport in Switzerland, quite good connections to Biel (every 30 minutes). Takes about 1.5 hours by train.
* Geneva (GVA) - good for Easyjet. There is just one train per hour to Biel, around 1.5 hours by train.
* Basel (BSL) - also good for Easyjet. There are bus connections to Basel and from there it's one hour by train.
* Berne Belp (BRN) - this is a small local airport, close to Bern but you still need to get to Biel and that's probably not much faster than Zurich because the Bus connections from this airport to Bern are not that great. From Bern it will take 30 minutes to Biel.

The local airline in Switzerland is [http://www.swiss.ch Swiss], which offers quite good trips from bigger cities.

----

====Accomodation====
There are several classes of hotels available in Biel:

* [http://www.lagolodge.ch/ Lago Lodge] - nice backpacker hostel directly at the lake of Biel. University is quite easy to reach by bus and the walk is not that far either.
* [http://www.continental-bienne.ch Hotel Continental] - 3-star hotel close to the lake as well. The road is quite busy so make sure you get a room towards the lake.
* [http://www.metropol-biel.ch Hotel Metropol] - 3-star hotel, 15-20 minutes walk to the University or bus.
* [http://www.lindenegg.ch/ Villa Lindenegg] - a very special and cute hotel in an old villa, 2 minutes away from the University, you can't get closer than that :)
* [http://www.accorhotels.com/accorhotels/fichehotel/gb/mer/6166/fiche_hotel.shtml Mercure Plaza] - 4-star hotel in the middle of the city
* [http://www.hotelelite.ch Hotel Elite] - 4-star hotel close to the railway station. Takes less than 10 minutes to the University.

If you can't afford a hotel we offer a room at the University where you can sleep with your sleeping bag and your mattress. The room is in the old manufacturing of Rolex and there are showers available too. It's probably not really comfortable but you don't have to pay anything for that :-) Please contact Adrian Gschwend if you want to do that, we have to know how many people do it like this. Email: ktk [at] netlabs.org 
Update: I made some pictures about the location: http://ktk.netlabs.org/gallery/HTIBiel
----

===Gallery===
There are some pictures online, check http://ktk.netlabs.org/gallery/HTIBiel

===Contact===
If you have comments or want further information about the workshop, you can always reach us by sending an eMail to: 
DevelopersWorkshop [at] netlabs.org 
Adrian Gschwend is mainly responsible for organizing the workshop. 

----
===Announcement Mailing List===
The announcement mailing list is closed now.

GpiEnableYInversion()

2005-11-25T21:31:25Z

ShadoW: GpiBitBlt, height - 1

Voyager

2005-11-22T22:37:06Z

ShadoW: Feedback for the Users

==Discussion==

This document is already some kind of discussion, you can add your comments in here as well. For real discussion please consult the [[Mailinglists | mailinglist]] <tt>voyager-dev@netlabs.org</tt>, or use the [http://dir.gmane.org/gmane.org.netlabs.voyager.devel gmane.org web/news interface] to it.

==Documentation==
===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.

===Darwin Documentation===
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.

* [http://www.kernelthread.com/software/fslogger/ Filechange notification] in Mac OSX "Tiger".

==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].
* [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]
* [http://www.opensolaris.org/os/ OpenSolaris]
* [http://www.ogre3d.org/ Ogre 3D] The open source real time 3D rendering engine - for nice 3D effects on the Voyager desktop
* [http://slashdot.org/article.pl?sid=05/11/03/1744230&tid=190&tid=109 Microsoft Singularity] - interesting paper by Microsoft about a concept study of a new OS
* [http://arstechnica.com/reviews/os/macosx-10.4.ars/13 Quartz and Quartz extreme], nice article giving an overview
* [http://klik.atekon.de/ Klik]: application bundles for KDE.
* More about application bundles: [http://mozart.chat.net/~jeske/unsolicitedDave/app_wrappers_yet_again.html http://mozart.chat.net/~jeske/unsolicitedDave/app_wrappers_yet_again.html], [http://mozart.chat.net/~jeske/unsolicitedDave/next_wrapper_description.html http://mozart.chat.net/~jeske/unsolicitedDave/next_wrapper_description.html], [http://mozart.chat.net/~jeske/unsolicitedDave/kde_encap_ideas.html http://mozart.chat.net/~jeske/unsolicitedDave/kde_encap_ideas.html]
* [http://rox.sourceforge.net/phpwiki/index.php/HomePage Rox] a quite nice desktop environment with features we also seek to implement

== Design Decisions ==
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===
* [http://x.org X11]
* [http://www.khronos.org/opengles OpenGL ES] (an OpenGL only desktop without X!)
* [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.
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===
* [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.

===Layer between 2D API and window manager (please enter name suggestions)===
Between the 2D API and the window manager one layer is missing
* that cares for user input by mouse, keyboard, ...
* that knows the basics about windows and controls their behaviour (A window manager only modifies this behaviour!)
* a Session manager that manages the processes which want do to screen output
* a message architecture that connects everything and enables inter-client communication

Questions:
* Should we choose X for that? Quasi-standard, but old
* modify existing(?) systems
* port Presentation Manager -> access to source code needed
* code that ourselves?

=== Window Manager ===
To manage the windows we need some sort of window manager. So far most implementations are done for X, we need to abstract that directly on Cairo.

* [http://www.freedesktop.org/Standards/wm-spec Window Manager Specification Project]
* [http://tronche.com/gui/x/icccm/ Inter-Client Communication Conventions Manual] - Support this standard in order to let X applications run
* [http://www.freedesktop.org/wiki/Software_2fwaimea Waimea] - WM which is using Cairo for all rendering, they write it's for X so one would have to check if this can be separated from X as well.

==== Ideas for a new Window Manager ====
What features should a new windows manager have?

Cinc: Obviously these ideas are inspired by stuff usually found on X. The WM needed for this project isn't the kind of
WM X uses. I think WM is the wrong word for it anyway. What's needed is primarily a compositing engine which is in charge
of allocating surfaces, giving them to the app, the app draws into them and the compositor puts it on the screen.
Input support is probably needed for this layer, too, so the compositor may move and stack windows correctly.
The final appearance of the graphics drawn on the surfacces is up to the applications not the compositor. It must be
that way IMHO because no compositor coder can imagine what app developer will finally do with a given infrastructure.
E.g. creating close, maximize etc. widgets in the compositor/WM effectively prevents the application developer from
adding his own widgets or removing the given one. OTOH if there's a documented way to tinker with (per window) then it's ok.

The compositor/WM should be inspired by the Presentation manager (PM) found in OS/2. Granted it's old technology it's
unbelievable flexible. It's possible for the coder to alter the handling of every window/widget by subclassing the window procedures
provided by the system. For example the information area found in [http://www.os2world.com/cdwriting WPS-wizard] uses
this feature. PM is directed to order all the window areas differently (titlebar, close/maximize, client area) to give room for the
information area. The coders of PM never thought about the possibility to add such informations to windows back when they
did PM. It's not a hack and there's no need to change any WM code to get this to work.

Lexip: What about the common look and feel of all the headers of the client windows? I'd like to have a common theme for example, and all apps should have a header (with a little icon, and the close/minimize/... buttons) that paints according to that theme file.

Cinc: ACK. What I mean is the WM should not restrict the developer from adding/removing widgets, from modifying the way how things are done for a particular window (e.g. positioning of widgets). This also applies on how things are painted. If the developer decides to remove all widgets and use an ugly custom theme (which is bad) he should be free to do so.

===== Main Features =====
* Built i18n (internationoalization)
* .prestartup and .poststartup files
* Multiscreen support (with possibility of virtual desktops 1 being on physical screen 1, while having virtual desktop 4 on screen 2)
** Preview of desktop X on desktop Y. Like you have one desktop with the presentation on desktop X and on desktop Y (your main display for example) you see a resizable preview so you could have your script on the main display and still step through the slides
* Anti aliasing
* Virtual desktops (different layouts and number of desktops - 4x2, 3x3, ...)
* Storing sessions. Cinc: not sure the WM should do that
* 100% ewmh complient. Cinc: ???? if this is some X thingie it's probably not needed -> Lexip: yeah, it's X stuff, but if we want to support starting Xapps, and we should do that, then we gotta be ewmh complient with our WM/compositor
* Large desktops (scrolling and paging)
* Themes with possibility of associating a background image or pattern (i.e. blackbox)

===== Client Window Features =====
* Client window header can be top/bottom/right/left (with vertical text if necessary).
* Window manager keeps track of stacking order of all client windows
* Sticky windows - Possibility to show clients on all or few or just one virtual desktop
* Virtual desktops with resolutions different from the physical screen resolution.
* Ability to display multiple virtual desktops on one physical screen.
* Maximization:
** Maximize to given area
** Maximize to actual screen
** Maximize to more than one screen
** Maximize vertically only
** Maximize horizontally only
* Clients can influence their states:
** Maximized
** Stacking order
** Shading
** Stickiness
** Desktop(s)
* Window in Window handling for MDI applications
* Edge snapping while move- resizing a client window
* Client window shading
* Store client window properties per application (size, position, etc)
* Client window can drop shadow
* Application icons in client window headers
* Different focus models (click to focus, focus follows mouse, ...)

===== Docking Area Features =====
* Allow having multiple docking areas
* Docking areas can be hid (approaching mouse makes them appeare)
* Transparency
* Drop shadow

Cinc: The WM should not be in charge of this. The Dock (or whatever) is just an application and should be treated as one.

Lexip: question again about the theme. If the WM/compositor is not in charge of the docker, how can we set a common theme to it?

Cinc: The WM/OS should provide the default bitmaps for it (or better any app) which can be queried by the app. Changing the theme will automatically change these BMPs. For buttons and alike the OS should provide a default drawing function which will ensure every app which uses the default automatically has a similar look and feel.

===== Menu Features =====
* Dynamically filled menus (piped menus). Cinc: That's mostly up to the application IMHO with the exception of system menus.
* Menu configuration can be separated over several files, i.e. one file for each submenu section
* All the submenues can be called separatly (by key combination for example)
* Dockable menues (like blackbox)
* Transparency
* Drop shadow
* Icons for entries

Cinc: I think the WM/compositor should only provide the infrastructure to show menus. The final appearance/usability is up to the app.

Lexip: Here I'm talking about the system menu. The menu where you can start all you apps, or anything that you'd like to have in a menu. System menu is startable by right clicking on an empty spot on the background, or by keying-in some keyboard combination.

Cinc: IMHO such a system menu also should be a dedicated app (so it is replacable without tinkering with the WM). This app monitors the input queue and reacts when the configured message arrives (keyboard/mouse/whatever).

===== Configuration Features =====
* Configuration changes take effect withou restarting the wm
* Every single command is configurable to hava a certain keyboard or mouse click shortcut.
* Shortcuts are simple keyboard shortcuts (i.e. Ctrl+F1), or so called keychains known from Emacs editor (i.e. Alt+e+x)
* The wm allows mouse gestures, and keyboard mouse combined input (i.e. ctrl+mouse1 click, etc.)
* Single, double, or even tripple clicks call different actions (attention with patent from M$ in USA)
* Clicking the client window header is a different action than clicking the clients body for example. Cinc: can easily be done by treating those two as two coupled windows.

===== Extensibility =====
* Programming interface (every single command can be called from outside).
* Allow writing modules and applications that interact with the wm. Cinc: ah ok, addresses some of my concerns from above

===== Other =====
* Ability to play (opengl) games in fullscreen on virtual desktops instead of physical screens. (Today, if a game goes fullscreen, it'll either spread over all physical screens or the other screens are switched off... which is not nice if you would like to have the server stats/a map/whatever on the secondary screen).

Lexip: that sounds as a nice idea to me. we gotta do that

=== 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 ?
*** easy syncing/unmounting for usb mass storage devices
** 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?).

=== Desktop (WPS) ===

* The WPS should be designed with REXX scriptability in mind (like WPS-wizard addon)

Work is in progress. See the [[desktop]] page.

'''Note:''' Don't use the linked page for discussion. If you want to discuss use this section or the discussion page (hey that's what it was made for).

==== Spirit and Purpose of the WPS ====
The WPS only shows those parts of the computer system you have to deal with as a user.

Its objects are taken from the user's world of experience. The implementation details are hidden.

It is very intuitive to use. A Graphical GUI shows you, what is possible to do and what not. (Unlike a command line! The unix shell TAB key is a notable exception. But generally this can easier shown with graphics.)

The WPS is only for the user! Programs have DLLs and APIs of their own. (If not, then there is something missing on the system.)

Some WPS objects show or represent system details. That is, because daily administration tasks can also be regarded as "usage".

==== Security ====

Security should be a concern when creating the desktop application. GTK isn't secure by design so the desktop wont be either. Nevertheless we shouldn't open additional holes. The concept of the desktop allows arbitrary class and method replacement. So trojans can do whatever they want with it when they manage to get into the desktop app.

Ideas:

* Only allow signed/hashed classes to be loaded
* Maybe require that every author uses GunPG to sign his/her class
* User has to allow loading any additional classes once
* "Save" classes will be listed in the users save class list
* The save class list is signed (GnuPG) to prevent altering

Is this sufficient?

=== 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

=== Network Transparency ===
It would be cool to execute applications remotely.

What we don't want is a distributed operating system like Amoeba or Inferno.

The network transport would be inside Cairo or between Cairo and OpenGL.
(Above Cairo makes no sense, because Cairo can also manipulate memory-stored images; below OpenGL is too much data overhead.)

When a user runs an application remotely, he wants to access devices on the client and the server. Examples for devices are
* printers
* mice, keyboard
* audio
* screens
* hard disks
* USB attached devices
* DVD burners

We need some kind of abstraction layer. It would be nice, if everything can be controlled by WPS objects:
* drag application on computer -> application gets executed there
* double-click (or also drag'n'drop) keyboard object -> this keyboard works for my console session

=== 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).

== Stuff ==
* With the advance of virtualization technologies like XEN, Vanderpool and multicore cpus it becomes more and more common to have a second, virtual computer running in a VM. It should be possible to map the virtual screen of the VM to a physically existing display. (The idea is to give the user the feeling that he actually has two different computers (with a shared set of input devices). It might even be possible to add another set of input devices, so that two users could work on one computer. (one or maybe even both using an emulated computer...)

* [http://herpolhode.com/rob/ugly.pdf What's bad about Unix]. Nice reading
* [http://en.wikipedia.org/wiki/Plan_9_(operating_system) Plan 9]. The system the author of the reading above advocates to some degree. Not compatible enough, but interesting concepts.

== 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.
** I think the problem of current user interfaces is that they have a lot data dependencies. This increases the response time as they often have to wait for the data to become available before they can start to draw. Data dependencies mostly stem from an overdose of flexibility (I'm talking windows xp now).
*** XP's start menu: it is based on the directory structure in the startmenu folder. So in order to draw the menu it has to read from the hard disk several times as it needs to find out the structure and load the icons of the programs (they are mostly cached after the first time).
*** Drive windows, where the window needs to gather/update the drive information before it can be drawn the first time.
*** Explorer windows that display extended file info (eg id3 tags of mp3s) need to parse the files first. (in xp a corrupt media file can block the explorer, before you even get the chance to touch it)

Short:
Eyecandy and advanced/unnecessary features (even when switched off) waste cpu time.

* 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.

* As soon as we further expand the usage of WPS objects, the templates folder will grow and likewise the number of possible interactions and combinations of objects.
** How can the objects be sorted or structured so that the template folder won't scare of casual users?
** How can we tell the users about interactions?
*** Example Drag'n'Drop: When the user starts dragging, display possible targets with arrows, colors, or other marks?

Or even let the objects come out of their hiding place, if they are not visible on the screen or in subfolders?
*** Example Creating of structures: XWorkplace has "Create new" in the context menu with the entries "Data File", "Folder", "Url Folder", "Program Object" as standard. The idea is good, but can be better. Take a strategy game you don't know and build up a base very fast. Now let an OS/2 newbie do the same with OS/2 objects. It is much more complicated. There is no way to see what objects fit into each other and you have to know that there is a templates folder and there is a system setup folder with palettes and themes. You could sum up these sentences as the demand for "Feedback for the Users".

== Implementation ==
You will find links to pages with some beef here later on.

* Information about the [[desktop]] development.

Voyager

2005-11-22T21:36:42Z

ShadoW: network stuff

==Discussion==

This document is already some kind of discussion, you can add your comments in here as well. For real discussion please consult the [[Mailinglists | mailinglist]] <tt>voyager-dev@netlabs.org</tt>, or use the [http://dir.gmane.org/gmane.org.netlabs.voyager.devel gmane.org web/news interface] to it.

==Documentation==
===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.

===Darwin Documentation===
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.

* [http://www.kernelthread.com/software/fslogger/ Filechange notification] in Mac OSX "Tiger".

==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].
* [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]
* [http://www.opensolaris.org/os/ OpenSolaris]
* [http://www.ogre3d.org/ Ogre 3D] The open source real time 3D rendering engine - for nice 3D effects on the Voyager desktop
* [http://slashdot.org/article.pl?sid=05/11/03/1744230&tid=190&tid=109 Microsoft Singularity] - interesting paper by Microsoft about a concept study of a new OS
* [http://arstechnica.com/reviews/os/macosx-10.4.ars/13 Quartz and Quartz extreme], nice article giving an overview
* [http://klik.atekon.de/ Klik]: application bundles for KDE.
* More about application bundles: [http://mozart.chat.net/~jeske/unsolicitedDave/app_wrappers_yet_again.html http://mozart.chat.net/~jeske/unsolicitedDave/app_wrappers_yet_again.html], [http://mozart.chat.net/~jeske/unsolicitedDave/next_wrapper_description.html http://mozart.chat.net/~jeske/unsolicitedDave/next_wrapper_description.html], [http://mozart.chat.net/~jeske/unsolicitedDave/kde_encap_ideas.html http://mozart.chat.net/~jeske/unsolicitedDave/kde_encap_ideas.html]
* [http://rox.sourceforge.net/phpwiki/index.php/HomePage Rox] a quite nice desktop environment with features we also seek to implement

== Design Decisions ==
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===
* [http://x.org X11]
* [http://www.khronos.org/opengles OpenGL ES] (an OpenGL only desktop without X!)
* [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.
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===
* [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.

===Layer between 2D API and window manager (please enter name suggestions)===
Between the 2D API and the window manager one layer is missing
* that cares for user input by mouse, keyboard, ...
* that knows the basics about windows and controls their behaviour (A window manager only modifies this behaviour!)
* a Session manager that manages the processes which want do to screen output
* a message architecture that connects everything and enables inter-client communication

Questions:
* Should we choose X for that? Quasi-standard, but old
* modify existing(?) systems
* port Presentation Manager -> access to source code needed
* code that ourselves?

=== Window Manager ===
To manage the windows we need some sort of window manager. So far most implementations are done for X, we need to abstract that directly on Cairo.

* [http://www.freedesktop.org/Standards/wm-spec Window Manager Specification Project]
* [http://tronche.com/gui/x/icccm/ Inter-Client Communication Conventions Manual] - Support this standard in order to let X applications run
* [http://www.freedesktop.org/wiki/Software_2fwaimea Waimea] - WM which is using Cairo for all rendering, they write it's for X so one would have to check if this can be separated from X as well.

==== Ideas for a new Window Manager ====
What features should a new windows manager have?

Cinc: Obviously these ideas are inspired by stuff usually found on X. The WM needed for this project isn't the kind of
WM X uses. I think WM is the wrong word for it anyway. What's needed is primarily a compositing engine which is in charge
of allocating surfaces, giving them to the app, the app draws into them and the compositor puts it on the screen.
Input support is probably needed for this layer, too, so the compositor may move and stack windows correctly.
The final appearance of the graphics drawn on the surfacces is up to the applications not the compositor. It must be
that way IMHO because no compositor coder can imagine what app developer will finally do with a given infrastructure.
E.g. creating close, maximize etc. widgets in the compositor/WM effectively prevents the application developer from
adding his own widgets or removing the given one. OTOH if there's a documented way to tinker with (per window) then it's ok.

The compositor/WM should be inspired by the Presentation manager (PM) found in OS/2. Granted it's old technology it's
unbelievable flexible. It's possible for the coder to alter the handling of every window/widget by subclassing the window procedures
provided by the system. For example the information area found in [http://www.os2world.com/cdwriting WPS-wizard] uses
this feature. PM is directed to order all the window areas differently (titlebar, close/maximize, client area) to give room for the
information area. The coders of PM never thought about the possibility to add such informations to windows back when they
did PM. It's not a hack and there's no need to change any WM code to get this to work.

Lexip: What about the common look and feel of all the headers of the client windows? I'd like to have a common theme for example, and all apps should have a header (with a little icon, and the close/minimize/... buttons) that paints according to that theme file.

Cinc: ACK. What I mean is the WM should not restrict the developer from adding/removing widgets, from modifying the way how things are done for a particular window (e.g. positioning of widgets). This also applies on how things are painted. If the developer decides to remove all widgets and use an ugly custom theme (which is bad) he should be free to do so.

===== Main Features =====
* Built i18n (internationoalization)
* .prestartup and .poststartup files
* Multiscreen support (with possibility of virtual desktops 1 being on physical screen 1, while having virtual desktop 4 on screen 2)
** Preview of desktop X on desktop Y. Like you have one desktop with the presentation on desktop X and on desktop Y (your main display for example) you see a resizable preview so you could have your script on the main display and still step through the slides
* Anti aliasing
* Virtual desktops (different layouts and number of desktops - 4x2, 3x3, ...)
* Storing sessions. Cinc: not sure the WM should do that
* 100% ewmh complient. Cinc: ???? if this is some X thingie it's probably not needed -> Lexip: yeah, it's X stuff, but if we want to support starting Xapps, and we should do that, then we gotta be ewmh complient with our WM/compositor
* Large desktops (scrolling and paging)
* Themes with possibility of associating a background image or pattern (i.e. blackbox)

===== Client Window Features =====
* Client window header can be top/bottom/right/left (with vertical text if necessary).
* Window manager keeps track of stacking order of all client windows
* Sticky windows - Possibility to show clients on all or few or just one virtual desktop
* Virtual desktops with resolutions different from the physical screen resolution.
* Ability to display multiple virtual desktops on one physical screen.
* Maximization:
** Maximize to given area
** Maximize to actual screen
** Maximize to more than one screen
** Maximize vertically only
** Maximize horizontally only
* Clients can influence their states:
** Maximized
** Stacking order
** Shading
** Stickiness
** Desktop(s)
* Window in Window handling for MDI applications
* Edge snapping while move- resizing a client window
* Client window shading
* Store client window properties per application (size, position, etc)
* Client window can drop shadow
* Application icons in client window headers
* Different focus models (click to focus, focus follows mouse, ...)

===== Docking Area Features =====
* Allow having multiple docking areas
* Docking areas can be hid (approaching mouse makes them appeare)
* Transparency
* Drop shadow

Cinc: The WM should not be in charge of this. The Dock (or whatever) is just an application and should be treated as one.

Lexip: question again about the theme. If the WM/compositor is not in charge of the docker, how can we set a common theme to it?

Cinc: The WM/OS should provide the default bitmaps for it (or better any app) which can be queried by the app. Changing the theme will automatically change these BMPs. For buttons and alike the OS should provide a default drawing function which will ensure every app which uses the default automatically has a similar look and feel.

===== Menu Features =====
* Dynamically filled menus (piped menus). Cinc: That's mostly up to the application IMHO with the exception of system menus.
* Menu configuration can be separated over several files, i.e. one file for each submenu section
* All the submenues can be called separatly (by key combination for example)
* Dockable menues (like blackbox)
* Transparency
* Drop shadow
* Icons for entries

Cinc: I think the WM/compositor should only provide the infrastructure to show menus. The final appearance/usability is up to the app.

Lexip: Here I'm talking about the system menu. The menu where you can start all you apps, or anything that you'd like to have in a menu. System menu is startable by right clicking on an empty spot on the background, or by keying-in some keyboard combination.

Cinc: IMHO such a system menu also should be a dedicated app (so it is replacable without tinkering with the WM). This app monitors the input queue and reacts when the configured message arrives (keyboard/mouse/whatever).

===== Configuration Features =====
* Configuration changes take effect withou restarting the wm
* Every single command is configurable to hava a certain keyboard or mouse click shortcut.
* Shortcuts are simple keyboard shortcuts (i.e. Ctrl+F1), or so called keychains known from Emacs editor (i.e. Alt+e+x)
* The wm allows mouse gestures, and keyboard mouse combined input (i.e. ctrl+mouse1 click, etc.)
* Single, double, or even tripple clicks call different actions (attention with patent from M$ in USA)
* Clicking the client window header is a different action than clicking the clients body for example. Cinc: can easily be done by treating those two as two coupled windows.

===== Extensibility =====
* Programming interface (every single command can be called from outside).
* Allow writing modules and applications that interact with the wm. Cinc: ah ok, addresses some of my concerns from above

===== Other =====
* Ability to play (opengl) games in fullscreen on virtual desktops instead of physical screens. (Today, if a game goes fullscreen, it'll either spread over all physical screens or the other screens are switched off... which is not nice if you would like to have the server stats/a map/whatever on the secondary screen).

Lexip: that sounds as a nice idea to me. we gotta do that

=== 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 ?
*** easy syncing/unmounting for usb mass storage devices
** 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?).

=== Desktop (WPS) ===

* The WPS should be designed with REXX scriptability in mind (like WPS-wizard addon)

Work is in progress. See the [[desktop]] page.

'''Note:''' Don't use the linked page for discussion. If you want to discuss use this section or the discussion page (hey that's what it was made for).

==== Security ====

Security should be a concern when creating the desktop application. GTK isn't secure by design so the desktop wont be either. Nevertheless we shouldn't open additional holes. The concept of the desktop allows arbitrary class and method replacement. So trojans can do whatever they want with it when they manage to get into the desktop app.

Ideas:

* Only allow signed/hashed classes to be loaded
* Maybe require that every author uses GunPG to sign his/her class
* User has to allow loading any additional classes once
* "Save" classes will be listed in the users save class list
* The save class list is signed (GnuPG) to prevent altering

Is this sufficient?

=== 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

=== Network Transparency ===
It would be cool to execute applications remotely.

What we don't want is a distributed operating system like Amoeba or Inferno.

The network transport would be inside Cairo or between Cairo and OpenGL.
(Above Cairo makes no sense, because Cairo can also manipulate memory-stored images; below OpenGL is too much data overhead.)

When a user runs an application remotely, he wants to access devices on the client and the server. Examples for devices are
* printers
* mice, keyboard
* audio
* screens
* hard disks
* USB attached devices
* DVD burners

We need some kind of abstraction layer. It would be nice, if everything can be controlled by WPS objects:
* drag application on computer -> application gets executed there
* double-click (or also drag'n'drop) keyboard object -> this keyboard works for my console session

=== 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).

== Stuff ==
* With the advance of virtualization technologies like XEN, Vanderpool and multicore cpus it becomes more and more common to have a second, virtual computer running in a VM. It should be possible to map the virtual screen of the VM to a physically existing display. (The idea is to give the user the feeling that he actually has two different computers (with a shared set of input devices). It might even be possible to add another set of input devices, so that two users could work on one computer. (one or maybe even both using an emulated computer...)

* [http://herpolhode.com/rob/ugly.pdf What's bad about Unix]. Nice reading
* [http://en.wikipedia.org/wiki/Plan_9_(operating_system) Plan 9]. The system the author of the reading above advocates to some degree. Not compatible enough, but interesting concepts.

== 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.
** I think the problem of current user interfaces is that they have a lot data dependencies. This increases the response time as they often have to wait for the data to become available before they can start to draw. Data dependencies mostly stem from an overdose of flexibility (I'm talking windows xp now).
*** XP's start menu: it is based on the directory structure in the startmenu folder. So in order to draw the menu it has to read from the hard disk several times as it needs to find out the structure and load the icons of the programs (they are mostly cached after the first time).
*** Drive windows, where the window needs to gather/update the drive information before it can be drawn the first time.
*** Explorer windows that display extended file info (eg id3 tags of mp3s) need to parse the files first. (in xp a corrupt media file can block the explorer, before you even get the chance to touch it)

Short:
Eyecandy and advanced/unnecessary features (even when switched off) waste cpu time.

* 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.

== Implementation ==
You will find links to pages with some beef here later on.

* Information about the [[desktop]] development.

Voyager

2005-11-07T12:35:36Z

ShadoW: Plan 9

==Documentation==
===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.

===Darwin Documentation===
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].
* [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]
* [http://www.opensolaris.org/os/ OpenSolaris]
* [http://www.ogre3d.org/ Ogre 3D] The open source real time 3D rendering engine - for nice 3D effects on the Voyager desktop
* [http://slashdot.org/article.pl?sid=05/11/03/1744230&tid=190&tid=109 Microsoft Singularity] - interesting paper by Microsoft about a concept study of a new OS
* [http://arstechnica.com/reviews/os/macosx-10.4.ars/13 Quartz and Quartz extreme], nice article giving an overview

== Design Decisions ==
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===
* [http://x.org X11]
* [http://www.khronos.org/opengles OpenGL ES] (an OpenGL only desktop without X!)
* [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.
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===
* [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.

===Layer between 2D API and window manager (please enter name suggestions)===
Between the 2D API and the window manager one layer is missing
* that cares for user input by mouse, keyboard, ...
* that knows the basics about windows and controls their behaviour (A window manager only modifies this behaviour!)
* a Session manager that manages the processes which want do to screen output
* a message architecture that connects everything and enables inter-client communication

Questions:
* Should we choose X for that? Quasi-standard, but old
* modify existing(?) systems
* port Presentation Manager -> access to source code needed
* code that ourselves?

=== Window Manager ===
To manage the windows we need some sort of window manager. So far most implementations are done for X, we need to abstract that directly on Cairo.

* [http://www.freedesktop.org/Standards/wm-spec Window Manager Specification Project]
* [http://tronche.com/gui/x/icccm/ Inter-Client Communication Conventions Manual] - Support this standard in order to let X applications run
* [http://www.freedesktop.org/wiki/Software_2fwaimea Waimea] - WM which is using Cairo for all rendering, they write it's for X so one would have to check if this can be separated from X as well.

==== Ideas for a new Window Manager ====
What features should a new windows manager have?

Cinc: Obviously these ideas are inspired by stuff usually found on X. The WM needed for this project isn't the kind of
WM X uses. I think WM is the wrong word for it anyway. What's needed is primarily a compositing engine which is in charge
of allocating surfaces, giving them to the app, the app draws into them and the compositor puts it on the screen.
Input support is probably needed for this layer, too, so the compositor may move and stack windows correctly.
The final appearance of the graphics drawn on the surfacces is up to the applications not the compositor. It must be
that way IMHO because no compositor coder can imagine what app developer will finally do with a given infrastructure.
E.g. creating close, maximize etc. widgets in the compositor/WM effectively prevents the application developer from
adding his own widgets or removing the given one. OTOH if there's a documented way to tinker with (per window) then it's ok.

The compositor/WM should be inspired by the Presentation manager (PM) found in OS/2. Granted it's old technology it's
unbelievable flexible. It's possible for the coder to alter the handling of every window/widget by subclassing the window procedures
provided by the system. For example the information area found in [http://www.os2world.com/cdwriting WPS-wizard] uses
this feature. PM is directed to order all the window areas differently (titlebar, close/maximize, client area) to give room for the
information area. The coders of PM never thought about the possibility to add such informations to windows back when they
did PM. It's not a hack and there's no need to change any WM code to get this to work.

Lexip: What about the common look and feel of all the headers of the client windows? I'd like to have a common theme for example, and all apps should have a header (with a little icon, and the close/minimize/... buttons) that paints according to that theme file.

Cinc: ACK. What I mean is the WM should not restrict the developer from adding/removing widgets, from modifying the way how things are done for a particular window (e.g. positioning of widgets). This also applies on how things are painted. If the developer decides to remove all widgets and use an ugly custom theme (which is bad) he should be free to do so.

===== Main Features =====
* Built i18n (internationoalization)
* .prestartup and .poststartup files
* Multiscreen support (with possibility of virtual desktops 1 being on physical screen 1, while having virtual desktop 4 on screen 2)
* Anti aliasing
* Virtual desktops (different layouts and number of desktops - 4x2, 3x3, ...)
* Storing sessions. Cinc: not sure the WM should do that
* 100% ewmh complient. Cinc: ???? if this is some X thingie it's probably not needed -> Lexip: yeah, it's X stuff, but if we want to support starting Xapps, and we should do that, then we gotta be ewmh complient with our WM/compositor
* Large desktops (scrolling and paging)
* Themes with possibility of associating a background image or pattern (i.e. blackbox)

===== Client Window Features =====
* Client window header can be top/bottom/right/left (with vertical text if necessary).
* Window manager keeps track of stacking order of all client windows
* Sticky windows - Possibility to show clients on all or few or just one virtual desktop
* Virtual desktops with resolutions different from the physical screen resolution.
* Ability to display multiple virtual desktops on one physical screen.
* Maximization:
** Maximize to given area
** Maximize to actual screen
** Maximize to more than one screen
** Maximize vertically only
** Maximize horizontally only
* Clients can influence their states:
** Maximized
** Stacking order
** Shading
** Stickiness
** Desktop(s)
* Window in Window handling for MDI applications
* Edge snapping while move- resizing a client window
* Client window shading
* Store client window properties per application (size, position, etc)
* Client window can drop shadow
* Application icons in client window headers
* Different focus models (click to focus, focus follows mouse, ...)

===== Docking Area Features =====
* Allow having multiple docking areas
* Docking areas can be hid (approaching mouse makes them appeare)
* Transparency
* Drop shadow

Cinc: The WM should not be in charge of this. The Dock (or whatever) is just an application and should be treated as one.

Lexip: question again about the theme. If the WM/compositor is not in charge of the docker, how can we set a common theme to it?

Cinc: The WM/OS should provide the default bitmaps for it (or better any app) which can be queried by the app. Changing the theme will automatically change these BMPs. For buttons and alike the OS should provide a default drawing function which will ensure every app which uses the default automatically has a similar look and feel.

===== Menu Features =====
* Dynamically filled menus (piped menus). Cinc: That's mostly up to the application IMHO with the exception of system menus.
* Menu configuration can be separated over several files, i.e. one file for each submenu section
* All the submenues can be called separatly (by key combination for example)
* Dockable menues (like blackbox)
* Transparency
* Drop shadow
* Icons for entries

Cinc: I think the WM/compositor should only provide the infrastructure to show menus. The final appearance/usability is up to the app.

Lexip: Here I'm talking about the system menu. The menu where you can start all you apps, or anything that you'd like to have in a menu. System menu is startable by right clicking on an empty spot on the background, or by keying-in some keyboard combination.

Cinc: IMHO such a system menu also should be a dedicated app (so it is replacable without tinkering with the WM). This app monitors the input queue and reacts when the configured message arrives (keyboard/mouse/whatever).

===== Configuration Features =====
* Configuration changes take effect withou restarting the wm
* Every single command is configurable to hava a certain keyboard or mouse click shortcut.
* Shortcuts are simple keyboard shortcuts (i.e. Ctrl+F1), or so called keychains known from Emacs editor (i.e. Alt+e+x)
* The wm allows mouse gestures, and keyboard mouse combined input (i.e. ctrl+mouse1 click, etc.)
* Single, double, or even tripple clicks call different actions (attention with patent from M$ in USA)
* Clicking the client window header is a different action than clicking the clients body for example. Cinc: can easily be done by treating those two as two coupled windows.

===== Extensibility =====
* Programming interface (every single command can be called from outside).
* Allow writing modules and applications that interact with the wm. Cinc: ah ok, addresses some of my concerns from above

===== Other =====
* Ability to play (opengl) games in fullscreen on virtual desktops instead of physical screens. (Today, if a game goes fullscreen, it'll either spread over all physical screens or the other screens are switched off... which is not nice if you would like to have the server stats/a map/whatever on the secondary screen).

Lexip: that sounds as a nice idea to me. we gotta do that

=== 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 ?
*** easy syncing/unmounting for usb mass storage devices
** 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).

== Stuff ==
* With the advance of virtualization technologies like XEN, Vanderpool and multicore cpus it becomes more and more common to have a second, virtual computer running in a VM. It should be possible to map the virtual screen of the VM to a physically existing display. (The idea is to give the user the feeling that he actually has two different computers (with a shared set of input devices). It might even be possible to add another set of input devices, so that two users could work on one computer. (one or maybe even both using an emulated computer...)

* [http://herpolhode.com/rob/ugly.pdf What's bad about Unix]. Nice reading
* [http://en.wikipedia.org/wiki/Plan_9_(operating_system) Plan 9]. The system the author of the reading above advocates to some degree. Not compatible enough, but interesting concepts.

== 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.
** I think the problem of current user interfaces is that they have a lot data dependencies. This increases the response time as they often have to wait for the data to become available before they can start to draw. Data dependencies mostly stem from an overdose of flexibility (I'm talking windows xp now).
*** XP's start menu: it is based on the directory structure in the startmenu folder. So in order to draw the menu it has to read from the hard disk several times as it needs to find out the structure and load the icons of the programs (they are mostly cached after the first time).
*** Drive windows, where the window needs to gather/update the drive information before it can be drawn the first time.
*** Explorer windows that display extended file info (eg id3 tags of mp3s) need to parse the files first. (in xp a corrupt media file can block the explorer, before you even get the chance to touch it)

Short:
Eyecandy and advanced/unnecessary features (even when switched off) waste cpu time.

* 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.

Voyager

2005-11-03T13:22:47Z

ShadoW: missing layer

Voyager

2005-10-31T08:58:13Z

ShadoW: added Snap

Voyager

2005-10-30T21:36:14Z

ShadoW:

Voyager

2005-10-30T21:35:51Z

ShadoW:

Voyager

2005-10-30T21:35:16Z

ShadoW: move ggi to 2D api

Voyager

2005-10-30T21:29:50Z

ShadoW: corrected links

Voyager

2005-10-30T21:27:18Z

ShadoW: 2D APIs

Voyager

2005-10-28T16:03:53Z

ShadoW: added DirectFB

Voyager

2005-10-28T13:26:45Z

ShadoW: additional question

Voyager

2005-10-28T10:30:53Z

ShadoW: X on GL

Voyager

2005-10-27T23:43:14Z

ShadoW:

Voyager

2005-10-27T22:38:17Z

ShadoW: link to gtk+ info

Voyager

2005-10-26T20:53:02Z

ShadoW: link has changed, while I read the page!?!

Voyager

2005-10-26T20:49:17Z

ShadoW: Added link to Jon Smirl's article