NikiWiki - User contributions [en]

Mailinglists

2008-04-30T15:40:38Z

Cinc: Fixed links to community ML web frontend

[[Category:Projects]]
== Mailinglists for projects ==
netlabs.org provides some mailinglists for its projects. Usualy the name is projectname-dev and projectname-user. As you can imagine the -dev list is ment for developers and the -user list for users of the project itself. Please respect that separation and do not post user questions in the developer list!

* To post a message to the list, send an email to <tt><listname>@netlabs.org</tt>
* To subscribe, e-mail: <tt><listname>-subscribe@netlabs.org</tt>
* To unsubscribe, e-mail: <tt><listname>-unsubscribe@netlabs.org</tt>
* For additional commands, e-mail: <tt><listname>-help@netlabs.org</tt>

We also provide digest lists:

* To subscribe to the digest, e-mail: <tt><listname>-digest-subscribe@netlabs.org</tt>
* To unsubscribe from the digest, e-mail: <tt><listname>-digest-unsubscribe@netlabs.org</tt>

To post messages to the list, e-mail: <tt><listname>@netlabs.org</tt> 
Where <tt><listname></tt> is for example <tt>xworkplace-dev</tt>.

=== netlabs.org community ===
If you want to join the netlabs.org community mailinglist, send an eMail to <tt>community-subscribe@netlabs.org</tt>. The subject and the body of the eMail can be empty. You will almost immediately receive an email to confirm your subscription request. To finally subscribe, you need to reply to the confirmation email! If you forget to do that, you will not be subscribed to the list! 

The website for the community mailinglist is:
http://dir.gmane.org/gmane.org.netlabs.community

This points directly to the messages:
http://news.gmane.org/gmane.org.netlabs.community/

=== gmane.org: Newsgroup interface & web archive ===
To make sure that everyone can access the mailinglists easily we also provide a newsgroup interface at http://gmane.org where you can read and post messages to the lists. 
gmane.org is an excellent service that provides a newsgroup interface for subscribed mailinglists. Also it acts as an archive for the list and they provide a very simple to use webinterface where you can also post messages if you wish.

All mailinglists at netlabs.org are subscribed in our own netlabs hierarchy: [http://news.gmane.org/index.php?prefix=gmane.org.netlabs gmane.org.netlabs]

You can either read them with your prefered newsreader or via the web interface. The newsserver is news://news.gmane.org

You can also post to the lists without a subscription to the list itself! The first time you post a message via news you will get a confirmation email so it is necessary that you provide a valid email address in your news settings. Once you confirmed that email you will be able to post messages to the list wihtout a real subscription to the mailinglist itself. Note that you '''have''' to provide a '''valid''' email address in your newsreader for sure, otherwise it will not work.

Enjoy!

Main Page

2008-04-30T15:28:27Z

Cinc: IRC now on irc.freenode.net

__NOTOC__

Welcome to the Wiki at netlabs.org. You will find a lot of interesting information about OS/2 and [http://www.ecomstation.com eCS] on this page. 
You can take part in the community as follows
* read the [[Netlabs_News|netlabs.org news]]
* join the [[Mailinglists|community mailinglist]]
* join the [irc://irc.freenode.net/#netlabs #netlabs IRC channel] (currently on irc.freenode.net).

'''CONTRIBUTE''': Unfortunately, we have to prevent registering new users till we have fixed the spamming-problems on the Wiki, sorry! If you want to '''create an user account''' please send an email with your desired user name to os2info [at] gmx.net and we will generate it for you. Will be fixed ASAP.

== Roadmap ==
Where are we now and where could we go. Open for discussions.

*[[Ideas]] - This is so far a random collection of ideas and stuff we have in our heads and which probably is worth creating a project for.
** [[Ideas#New_PM_Controls|New PM Controls]]

* [[Community]] - Discussions about the netlabs.org community, website, and so on. Complain here :)

* [[The Warp Wishlist]]- The OS/2 Warp WishList is now available on wiki format.

* [[Netlabs bi weekly newsletter]] - ''New'' The latest netlabs.org news

* [[Netlabs News]] - Even later than above

* [[Voyager]] - See some discussion on the new eComStation platform that the developers community currently designs

* [[Warpstock Europe Websites]] - Discussion of a concept that aims to provide infrastructure and information to organizers, and information and services to users/visitors.

* [[UniAudio Development]] Universal Audio Driver Development Discussion

* [[WarpVision Development]] WarpVision media player development discussion

*[[Fundraising campaign]] - Projects that could be realized, support your favourite one!

*[[XWorkplace]] - XWorkplace Future Plans and Ideas

*[[Network Connection Manager]] - Design for follow-up to Wireless LAN Monitor

*[[DOSBox Port]] - DOSBox Port for OS/2-eCS Project

*[[Odin]] - ODIN Project todo and Ideas

*[[eSchemes]] - eComStation WPS-based look & feel system

*[[Mr2ice]] - MR/2 ICE is a full featured OS/2 native mail and news client.

*[[MMOS2 Related Projects]] - A list of MMO2 Related sofware developments.

*[[Extensions for WarpIN]] - A list of suggested exentions to WarpIN

== Shop ==
[[Image:Netlabs_watch.png|frame|netlabs watch]]
We do have a shop for shirts and more ... [http://shop.netlabs.org shop.netlabs.org]! Prices include a small extra to support netlabs.org's future...

== New Logo and Redesign ==
* [[Redesign]] - The new logo is choosen and a first and hopefully final draft for the new site layout has been created - check it out ;)

== Development ==

NOTE: This section should not be extended anymore. We reloaded the [http://www.edm2.com EDM/2 magazine] and we recommend to put all developer stuff in there. This wiki is a mess at the moment and we will clean that up one day and migrate the stuff that makes sense to EDM/2. Thanks!

This section contains hints and tricks and descriptions of undocumented
stuff. Undocumented means there's no official documentation or the
documentation (for example included on DevCon CDs) isn't available to
the public anymore. But DON'T JUST COPY any documentation you may have into the Wiki. Keep in mind it's copyrighted!

* [[Undocumented stuff]]
* [[Mozilla]] - some stuff regarding building Mozilla on OS/2
* [http://www.edm2.com/index.php/SDL SDL] - some tips & tricks about how to port applications using SDL to OS/2
* [http://www.edm2.com/index.php/How_to_program_for_the_WPS WPS] - how to program for the [http://en.wikipedia.org/wiki/Workplace_Shell WPS]. Note: the german Wikipedia may have more information about the WPS. Go [http://de.wikipedia.org/wiki/Workplace_Shell here].

==OS/2 and eCS resources==
===Drivers===
*Visit http://www.os2warp.be if you want to know if your hardware is supported.
*See a [http://www.ecomstation.it/pido2/home/mircomir/fixpak.php?lang=en driver list] generated from eCSoft/2 database.

===Software===
For software have a look here:

* http://hobbes.nmsu.edu
* http://en.ecomstation.ru/apecs.php
* http://www.ecomstation.it/ecsoft2/
* http://www.unixos2.org - ported *nix tools. A little bit cumbersome to find stuff there but nevertheless worth the effort

===Programs===
How to use specific programs, HowTos, FAQs etc.

MR/2 ICE [[mr2ice]] is a full featured OS/2 native mail and news client.

===eCS Maintainance===
Quite a few things are different in eComStation compared to OS/2. Find tips and tricks for common (and not so common) tasks.

* [[Rebuild your eCS desktop]]

==netlabs.org Servers==
===ToDo's & History===
This is the list of tasks for netlabs.org Webservers and the history of what I (ktk) did
*[[netlabs.org]]

===Mail account===
Some information for those who own a mailbox at netlabs.org
*[[netlabs.org Mailing]]
===Admin Guide===
So far it's more or less just me who does all the work on netlabs.org webpages and this somewhat sucks because like this a lot of stuff depends on my lazyness. The following document explains the tasks necessary to create a new project at netlabs.org, including setting up CVS repositories, creating webpages and so on. I hope that I will find some volunteers one day who help me on doing that.
*[[Admin Guide]]

Voyager API Design Guide

2008-03-20T23:20:30Z

Cinc: Minor rewrite

[[Category:Voyager]]
This page contains a first draft for the Design and Implementation Guide for the Voyager API. Please note that the codename Voyager will not appear in the resulting document anylonger, once this document has reached the final version.

Please see also the pages
* [[Voyager_API_Basics|The Voyager API Basics]] - containing the basic ideas for the Voyager API
* [[Voyager_API_Design|The Voyager API Design]] containing the design/coverage of the upcoming Voyager API

[[Voyager|Voyager Main Page]]

== Foreword ==
The Voyager API will be implemented as an object oriented class library, using the Netlabs Object Model (NOM).

In the progress of ongoing development, for different reasons it may be required that the Voyager API could use extensions, due to
* changes within the system, applications require additional interfaces to
** the underlying kernel or
** supporting libraries
* new hardware or file formats requiring support
* new concepts requiring implementation of new classes and/or frameworks (sets of classes)

In order to keep a high quality standard within the Voyager API, it is vital to ensure that contributions match the way the current Voyager API is designed and implemented. This is the task of the maintainers of the Voyager API, and is done by
* maintaining this document, defining the rules and methods for design and implementation
* providing expertise before or during the design and/or implementation of an extension (the earlier involved, the better)
* deciding if a given contribution can be accepted or has to be modified to meet the requirements for a contribution to the Voyager API

== About this document ==
This document is intended for the following people:
* developers, for understanding
** the methods and rules that are used for and apply to the task of designing and implementing additions to the Voyager API
** how to contribute extensions to the maintainers of the Voyager API
* maintainers of the Voyager API, for
** ensuring that contributed extensions apply to the rules of design and implementation described in this document and meet the requirements for a contribution
** performing the defined methods/procedures when accepting a contribution

== Design Goals for the Voyager API ==
The design goals for the Voyager API are:
* the API is implemented as an object oriented class library
* using Netlabs Object Model (NOM)
** allows bindings for non-OO compiler and script languages
** allows better binary compatibility for external extensions
* no 1-1 implementation of (one of) the underlying libraries
** trade in some flexibility for simplicity
** cover approx. 60-80% of the used cases of the supported libraries
* gain the same reputation concerning quality like the OS/2 API
** see this API as '''advertisement''' for Voyager as an '''exemplary development platform'''

== Implementing the Voyager API as an object oriented class library ==
The Voyager API will be implemented using the Netlabs Object Model (NOM), implementing a runtime for an object oriented class library. Thus the API itself will be implemented as software classes, allowing access to data and functionality by their interface, being implemented by methods (kind of functions) and members (variables).

Within the class library, all software classes are part of the class hierarchy, where specialized subclasses are derived from parent classes. Subclasses inherit the behaviour from the parent class, and extend an/or modify the behaviour of the parent class. Some of the parent classes are so-called 'abstract classes' that is they are not intended to create instances of it, but only for implementing base functionality for subclasses. A special form of this are 'virtual base classes', which do not implement any code, but only define the mandantory interface of a subclass (e.g. a virtual base class for file decoder defines that a subclass for handling of a specific file must implement the method ReadFileContents).

The complete API will be spearated into major parts by [[Voyager_API_Design|groups of classes]]. When the API is to be extended, this can happen by
* implementing the extension in a new or existing method in an existing class
* derive a new class from an existing one, and implementing the extension in this class
* define a new major API or framework and derive a complete new group of classes from the root class, implementing the extension in these classes

The following rules apply when deciding which of these options are applicable for a given extension:
* ''<not yet determined>''

Another design issue is to decide when using native compiler types (or appropriate typedef's) instead of classes for data types. In general, for maximum performance and minimum complexity, the native compiler data types should be used for simple data types. For complex data types, or where compiler implemented operators are not sufficient, data type classes should be implemented. In general, data type classes will be implemented by the Netlabs Object Model (NOM), if they are not specific to a special part of the Voyager API implemented with it.

== The Voyager API Classes and Interface Namespace ==

Cinc: this part must be reviewed and should be considered a proposal only.
 cla: all of this document must be considered as a proposal :-)

The class names and the names of the classes' methods and members are prefixed by a tag identifying the major part of the API.

the next section is not true [[User:Simpson 2|Simpson 2]] 18:21, 20 March 2008 (CET) 
<strike>The reasons for the member name prefix is that the IDL compiler creates access macros with the method or member name prepended by an underscore only. If the members would not be prefixed, two classes within the entire class hierarchy could not have a method with the same name without resorting to the full method name which is built from the class name followed by the method name. </strike>
Secondly using prefixes helps identifying the class group a method belongs to.

Within a major part of the Voyager API,
* class names are prepended with an all upper case prefix, like SVC, SYS, WP, e.g. SYSObject
* member names are prepended with a lower case prefix, like svc, sys, wp, e.g. sysQueryUniverseSize()
* symbol names are prepended with an uppercase prefix with a trailing underscore, like SVC_, SYS_, WP_
* API function names are prepended with a mixed case prefix, like Svc, Sys, Wp, e.g. SysCalculateNewUniverseSize()
* Prefix for helper functions (internal, maybe static, functions not visible to the world) needs to be defined

The class hierarchy of a major part of the Voyager API starts with the class XXXObject, where XXX is the all uppercase prefix of the API Part. Most class of this API part are derived from this base class.

In addition to that the following rules apply to naming methods:
* where methods return a pointer to an object or data type
** *query* methods return a pointer to original data that may not be altered or freed
** *get* methods return a pointer to a copy of original data where the copy has to be released by the caller (destroy the object or free memory. A dedicated method to do that is ususally appropriate).

== Extending the Voyager API ==

''<to be edited>''

The following tasks are to be processed when suggesting an extension to the Voyager API:
* document new functionality
** used case
** requirements
* (*) search for (base) classes for either to
** implement it in a new or existing method in an existing class
** derive a new class from an existing one for it
** define a new major API or framework, derive from root class for it
* (*) analyse and document design options
* define testcases per design option
* (*) decide for one option, document the reasons for the decision
* implement the extension within a testcase
* perform the testcase, document results
* send contribution to the API maintainers, including
** the testcase with source
** all documentation items

For the steps marked with (*) it may make sense to discuss the existing results with the maintainers of the API, to make sure that the testcase implementation already meets all requirements and design and implementation rules.

== Accepting contributions for the Voyager API ==

''<to be edited>''

When a proposal for an extension is being sent to the maintainer team, the team will determine the maintainer for that extension (not necessarily one of the team). The proposal can be sent in as an idea only, when asking for expertise and feedback, or already as a fully implemented extension.

In order to process the extension proposal, 'the maintainer' will perform the following steps, where generally one major step will be performed only when the predecessor has been finished:
* provide expertise and feedback to the author of the extension
* review the contribution for the following aspects (if already available)
** usability of new functionality
** design options analysis and decision
** testcase implementation and results
* develop further design and implementation alternative(s), where applicable
** pass back to author for review and modification, where required
* discuss changes to this Design and Implementation Guide, where applicable/required
* perform final discussion in maintainer team
* within the maintainer team, decide to accept or reject the contribution, concerning design and implementation

* when accepted
** request further documentation for the API docs, where required
** add the extension and documentation to the Voyager API code archive
** extend the build environment in the source archive, where required
* when rejected, document reasons and, where applicable, either
** request modification
** propose design alternative(s)

It may be necessary to perform this procedure several times, before an extension is completely accepted or rejected.

== Appendix: Requirements for testcase packages ==
''<to be edited>''
* documentation
** design
** per testcase
*** description (including prerequisites)
*** how to execute
*** expected result
* compiled binaries

== Appendix: Building the Voyager API ==
''<to be edited>''
* define the standard build environment for the Voyager API
** required programs
** provided methods
*** build all, docs,
*** call debugger ?
*** build/maintain release packages
* document how to technically extend the build system for to add a new class and/or method

Voyager

2007-11-10T11:23:57Z

Cinc: Removed link until linked page is up to dat

[[Category:Voyager]]

We currently discuss about the design on Voyager. This is separated into the following parts:

* [[Voyager_Discussion|Voyager Discussion]] - contains the ideas which evolved from quite some discussions

* [[Voyager_API_Basics|The Voyager API Basics]] - contains the basic ideas for the Voyager API

* [[Voyager_API_Design|The Voyager API Design]] - contains the design/coverage of the upcoming Voyager specific API
** [[Desktop_class_list|Preliminary list of desktop classes]] - contains a separate (yet incomplete!) list of Desktop Classes

* [[Voyager_API_Design_Guide|The Voyager API Design and Implementation Guide]] - contains the methods and rules for implementing the Voyager API

* [[Voyager_API_Roadmap|The Voyager API Roadmap]] - contains a list of issues/todos

Voyager

2007-11-09T22:04:01Z

Cinc: New link to the desktop design page

Support class list

2007-09-08T07:29:46Z

Cinc: added first(), last() methods to NOMArray

<ClassTree title="Support classes (Foundation)">

* NOMArray: NOMObject:Base class for arrays
** length(): This method queries the length of the array
**first()
**last()

* NOMPtrArray:NOMArray:An array class holding pointers on data.
** append(gpointer* pItem):Append an item to the end of the array.
** nomInit(): Override to initialize the GPtrArray.

* NOMObjectArray:NOMPtrArray:Array class holding NOM objects. It's possible to set the type of object an array is supposed to hold. When trying to add an object the type is checked and if it's the correct class (or a subclass) it will be accepted.

* NOMString:NOMObject:A generic string class holding UTF-8 strings.
** NOMString* assign(NOMString *nomString)
** NOMString* append(NOMString *nomString)
** NOMString* prepend(NOMString *nomString)
** ulong length(): Returns the length of the string in chars. Note that the byte length may be higher.
** NOMString* truncate(ulong ulNewLen):Cut off the end of the string. Note that the returned value is not a copy.

* NOMPath:NOMString:This class adds methods for dealing with paths like striping parts, adding separators.
** NOMPath* appendPath(NOMPAth* nomPath): append a new path section taking into account separators. A new path is returned.
** NOMPath* appendSeparator():Append a Separator if the path doesn't end with one. A new path including the separator is returned.
** NOMPath* stripSeparator(): Remove the separator from the end of a path.
** NOMPath* queryRoot()
** NOMPath* erasePathBegin(): Removes the first directory of a path including the first separator (after the dir part).
** NOMPath* getPathBegin(): Returns a new path holding the part up to the first separator. Use erasePAthBegin() to remove this part from the source path.
** boolean queryPathIsAbsolute(): Only implemented for OS/2.
</ClassTree>

Voyager API Design

2007-08-30T20:22:10Z

Cinc: /* highlevel GUI - GUI */ Stub page for classes

[[Category:Voyager]]
Welcome to the Wiki Page explaining the design of the Voyager API.

Please see also the pages
* [[Voyager_API_Basics|The Voyager API Basics]] - containing the basic ideas for the Voyager API
* [[Voyager_API_Design_Guide|The Voyager API Design and Implementation Guide]] - containing the methods and rules for implementing the Voyager API

'''Please note'''
* The page is organized as a list of sections, where each section names a specific major part of the Voyager API (with the exception of the section ''Virtual Base Classes'')
* The title of the major part includes the proposed prefix for class/method/Symbol names (here: class name prefix, all uppercase)
* Each section API may be used as a base for an API of another section, where applicable
* Take into account that the API will likely be implemented as an object oriented class library. Using the Netlabs Object Model this will be compiler and language independent (so e.g. C and Classic REXX can also be used)
* If you have additions or a completely new main section, please feel free to add it
* If you feel that a part of the structure better would be reorganized (joining or splitting major sections, moving parts between major sections), please contact the netlabs.org core team first for prior discussion. However, all suggestions and comments are very welcome and highly appreciated!

[[Voyager|Voyager Main Page]]

== System Resources & Management - SYS ==
This section implements system near resource handling (including kernel related hardware)
* Wrapper for Kernel Services, Memory, Interrupts, Timer, ACPI
* DMI (incl. Process Management)
* Interprocess Communications
** Shared Memory, Semaphores, Queues, (Named) Pipes, more...
* Add more...

== Basic Device Input/Output - DEV ==
This section implements input and output from and to peripheral hardware for applications, and encapsulates existing APIs (where possible, in a unified manner)
* Keyboard, Mouse
* Sound
* Video
* USB
* Firewire
* NICs, other adpaters
* more...

== System Security - SYS or SEC ==
This section implements access restrictions and other security methods.
* refer to Security/2 design ?
* Add more...

== System Component Configuration - SYS or CFG ==
This section implements configuration of system components (possibly also application components via a framework ?)

Here is a list of goals:
* encapsulates any kernel specific means of configuration
** like driver config (per config.sys, registry, ini file ...)
* implements an internal (?) database for configuration data (like OS2.INI or Registry)
* may superseed DMI, and a DMI implementation may use this part of the API
* includes Disk & Partition Management
* Add more...

== System Service Management - SVC ==
This section implements the means for managing system or application services
* see the design sketch from Warpstock Europe 2005 as a proposal: [http://www.clanganke.de/os2/pres/wse2005/all04_en.sdd ALL04 - Service Management for OS/2 and eComStation] (requires StarOffice 5.1 or OpenOffice.org)
* Add more...

== Unified Data Access - ??? ==
This section implements a unified view on data (fuse alike)
* Filesystem Protocols incl. Named Pipes (Samba, NFS, more...)
* Internet Protocols (http, rtsp, SSH, more...)
* Add more...

== lowlevel graphics - GPI ==
This section implements basic GUI stuff.
* primitives (lines, circles, more...)
* font rendering
* image handling (scaling, blending, more...)
* Add more...

== highlevel GUI - GUI ==
This section implements highlevel GUI features used for creating windows, controls and so forth.
* frame window
* controls, frame controls
* text window (support for terminal window)
* Add more...

[[Gui_class_list|Preliminary list of GUI classes]] to be implemented.

== Desktop Objects - WP ==
This section implements nothing less than all classes that implement the workplace Shell replacement.
* (a.k.a. Workplace Shell Replacement and its objects)

[[Desktop_class_list|Preliminary list of desktop classes]] to be implemented.

== (Virtual) Base Classes & Frameworks ==
This is not a real major API part, but a placeholder for all parts of the API, where we could either
* create (virtual) base classes to allow easy and future safe extension of the Voyager API or
* create a general framework for a given purpose

Depending on the issue, a given framework or (set of) base classe(s) possibly could be put into one of the above main sections as well, or end up in a completely new section. This may happen during the discussion.

Here is a first list:
* [http://svn.netlabs.org/v_nom Netlabs Object Model (NOM)], runtime for the Voyager specific API (see the [[Voyager_API_Basics#Design_goals_for_the_Voyager_API|Design goals for the Voyager API]])
* support classes (strings, arrays). [[support_class_list|Preliminary list of classes]] to be implemented.
* application protocols (including filesystem access)(see section Application protocols)
* Resource Management see design proposal from netlabs.org Developers Workshop 2007: [http://www.clanganke.de/os2/pres/dws2007/resources/index.html Managing Sets of Program Resources]
* file or stream format encoder/decoder
* System Configuration Components
* access to streamed data (file stream, TCP/IP stream, more)
* internet protocols
* much more for virtually anything, for all main sections!
* Add more...

Support class list

2007-08-30T20:07:28Z

Cinc: Added NOMPath methods

<ClassTree title="Support classes (Foundation)">

* NOMArray: NOMObject:Base class for arrays
** length(): This method queries the length of the array

* NOMPtrArray:NOMArray:An array class holding pointers on data.
** append(gpointer* pItem):Append an item to the end of the array.
** nomInit(): Override to initialize the GPtrArray.

* NOMObjectArray:NOMPtrArray:Array class holding NOM objects. It's possible to set the type of object an array is supposed to hold. When trying to add an object the type is checked and if it's the correct class (or a subclass) it will be accepted.

* NOMString:NOMObject:A generic string class holding UTF-8 strings.
** NOMString* assign(NOMString *nomString)
** NOMString* append(NOMString *nomString)
** NOMString* prepend(NOMString *nomString)
** ulong length(): Returns the length of the string in chars. Note that the byte length may be higher.
** NOMString* truncate(ulong ulNewLen):Cut off the end of the string. Note that the returned value is not a copy.

* NOMPath:NOMString:This class adds methods for dealing with paths like striping parts, adding separators.
** NOMPath* appendPath(NOMPAth* nomPath): append a new path section taking into account separators. A new path is returned.
** NOMPath* appendSeparator():Append a Separator if the path doesn't end with one. A new path including the separator is returned.
** NOMPath* stripSeparator(): Remove the separator from the end of a path.
** NOMPath* queryRoot()
** NOMPath* erasePathBegin(): Removes the first directory of a path including the first separator (after the dir part).
** NOMPath* getPathBegin(): Returns a new path holding the part up to the first separator. Use erasePAthBegin() to remove this part from the source path.
** boolean queryPathIsAbsolute(): Only implemented for OS/2.
</ClassTree>

Support class list

2007-08-30T19:50:39Z

Cinc: Added NOMPath class

Support class list

2007-08-21T20:44:29Z

Cinc: Added some methods

<ClassTree title="Support classes (Foundation)">

* NOMArray: NOMObject:Base class for arrays
** length(): This method queries the length (or size) of the array

* NOMPtrArray:NOMArray:An array class holding pointers on data.
** append(gpointer* pItem):Append an item to the end of the array.
** nomInit(): Override to initialize the GPtrArray.

* NOMObjectArray:NOMPtrArray:Array class holding NOM objects. It's possible to set the type of object an array is supposed to hold. When trying to add an object the type is checked and if it's the correct class (or a subclass) it will be accepted.

* NOMString:NOMObject:A generic string class holding UTF-8 strings.
** NOMString* assign(NOMString *nomString)
** NOMString* append(NOMString *nomString)
** NOMString* prepend(NOMString *nomString)
** ulong length(): Returns the length of the string in chars. Note that the byte length may be higher.
**NOMString* truncate(ulong ulNewLen)

Support class list

2007-08-21T11:29:24Z

Cinc: Started list of support classes

<ClassTree title="Support classes (Foundation)">

* NOMArray: NOMObject:Base class for arrays
** length(): This method queries the length (or size) of the array

* NOMPtrArray:NOMArray:An array class holding pointers on data.

* NOMObjectArray:NOMPtrArray:Array class holding NOM objects. It's possible to set the type of object an array is supposed to hold. When trying to add an object the type is checked and if it's the correct class (or a subclass) it will be accepted.

* NOMString:NOMObject:A generic string class holding UTF-8 strings.

Voyager API Basics

2007-08-21T05:17:46Z

Cinc: Triton is a Voyager API

[[Category:Voyager]]
Welcome to the Wiki Page explaining the design goals and basic information on the Voyager API.

Please see also the pages
* [[Voyager_API_Design|The Voyager API Design]] containing the design/coverage of the upcoming Voyager API
* [[Voyager_API_Design_Guide|The Voyager API Design and Implementation Guide]] - containing the methods and rules for implementing the Voyager API

[[Voyager|Voyager Main Page]]

== Foreword ==
The developers of OS/2 and eComStation have always favoured the API of their platform over other platform APIs, because it is solid and stable, well structured, consistently designed and mostly easy to use and understand. In the attempt to create the new Voyager platform, the developers taking part in it intend to provide an API being of the very same, high quality. While not everything can be implemented from the beginning that can be thought of, we aim at a design that can be extended in an easy and meaningful way and thus is and will be future safe. For that we intend to setup methods for assuring quality in the ongoing design of this API.

This page explains the basic thoughts on the API design and concerning this, reflects the current status of discussion in the netlabs.org core team. Nothing is completely decided yet, but we expect that this will not change (much) anymore.

Please see also the section [[Voyager_API_Design|The Voyager API Design]]. This has been separated from this page, as we expect it to receive much more frequent changes.

== What is the Voyager API ==
It is essential to distinct between all APIs supported by the Voyager platform, and the Voyager API - or better, the Voyager specific API. If we talk about the '''Voyager API''', the latter, so the bold printed part of the following list is meant.

Currently we see the following distinction:

* '''Voyager API''' e.g. Triton (to be implemented)

* Supported APIs (to be ported/implemented)
** APIs of supported/integrated libraries
*** GLIB, GTK+, Cairo, TCP/IP, more...
** Integration APIs for scripting engines
*** REXX, Ruby, Python, Perl, more...
** Compatibility APIs (to be ported/implemented)
*** eCS & OS/2: VIO,MOU,KBD
*** Posix ?
*** more...?

== Reasons for a Voyager API ==
We see the following reasons to provide a Voyager specific API and not to go for a new platform without a specific API
* encapsulate Voyager specific and kernel specific implementation details
* allow program development independently from the supported APIs/libraries
* provide an easier API compared to the sum of APIs of the supported libraries
** suitable for most used cases
** requires only a flatter learning curve - better for beginners

== Design goals for the Voyager API ==
Please refer to the [[Voyager_API_Design_Guide|Voyager API Design and Implementation Guide]].

Voyager API Design

2007-08-21T05:14:16Z

Cinc: Typo police...

[[Category:Voyager]]
Welcome to the Wiki Page explaining the design of the Voyager API.

Please see also the pages
* [[Voyager_API_Basics|The Voyager API Basics]] - containing the basic ideas for the Voyager API
* [[Voyager_API_Design_Guide|The Voyager API Design and Implementation Guide]] - containing the methods and rules for implementing the Voyager API

'''Please note'''
* The page is organized as a list of sections, where each section names a specific major part of the Voyager API (with the exception of the section ''Virtual Base Classes'')
* The title of the major part includes the proposed prefix for class/method/Symbol names (here: class name prefix, all uppercase)
* Each section API may be used as a base for an API of another section, where applicable
* Take into account that the API will likely be implemented as an object oriented class library. Using the Netlabs Object Model this will be compiler and language independent (so e.g. C and Classic REXX can also be used)
* If you have additions or a completely new main section, please feel free to add it
* If you feel that a part of the structure better would be reorganized (joining or splitting major sections, moving parts between major sections), please contact the netlabs.org core team first for prior discussion. However, all suggestions and comments are very welcome and highly appreciated!

[[Voyager|Voyager Main Page]]

== System Resources & Management - SYS ==
This section implements system near resource handling (including kernel related hardware)
* Wrapper for Kernel Services, Memory, Interrupts, Timer, ACPI
* DMI (incl. Process Management)
* Interprocess Communications
** Shared Memory, Semaphores, Queues, (Named) Pipes, more...
* Add more...

== Basic Device Input/Output - DEV ==
This section implements input and output from and to peripheral hardware for applications, and encapsulates existing APIs (where possible, in a unified manner)
* Keyboard, Mouse
* Sound
* Video
* USB
* Firewire
* NICs, other adpaters
* more...

== System Security - SYS or SEC ==
This section implements access restrictions and other security methods.
* refer to Security/2 design ?
* Add more...

== System Component Configuration - SYS or CFG ==
This section implements configuration of system components (possibly also application components via a framework ?)

Here is a list of goals:
* encapsulates any kernel specific means of configuration
* implements an internal (?) database for configuration data (like OS2.INI or Registry)
* may superseed DMI, and a DMI implementation may use this part of the API
* includes Disk & Partition Management
* Add more...

== System Service Management - SVC ==
This section implements the means for managing system or application services
* see the design sketch from Warpstock Europe 2005 as a proposal: [http://www.clanganke.de/os2/pres/wse2005/all04_en.sdd ALL04 - Service Management for OS/2 and eComStation] (requires StarOffice 5.1 or OpenOffice.org)
* Add more...

== Unified Data Access - ??? ==
This section implements a unified view on data (fuse alike)
* Filesystem Protocols incl. Named Pipes (Samba, NFS, more...)
* Internet Protocols (http, rtsp, SSH, more...)
* Add more...

== lowlevel graphics - GPI ==
This section implements basic GUI stuff.
* primitives (lines, circles, more...)
* font rendering
* image handling (scaling, blending, more...)
* Add more...

== highlevel GUI - GUI ==
This section implements highlevel GUI features used for creating windows, controls and so forth.
* frame window
* controls, frame controls
* text window (support for terminal window)
* Add more...

== Desktop Objects - WP ==
This section implements nothing less than all classes that implement the workplace Shell replacement.
* (a.k.a. Workplace Shell Replacement and its objects)

[[Desktop_class_list|Preliminary list of desktop classes]] to be implemented.

== (Virtual) Base Classes & Frameworks ==
This is not a real major API part, but a placeholder for all parts of the API, where we could either
* create (virtual) base classes to allow easy and future safe extension of the Voyager API or
* create a general framework for a given purpose

Depending on the issue, a given framework or (set of) base classe(s) possibly could be put into one of the above main sections as well, or end up in a completely new section. This may happen during the discussion.

Here is a first list:
* [http://svn.netlabs.org/v_nom Netlabs Object Model (NOM)], runtime for the Voyager specific API (see the [[Voyager_API_Basics#Design_goals_for_the_Voyager_API|Design goals for the Voyager API]])
* support classes (strings, arrays). [[support_class_list|Preliminary list of classes]] to be implemented.
* application protocols (including filesystem access)(see section Application protocols)
* Resource Management see design proposal from netlabs.org Developers Workshop 2007: [http://www.clanganke.de/os2/pres/dws2007/resources/index.html Managing Sets of Program Resources]
* file or stream format encoder/decoder
* System Configuration Components
* access to streamed data (file stream, TCP/IP stream, more)
* internet protocols
* much more for virtually anything, for all main sections!
* Add more...

Voyager API Design Guide

2007-08-21T05:11:57Z

Cinc: Detailed reasons for method naming

[[Category:Voyager]]
This page contains a first draft for the Design and Implementation Guide for the Voyager API. Please note that the codename Voyager will not appear in the resulting document anylonger, once this document has reached the final version.

Please see also the pages
* [[Voyager_API_Basics|The Voyager API Basics]] - containing the basic ideas for the Voyager API
* [[Voyager_API_Design|The Voyager API Design]] containing the design/coverage of the upcoming Voyager API

[[Voyager|Voyager Main Page]]

== Foreword ==
The Voyager API will be implemented as an object oriented class library, using the Netlabs Object Model (NOM).

In the progress of ongoing development, for different reasons it may be required that the Voyager API could use extensions, due to
* changes within the system, applications require additional interfaces to
** the underlying kernel or
** supporting libraries
* new hardware or file formats requiring support
* new concepts requiring implementation of new classes and/or frameworks (sets of classes)

In order to keep a high quality standard within the Voyager API, it is vital to ensure that contributions match the way the current Voyager API is designed and implemented. This is the task of the maintainers of the Voyager API, and is done by
* maintaining this document, defining the rules and methods for design and implementation
* providing expertise before or during the design and/or implementation of an extension (the earlier involved, the better)
* deciding if a given contribution can be accepted or has to be modified to meet the requirements for a contribution to the Voyager API

== About this document ==
This document is intended for the following people:
* developers, for understanding
** the methods and rules that are used for and apply to the task of designing and implementing additions to the Voyager API
** how to contribute extensions to the maintainers of the Voyager API
* maintainers of the Voyager API, for
** ensuring that contributed extensions apply to the rules of design and implementation described in this document and meet the requirements for a contribution
** performing the defined methods/procedures when accepting a contribution

== Design Goals for the Voyager API ==
The design goals for the Voyager API are:
* the API is implemented as an object oriented class library
* using Netlabs Object Model (NOM)
** allows bindings for non-OO compiler and script languages
** allows better binary compatibility for external extensions
* no 1-1 implementation of (one of) the underlying libraries
** trade in some flexibility for simplicity
** cover approx. 60-80% of the used cases of the supported libraries
* gain the same reputation concerning quality like the OS/2 API
** see this API as '''advertisement''' for Voyager as an '''exemplary development platform'''

== Implementing the Voyager API as an object oriented class library ==
The Voyager API will be implemented using the Netlabs Object Model (NOM), implementing a runtime for an object oriented class library. Thus the API itself will be implemented as software classes, allowing access to data and functionality by their interface, being implemented by methods (kind of functions) and members (variables).

Within the class library, all software classes are part of the class hierarchy, where specialized subclasses are derived from parent classes. Subclasses inherit the behaviour from the parent class, and extend an/or modify the behaviour of the parent class. Some of the parent classes are so-called 'abstract classes' that is they are not intended to create instances of it, but only for implementing base functionality for subclasses. A special form of this are 'virtual base classes', which do not implement any code, but only define the mandantory interface of a subclass (e.g. a virtual base class for file decoder defines that a subclass for handling of a specific file must implement the method ReadFileContents).

The complete API will be spearated into major parts by [[Voyager_API_Design|groups of classes]]. When the API is to be extended, this can happen by
* implementing the extension in a new or existing method in an existing class
* derive a new class from an existing one, and implementing the extension in this class
* define a new major API or framework and derive a complete new group of classes from the root class, implementing the extension in these classes

The following rules apply when deciding which of these options are applicable for a given extension:
* ''<not yet determined>''

Another design issue is to decide when using native compiler types (or appropriate typedef's) instead of classes for data types. In general, for maximum performance and minimum complexity, the native compiler data types should be used for simple data types. For complex data types, or where compiler implemented operators are not sufficient, data type classes should be implemented. In general, data type classes will be implemented by the Netlabs Object Model (NOM), if they are not specific to a special part of the Voyager API implemented with it.

== The Voyager API Classes and Interface Namespace ==

Cinc: this part must be reviewed and should be considered a proposal only.
 cla: all of this document must be considered as a proposal :-)

The class names and the names of the classes' methods and members are prefixed by a tag identifying the major part of the API.

The reasons for the member name prefix is that the IDL compiler creates access macros with the method or member name prepended by an underscore only. If the members would not be prefixed, two classes within the entire class hierarchy could not have a method with the same name without resorting to the full method name which is built from the class name followed by the method name. Secondly using prefixes
helps identifying the class group a method belongs to.

Within a major part of the Voyager API,
* class names are prepended with an all upper case prefix, like SVC, SYS, WP, e.g. SYSObject
* member names are prepended with a lower case prefix, like svc, sys, wp, e.g. sysQueryUniverseSize()
* symbol names are prepended with an uppercase prefix with a trailing underscore, like SVC_, SYS_, WP_
* API function names are prepended with a mixed case prefix, like Svc, Sys, Wp, e.g. SysCalculateNewUniverseSize()
* Prefix for helper functions (internal, maybe static, functions not visible to the world) needs to be defined

In addition to that the following rules apply to naming methods:
* where methods return a pointer to an object or data type
** *query* methods return a pointer to original data that may not be altered or freed
** *get* methods return a pointer to a copy of original data where the copy has to be released by the caller (destroy the object or free memory. A dedicated method to do that is ususally appropriate).

== Extending the Voyager API ==

''<to be edited>''

The following tasks are to be processed when suggesting an extension to the Voyager API:
* document new functionality
** used case
** requirements
* (*) search for (base) classes for either to
** implement it in a new or existing method in an existing class
** derive a new class from an existing one for it
** define a new major API or framework, derive from root class for it
* (*) analyse and document design options
* define testcases per design option
* (*) decide for one option, document the reasons for the decision
* implement the extension within a testcase
* perform the testcase, document results
* send contribution to the API maintainers, including
** the testcase with source
** all documentation items

For the steps marked with (*) it may make sense to discuss the existing results with the maintainers of the API, to make sure that the testcase implementation already meets all requirements and design and implementation rules.

== Accepting contributions for the Voyager API ==

''<to be edited>''

When a proposal for an extension is being sent to the maintainer team, the team will determine the maintainer for that extension (not necessarily one of the team). The proposal can be sent in as an idea only, when asking for expertise and feedback, or already as a fully implemented extension.

In order to process the extension proposal, 'the maintainer' will perform the following steps, where generally one major step will be performed only when the predecessor has been finished:
* provide expertise and feedback to the author of the extension
* review the contribution for the following aspects (if already available)
** usability of new functionality
** design options analysis and decision
** testcase implementation and results
* develop further design and implementation alternative(s), where applicable
** pass back to author for review and modification, where required
* discuss changes to this Design and Implementation Guide, where applicable/required
* perform final discussion in maintainer team
* within the maintainer team, decide to accept or reject the contribution, concerning design and implementation

* when accepted
** request further documentation for the API docs, where required
** add the extension and documentation to the Voyager API code archive
** extend the build environment in the source archive, where required
* when rejected, document reasons and, where applicable, either
** request modification
** propose design alternative(s)

It may be necessary to perform this procedure several times, before an extension is completely accepted or rejected.

== Appendix: Requirements for testcase packages ==
''<to be edited>''
* documentation
** design
** per testcase
*** description (including prerequisites)
*** how to execute
*** expected result
* compiled binaries

== Appendix: Building the Voyager API ==
''<to be edited>''
* define the standard build environment for the Voyager API
** required programs
** provided methods
*** build all, docs,
*** call debugger ?
*** build/maintain release packages
* document how to technically extend the build system for to add a new class and/or method

Voyager API Design Guide

2007-08-21T05:06:14Z

Cinc: Examples for naming. Some details.

[[Category:Voyager]]
This page contains a first draft for the Design and Implementation Guide for the Voyager API. Please note that the codename Voyager will not appear in the resulting document anylonger, once this document has reached the final version.

Please see also the pages
* [[Voyager_API_Basics|The Voyager API Basics]] - containing the basic ideas for the Voyager API
* [[Voyager_API_Design|The Voyager API Design]] containing the design/coverage of the upcoming Voyager API

[[Voyager|Voyager Main Page]]

== Foreword ==
The Voyager API will be implemented as an object oriented class library, using the Netlabs Object Model (NOM).

In the progress of ongoing development, for different reasons it may be required that the Voyager API could use extensions, due to
* changes within the system, applications require additional interfaces to
** the underlying kernel or
** supporting libraries
* new hardware or file formats requiring support
* new concepts requiring implementation of new classes and/or frameworks (sets of classes)

In order to keep a high quality standard within the Voyager API, it is vital to ensure that contributions match the way the current Voyager API is designed and implemented. This is the task of the maintainers of the Voyager API, and is done by
* maintaining this document, defining the rules and methods for design and implementation
* providing expertise before or during the design and/or implementation of an extension (the earlier involved, the better)
* deciding if a given contribution can be accepted or has to be modified to meet the requirements for a contribution to the Voyager API

== About this document ==
This document is intended for the following people:
* developers, for understanding
** the methods and rules that are used for and apply to the task of designing and implementing additions to the Voyager API
** how to contribute extensions to the maintainers of the Voyager API
* maintainers of the Voyager API, for
** ensuring that contributed extensions apply to the rules of design and implementation described in this document and meet the requirements for a contribution
** performing the defined methods/procedures when accepting a contribution

== Design Goals for the Voyager API ==
The design goals for the Voyager API are:
* the API is implemented as an object oriented class library
* using Netlabs Object Model (NOM)
** allows bindings for non-OO compiler and script languages
** allows better binary compatibility for external extensions
* no 1-1 implementation of (one of) the underlying libraries
** trade in some flexibility for simplicity
** cover approx. 60-80% of the used cases of the supported libraries
* gain the same reputation concerning quality like the OS/2 API
** see this API as '''advertisement''' for Voyager as an '''exemplary development platform'''

== Implementing the Voyager API as an object oriented class library ==
The Voyager API will be implemented using the Netlabs Object Model (NOM), implementing a runtime for an object oriented class library. Thus the API itself will be implemented as software classes, allowing access to data and functionality by their interface, being implemented by methods (kind of functions) and members (variables).

Within the class library, all software classes are part of the class hierarchy, where specialized subclasses are derived from parent classes. Subclasses inherit the behaviour from the parent class, and extend an/or modify the behaviour of the parent class. Some of the parent classes are so-called 'abstract classes' that is they are not intended to create instances of it, but only for implementing base functionality for subclasses. A special form of this are 'virtual base classes', which do not implement any code, but only define the mandantory interface of a subclass (e.g. a virtual base class for file decoder defines that a subclass for handling of a specific file must implement the method ReadFileContents).

The complete API will be spearated into major parts by [[Voyager_API_Design|groups of classes]]. When the API is to be extended, this can happen by
* implementing the extension in a new or existing method in an existing class
* derive a new class from an existing one, and implementing the extension in this class
* define a new major API or framework and derive a complete new group of classes from the root class, implementing the extension in these classes

The following rules apply when deciding which of these options are applicable for a given extension:
* ''<not yet determined>''

Another design issue is to decide when using native compiler types (or appropriate typedef's) instead of classes for data types. In general, for maximum performance and minimum complexity, the native compiler data types should be used for simple data types. For complex data types, or where compiler implemented operators are not sufficient, data type classes should be implemented. In general, data type classes will be implemented by the Netlabs Object Model (NOM), if they are not specific to a special part of the Voyager API implemented with it.

== The Voyager API Classes and Interface Namespace ==

Cinc: this part must be reviewed and should be considered a proposal only.
 cla: all of this document must be considered as a proposal :-)

The class names and the names of the classes' methods and members are prefixed by a tag identifying the major part of the API.

The reasons for the member name prefix is that the IDL compiler creates access macros with the method or member name prepended by an underscore only. If the members would not be prefixed, two classes within the entire class hierarchy could not have a method with the same name. The name clash problem is not completely solved by the member name prefix, but eased a lot.

Within a major part of the Voyager API,
* class names are prepended with an all upper case prefix, like SVC, SYS, WP, e.g. SYSObject
* member names are prepended with a lower case prefix, like svc, sys, wp, e.g. sysQueryUniverseSize()
* symbol names are prepended with an uppercase prefix with a trailing underscore, like SVC_, SYS_, WP_
* API function names are prepended with a mixed case prefix, like Svc, Sys, Wp, e.g. SysCalculateNewUniverseSize()
* Prefix for helper functions (internal, maybe static, functions not visible to the world) needs to be defined

In addition to that the following rules apply to naming methods:
* where methods return a pointer to an object or data type
** *query* methods return a pointer to original data that may not be altered or freed
** *get* methods return a pointer to a copy of original data where the copy has to be released by the caller (destroy the object or free memory. A dedicated method to do that is ususally appropriate).

== Extending the Voyager API ==

''<to be edited>''

The following tasks are to be processed when suggesting an extension to the Voyager API:
* document new functionality
** used case
** requirements
* (*) search for (base) classes for either to
** implement it in a new or existing method in an existing class
** derive a new class from an existing one for it
** define a new major API or framework, derive from root class for it
* (*) analyse and document design options
* define testcases per design option
* (*) decide for one option, document the reasons for the decision
* implement the extension within a testcase
* perform the testcase, document results
* send contribution to the API maintainers, including
** the testcase with source
** all documentation items

For the steps marked with (*) it may make sense to discuss the existing results with the maintainers of the API, to make sure that the testcase implementation already meets all requirements and design and implementation rules.

== Accepting contributions for the Voyager API ==

''<to be edited>''

When a proposal for an extension is being sent to the maintainer team, the team will determine the maintainer for that extension (not necessarily one of the team). The proposal can be sent in as an idea only, when asking for expertise and feedback, or already as a fully implemented extension.

In order to process the extension proposal, 'the maintainer' will perform the following steps, where generally one major step will be performed only when the predecessor has been finished:
* provide expertise and feedback to the author of the extension
* review the contribution for the following aspects (if already available)
** usability of new functionality
** design options analysis and decision
** testcase implementation and results
* develop further design and implementation alternative(s), where applicable
** pass back to author for review and modification, where required
* discuss changes to this Design and Implementation Guide, where applicable/required
* perform final discussion in maintainer team
* within the maintainer team, decide to accept or reject the contribution, concerning design and implementation

* when accepted
** request further documentation for the API docs, where required
** add the extension and documentation to the Voyager API code archive
** extend the build environment in the source archive, where required
* when rejected, document reasons and, where applicable, either
** request modification
** propose design alternative(s)

It may be necessary to perform this procedure several times, before an extension is completely accepted or rejected.

== Appendix: Requirements for testcase packages ==
''<to be edited>''
* documentation
** design
** per testcase
*** description (including prerequisites)
*** how to execute
*** expected result
* compiled binaries

== Appendix: Building the Voyager API ==
''<to be edited>''
* define the standard build environment for the Voyager API
** required programs
** provided methods
*** build all, docs,
*** call debugger ?
*** build/maintain release packages
* document how to technically extend the build system for to add a new class and/or method

Voyager API Design

2007-07-31T07:35:14Z

Cinc: Added link to support class list

Welcome to the Wiki Page explaining the design of the Voyager API.

Please see also the pages
* [[Voyager_API_Basics|The Voyager API Basics]] - containing the basic ideas for the Voyager API
* [[Voyager_API_Design_Guide|The Voyager API Design and Implementation Guide]] - containing the methods and rules for implementing the Voyager API

'''Please note'''
* The page is organized as a list of sections, where each section names a specific major part of the Voyager API (with the excetipon of the section ''Virtual Base Classes'')
* Each section API may be used as a base for an API of another section, where applicable
* Take into account that the API will likely be implemented as an object oriented class library. Using the Netlabs Object Model this will be compiler and language independent (so e.g. C and Classic REXX can also be used)
* If you have additions or a completely new main section, please feel free to add it
* If you feel that a part of the structure better would be reorganized (joining or splitting major sections, moving parts between major sections), please contact the netlabs.org core team first for prior discussion. However, all suggestions and comments are very welcome and highly appreciated!

[[Voyager|Voyager Main Page]]

== System Resources & Management ==
This section implements system near resource handling (including kernel related hardware)
* Wrapper for Kernel Services, Memory, Interrupts, Timer, ACPI
* DMI (incl. Process Management)
* Interprocess Communications
** Shared Memory, Semaphores, Queues, (Named) Pipes, more...
* Add more...

== Basic Device Input/Output ==
This section implements input and output from and to peripheral hardware for applications, and encapsulates existing APIs (where possible, in a unified manner)
* Keyboard, Mouse
* Sound
* Video
* USB
* Firewire
* NICs, other adpaters
* more...

== System Security ==
This section implements access restrictions and other security methods.
* refer to Security/2 design ?
* Add more...

== System Component Configuration ==
This section implements configuration of system components (possibly also application components via a framework ?)

Here is a list of goals:
* encapsulates any kernel specific means of configuration
* implements an internal (?) database for configuration data (like OS2.INI or Registry)
* may superseed DMI, and a DMI implementation may use this part of the API
* includes Disk & Partition Management
* Add more...

== System Service Management ==
This section implements the means for managing system or application services
* see the design sketch from Warpstock Europe 2005 as a proposal: [http://www.clanganke.de/os2/pres/wse2005/all04_en.sdd ALL04 - Service Management for OS/2 and eComStation] (requires StarOffice 5.1 or OpenOffice.org)
* Add more...

== Unified Data Access ==
This section implements a unified view on data (fuse alike)
* Filesystem Protocols incl. Named Pipes (Samba, NFS, more...)
* Internet Protocols (http, rtsp, SSH, more...)
* Add more...

== lowlevel graphics ==
This section implements basic GUI stuff.
* primitives (lines, circles, more...)
* font rendering
* image handling (scaling, blending, more...)
* Add more...

== highlevel GUI ==
This section implements highlevel GUI features used for creating windows, controls and so forth.
* frame window
* controls, frame controls
* text window (support for terminal window)
* Add more...

== Desktop Objects ==
This section implements nothing less than all classes that implement the workplace Shell replacement.
* (a.k.a. Workplace Shell Replacement and its objects)

[[Desktop_class_list|Preliminary list of desktop classes]] to be implemented.

== (Virtual) Base Classes & Frameworks ==
This is not a real major API part, but a placeholder for all parts of the API, where we could either
* create (virtual) base classes to allow easy and future safe extension of the Voyager API or
* create a general framework for a given purpose

Depending on the issue, a given framework or (set of) base classe(s) possibly could be put into one of the above main sections as well, or end up in a completely new section. This may happen during the discussion.

Here is a first list:
* [http://svn.netlabs.org/v_nom Netlabs Object Model (NOM)], runtime for the Voyager specific API (see the [[Voyager_API_Basics#Design_goals_for_the_Voyager_API|Design goals for the Voyager API]])
* support classes (strings, arrays). [[support_class_list|Preliminary list of classes]] to be implemented.
* application protocols (including filesystem access)(see section Application protocols)
* Resource Management see design proposal from netlabs.org Developers Workshop 2007: [http://www.clanganke.de/os2/pres/dws2007/resources/index.html Managing Sets of Program Resources]
* file or stream format encoder/decoder
* System Configuration Components
* access to streamed data (file stream, TCP/IP stream, more)
* internet protocols
* much more for virtually anything, for all main sections!
* Add more...

Desktop class list

2007-07-31T07:31:39Z

Cinc: Added some classes and methods

This is a list of desktop classes and methods for the Voyager desktop. Note that this list is in no way exhaustive.

* WPObject:NOMObject
** wpInitData()
** wpUnInitData()
** wpAllocMem()
** wpFreeMem()
** wpFree()
**wpOpen()
**wpLockObject()
**wpUnlockObject()
**wpObjectIsLocked()
**wpQueryIcon() (???)
**wpRequestObjectMutexSem()
**wpReleaseObjectMutexSem()
**wpSetTitle()
**wpQueryTitle()
**wpDisplayMenu()
**wpModifyMenu()
**wpFilterMenu()
**wpMenuItemSelected()
**wpInsertMenuItem()
**wpAddSettingsPages()
**wpInsertSettingsPage()
**wpViewObject()
**wpSwitchTo()
**wpRegisterView()
**wpAddToObjUseList()
**wpDeleteFromObjUseList()
**wpFindUseItem()
**wpFindViewItem()
**wpSaveDeferred()
**wpDaveImmediate()
**wpSetFolder()
**wpQueryFolder()
**wpSetTitleFromCString() (???)
**wpQueryDefaultView()
**wpSetDefaultView()
**wpQueryConcurrentView()
**wpSetConcurrentView()
**wpDragOver()
**wpDrop()
**wpMoveObject()
**wpCopyObject()

* WPFileSystem:WPObject
**wpQueryFileName

* WPDataFile:WPFileSystem
**wpQueryFileSize()

* WPFolder:WPFileSystem
**wpPopulate()
**wpCreateFolderWindow()
**wpQueryFldrFlags()
**wpSetFldrFlags()
**wpAddToContent()
**wpQueryContent()
**wpDeleteFromContent()
**wpAddToStore()
**wpDeleteFromStore()

* WPWindow:NOMWindow
**wpSetObject()
**wpQueryObject()
**wpSetWindowTitle()

* WPFolderWindow:WPWindow
**wpQueryContainerHandle()
**wpSetContainerHandle()
**wpConnectDefaultSignalHandlers()

* WPNoteBook:WPWindow
**wpQueryNoteBook()
**wpSetNoteBook()

Voyager API Design Guide

2007-07-30T21:07:32Z

Cinc: /* Extending the Voyager API */

This page contains a first draft for the Design and Implementation Guide for the Voyager API. Please note that the codename Voyager will not appear in the resulting document anylonger, once this document has reached the final version.

Please see also the pages
* [[Voyager_API_Basics|The Voyager API Basics]] - containing the basic ideas for the Voyager API
* [[Voyager_API_Design|The Voyager API Design]] containing the design/coverage of the upcoming Voyager API

[[Voyager|Voyager Main Page]]

== Foreword ==
The Voyager API will be implemented as an object oriented class library, using the Netlabs Object Model (NOM).

In the progress of ongoing development, for different reasons it may be required that the Voyager API could use extensions, due to
* changes within the system, applications require additional interfaces to
** the underlying kernel or
** supporting libraries
* new hardware or file formats requiring support
* new concepts requiring implementation of new classes and/or frameworks (sets of classes)

In order to keep a high quality standard within the Voyager API, it is vital to ensure that contributions match the way the current Voyager API is designed and implemented. This is the task of the maintainers of the Voyager API, and is done by
* maintaining this document, defining the rules and methods for design and implementation
* providing expertise before or during the design and/or implementation of an extension (the earlier involved, the better)
* deciding if a given contribution can be accepted or has to be modified to meet the requirements for a contribution to the Voyager API

== About this document ==
This document is intended for the following people:
* developers, for understanding
** the methods and rules that are used for and apply to the task of designing and implementing additions to the Voyager API
** how to contribute extensions to the maintainers of the Voyager API
* maintainers of the Voyager API, for
** ensuring that contributed extensions apply to the rules of design and implementation described in this document and meet the requirements for a contribution
** performing the defined methods/procedures when accepting a contribution

== Design Goals for the Voyager API ==
The design goals for the Voyager API are:
* the API is implemented as an object oriented class library
* using Netlabs Object Model (NOM)
** allows bindings for non-OO compiler and script languages
** allows better binary compatibility for external extensions
* no 1-1 implementation of (one of) the underlying libraries
** trade in some flexibility for simplicity
** cover approx. 60-80% of the used cases of the supported libraries
* gain the same reputation concerning quality like the OS/2 API
** see this API as '''advertisement''' for Voyager as an '''exemplary development platform'''

== Implementing the Voyager API as an object oriented class library ==
The Voyager API will be implemented using the Netlabs Object Model (NOM), implementing a runtime for an object oriented class library. Thus the API itself will be implemented as software classes, allowing access to data and functionality by their interface, being implemented by methods (kind of functions) and members (variables).

Within the class library, all software classes are part of the class hierarchy, where specialized subclasses are derived from parent classes. Subclasses inherit the behaviour from the parent class, and extend an/or modify the behaviour of the parent class. Some of the parent classes are so-called 'abstract classes' that is they are not intended to create instances of it, but only for implementing base functionality for subclasses. A special form of this are 'virtual base classes', which do not implement any code, but only define the mandantory interface of a subclass (e.g. a virtual base class for file decoder defines that a subclass for handling of a specific file must implement the method ReadFileContents).

The complete API will be spearated into major parts by [[Voyager_API_Design|groups of classes]]. When the API is to be extended, this can happen by
* implementing the extension in a new or existing method in an existing class
* derive a new class from an existing one, and implementing the extension in this class
* define a new major API or framework and derive a complete new group of classes from the root class, implementing the extension in these classes

The following rules apply when deciding which of these options are applicable for a given extension:
* ''<not yet determined>''

Another design issue is to decide when using native compiler types (or appropriate typedef's) instead of classes for data types. In general, for maximum performance and minimum complexity, the native compiler data types should be used for simple data types. For complex data types, or where compiler implemented operators are not sufficient, data type classes should be implemented. In general, data type classes will be implemented by the Netlabs Object Model (NOM), if they are not specific to a special part of the Voyager API implemented with it.

== The Voyager API Classes and Interface Namespace ==

Cinc: this part must be reviewed and should be considered a proposal only.

The class names and the names of the classes' methods and members are prefixed by a tag identifying the major part of the API.

The reasons for the member name prefix is that the IDL compiler creates access macros with the method or member name prepended by an underscore only. If the members would not be prefixed, two classes within the entire class hierarchy could not have a method with the same name. The name clash problem is not completely solved by the member name prefix, but eased a lot.

Within a major part of the Voyager API,
* class names are prepended with a mixed case prefix, like Svc, Sys, Wp
* member names are prepended with a lower case prefix, like svc, sys, wp
* symbols are prepended with an uppercase prefix with a trailing underscore, like SVC_, SYS_, WP_

== Extending the Voyager API ==

''<to be edited>''

The following tasks are to be processed when suggesting an extension to the Voyager API:
* document new functionality
** used case
** requirements
* (*) search for (base) classes for either to
** implement it in a new or existing method in an existing class
** derive a new class from an existing one for it
** define a new major API or framework, derive from root class for it
* (*) analyse and document design options
* define testcases per design option
* (*) decide for one option, document the reasons for the decision
* implement the extension within a testcase
* perform the testcase, document results
* send contribution to the API maintainers, including
** the testcase with source
** all documentation items

For the steps marked with (*) it may make sense to discuss the existing results with the maintainers of the API, to make sure that the testcase implementation already meets all requirements and design and implementation rules.

== Accepting contributions for the Voyager API ==

''<to be edited>''

When a proposal for an extension is being sent to the maintainer team, the team will determine the maintainer for that extension (not necessarily one of the team). The proposal can be sent in as an idea only, when asking for expertise and feedback, or already as a fully implemented extension.

In order to process the extension proposal, 'the maintainer' will perform the following steps, where generally one major step will be performed only when the predecessor has been finished:
* provide expertise and feedback to the author of the extension
* review the contribution for the following aspects (if already available)
** usability of new functionality
** design options analysis and decision
** testcase implementation and results
* develop further design and implementation alternative(s), where applicable
** pass back to author for review and modification, where required
* discuss changes to this Design and Implementation Guide, where applicable/required
* perform final discussion in maintainer team
* within the maintainer team, decide to accept or reject the contribution, concerning design and implementation

* when accepted
** request further documentation for the API docs, where required
** add the extension and documentation to the Voyager API code archive
** extend the build environment in the source archive, where required
* when rejected, document reasons and, where applicable, either
** request modification
** propose design alternative(s)

It may be necessary to perform this procedure several times, before an extension is completely accepted or rejected.

== Appendix: Requirements for testcase packages ==
''<to be edited>''
* documentation
** design
** per testcase
*** description (including prerequisites)
*** how to execute
*** expected result
* compiled binaries

== Appendix: Building the Voyager API ==
''<to be edited>''
* define the standard build environment for the Voyager API
** required programs
** provided methods
*** build all, docs,
*** call debugger ?
*** build/maintain release packages
* document how to technically extend the build system for to add a new class and/or method

Voyager API Design Guide

2007-07-30T21:06:57Z

Cinc: /* Accepting contributions for the Voyager API */

This page contains a first draft for the Design and Implementation Guide for the Voyager API. Please note that the codename Voyager will not appear in the resulting document anylonger, once this document has reached the final version.

Please see also the pages
* [[Voyager_API_Basics|The Voyager API Basics]] - containing the basic ideas for the Voyager API
* [[Voyager_API_Design|The Voyager API Design]] containing the design/coverage of the upcoming Voyager API

[[Voyager|Voyager Main Page]]

== Foreword ==
The Voyager API will be implemented as an object oriented class library, using the Netlabs Object Model (NOM).

In the progress of ongoing development, for different reasons it may be required that the Voyager API could use extensions, due to
* changes within the system, applications require additional interfaces to
** the underlying kernel or
** supporting libraries
* new hardware or file formats requiring support
* new concepts requiring implementation of new classes and/or frameworks (sets of classes)

In order to keep a high quality standard within the Voyager API, it is vital to ensure that contributions match the way the current Voyager API is designed and implemented. This is the task of the maintainers of the Voyager API, and is done by
* maintaining this document, defining the rules and methods for design and implementation
* providing expertise before or during the design and/or implementation of an extension (the earlier involved, the better)
* deciding if a given contribution can be accepted or has to be modified to meet the requirements for a contribution to the Voyager API

== About this document ==
This document is intended for the following people:
* developers, for understanding
** the methods and rules that are used for and apply to the task of designing and implementing additions to the Voyager API
** how to contribute extensions to the maintainers of the Voyager API
* maintainers of the Voyager API, for
** ensuring that contributed extensions apply to the rules of design and implementation described in this document and meet the requirements for a contribution
** performing the defined methods/procedures when accepting a contribution

== Design Goals for the Voyager API ==
The design goals for the Voyager API are:
* the API is implemented as an object oriented class library
* using Netlabs Object Model (NOM)
** allows bindings for non-OO compiler and script languages
** allows better binary compatibility for external extensions
* no 1-1 implementation of (one of) the underlying libraries
** trade in some flexibility for simplicity
** cover approx. 60-80% of the used cases of the supported libraries
* gain the same reputation concerning quality like the OS/2 API
** see this API as '''advertisement''' for Voyager as an '''exemplary development platform'''

== Implementing the Voyager API as an object oriented class library ==
The Voyager API will be implemented using the Netlabs Object Model (NOM), implementing a runtime for an object oriented class library. Thus the API itself will be implemented as software classes, allowing access to data and functionality by their interface, being implemented by methods (kind of functions) and members (variables).

Within the class library, all software classes are part of the class hierarchy, where specialized subclasses are derived from parent classes. Subclasses inherit the behaviour from the parent class, and extend an/or modify the behaviour of the parent class. Some of the parent classes are so-called 'abstract classes' that is they are not intended to create instances of it, but only for implementing base functionality for subclasses. A special form of this are 'virtual base classes', which do not implement any code, but only define the mandantory interface of a subclass (e.g. a virtual base class for file decoder defines that a subclass for handling of a specific file must implement the method ReadFileContents).

The complete API will be spearated into major parts by [[Voyager_API_Design|groups of classes]]. When the API is to be extended, this can happen by
* implementing the extension in a new or existing method in an existing class
* derive a new class from an existing one, and implementing the extension in this class
* define a new major API or framework and derive a complete new group of classes from the root class, implementing the extension in these classes

The following rules apply when deciding which of these options are applicable for a given extension:
* ''<not yet determined>''

Another design issue is to decide when using native compiler types (or appropriate typedef's) instead of classes for data types. In general, for maximum performance and minimum complexity, the native compiler data types should be used for simple data types. For complex data types, or where compiler implemented operators are not sufficient, data type classes should be implemented. In general, data type classes will be implemented by the Netlabs Object Model (NOM), if they are not specific to a special part of the Voyager API implemented with it.

== The Voyager API Classes and Interface Namespace ==

Cinc: this part must be reviewed and should be considered a proposal only.

The class names and the names of the classes' methods and members are prefixed by a tag identifying the major part of the API.

The reasons for the member name prefix is that the IDL compiler creates access macros with the method or member name prepended by an underscore only. If the members would not be prefixed, two classes within the entire class hierarchy could not have a method with the same name. The name clash problem is not completely solved by the member name prefix, but eased a lot.

Within a major part of the Voyager API,
* class names are prepended with a mixed case prefix, like Svc, Sys, Wp
* member names are prepended with a lower case prefix, like svc, sys, wp
* symbols are prepended with an uppercase prefix with a trailing underscore, like SVC_, SYS_, WP_

== Extending the Voyager API ==
The following tasks are to be processed when suggesting an extension to the Voyager API:
* document new functionality
** used case
** requirements
* (*) search for (base) classes for either to
** implement it in a new or existing method in an existing class
** derive a new class from an existing one for it
** define a new major API or framework, derive from root class for it
* (*) analyse and document design options
* define testcases per design option
* (*) decide for one option, document the reasons for the decision
* implement the extension within a testcase
* perform the testcase, document results
* send contribution to the API maintainers, including
** the testcase with source
** all documentation items

For the steps marked with (*) it may make sense to discuss the existing results with the maintainers of the API, to make sure that the testcase implementation already meets all requirements and design and implementation rules.

== Accepting contributions for the Voyager API ==

''<to be edited>''

When a proposal for an extension is being sent to the maintainer team, the team will determine the maintainer for that extension (not necessarily one of the team). The proposal can be sent in as an idea only, when asking for expertise and feedback, or already as a fully implemented extension.

In order to process the extension proposal, 'the maintainer' will perform the following steps, where generally one major step will be performed only when the predecessor has been finished:
* provide expertise and feedback to the author of the extension
* review the contribution for the following aspects (if already available)
** usability of new functionality
** design options analysis and decision
** testcase implementation and results
* develop further design and implementation alternative(s), where applicable
** pass back to author for review and modification, where required
* discuss changes to this Design and Implementation Guide, where applicable/required
* perform final discussion in maintainer team
* within the maintainer team, decide to accept or reject the contribution, concerning design and implementation

* when accepted
** request further documentation for the API docs, where required
** add the extension and documentation to the Voyager API code archive
** extend the build environment in the source archive, where required
* when rejected, document reasons and, where applicable, either
** request modification
** propose design alternative(s)

It may be necessary to perform this procedure several times, before an extension is completely accepted or rejected.

== Appendix: Requirements for testcase packages ==
''<to be edited>''
* documentation
** design
** per testcase
*** description (including prerequisites)
*** how to execute
*** expected result
* compiled binaries

== Appendix: Building the Voyager API ==
''<to be edited>''
* define the standard build environment for the Voyager API
** required programs
** provided methods
*** build all, docs,
*** call debugger ?
*** build/maintain release packages
* document how to technically extend the build system for to add a new class and/or method

Voyager API Design Guide

2007-07-30T21:02:40Z

Cinc: /* The Voyager API Classes and Interface Namespace */

This page contains a first draft for the Design and Implementation Guide for the Voyager API. Please note that the codename Voyager will not appear in the resulting document anylonger, once this document has reached the final version.

Please see also the pages
* [[Voyager_API_Basics|The Voyager API Basics]] - containing the basic ideas for the Voyager API
* [[Voyager_API_Design|The Voyager API Design]] containing the design/coverage of the upcoming Voyager API

[[Voyager|Voyager Main Page]]

== Foreword ==
The Voyager API will be implemented as an object oriented class library, using the Netlabs Object Model (NOM).

In the progress of ongoing development, for different reasons it may be required that the Voyager API could use extensions, due to
* changes within the system, applications require additional interfaces to
** the underlying kernel or
** supporting libraries
* new hardware or file formats requiring support
* new concepts requiring implementation of new classes and/or frameworks (sets of classes)

In order to keep a high quality standard within the Voyager API, it is vital to ensure that contributions match the way the current Voyager API is designed and implemented. This is the task of the maintainers of the Voyager API, and is done by
* maintaining this document, defining the rules and methods for design and implementation
* providing expertise before or during the design and/or implementation of an extension (the earlier involved, the better)
* deciding if a given contribution can be accepted or has to be modified to meet the requirements for a contribution to the Voyager API

== About this document ==
This document is intended for the following people:
* developers, for understanding
** the methods and rules that are used for and apply to the task of designing and implementing additions to the Voyager API
** how to contribute extensions to the maintainers of the Voyager API
* maintainers of the Voyager API, for
** ensuring that contributed extensions apply to the rules of design and implementation described in this document and meet the requirements for a contribution
** performing the defined methods/procedures when accepting a contribution

== Design Goals for the Voyager API ==
The design goals for the Voyager API are:
* the API is implemented as an object oriented class library
* using Netlabs Object Model (NOM)
** allows bindings for non-OO compiler and script languages
** allows better binary compatibility for external extensions
* no 1-1 implementation of (one of) the underlying libraries
** trade in some flexibility for simplicity
** cover approx. 60-80% of the used cases of the supported libraries
* gain the same reputation concerning quality like the OS/2 API
** see this API as '''advertisement''' for Voyager as an '''exemplary development platform'''

== Implementing the Voyager API as an object oriented class library ==
The Voyager API will be implemented using the Netlabs Object Model (NOM), implementing a runtime for an object oriented class library. Thus the API itself will be implemented as software classes, allowing access to data and functionality by their interface, being implemented by methods (kind of functions) and members (variables).

Within the class library, all software classes are part of the class hierarchy, where specialized subclasses are derived from parent classes. Subclasses inherit the behaviour from the parent class, and extend an/or modify the behaviour of the parent class. Some of the parent classes are so-called 'abstract classes' that is they are not intended to create instances of it, but only for implementing base functionality for subclasses. A special form of this are 'virtual base classes', which do not implement any code, but only define the mandantory interface of a subclass (e.g. a virtual base class for file decoder defines that a subclass for handling of a specific file must implement the method ReadFileContents).

The complete API will be spearated into major parts by [[Voyager_API_Design|groups of classes]]. When the API is to be extended, this can happen by
* implementing the extension in a new or existing method in an existing class
* derive a new class from an existing one, and implementing the extension in this class
* define a new major API or framework and derive a complete new group of classes from the root class, implementing the extension in these classes

The following rules apply when deciding which of these options are applicable for a given extension:
* ''<not yet determined>''

Another design issue is to decide when using native compiler types (or appropriate typedef's) instead of classes for data types. In general, for maximum performance and minimum complexity, the native compiler data types should be used for simple data types. For complex data types, or where compiler implemented operators are not sufficient, data type classes should be implemented. In general, data type classes will be implemented by the Netlabs Object Model (NOM), if they are not specific to a special part of the Voyager API implemented with it.

== The Voyager API Classes and Interface Namespace ==

Cinc: this part must be reviewed and should be considered a proposal only.

The class names and the names of the classes' methods and members are prefixed by a tag identifying the major part of the API.

The reasons for the member name prefix is that the IDL compiler creates access macros with the method or member name prepended by an underscore only. If the members would not be prefixed, two classes within the entire class hierarchy could not have a method with the same name. The name clash problem is not completely solved by the member name prefix, but eased a lot.

Within a major part of the Voyager API,
* class names are prepended with a mixed case prefix, like Svc, Sys, Wp
* member names are prepended with a lower case prefix, like svc, sys, wp
* symbols are prepended with an uppercase prefix with a trailing underscore, like SVC_, SYS_, WP_

== Extending the Voyager API ==
The following tasks are to be processed when suggesting an extension to the Voyager API:
* document new functionality
** used case
** requirements
* (*) search for (base) classes for either to
** implement it in a new or existing method in an existing class
** derive a new class from an existing one for it
** define a new major API or framework, derive from root class for it
* (*) analyse and document design options
* define testcases per design option
* (*) decide for one option, document the reasons for the decision
* implement the extension within a testcase
* perform the testcase, document results
* send contribution to the API maintainers, including
** the testcase with source
** all documentation items

For the steps marked with (*) it may make sense to discuss the existing results with the maintainers of the API, to make sure that the testcase implementation already meets all requirements and design and implementation rules.

== Accepting contributions for the Voyager API ==
When a proposal for an extension is being sent to the maintainer team, the team will determine the maintainer for that extension (not necessarily one of the team). The proposal can be sent in as an idea only, when asking for expertise and feedback, or already as a fully implemented extension.

In order to process the extension proposal, 'the maintainer' will perform the following steps, where generally one major step will be performed only when the predecessor has been finished:
* provide expertise and feedback to the author of the extension
* review the contribution for the following aspects (if already available)
** usability of new functionality
** design options analysis and decision
** testcase implementation and results
* develop further design and implementation alternative(s), where applicable
** pass back to author for review and modification, where required
* discuss changes to this Design and Implementation Guide, where applicable/required
* perform final discussion in maintainer team
* within the maintainer team, decide to accept or reject the contribution, concerning design and implementation

* when accepted
** request further documentation for the API docs, where required
** add the extension and documentation to the Voyager API code archive
** extend the build environment in the source archive, where required
* when rejected, document reasons and, where applicable, either
** request modification
** propose design alternative(s)

It may be necessary to perform this procedure several times, before an extension is completely accepted or rejected.

== Appendix: Requirements for testcase packages ==
''<to be edited>''
* documentation
** design
** per testcase
*** description (including prerequisites)
*** how to execute
*** expected result
* compiled binaries

== Appendix: Building the Voyager API ==
''<to be edited>''
* define the standard build environment for the Voyager API
** required programs
** provided methods
*** build all, docs,
*** call debugger ?
*** build/maintain release packages
* document how to technically extend the build system for to add a new class and/or method

Desktop class list

2007-07-25T06:45:47Z

Cinc: Started list of desktop classes

This is a list of desktop classes and methods for the Voyager desktop. Note that this list is in no way exhaustive.

* WPObject:NOMObject
** wpInit()
** wpUnInit()
** wpAllocMem()
** wpFreeMem()
** wpFree()
* WPFileSystem:WPObject

* WPDataFile:WPFileSystem

* WPFolder:WPFileSystem

Voyager API Design

2007-07-25T06:35:07Z

Cinc: /* Desktop Objects */

Welcome to the Wiki Page explaining the design of the Voyager API.

Please see also the page [[Voyager_API_Basics|The Voyager API Basics]], containing the basic ideas and design goals for the Voyager API.

'''Please note'''
* The page is organized as a list of sections, where each section names a specific major part of the Voyager API (with the excetipon of the section ''Virtual Base Classes'')
* Each section API may be used as a base for an API of another section, where applicable
* Take into account that the API will likely be implemented as an object oriented class library. Using the Netlabs Object Model this will be compiler and language independent (so e.g. C and Classic REXX can also be used)
* If you have additions or a completely new main section, please feel free to add it
* If you feel that a part of the structure better would be reorganized (joining or splitting major sections, moving parts between major sections), please contact the netlabs.org core team first for prior discussion. However, all suggestions and comments are very welcome and highly appreciated!

[[Voyager|Voyager Main Page]]

== System Resources & Management ==
This section implements system near resource handling (including kernel related hardware)
* Wrapper for Kernel Services, Memory, Interrupts, Timer, ACPI
* DMI (incl. Process Management)
* Interprocess Communications
** Shared Memory, Semaphores, Queues, (Named) Pipes, more...
* Add more...

== Basic Device Input/Output ==
This section implements input and output from and to peripheral hardware for applications, and encapsulates existing APIs (where possible, in a unified manner)
* Keyboard, Mouse
* Sound
* Video
* USB
* Firewire
* NICs, other adpaters
* more...

== System Security ==
This section implements access restrictions and other security methods.
* refer to Security/2 design ?
* Add more...

== System Component Configuration ==
This section implements configuration of system components (possibly also application components via a framework ?)

Here is a list of goals:
* encapsulates any kernel specific means of configuration
* implements an internal (?) database for configuration data (like OS2.INI or Registry)
* may superseed DMI, and a DMI implementation may use this part of the API
* includes Disk & Partition Management
* Add more...

== System Service Management ==
This section implements the means for managing system or application services
* see the design sketch from Warpstock Europe 2005 as a proposal: [http://www.clanganke.de/os2/pres/wse2005/all04_en.sdd ALL04 - Service Management for OS/2 and eComStation] (requires StarOffice 5.1 or OpenOffice.org)
* Add more...

== Unified Data Access ==
This section implements a unified view on data (fuse alike)
* Filesystem Protocols incl. Named Pipes (Samba, NFS, more...)
* Internet Protocols (http, rtsp, SSH, more...)
* Add more...

== lowlevel graphics ==
This section implements basic GUI stuff.
* primitives (lines, circles, more...)
* font rendering
* image handling (scaling, blending, more...)
* Add more...

== highlevel GUI ==
This section implements highlevel GUI features used for creating windows, controls and so forth.
* frame window
* controls, frame controls
* text window (support for terminal window)
* Add more...

== Desktop Objects ==
This section implements nothing less than all classes that implement the workplace Shell replacement.
* (a.k.a. Workplace Shell Replacement and its objects)

[[Desktop_class_list|Preliminary list of desktop classes]] to be implemented.

== (Virtual) Base Classes ==
This is not a real major API part, but a placeholder for all parts of the API, where we could create (virtual) base classes to allow easy and future safe extension of the Voyager API. The topics listed here could be included in some of the major sections, the reason to summarize it here is to make clear that we need to have a method to create such classes as little frameworks in a consistent way.
Here is a first list:
* support classes (strings, arrays)
* application protocols (including filesystem access)(see section Application protocols)
* file or stream format encoder/decoder
* System Configuration Components
* access to streamed data (file stream, TCP/IP stream, more)
* internet protocols
* much more for virtually anything, for all main sections!
* Add more...

ESchemes

2007-06-29T20:08:54Z

Cinc: /* OS Skinning/Schemeing */

== OS Skinning/Schemeing ==

[[Image:ESCHEMES.PNG|thumb|Beta 1.10]]
[[Image:Eschemes_1_11.png|thumb|Beta 1.11 Colors/Controls preview]] [[Image:Eschemes_1_11_ptr.png|thumb|Beta 1.11 Pointers preview]]
[[Image:Eschemes_1_11_snd.png|thumb|Beta 1.11 Sounds preview]]
[[Image:Eschemes_1_11_obj.png|thumb|Beta 1.11 WPS Objects settings preview]]
[[Image:Eschemes_1_11_cls.png|thumb|Beta 1.11 WPS Classes settings preview]]

(Files for the eSchemes project can now be found at the [http://betazone.ecomstation.com eComstation Betazone])

Note that eSchemes is only available as a commercial product for non-eCS users.

=== Introduction ===

While I think that the look is not very imporant in an OS design, we have to recognize that the desire/need to change the interface to match the user's taste have had a major role in the design of recent GUIs.

Recent eComstation releases (1.1 and 1.2) are getting better at handling this, with the possibility to change the standard icons, change some of the GUI controls (system box, max/min/hide/close buttons), change the titlebar, change the pushbuttons, check-boxes and radio-buttons.

All in all, it is a pretty comprehensive list of possible interface changes, but we're still far from the competition.
Adding some third-party tools, we can get rid of the standard gray color, add some transparency, change window borders, etc.

=== The Problem ===

So, where's the problem?
* We need FAR TOO MANY different pieces of software to change the interface
* Every piece of software does its own thing, and many times there are conflicts
* Different pieces of sotware choose to do the same things in different ways
* You have to reboot to activate most of the changes
* We have no means of using non-square windows

Let's see how many pieces of software one may need in order to change the interface in a way that at least resembles the capabilities of other platforms:

* The standard scheme palette. This is pretty limited. It can't change all the colors, and you can't add more schemes to the palette. ''(Cinc: You may create new sheme palettes to overcome the limitation.)''
* SysColors (http://os2.ru/articles/dev/prog/syscolors/index.phtml.ru) This can change more system colors, but has no support for saving schemes. BTW, the source is available.
* eStyler or Styler/2. While Styler/2 should support a superset of eStyler functions, there are things that eStyler does (such as replacing buttons) but Styler/2 don't. But Styler/2 supports on-the-fly changing of title-bar controls, while eStyler doesn't. So one can't trade eStyler for Styler/2 (or the other way around) without losing some functionality.
* ColourManager/2. This one supports changing of all (but the most hidden ones) colors in the interface, and (once again) changing title-bar controls and other buttons. This one requires a reboot, too. And uses a different format for the resources from eStyler. Fortunately, CoulourManager/2 is now available in source-code to eCS developers.
* CandyBarz (Netlabs). This is the most advanced skinning application for OS/2, but it is less stable than his counterparts, it is somewhat buggy and it's not developed anymore. It is opensource though, so anyone can in theory restart development. I'm under the impression that eStyler's (or ColourManager/2) way of changing controls is more stable and less error-prone ''(comment by Cinc: eStyler does the control changing the same way CandyBarZ does it AFAIK)'', but it may only be that CandyBarZ is quite old now. Can do most of the things that the other pieces of sotware do and more, and it does it on-the-fly.
''Cinc: CandyBarZ is/was work in progress with *a lot of* experimental stuff. So no wonder it's not too stable ;-). As a kind of testbed it showed how some things are better not done for such a theming engine. Well, I know what I'm speaking about here. I was one of the main coders. Transparency, custom controls, bitmaps in frames and controls are my childs.''
* Icon themes. Changes all of the standard icons of the OS. It is evolving in the direction of being a full replacement for Stardock's Icon Schemes, which was more powerful but it is closed-source and development has stopped. Another problem is replacing native term ''scheme'' by windows term ''theme''. We need common treminology.
* Window Themes. Changes title-bar controls (like eStyler) after a reboot. Changes radio-buttons and check-boxes, but NOT pushbuttons (you need eStyler or CandyBarZ for this). And also have term ''theme'' instead of ''scheme''.
* CandyFolders (Netlabs) to add some transparency to folder backrounds.
* NPSWPS to add drop shadows to windows, and animation effects.

See? If one wants to change everything that could be changeable he needs 9 pieces of software, with many overlapped functionalities. And in the end, some pieces of customization are still missing.

Given this situation it is impossible to develop/distribute comprehensive themes/skins for our OS, and give the user a hassle-free, auto-installing package.

What we need is ONE program capable of changing ALL of the resources, or at least the sum of those that are presently changeable with all the diverse software pieces. If it can't be done without rebooting, this software should at least have a very good previewing function.

=== To Do ===

To sum it up (and what implemented in eSchemes already):

* Change ALL the colors (like ColourManager/2, SysColors) '''Implemented with logic like CM/2'''
* Change title-bar controls (eStyler and CandyBarZ) '''Reused eStyler 1.1 code'''
* Change pushbuttons (eStyler and CandyBarZ) '''Reused eStyler 1.1 code'''
* Change check-boxes and radio-buttons (Window Themes, ColourManager/2, CandyBarZ) '''Implemented with logic like CM/2 and Window Themes'''
* Change (indipendently, or remove some of the) window borders (CandyBarz)
* Change icons (Icon themes) '''Implemented via WPS settings (including not icons only but any WPS settings'''
* Change titlebars (eStyler, Styler/2, ColourManager/2, CandyBarZ) '''Reused eStyler 1.1 code'''
* Globally change desktop/folder backgrounds (ColourManager/2) ''(Cinc: this one I don't understand. Please clarify.)''
* Transparency (CandyBarZ + CandyFolders)
* Animation and drop-shadows (NPSWPS)
* Subclassing/substituting the remaining controls (scroll bars, etc) (CandyBarZ)
* WISH: different title-bar controls for active/inactive windows ''(Cinc: CandyBarZ or are you speaking about titlebar buttons? -- Cris: yes, I'm speaking about buttons)''
* WISH: non-rectangular windows. There are at least two different libraries for this:
** ShapeWindow (LGPL - http://www.sra.co.jp/people/akira/os2/arch/shpwn200.zip)
** TileWindow (LGPL - http://hp.vector.co.jp/authors/VA001398/os2/softwares/libraries/twtk1_1_4bld14.zip)
''Cinc: these are awfully slow. Won't be possible without diving deep into PM (if possible at all)''

''Cris: don't think so, at least not if it isn't overused. With recent HW, the shape-window extensions are quite fast; moreover, if one uses it only to have rounded borders on windows (like WinXP or many Linux distros default scheme) the number of PM windows created is not boosted very much.''
* WISH: Ability to save everything as one scheme, easily distributable (''Cinc: CandyBarZ did this to some extent)'' '''Implemented loading (no save yet)'''

=== Discussion ===
[[eschemes discussion|Discussion]]

Rebuild your eCS desktop

2007-06-09T09:51:34Z

Cinc: Some minor clarifications

When following the steps outlined here the resulting desktop will be the one created during installation of the system. Any objects added by the user are not lost but preserved and may be moved to the newly built desktop later. This is kind of a last resort desktop maintainance trick when your INI files are completely broken and none of the known INI tools is able to recover them properly.

#Create a copy of your current INI files, just in case...
#Boot to the recovery options screen by pressing ALT-F1 when the white square appears in the upper left corner during boot
#Start a command line by pressing F2
#Go to the directory holding your INI files which is usually ''OS2'' on your boot drive
#Run <code>makini.exe os2.ini ini.rc</code> to create the first INI file
#Run <code>makini.exe os2sys.ini inisys.rc</code> to create the other INI file
#Reboot by entering <code>exit</code>

The system should drop you on a new desktop with some objects already created. Part two is to recreate all the objects built during initial installation.

#Open a command line and go to <code>x:\ecs\install</code>, where ''x'' is your boot drive
#Run <code>CLNDESK.EXE x:\ecs\install\rsp\shuf_ctl.ini x:\ecs\install\rsp\shuf_key.ini</code>

Your desktop and the relevant subdirectories (e.g. ''Programs'') are now populated with all the objects you know from your desktop just after installation. Any objects created during the lifetime of your system prior to recreating your desktop can be found in the folder ''Previous Desktop'' which can be found on your new desktop.

Keep in mind that some of the objects in this folder may be broken. Remember you created
a new desktop in the first place because the old one was broken...

([[User:Cinc|Cinc]] 11:11, 30 April 2007 (CEST))

Developers Workshop 2007

2007-06-08T07:56:27Z

Cinc: Und 'nen Sprecher gibts auch...

[[Image:Logodws07.png|right|frame|The workshop logo was created by [http://www.esthereberwijn.com/ Esther Eberwijn] ]]
=== Netlabs Developers Workshop 2007 July 7 & 8 Amsterdam, The Netherlands===

This page is dedicated to the ''OS/2'', ''eComStation'' and ''Voyager'' '''[[Developers Workshop]]''' 2007!

== News==
15-05-2007: The first 3 presentations are now listed with detailed information; Added two hotels 
08-05-2007: Added the first presentations 
08-04-2007: Sent out a message with ticket information and how to submit presentations 
29-03-2007: Added registration info

== What==

Like the years before, the workshop will be a '''great mix''' of information exchange between ''developers'' and ''translators'' from all over the world. They can be present on location or online.
It is cool to meet developers in real life to match faces to nicknames! This makes working online later easier and more fun as well.

Both days will have seven sessions of 45 minutes each. Starting at 9:00 AM and ending at 17:00 PM.
 We are currently talking to various developers to get the sessions filled with high quality content.
 So keep this page monitored to have the latest information! The final schedule will be posted soon.
 If you have not been contacted yet while you have an interesting subject to present about, then please contact us via mail at: '''mailto:developersworkshop@netlabs.org'''

=== Topics ===

Currently we have the following topics arranged already:

* '''Introduction to NOM''' (Netlabs Object Model)
** ''Chris Wohlgemuth''
** NOM is the object model developed for the Voyager project but may be used for any kind of apps. It's lightweight with C syntax, binary compatibility over releases and a free license. The presentation shows the architecture and gives examples how and why to use NOM in application development.
*** Why using NOM?
*** NOM compared to SOM
**** Garbage collection
**** Object pointer verification
**** ...
*** Current development status
*** Programming example
*** Future plans and contributing

* '''Utilizing multi core processors with multiple threads'''
* '''Voyager Resources'''
* '''A Freely Programmable USB-Interface for eCS - Focussing on the DLP-USB245M'''
** ''Uwe Hinz, OS/2 User Group Dresden''
** The presentation shows a possible way to overcome the barrier of missing USB-Drivers for eCS. Instead of programming one particular driver for a particular USB device, it will be explained how the already existing driver 'usbedc10.sys' by Wim Brul can do the job easily. Together with the famous USB-Interface Modul DLB-USB245M and a Microcontroller (MCU) the presentation will show how to build USB devices for eCS that can do digital I/O, analog I/O and a number of tasks in the world of Data Acquisition and Control (DAC). Two working examples written in VXREXX will be presented and some details about the USB protocol will be mentioned as well.
* '''How to create popular software products for eComStation'''
** ''Eugene Gorbunoff, eCo Software''
*** 100 tricks and tips
*** How to select a project
*** What do users need
*** How to organize work
*** How to collaborate with other developers
*** How to survive on eCS market
* '''eComStation User Interface'''
** ''Eugene Gorbunoff, eCo Software''
*** Advantages and disadvantages
*** New control elements, libraries and templates
*** The future of eComStation UI

== Costs==

=== Workshop===

This event is a great gathering and is being organized for the third time now by volunteers. We try to keep costs as low as possible, but we can't make it for free, unless you are a student!

 To make registration and payments easy and flexible you can use the
[http://www.mensys.net/DeveloperWorkshop2007/ '''Mensys'''] system for this.
'' Please register and pay up front, even if you are a student, so we don't have to deal with cash money and credit cards on location. Thereby preparing badges before the event starts already and making things go smoothly.''

 The following options are available:

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

=== Lunch ===

Each day a very complete lunch buffet (cold and warm) will be provided near the location (50 meters). This will cost '''14,- Euro''' per meal (without beverages, for which the bar will be opened), to be paid at the location.

== Where ==

After Dresden (Germany) and Biel (Swiss), this years edition will be held in the beautiful and famous city of '''Amsterdam''' in '''The Netherlands'''.
 As this city has ''many great things'' to offer, besides this workshop of course, if might be wise to extend your visit with some extra days! Then you can explore the many gems that can be found in this city. Take a look at the [http://www.iamsterdam.com/ '''Tourist Information'''] site to fill your agenda.

 The event location will be:
'''Cultural center Griffioen''' of the [http://www.vuamsterdam.com//home/index.cfm '''VU Amsterdam'''].
This university is also the seat of [http://en.wikipedia.org/wiki/Andrew_S._Tanenbaum '''Dr. Andrew S. Tanenbaum'''].

 It is located on the border of Amsterdam and Amstelveen, but it is '''very easy''' to '''reach''' from the city center!
 Here is some more information on the location itself, but it is in ''Dutch'' only:
[http://www.vu.nl/Organisatie/index.cfm/home_subsection.cfm/subsectionid/9DB86C70-F9C7-4704-8C9D9ED46EEDB063 '''Location information''']

== Sleeping ==
As Amsterdam is still a '''tourist magnet''' it is wise to arrange your ho(s)tel '''early'''!
 The same accounts for cheap flights, which are available from many international airports.

=== Cheap but good===
For a cheap, but good quality, hostel look at: 
[http://www.stayokay.com/index.cfm?fuseaction=Herbergen.showHomeHB&lng=2&id=3 '''StayOkay''']

This one is located on the edge of the city center, and close to the stops of '''tram line 5'''.
 ''Not practical when you come by car!''
 

=== Handy hotel ===
If you travel by '''car''', the following hotel might be of interest:
* [http://www.bastionhotels.nl/en/ourhotels/amsterdamzuidwest/ '''Bastion Hotel Amsterdam/Centrum-Zuidwest''']
 

=== Other ho(s)tels===
If you are looking for other hotels or hostels, try to find one close to '''tram line 5 or 51''' as that makes traveling to the location '''very easy'''! And cheap, as most hotels might have free/cheap parking.

'''Note:''' When looking for hotels in Amsterdam, We came across two hotels that are located close to the station Amsterdam - Zuid. We have no further information about the hotels, but we thought they should be listed here: 
* [http://www.novotel.com/novotel/fichehotel/de/nov/0515/fiche_hotel.shtml '''Novotel Amsterdam'''] 
* [http://www.ichotelsgroup.com/h/d/6c/394/de/hd/amsnt '''Holiday Inn Amsterdam''']
 

== Getting there==

There are many ways that lead to Amsterdam:

=== By train===

The event location is close to station ''''Amsterdam - Zuid''''. If you travel with an international train you need to transfer at ''''Amsterdam - Duivendrecht''''. Otherwise it might be easier to go to ''''Amsterdam - Centraal'''' and take one of two direct trams from there ('''line 5 and 51''').
 More information about train connections can be found at the [http://ns.nl/servlet/Satellite?cid=1075985690180&pagename=www.ns.nl%2FPage%2FSuperHomepageEnglish&lang=en&c=Page '''Nederlandse Spoorwegen'''] site.

=== By plane===

There is an enormous amount of airlines flying to ''''Amsterdam International Airport Schiphol''''. So it should be possible to get there at ''reasonable prices'', so book your tickets early! The airport is one stop away by train (''''Amsterdam - Zuid''''). Be sure '''NOT''' to travel into the direction of ''''Amsterdam - Centraal''''
 More information about arriving by plane can be found at the [http://schiphol.nl/home/Index.jsp;jsessionid=GKFNHKTzJL3JX1LyNQ6QMVLWH!2089105939?ASSORTMENT%3C%3East_id=1408474395729236&bmLocale=en&GENERIC%3C%3EclientGenericEvent=Changed+locale+to+en&GENERIC%3C%3EeventType=Locale&FOLDER%3C%3Efolder_id=1408474395729236&VIRTUAL_TEMPLATE%3C%3Evt_id=10134198673795849&bmForm=log_client_generic_event&bmFormID=1179256269064&bmUID=1179256269064 '''Schiphol'''] site.

=== By car===

Although there is ''plenty'' of ''free parking'' space '''near''' the event, be aware that parking is '''expensive''' and that there are '''high fines''' on ''not'' paying if you stay in the city of Amsterdam !!.
 From all directions: travel to 'Ring A10' and take exit 'VU Hospital'. More precise directions will follow soon.

In case you have a navigation system, here is the full address of the site:
 Cultuurcentrum Griffioen
 Uilenstede 106
 1183 AM Amstelveen
 Phone: (31)-(0)20-5985100

'''Hope to see you all there!'''
 ''Developer Workshop Team''

 This page is under construction. If you are looking for information which is not listed yet or have information that might be of interest to others then please mail us at: '''mailto:developersworkshop@netlabs.org'''

Developers Workshop 2007

2007-06-08T07:53:55Z

Cinc: Some info about NOM presentation

[[Image:Logodws07.png|right|frame|The workshop logo was created by [http://www.esthereberwijn.com/ Esther Eberwijn] ]]
=== Netlabs Developers Workshop 2007 July 7 & 8 Amsterdam, The Netherlands===

This page is dedicated to the ''OS/2'', ''eComStation'' and ''Voyager'' '''[[Developers Workshop]]''' 2007!

== News==
15-05-2007: The first 3 presentations are now listed with detailed information; Added two hotels 
08-05-2007: Added the first presentations 
08-04-2007: Sent out a message with ticket information and how to submit presentations 
29-03-2007: Added registration info

== What==

Like the years before, the workshop will be a '''great mix''' of information exchange between ''developers'' and ''translators'' from all over the world. They can be present on location or online.
It is cool to meet developers in real life to match faces to nicknames! This makes working online later easier and more fun as well.

Both days will have seven sessions of 45 minutes each. Starting at 9:00 AM and ending at 17:00 PM.
 We are currently talking to various developers to get the sessions filled with high quality content.
 So keep this page monitored to have the latest information! The final schedule will be posted soon.
 If you have not been contacted yet while you have an interesting subject to present about, then please contact us via mail at: '''mailto:developersworkshop@netlabs.org'''

=== Topics ===

Currently we have the following topics arranged already:

* '''Introduction to NOM''' (Netlabs Object Model)
** NOM is the object model developed for the Voyager project but may be used for any kind of apps. It's lightweight with C syntax, binary compatibility over releases and a free license. The presentation shows the architecture and gives examples how and why to use NOM in application development.
*** Why using NOM?
*** NOM compared to SOM
**** Garbage collection
**** Object pointer verification
**** ...
*** Current development status
*** Programming example
*** Future plans and contributing

* '''Utilizing multi core processors with multiple threads'''
* '''Voyager Resources'''
* '''A Freely Programmable USB-Interface for eCS - Focussing on the DLP-USB245M'''
** ''Uwe Hinz, OS/2 User Group Dresden''
** The presentation shows a possible way to overcome the barrier of missing USB-Drivers for eCS. Instead of programming one particular driver for a particular USB device, it will be explained how the already existing driver 'usbedc10.sys' by Wim Brul can do the job easily. Together with the famous USB-Interface Modul DLB-USB245M and a Microcontroller (MCU) the presentation will show how to build USB devices for eCS that can do digital I/O, analog I/O and a number of tasks in the world of Data Acquisition and Control (DAC). Two working examples written in VXREXX will be presented and some details about the USB protocol will be mentioned as well.
* '''How to create popular software products for eComStation'''
** ''Eugene Gorbunoff, eCo Software''
*** 100 tricks and tips
*** How to select a project
*** What do users need
*** How to organize work
*** How to collaborate with other developers
*** How to survive on eCS market
* '''eComStation User Interface'''
** ''Eugene Gorbunoff, eCo Software''
*** Advantages and disadvantages
*** New control elements, libraries and templates
*** The future of eComStation UI

== Costs==

=== Workshop===

This event is a great gathering and is being organized for the third time now by volunteers. We try to keep costs as low as possible, but we can't make it for free, unless you are a student!

 To make registration and payments easy and flexible you can use the
[http://www.mensys.net/DeveloperWorkshop2007/ '''Mensys'''] system for this.
'' Please register and pay up front, even if you are a student, so we don't have to deal with cash money and credit cards on location. Thereby preparing badges before the event starts already and making things go smoothly.''

 The following options are available:

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

=== Lunch ===

Each day a very complete lunch buffet (cold and warm) will be provided near the location (50 meters). This will cost '''14,- Euro''' per meal (without beverages, for which the bar will be opened), to be paid at the location.

== Where ==

After Dresden (Germany) and Biel (Swiss), this years edition will be held in the beautiful and famous city of '''Amsterdam''' in '''The Netherlands'''.
 As this city has ''many great things'' to offer, besides this workshop of course, if might be wise to extend your visit with some extra days! Then you can explore the many gems that can be found in this city. Take a look at the [http://www.iamsterdam.com/ '''Tourist Information'''] site to fill your agenda.

 The event location will be:
'''Cultural center Griffioen''' of the [http://www.vuamsterdam.com//home/index.cfm '''VU Amsterdam'''].
This university is also the seat of [http://en.wikipedia.org/wiki/Andrew_S._Tanenbaum '''Dr. Andrew S. Tanenbaum'''].

 It is located on the border of Amsterdam and Amstelveen, but it is '''very easy''' to '''reach''' from the city center!
 Here is some more information on the location itself, but it is in ''Dutch'' only:
[http://www.vu.nl/Organisatie/index.cfm/home_subsection.cfm/subsectionid/9DB86C70-F9C7-4704-8C9D9ED46EEDB063 '''Location information''']

== Sleeping ==
As Amsterdam is still a '''tourist magnet''' it is wise to arrange your ho(s)tel '''early'''!
 The same accounts for cheap flights, which are available from many international airports.

=== Cheap but good===
For a cheap, but good quality, hostel look at: 
[http://www.stayokay.com/index.cfm?fuseaction=Herbergen.showHomeHB&lng=2&id=3 '''StayOkay''']

This one is located on the edge of the city center, and close to the stops of '''tram line 5'''.
 ''Not practical when you come by car!''
 

=== Handy hotel ===
If you travel by '''car''', the following hotel might be of interest:
* [http://www.bastionhotels.nl/en/ourhotels/amsterdamzuidwest/ '''Bastion Hotel Amsterdam/Centrum-Zuidwest''']
 

=== Other ho(s)tels===
If you are looking for other hotels or hostels, try to find one close to '''tram line 5 or 51''' as that makes traveling to the location '''very easy'''! And cheap, as most hotels might have free/cheap parking.

'''Note:''' When looking for hotels in Amsterdam, We came across two hotels that are located close to the station Amsterdam - Zuid. We have no further information about the hotels, but we thought they should be listed here: 
* [http://www.novotel.com/novotel/fichehotel/de/nov/0515/fiche_hotel.shtml '''Novotel Amsterdam'''] 
* [http://www.ichotelsgroup.com/h/d/6c/394/de/hd/amsnt '''Holiday Inn Amsterdam''']
 

== Getting there==

There are many ways that lead to Amsterdam:

=== By train===

The event location is close to station ''''Amsterdam - Zuid''''. If you travel with an international train you need to transfer at ''''Amsterdam - Duivendrecht''''. Otherwise it might be easier to go to ''''Amsterdam - Centraal'''' and take one of two direct trams from there ('''line 5 and 51''').
 More information about train connections can be found at the [http://ns.nl/servlet/Satellite?cid=1075985690180&pagename=www.ns.nl%2FPage%2FSuperHomepageEnglish&lang=en&c=Page '''Nederlandse Spoorwegen'''] site.

=== By plane===

There is an enormous amount of airlines flying to ''''Amsterdam International Airport Schiphol''''. So it should be possible to get there at ''reasonable prices'', so book your tickets early! The airport is one stop away by train (''''Amsterdam - Zuid''''). Be sure '''NOT''' to travel into the direction of ''''Amsterdam - Centraal''''
 More information about arriving by plane can be found at the [http://schiphol.nl/home/Index.jsp;jsessionid=GKFNHKTzJL3JX1LyNQ6QMVLWH!2089105939?ASSORTMENT%3C%3East_id=1408474395729236&bmLocale=en&GENERIC%3C%3EclientGenericEvent=Changed+locale+to+en&GENERIC%3C%3EeventType=Locale&FOLDER%3C%3Efolder_id=1408474395729236&VIRTUAL_TEMPLATE%3C%3Evt_id=10134198673795849&bmForm=log_client_generic_event&bmFormID=1179256269064&bmUID=1179256269064 '''Schiphol'''] site.

=== By car===

Although there is ''plenty'' of ''free parking'' space '''near''' the event, be aware that parking is '''expensive''' and that there are '''high fines''' on ''not'' paying if you stay in the city of Amsterdam !!.
 From all directions: travel to 'Ring A10' and take exit 'VU Hospital'. More precise directions will follow soon.

In case you have a navigation system, here is the full address of the site:
 Cultuurcentrum Griffioen
 Uilenstede 106
 1183 AM Amstelveen
 Phone: (31)-(0)20-5985100

'''Hope to see you all there!'''
 ''Developer Workshop Team''

 This page is under construction. If you are looking for information which is not listed yet or have information that might be of interest to others then please mail us at: '''mailto:developersworkshop@netlabs.org'''

Rebuild your eCS desktop

2007-04-30T09:11:40Z

Cinc: Typo :-/

When following the steps outlined here the resulting desktop will be the one created during installation of the system. Any objects added by the user are not lost but preserved and may be moved to the newly built desktop later. This is kind of a last resort desktop maintainance trick when your INI files are completely broken and none of the known INI tools is able to recover them properly.

#Create a copy of your current INI files, just in case...
#Boot to a command line by pressing ALT-F1 when the white square appears in the upper left corner during boot
#Go to the directory holding your INI files which is usually ''OS2'' on your boot drive
#Run <code>makini.exe os2.ini ini.rc</code> to create the first INI file
#Run <code>makini.exe os2sys.ini inisys.rc</code> to create the other INI file
#Reboot

The system should drop you on a new desktop with some objects already created. Part two is to recreate all the objects built during initial installation.

#Open a command line and go to <code>x:\ecs\install</code>, where ''x'' is your boot drive
#Run <code>CLNDESK.EXE x:\ecs\install\rsp\shuf_ctl.ini x:\ecs\install\rsp\shuf_key.ini</code>

Your desktop and the relevant subdirectories (e.g. ''Programs'') are now populated with all the objects you know from your desktop just after installation. Any objects created during the lifetime of your system prior to recreating your desktop can be found in the folder ''Previous Desktop'' which can be found on your new desktop.

Keep in mind that some of the objects in this folder may be broken. Remember you created
a new desktop in the first place because the old one was broken...

([[User:Cinc|Cinc]] 11:11, 30 April 2007 (CEST))

Rebuild your eCS desktop

2007-04-30T09:11:04Z

Cinc: Step by step instructions how to rebuild the desktop on eCS

When following the steps outlined here the resulting desktop will be the one created during installation of the system. Any objects added by the user are not lost but preserved and may be moved to the newly built desktop later. This is kind of a last resort desktop maintainance trick when your INI files are completely broken and none of the known INI tools is able to recover them properly.

#Create a copy of your current INI files, just in case...
#Boot to a command line by pressing ALT-F1 when the white square appears in the upper left corner during boot
#Go to the directory holding your INI files which is usually ''OS2'' on your boot drive
#Run <code>makini.exe os2.ini ini.rc</code> to create the first INI file
#Run <code>makini.exe os2sys.ini inisys.rc</code> to create the other INI file
#Reboot

The system should drop you on a new desktop with some objects already created. Part two is to recreate all the objects built during initial installation.

#Open a command line and go to <code>x:\ecs\install</code>, where ''x'' is your boot drive
#Run <code>CLNDESK.EXE x:\ecs\install\rsp\shuf_ctl.ini x:\ecs\install\rsp\shuf_key.ini</code>

Your desktop and the relevant subdirectories (e.g. ''Programs'') is now populated with all the objects you know from your desktop just after installation. Any objects created during the lifetime of your system prior to recreating your desktop can be found in the folder ''Previous Desktop'' which can be found on your new desktop.

Keep in mind that some of the objects in this folder may be broken. Remember you created
a new desktop in the first place because the old one was broken...

([[User:Cinc|Cinc]] 11:11, 30 April 2007 (CEST))

Main Page

2007-04-30T08:36:07Z

Cinc: Added section about eCS maintainance

__NOTOC__

Welcome to the Wiki at netlabs.org. You will find a lot of interesting information about OS/2 and [http://www.ecomstation.com eCS] on this page. 
If you are interested in joining the '''community mailinglist''' please have a look [[Mailinglists | here]]!

'''CONTRIBUTE''': Unfortunately, we have to prevent registering new users till we have fixed the spamming-problems on the Wiki, sorry! If you want to '''create an user account''' please send an email with your desired user name to os2info [at] gmx.net and we will generate it for you. Will be fixed ASAP.

== Roadmap ==
Where are we now and where could we go. Open for discussions.

*[[Ideas]] - This is so far a random collection of ideas and stuff we have in our heads and which probably is worth creating a project for.
** [[Ideas#New_PM_Controls|New PM Controls]]

* [[Community]] - Discussions about the netlabs.org community, website, and so on. Complain here :)

* [[The Warp Wishlist]]- The OS/2 Warp WishList is now available on wiki format.

* [[Netlabs bi weekly newsletter]] - ''New'' The latest netlabs.org news

* [[Netlabs News]] - Even later than above

* [[Warpstock Europe Websites]] - Discussion of a concept that aims to provide infrastructure and information to organizers, and information and services to users/visitors.

* [[UniAudio Development]] Universal Audio Driver Development Discussion

* [[WarpVision Development]] WarpVision media player development discussion

*[[Fundraising campaign]] - Projects that could be realized, support your favourite one!

*[[XWorkplace]] - XWorkplace Future Plans and Ideas

*[[Network Connection Manager]] - Design for follow-up to Wireless LAN Monitor

*[[DOSBox Port]] - DOSBox Port for OS/2-eCS Project

*[[Odin]] - ODIN Project todo and Ideas

*[[eSchemes]] - eComStation WPS-based look & feel system

*[[Mr2ice]] - MR/2 ICE is a full featured OS/2 native mail and news client.

*[[MMOS2 Related Projects]] - A list of MMO2 Related sofware developments.

== Shop == [[Image:Netlabs_watch.png|frame|netlabs watch]]
We do have a shop for shirts and more ... [http://shop.netlabs.org shop.netlabs.org]! Prices include a small extra to support netlabs.org's future...

== New Logo and Redesign ==
* [[Redesign]] - The new logo is choosen and a first and hopefully final draft for the new site layout has been created - check it out ;)

== Development ==

NOTE: This section should not be extended anymore. We reloaded the [http://www.edm2.com EDM/2 magazine] and we recommend to put all developer stuff in there. This wiki is a mess at the moment and we will clean that up one day and migrate the stuff that makes sense to EDM/2. Thanks!

This section contains hints and tricks and descriptions of undocumented
stuff. Undocumented means there's no official documentation or the
documentation (for example included on DevCon CDs) isn't available to
the public anymore. But DON'T JUST COPY any documentation you may have into the Wiki. Keep in mind it's copyrighted!

* [[Undocumented stuff]]
* [[Mozilla]] - some stuff regarding building Mozilla on OS/2
* [http://www.edm2.com/index.php/SDL SDL] - some tips & tricks about how to port applications using SDL to OS/2
* [http://www.edm2.com/index.php/How_to_program_for_the_WPS WPS] - how to program for the [http://en.wikipedia.org/wiki/Workplace_Shell WPS]. Note: the german Wikipedia may have more information about the WPS. Go [http://de.wikipedia.org/wiki/Workplace_Shell here].

==OS/2 and eCS resources==
===Drivers===
*Visit http://www.os2warp.be if you want to know if your hardware is supported.
*See a [http://www.ecomstation.it/pido2/home/mircomir/fixpak.php?lang=en driver list] generated from eCSoft/2 database.

===Software===
For software have a look here:

* http://hobbes.nmsu.edu
* http://en.ecomstation.ru/apecs.php
* http://www.ecomstation.it/ecsoft2/
* http://www.unixos2.org - ported *nix tools. A little bit cumbersome to find stuff there but nevertheless worth the effort

===Programs===
How to use specific programs, HowTos, FAQs etc.

MR/2 ICE [[mr2ice]] is a full featured OS/2 native mail and news client.

===eCS Maintainance===
Quite a few things are different in eComStation compared to OS/2. Find tips and tricks for common (and not so common) tasks.

* [[Rebuild your eCS desktop]]

==netlabs.org Servers==
===ToDo's & History===
This is the list of tasks for netlabs.org Webservers and the history of what I (ktk) did
*[[netlabs.org]]

===Mail account===
Some information for those who own a mailbox at netlabs.org
*[[netlabs.org Mailing]]
===Admin Guide===
So far it's more or less just me who does all the work on netlabs.org webpages and this somewhat sucks because like this a lot of stuff depends on my lazyness. The following document explains the tasks necessary to create a new project at netlabs.org, including setting up CVS repositories, creating webpages and so on. I hope that I will find some volunteers one day who help me on doing that.
*[[Admin Guide]]

Netlabs News

2007-04-01T16:38:07Z

Cinc: /* 26. March - 1. April */

[[Category:Netlabs]]
[[Category:Newsletter]]

This page will be used to gather news about netlabs.org and it's projects. 

If you are looking for the bi-weekly newsletter, please go here: [[Netlabs_bi_weekly_newsletter]]
=== 26. March - 1. April ===
* WarpIN 1.0.15
** needs more information
* GenMAC
** donation stuff
* Voyager
** IDL compiler completely rewritten. This will make life way easier when creating enhancements for NOM.
** As usual some bug fixes.

=== Guidelines for mail gathering and bi-weekly processing ===
This is intended to be a procedure on how to create the bi-weekly newsletter, so that multiple people are able to do it, in case others are away.

The news is gathered on a weekly basis.
Sources for news are various. We know the following:
* [irc://irc.netlabs.org/#netlabs #netlabs] channel, just connect and see what comes by
* http://news.netlabs.org/
* various SVN timelines for the projects that are already in SVN (needs to be listed explicitly?)

There is a mail id on netlabs for mailing out the newsletter to various contacts.
The mail id is: news at netlabs dot org
It uses the following IMAP mailserver: mail dot netlabs dot org

For the start of a new newsletter a copy from the previous one can be made and then copy the new news into it, to make life easy :-)
The easiest way to get the text is grabbing it from the webpage in normal view mode.
Check the text a second time, and align it a bit.
Address it with BCC to the following addresses:
* martin at os2world dot com
* stevew at jafar dot hartnell dot edu
* submit at os2voice dot org
* webmaster at ecomstation dot com
* webredactie at os2-gg dot nl
* ktk at netlabs dot org
* j dot van dot der dot heide at hccnet dot nl
* os2info at gmx dot net

Don't forget the subject line with the next number and of it goes.

After the newsletter is sent the 'Netlabs bi-weekly newsletter' webpage has to be updated. (http://wiki.netlabs.org/index.php/Netlabs_bi_weekly_newsletter). Just copy the news on top of the others and add a heading.

Then the draft version of the bi-weekly page can be emptied and the heading for the next week can be added.

That is basicly the process of the bi-weekly newsletter.

Netlabs News

2007-03-12T18:21:19Z

Cinc: /* 5. March - 11. March */ More Voyager news

[[Category:Netlabs]]
[[Category:Newsletter]]

This page will be used to gather news about netlabs.org and it's projects. 

If you are looking for the bi-weekly newsletter, please go here: [[Netlabs_bi_weekly_newsletter]]
=== 5. March - 11. March ===
* Samba for eCS (OS/2)
** there is now also a svn and a trac see: http://svn.netlabs.org/samba
* Updates to The Config.sys Documentation Project
** Finally "The Config.sys Documentation Project" and the "ConfigTool 1.3.0 database" are combined together into a single wiki page on the EDM2. The invitation is open to everybody on the OS/2-eCS community to extend the wiki and add more config.sys commands.
** http://www.edm2.com/index.php/The_Config.sys_Documentation_Project
* Voyager News
** Added patches from winter camp 2007 hacking.
** Basic drag and drop for the desktop. Still working on that.
**Some more methods for the NOM kernel classes.
**Some automatic parameter checking when calling methods implemented.
**Preparation for runtime type information and introspection.
**Improved the Doxygen documentation.
**As usual a bunch of bug fixes... err... code refinements ;).
**Updates to the FAQ regarding license and source code.
**See SVN for more information: http://svn.netlabs.org/v_nom/timeline and http://svn.netlabs.org/v_desktop/timeline

=== 26. February - 4. March ===
* Warpstock Europe Website Discussion
** netlabs.org wiki is used to host a general discussion about concept for a Warpstock Europe website
** User input is welcome!
** See: http://wiki.netlabs.org/index.php/Warpstock_Europe_Websites
* DoxBox Version 0.70
** Now supports playing Audio-CDs in DOSBox
** See: ftp://ftp.netlabs.org/pub/dosbox
** Also of interest to DosBox users: DosBoxFront
*** See: http://hobbes.nmsu.edu/cgi-bin/h-search?key=dosboxfront
* Samba Server 3.0.24 and 3.0.25pre
** Paul Smedley is building Samba Server for netlabs.org
** See: http://smedley.info/os2ports/samba.html
* Uniaud
** We are working on getting the source code buildable
** See: http://svn.netlabs.org/uniaud
* Network Connection Manager - Design for follow-up to Wireless LAN Monitor
** Christian Langanke has started to work on the design for a follow-up to the Wireless LAN Monitor
** See: http://wiki.netlabs.org/index.php/Network_Connection_Manager
* netlabs.org without Adrian for 3 months
** Adrian Gschwend will be on vacation for 3 months :-)
** Read more about it here: http://blog.netlabs.org/?p=9
* FM/2
** Small bug fixes
** See: http://svn.netlabs.org/fm2/timeline
* kLIBC
** Small updates in the source code
** See: http://svn.netlabs.org/libc/timeline
* NewView
** Various small updates
** See: http://svn.netlabs.org/newview/timeline

=== Guidelines for mail gathering and bi-weekly processing ===
This is intended to be a procedure on how to create the bi-weekly newsletter, so that multiple people are able to do it, in case others are away.

The news is gathered on a weekly basis.
Sources for news are various. We know the following:
* [irc://irc.netlabs.org/#netlabs #netlabs] channel, just connect and see what comes by
* http://news.netlabs.org/
* various SVN timelines for the projects that are already in SVN (needs to be listed explicitly?)

There is a mail id on netlabs for mailing out the newsletter to various contacts.
The mail id is: news at netlabs dot org
It uses the following IMAP mailserver: mail dot netlabs dot org

For the start of a new newsletter a copy from the previous one can be made and then copy the new news into it, to make life easy :-)
The easiest way to get the text is grabbing it from the webpage in normal view mode.
Check the text a second time, and align it a bit.
Address it with BCC to the following addresses:
* martin at os2world dot com
* stevew at jafar dot hartnell dot edu
* submit at os2voice dot org
* webmaster at ecomstation dot com
* webredactie at os2-gg dot nl
* ktk at netlabs dot org
* j dot van dot der dot heide at hccnet dot nl
* os2info at gmx dot net

Don't forget the subject line with the next number and of it goes.

After the newsletter is sent the 'Netlabs bi-weekly newsletter' webpage has to be updated. (http://wiki.netlabs.org/index.php/Netlabs_bi_weekly_newsletter). Just copy the news on top of the others and add a heading.

Then the draft version of the bi-weekly page can be emptied and the heading for the next week can be added.

That is basicly the process of the bi-weekly newsletter.

Netlabs News

2007-03-12T18:14:45Z

Cinc: /* 5. March - 11. March */ Added Voyager news

[[Category:Netlabs]]
[[Category:Newsletter]]

This page will be used to gather news about netlabs.org and it's projects. 

If you are looking for the bi-weekly newsletter, please go here: [[Netlabs_bi_weekly_newsletter]]
=== 5. March - 11. March ===
* Samba for eCS (OS/2)
** there is now also a svn and a trac see: http://svn.netlabs.org/samba
* Updates to The Config.sys Documentation Project
** Finally "The Config.sys Documentation Project" and the "ConfigTool 1.3.0 database" are combined together into a single wiki page on the EDM2. The invitation is open to everybody on the OS/2-eCS community to extend the wiki and add more config.sys commands.
** http://www.edm2.com/index.php/The_Config.sys_Documentation_Project
* Voyager News
** Added patches from winter camp 2007 hacking.
** Basic drag and drop for the desktop. Still working on that.
**Some more methods for the NOM kernel classes.
**Some automatic parameter checking when calling methods implemented.
**Improved the Doxygen documentation.
**As usual a bunch of bug fixes... err... code refinements ;).
**Updates to the FAQ regarding license and source code.

=== 26. February - 4. March ===
* Warpstock Europe Website Discussion
** netlabs.org wiki is used to host a general discussion about concept for a Warpstock Europe website
** User input is welcome!
** See: http://wiki.netlabs.org/index.php/Warpstock_Europe_Websites
* DoxBox Version 0.70
** Now supports playing Audio-CDs in DOSBox
** See: ftp://ftp.netlabs.org/pub/dosbox
** Also of interest to DosBox users: DosBoxFront
*** See: http://hobbes.nmsu.edu/cgi-bin/h-search?key=dosboxfront
* Samba Server 3.0.24 and 3.0.25pre
** Paul Smedley is building Samba Server for netlabs.org
** See: http://smedley.info/os2ports/samba.html
* Uniaud
** We are working on getting the source code buildable
** See: http://svn.netlabs.org/uniaud
* Network Connection Manager - Design for follow-up to Wireless LAN Monitor
** Christian Langanke has started to work on the design for a follow-up to the Wireless LAN Monitor
** See: http://wiki.netlabs.org/index.php/Network_Connection_Manager
* netlabs.org without Adrian for 3 months
** Adrian Gschwend will be on vacation for 3 months :-)
** Read more about it here: http://blog.netlabs.org/?p=9
* FM/2
** Small bug fixes
** See: http://svn.netlabs.org/fm2/timeline
* kLIBC
** Small updates in the source code
** See: http://svn.netlabs.org/libc/timeline
* NewView
** Various small updates
** See: http://svn.netlabs.org/newview/timeline

=== Guidelines for mail gathering and bi-weekly processing ===
This is intended to be a procedure on how to create the bi-weekly newsletter, so that multiple people are able to do it, in case others are away.

The news is gathered on a weekly basis.
Sources for news are various. We know the following:
* [irc://irc.netlabs.org/#netlabs #netlabs] channel, just connect and see what comes by
* http://news.netlabs.org/
* various SVN timelines for the projects that are already in SVN (needs to be listed explicitly?)

There is a mail id on netlabs for mailing out the newsletter to various contacts.
The mail id is: news at netlabs dot org
It uses the following IMAP mailserver: mail dot netlabs dot org

For the start of a new newsletter a copy from the previous one can be made and then copy the new news into it, to make life easy :-)
The easiest way to get the text is grabbing it from the webpage in normal view mode.
Check the text a second time, and align it a bit.
Address it with BCC to the following addresses:
* martin at os2world dot com
* stevew at jafar dot hartnell dot edu
* submit at os2voice dot org
* webmaster at ecomstation dot com
* webredactie at os2-gg dot nl
* ktk at netlabs dot org
* j dot van dot der dot heide at hccnet dot nl
* os2info at gmx dot net

Don't forget the subject line with the next number and of it goes.

After the newsletter is sent the 'Netlabs bi-weekly newsletter' webpage has to be updated. (http://wiki.netlabs.org/index.php/Netlabs_bi_weekly_newsletter). Just copy the news on top of the others and add a heading.

Then the draft version of the bi-weekly page can be emptied and the heading for the next week can be added.

That is basicly the process of the bi-weekly newsletter.

Voyager FAQ

2007-03-12T06:30:53Z

Cinc: /* This project is too big, you will fail */

[[Category:Voyager]]
=Voyager Frequently Asked Questions=
Assembled by:
* Adrian Gschwend, aka ''ktk''
* Cinc

Intro: 
''"I know that you're afraid. You're afraid of us. You're afraid of change. I don't know the future. I didn't come here to tell you how this is going to end. I came here to tell you how it's going to begin."''

([http://en.wikiquote.org/wiki/Matrix Source] :)
==General==
===What is Voyager?===
Voyager is the codename for the idea of having a replacement OS/2 on top of modern technology. This idea is the result of around 1.5 years of thinking a '''lot''' about what we can do in the future as current OS/2 and [http://www.ecomstation.com/ eComStation] users.
Note that it's absolutely impossible to convey what we plan to do in a few sentences. I made a speech on it at Warpstock Europe 2005 that, by itself, took 1.5 hours so you get the point :)

Before you continue you should probably consult:

* My presentation at [http://warpstock.net/wse2005/presentations/presentations/ Warpstock Europe 2005]. Get the ALL06 PDF.
* My presentation as DivX ([ftp://ftp.netlabs.org/pub/voyager/wse05_all06-1.avi part 1, current situation (360 MB)],[ftp://ftp.netlabs.org/pub/voyager/wse05_all06-2.avi part 2, outlook & Voyager (366 MB)]) or MP3 (available soon). Use WarpVision or VLC 0.8.4a to play (VLC 0.8.2 won't work).
* The [[Voyager]] page in this Wiki and...
* The [http://dir.gmane.org/gmane.org.netlabs.voyager.devel Voyager mailinglist] at gmane.org

Note that our path is firmly set and long past the point of discussion. As a potential contributor, know from the onset, that acceptance of this path is a must. Take it or leave it, it's our choice and we have our reasons.

===How is this releated to OS/2 and eCS?===
A lot and not much ;) Voyager is basically a re-implementation of a lot of ideas already implemented in the [http://en.wikipedia.org/wiki/Workplace_Shell WPS], the Workplace Shell of OS/2, the multimedia subsystem (like IO procedures) and other areas which make OS/2 unique. As mentioned in the ALL06 PDF, the WPS has still unique concepts that are not implemented in any of the free and well-known desktops like [http://www.gnome.org Gnome] or [http://www.kde.org KDE].
Our goal is to get the "WPS and OS/2 feeling" on top of new, (and existing), open source technologies, in a way that's more or less independent of the kernel used.

One of the main concerns of current OS/2 and eCS users is good backward compatiblity. This is addressed [[Voyager_FAQ#Will_Voyager_support_my_OS.2F2_and_eCS_applications.3F | below]].

===How is this related to MacOS X?===
I talk a lot about the MacOS X in my presentation for various reasons:
* The MacOS X Desktop does have a lot in common with the WPS. We're going to limit our talk to some of the ideas and concepts here. The reasons for the similarity are quite simple: Apple, IBM and HP had a company called [http://en.wikipedia.org/wiki/Taligent Taligent] in the 90s which worked on an object oriented OS. The project was cancelled in 1995, but some of the conceptual ideas survived. Some of these made it into the MacOS X which has also been influenced by [http://en.wikipedia.org/wiki/NeXT_Computer NeXT] which also has some ideas in common with OS/2s WPS.
* MacOS X provides a powerful 2D engine called [http://www.apple.com/macosx/features/quartzextreme/ Quartz Extreme], we think this is the way to go today and Voyager has planned something like this utilizing [http://www.cairographics.org Cairo] as the 2D engine.
* MacOS X provides an X implementation for compatiblity with Unix applications. Netlabs.org will provide something similar with [http://everblue.netlabs.org/ Everblue].
* Apple has already solved quite a few problems that we have now with OS/2 and eCS, (no real multiuser system, no real security concept etc). If you want to know more about our plans to deal with this read the [http://developer.apple.com/documentation/Darwin/Kernel-date.html Kernel Programming Guide] at apple.com. It is always a good idea to learn from others as there's no point in re-inventing the wheel.

===Is Voyager yet another Linux distribution?===
No! Voyager is more than just repackaged linux stuff with a pretty desktop (in fact it is more likely BSD stuff...). We will kill some sacred cows of the *nix camp like X as the graphics foundation or so called choice. You won't have ten editors for your config files, you won't have several window managers but one, you won't have a dozen file systems to choose from but only one or two. You get the picture... '''Since there's no decision for the kernel yet the rumours Voyager would use the linux kernel are just - rumours.'''
Voyager won't require you do recompile your kernel every few weeks or hunt down package dependency when installing new apps by providing a standard set of base libs.

===I heard Voyager uses the Linux kernel===
Read the answer to the previous question! For your convenience I highlighted the sentence which may interest you.

I type this very slowly so every OS/2 zealot going berzerk may understand it: There is no decision about which kernel to use, yet. There's no decision about using the Linux kernel, there's not even a discussion about using the Linux kernel. Whenever somebody is telling you Voyager is using the Linux kernel just ignore that.

===Will netlabs.org stop providing software for OS/2 and eCS now?===
'''Definitely''' not! We will continue to provide essential software for OS/2 the next years. Voyager is in our opinion a great option for the future but we know very well that it will take some time until you can use that as full replacement for what you use now.

The best choice you can do at the moment is to work with eComStation, version 2 of eCS will provide some essential enhancements, many of the ideas are planned for Voyager as well. So one could say that Voyager could become something like eComStation 3.0 once.
===How can I support Voyager?===
There are several possibilities:
* We definitely need skilled developers. We have a wide range of tasks available, please consult the [[Voyager]] page to get an impression and join the [http://dir.gmane.org/gmane.org.netlabs.voyager.devel mailinglist] if you can contribute in some form.
* Motivate skilled coders to help on the project. We think that the idea is very tempting and unique and we already successfully motivated developers outside of the OS/2 and eCS community. This is essential for this project.
* Buy [http://www.ecomstation.com eComStation]. netlabs.org is working closely with SSI and Mensys to provide new software on eCS. Supporting eCS is thus an exellent way to also fund development of Voyager indirectly.
* Buy netlabs.org sponsoring units in the [http://shop.mensys.nl/catalogue/mns_NETLABS.html Mensys] shop, we get 100% of the amount you donate there!
* Present Voyager at your local usergroup. We need to spread the word to motivate people to contribute in any form. For sure you are welcome to show the DivX of the presentation as well.
* Help out with the [[Voyager_Support | documentation]] of Voyager

==Technology==
===Will Voyager support my OS/2 and eCS applications?===
That's a question we can't answer that easy at the moment. For sure it would be nice if we reach that state one day but that depends on quite a lot of things. There are several options:
* use a virtual machine like [http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ XEN] to run OS/2 or eCS in there. Will definitely work but is not a soft migration
* implement the OS/2 base API on an existing Kernel to provide API compatibility. This could even be extended to binary compatibility if we work hard on it.
** [http://www.osfree.org osFree] has something in mind, see [http://www.falvotech.com/projects/os3.php here] as well.
** There is a project at [http://os2linux.sourceforge.net/ Sourceforge] which provides a base OS/2 API already on Linux, written by an IBM employee. This library is not complete yet but provides a base to work on
* implement at least parts of GPI and PM on top of an existing 2D engine like Cairo for PM compatibility. This is a very big task and we are not sure if it is worth doing that but if a group of people volunteers to write that, get in contact with us on the Voyager mailinglist. Note that such a project should definitely integrate well with our idea, otherwise it will not help at all.

Another possiblity might come up with the design of Voyager, at the moment the most likely Glitz backend will be xorg OpenGL drivers, so we would get drivers from the HW-vendors. This opens a new interesting approach for backward compatibility, that would involve the following steps:
* compile Xorg on OS/2 with Innotek LIBC
* get the binary only drivers to work (should work somehow in theory)
* compile Glitz using xorg backend
* recompile GTK2 & all libraries used with Innotek LIBC
* write a GRADD driver that renders using OpenGL, which means it would render into the OpenGL driver of Xorg. Like this it should even be possible to have a windowed PM in Glitz.

The benefit would be that we would also get HW acceleration in the current OS/2 or eCS.

In short one can say that binary compatibility is technically possible up to a certain point at least. One can debate about if this is useful or not.

===Why something new? There is Gnome, KDE...===

If you think KDE, GNOME... fit your needs , that's fine, just move on because you have found a solution for your personal computing needs. The people involved
with Voyager so far don't think desktops other than the WPS which are available today fit their needs. Different people, different preferences.

Or to quote [http://en.wikiquote.org/wiki/Larry_wall Larry Wall]: "There's More Than One Way to Do It".

===Why not X?===

Voyager is a desktop OS. We don't see any need for opening a window on a machine located somewhere in China when your monitor is only 50cm away from you.

And, we don't like X. Period.

(Note: We talk about X in terms of Xlib here, we are currently trying to understand the display driver concept of XFree86/Xorg because we would like to be able to use the OpenGL drivers of it).

===This project is too big, you will fail===

Maybe. But honestly without trying you won't know...

==Development==
===Under what license is Voyager released?===
The source is dual licensed. It is covered by the CDDL and the LGPL.

===Where can I download sourcecode?===
The source can be found in a subversion tree on netlabs.org. Trac provides
a web interface for browsing. Currently you find the following.

* [http://svn.netlabs.org/v_doc Documentation].
* [http://svn.netlabs.org/v_nom Netlabs Object Model].
* [http://svn.netlabs.org/v_desktop Desktop].
* [http://svn.netlabs.org/v_triton Multimedia subsystem].

Information how to download the source will follow.

===Should I still work on OS/2 and eCS applications?===
Sure! OS/2 and eCS will be around for a very long time and Voyager will need quite some time to be mature enough to be usable. But if you intend to support the
Voyager approach any time you should try to code in a portable way. Instead of using the OS/2-API use a portable runtime instead e.g. GLib, NPL or APL. Consider using a cross
platform toolkit for the UI like DynamicWindows, GTK, XUL. Use only standard WPS methods without PM-specific tricks.

If you don't like the Voyager approach anyway, why do you ask in the first place ;)?

===Whats next with Voyager - where are we?===
Ask the oracle :-)

We definitely can't give any assumptions about when we will be ready for a public release. One lesson we definitely learned in the past years with netlabs.org and other software projects is that release plans never work as announced :)

There are some very rough plans at the moment:
* we would like to present some first prototypes of various components at Developer Workshop 2006 in Biel/Bienne. Those components are more or less technology studies for interested developers.
* till Warpstock Europe 2006 we hope to present a basic development setup which makes it easy for other developers to join the project on various platforms. This means you should be able to contribute on OS/2 & eCS, Linux, BSD and probably even MacOS X.

''"Where we go from there is a choice I leave to you."''

Voyager FAQ

2007-03-12T06:28:24Z

Cinc: Added links to subversion.

[[Category:Voyager]]
=Voyager Frequently Asked Questions=
Assembled by:
* Adrian Gschwend, aka ''ktk''
* Cinc

Intro: 
''"I know that you're afraid. You're afraid of us. You're afraid of change. I don't know the future. I didn't come here to tell you how this is going to end. I came here to tell you how it's going to begin."''

([http://en.wikiquote.org/wiki/Matrix Source] :)
==General==
===What is Voyager?===
Voyager is the codename for the idea of having a replacement OS/2 on top of modern technology. This idea is the result of around 1.5 years of thinking a '''lot''' about what we can do in the future as current OS/2 and [http://www.ecomstation.com/ eComStation] users.
Note that it's absolutely impossible to convey what we plan to do in a few sentences. I made a speech on it at Warpstock Europe 2005 that, by itself, took 1.5 hours so you get the point :)

Before you continue you should probably consult:

* My presentation at [http://warpstock.net/wse2005/presentations/presentations/ Warpstock Europe 2005]. Get the ALL06 PDF.
* My presentation as DivX ([ftp://ftp.netlabs.org/pub/voyager/wse05_all06-1.avi part 1, current situation (360 MB)],[ftp://ftp.netlabs.org/pub/voyager/wse05_all06-2.avi part 2, outlook & Voyager (366 MB)]) or MP3 (available soon). Use WarpVision or VLC 0.8.4a to play (VLC 0.8.2 won't work).
* The [[Voyager]] page in this Wiki and...
* The [http://dir.gmane.org/gmane.org.netlabs.voyager.devel Voyager mailinglist] at gmane.org

Note that our path is firmly set and long past the point of discussion. As a potential contributor, know from the onset, that acceptance of this path is a must. Take it or leave it, it's our choice and we have our reasons.

===How is this releated to OS/2 and eCS?===
A lot and not much ;) Voyager is basically a re-implementation of a lot of ideas already implemented in the [http://en.wikipedia.org/wiki/Workplace_Shell WPS], the Workplace Shell of OS/2, the multimedia subsystem (like IO procedures) and other areas which make OS/2 unique. As mentioned in the ALL06 PDF, the WPS has still unique concepts that are not implemented in any of the free and well-known desktops like [http://www.gnome.org Gnome] or [http://www.kde.org KDE].
Our goal is to get the "WPS and OS/2 feeling" on top of new, (and existing), open source technologies, in a way that's more or less independent of the kernel used.

One of the main concerns of current OS/2 and eCS users is good backward compatiblity. This is addressed [[Voyager_FAQ#Will_Voyager_support_my_OS.2F2_and_eCS_applications.3F | below]].

===How is this related to MacOS X?===
I talk a lot about the MacOS X in my presentation for various reasons:
* The MacOS X Desktop does have a lot in common with the WPS. We're going to limit our talk to some of the ideas and concepts here. The reasons for the similarity are quite simple: Apple, IBM and HP had a company called [http://en.wikipedia.org/wiki/Taligent Taligent] in the 90s which worked on an object oriented OS. The project was cancelled in 1995, but some of the conceptual ideas survived. Some of these made it into the MacOS X which has also been influenced by [http://en.wikipedia.org/wiki/NeXT_Computer NeXT] which also has some ideas in common with OS/2s WPS.
* MacOS X provides a powerful 2D engine called [http://www.apple.com/macosx/features/quartzextreme/ Quartz Extreme], we think this is the way to go today and Voyager has planned something like this utilizing [http://www.cairographics.org Cairo] as the 2D engine.
* MacOS X provides an X implementation for compatiblity with Unix applications. Netlabs.org will provide something similar with [http://everblue.netlabs.org/ Everblue].
* Apple has already solved quite a few problems that we have now with OS/2 and eCS, (no real multiuser system, no real security concept etc). If you want to know more about our plans to deal with this read the [http://developer.apple.com/documentation/Darwin/Kernel-date.html Kernel Programming Guide] at apple.com. It is always a good idea to learn from others as there's no point in re-inventing the wheel.

===Is Voyager yet another Linux distribution?===
No! Voyager is more than just repackaged linux stuff with a pretty desktop (in fact it is more likely BSD stuff...). We will kill some sacred cows of the *nix camp like X as the graphics foundation or so called choice. You won't have ten editors for your config files, you won't have several window managers but one, you won't have a dozen file systems to choose from but only one or two. You get the picture... '''Since there's no decision for the kernel yet the rumours Voyager would use the linux kernel are just - rumours.'''
Voyager won't require you do recompile your kernel every few weeks or hunt down package dependency when installing new apps by providing a standard set of base libs.

===I heard Voyager uses the Linux kernel===
Read the answer to the previous question! For your convenience I highlighted the sentence which may interest you.

I type this very slowly so every OS/2 zealot going berzerk may understand it: There is no decision about which kernel to use, yet. There's no decision about using the Linux kernel, there's not even a discussion about using the Linux kernel. Whenever somebody is telling you Voyager is using the Linux kernel just ignore that.

===Will netlabs.org stop providing software for OS/2 and eCS now?===
'''Definitely''' not! We will continue to provide essential software for OS/2 the next years. Voyager is in our opinion a great option for the future but we know very well that it will take some time until you can use that as full replacement for what you use now.

The best choice you can do at the moment is to work with eComStation, version 2 of eCS will provide some essential enhancements, many of the ideas are planned for Voyager as well. So one could say that Voyager could become something like eComStation 3.0 once.
===How can I support Voyager?===
There are several possibilities:
* We definitely need skilled developers. We have a wide range of tasks available, please consult the [[Voyager]] page to get an impression and join the [http://dir.gmane.org/gmane.org.netlabs.voyager.devel mailinglist] if you can contribute in some form.
* Motivate skilled coders to help on the project. We think that the idea is very tempting and unique and we already successfully motivated developers outside of the OS/2 and eCS community. This is essential for this project.
* Buy [http://www.ecomstation.com eComStation]. netlabs.org is working closely with SSI and Mensys to provide new software on eCS. Supporting eCS is thus an exellent way to also fund development of Voyager indirectly.
* Buy netlabs.org sponsoring units in the [http://shop.mensys.nl/catalogue/mns_NETLABS.html Mensys] shop, we get 100% of the amount you donate there!
* Present Voyager at your local usergroup. We need to spread the word to motivate people to contribute in any form. For sure you are welcome to show the DivX of the presentation as well.
* Help out with the [[Voyager_Support | documentation]] of Voyager

==Technology==
===Will Voyager support my OS/2 and eCS applications?===
That's a question we can't answer that easy at the moment. For sure it would be nice if we reach that state one day but that depends on quite a lot of things. There are several options:
* use a virtual machine like [http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ XEN] to run OS/2 or eCS in there. Will definitely work but is not a soft migration
* implement the OS/2 base API on an existing Kernel to provide API compatibility. This could even be extended to binary compatibility if we work hard on it.
** [http://www.osfree.org osFree] has something in mind, see [http://www.falvotech.com/projects/os3.php here] as well.
** There is a project at [http://os2linux.sourceforge.net/ Sourceforge] which provides a base OS/2 API already on Linux, written by an IBM employee. This library is not complete yet but provides a base to work on
* implement at least parts of GPI and PM on top of an existing 2D engine like Cairo for PM compatibility. This is a very big task and we are not sure if it is worth doing that but if a group of people volunteers to write that, get in contact with us on the Voyager mailinglist. Note that such a project should definitely integrate well with our idea, otherwise it will not help at all.

Another possiblity might come up with the design of Voyager, at the moment the most likely Glitz backend will be xorg OpenGL drivers, so we would get drivers from the HW-vendors. This opens a new interesting approach for backward compatibility, that would involve the following steps:
* compile Xorg on OS/2 with Innotek LIBC
* get the binary only drivers to work (should work somehow in theory)
* compile Glitz using xorg backend
* recompile GTK2 & all libraries used with Innotek LIBC
* write a GRADD driver that renders using OpenGL, which means it would render into the OpenGL driver of Xorg. Like this it should even be possible to have a windowed PM in Glitz.

The benefit would be that we would also get HW acceleration in the current OS/2 or eCS.

In short one can say that binary compatibility is technically possible up to a certain point at least. One can debate about if this is useful or not.

===Why something new? There is Gnome, KDE...===

If you think KDE, GNOME... fit your needs , that's fine, just move on because you have found a solution for your personal computing needs. The people involved
with Voyager so far don't think desktops other than the WPS which are available today fit their needs. Different people, different preferences.

Or to quote [http://en.wikiquote.org/wiki/Larry_wall Larry Wall]: "There's More Than One Way to Do It".

===Why not X?===

Voyager is a desktop OS. We don't see any need for opening a window on a machine located somewhere in China when your monitor is only 50cm away from you.

And, we don't like X. Period.

(Note: We talk about X in terms of Xlib here, we are currently trying to understand the display driver concept of XFree86/Xorg because we would like to be able to use the OpenGL drivers of it).

===This project is too big, you will fail===

Maybe. But honestly without trying you wont know...

==Development==
===Under what license is Voyager released?===
The source is dual licensed. It is covered by the CDDL and the LGPL.

===Where can I download sourcecode?===
The source can be found in a subversion tree on netlabs.org. Trac provides
a web interface for browsing. Currently you find the following.

* [http://svn.netlabs.org/v_doc Documentation].
* [http://svn.netlabs.org/v_nom Netlabs Object Model].
* [http://svn.netlabs.org/v_desktop Desktop].
* [http://svn.netlabs.org/v_triton Multimedia subsystem].

Information how to download the source will follow.

===Should I still work on OS/2 and eCS applications?===
Sure! OS/2 and eCS will be around for a very long time and Voyager will need quite some time to be mature enough to be usable. But if you intend to support the
Voyager approach any time you should try to code in a portable way. Instead of using the OS/2-API use a portable runtime instead e.g. GLib, NPL or APL. Consider using a cross
platform toolkit for the UI like DynamicWindows, GTK, XUL. Use only standard WPS methods without PM-specific tricks.

If you don't like the Voyager approach anyway, why do you ask in the first place ;)?

===Whats next with Voyager - where are we?===
Ask the oracle :-)

We definitely can't give any assumptions about when we will be ready for a public release. One lesson we definitely learned in the past years with netlabs.org and other software projects is that release plans never work as announced :)

There are some very rough plans at the moment:
* we would like to present some first prototypes of various components at Developer Workshop 2006 in Biel/Bienne. Those components are more or less technology studies for interested developers.
* till Warpstock Europe 2006 we hope to present a basic development setup which makes it easy for other developers to join the project on various platforms. This means you should be able to contribute on OS/2 & eCS, Linux, BSD and probably even MacOS X.

''"Where we go from there is a choice I leave to you."''

Voyager FAQ

2007-03-12T06:19:43Z

Cinc: Added current license information

[[Category:Voyager]]
=Voyager Frequently Asked Questions=
Assembled by:
* Adrian Gschwend, aka ''ktk''
* Cinc

Intro: 
''"I know that you're afraid. You're afraid of us. You're afraid of change. I don't know the future. I didn't come here to tell you how this is going to end. I came here to tell you how it's going to begin."''

([http://en.wikiquote.org/wiki/Matrix Source] :)
==General==
===What is Voyager?===
Voyager is the codename for the idea of having a replacement OS/2 on top of modern technology. This idea is the result of around 1.5 years of thinking a '''lot''' about what we can do in the future as current OS/2 and [http://www.ecomstation.com/ eComStation] users.
Note that it's absolutely impossible to convey what we plan to do in a few sentences. I made a speech on it at Warpstock Europe 2005 that, by itself, took 1.5 hours so you get the point :)

Before you continue you should probably consult:

* My presentation at [http://warpstock.net/wse2005/presentations/presentations/ Warpstock Europe 2005]. Get the ALL06 PDF.
* My presentation as DivX ([ftp://ftp.netlabs.org/pub/voyager/wse05_all06-1.avi part 1, current situation (360 MB)],[ftp://ftp.netlabs.org/pub/voyager/wse05_all06-2.avi part 2, outlook & Voyager (366 MB)]) or MP3 (available soon). Use WarpVision or VLC 0.8.4a to play (VLC 0.8.2 won't work).
* The [[Voyager]] page in this Wiki and...
* The [http://dir.gmane.org/gmane.org.netlabs.voyager.devel Voyager mailinglist] at gmane.org

Note that our path is firmly set and long past the point of discussion. As a potential contributor, know from the onset, that acceptance of this path is a must. Take it or leave it, it's our choice and we have our reasons.

===How is this releated to OS/2 and eCS?===
A lot and not much ;) Voyager is basically a re-implementation of a lot of ideas already implemented in the [http://en.wikipedia.org/wiki/Workplace_Shell WPS], the Workplace Shell of OS/2, the multimedia subsystem (like IO procedures) and other areas which make OS/2 unique. As mentioned in the ALL06 PDF, the WPS has still unique concepts that are not implemented in any of the free and well-known desktops like [http://www.gnome.org Gnome] or [http://www.kde.org KDE].
Our goal is to get the "WPS and OS/2 feeling" on top of new, (and existing), open source technologies, in a way that's more or less independent of the kernel used.

One of the main concerns of current OS/2 and eCS users is good backward compatiblity. This is addressed [[Voyager_FAQ#Will_Voyager_support_my_OS.2F2_and_eCS_applications.3F | below]].

===How is this related to MacOS X?===
I talk a lot about the MacOS X in my presentation for various reasons:
* The MacOS X Desktop does have a lot in common with the WPS. We're going to limit our talk to some of the ideas and concepts here. The reasons for the similarity are quite simple: Apple, IBM and HP had a company called [http://en.wikipedia.org/wiki/Taligent Taligent] in the 90s which worked on an object oriented OS. The project was cancelled in 1995, but some of the conceptual ideas survived. Some of these made it into the MacOS X which has also been influenced by [http://en.wikipedia.org/wiki/NeXT_Computer NeXT] which also has some ideas in common with OS/2s WPS.
* MacOS X provides a powerful 2D engine called [http://www.apple.com/macosx/features/quartzextreme/ Quartz Extreme], we think this is the way to go today and Voyager has planned something like this utilizing [http://www.cairographics.org Cairo] as the 2D engine.
* MacOS X provides an X implementation for compatiblity with Unix applications. Netlabs.org will provide something similar with [http://everblue.netlabs.org/ Everblue].
* Apple has already solved quite a few problems that we have now with OS/2 and eCS, (no real multiuser system, no real security concept etc). If you want to know more about our plans to deal with this read the [http://developer.apple.com/documentation/Darwin/Kernel-date.html Kernel Programming Guide] at apple.com. It is always a good idea to learn from others as there's no point in re-inventing the wheel.

===Is Voyager yet another Linux distribution?===
No! Voyager is more than just repackaged linux stuff with a pretty desktop (in fact it is more likely BSD stuff...). We will kill some sacred cows of the *nix camp like X as the graphics foundation or so called choice. You won't have ten editors for your config files, you won't have several window managers but one, you won't have a dozen file systems to choose from but only one or two. You get the picture... '''Since there's no decision for the kernel yet the rumours Voyager would use the linux kernel are just - rumours.'''
Voyager won't require you do recompile your kernel every few weeks or hunt down package dependency when installing new apps by providing a standard set of base libs.

===I heard Voyager uses the Linux kernel===
Read the answer to the previous question! For your convenience I highlighted the sentence which may interest you.

I type this very slowly so every OS/2 zealot going berzerk may understand it: There is no decision about which kernel to use, yet. There's no decision about using the Linux kernel, there's not even a discussion about using the Linux kernel. Whenever somebody is telling you Voyager is using the Linux kernel just ignore that.

===Will netlabs.org stop providing software for OS/2 and eCS now?===
'''Definitely''' not! We will continue to provide essential software for OS/2 the next years. Voyager is in our opinion a great option for the future but we know very well that it will take some time until you can use that as full replacement for what you use now.

The best choice you can do at the moment is to work with eComStation, version 2 of eCS will provide some essential enhancements, many of the ideas are planned for Voyager as well. So one could say that Voyager could become something like eComStation 3.0 once.
===How can I support Voyager?===
There are several possibilities:
* We definitely need skilled developers. We have a wide range of tasks available, please consult the [[Voyager]] page to get an impression and join the [http://dir.gmane.org/gmane.org.netlabs.voyager.devel mailinglist] if you can contribute in some form.
* Motivate skilled coders to help on the project. We think that the idea is very tempting and unique and we already successfully motivated developers outside of the OS/2 and eCS community. This is essential for this project.
* Buy [http://www.ecomstation.com eComStation]. netlabs.org is working closely with SSI and Mensys to provide new software on eCS. Supporting eCS is thus an exellent way to also fund development of Voyager indirectly.
* Buy netlabs.org sponsoring units in the [http://shop.mensys.nl/catalogue/mns_NETLABS.html Mensys] shop, we get 100% of the amount you donate there!
* Present Voyager at your local usergroup. We need to spread the word to motivate people to contribute in any form. For sure you are welcome to show the DivX of the presentation as well.
* Help out with the [[Voyager_Support | documentation]] of Voyager

==Technology==
===Will Voyager support my OS/2 and eCS applications?===
That's a question we can't answer that easy at the moment. For sure it would be nice if we reach that state one day but that depends on quite a lot of things. There are several options:
* use a virtual machine like [http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ XEN] to run OS/2 or eCS in there. Will definitely work but is not a soft migration
* implement the OS/2 base API on an existing Kernel to provide API compatibility. This could even be extended to binary compatibility if we work hard on it.
** [http://www.osfree.org osFree] has something in mind, see [http://www.falvotech.com/projects/os3.php here] as well.
** There is a project at [http://os2linux.sourceforge.net/ Sourceforge] which provides a base OS/2 API already on Linux, written by an IBM employee. This library is not complete yet but provides a base to work on
* implement at least parts of GPI and PM on top of an existing 2D engine like Cairo for PM compatibility. This is a very big task and we are not sure if it is worth doing that but if a group of people volunteers to write that, get in contact with us on the Voyager mailinglist. Note that such a project should definitely integrate well with our idea, otherwise it will not help at all.

Another possiblity might come up with the design of Voyager, at the moment the most likely Glitz backend will be xorg OpenGL drivers, so we would get drivers from the HW-vendors. This opens a new interesting approach for backward compatibility, that would involve the following steps:
* compile Xorg on OS/2 with Innotek LIBC
* get the binary only drivers to work (should work somehow in theory)
* compile Glitz using xorg backend
* recompile GTK2 & all libraries used with Innotek LIBC
* write a GRADD driver that renders using OpenGL, which means it would render into the OpenGL driver of Xorg. Like this it should even be possible to have a windowed PM in Glitz.

The benefit would be that we would also get HW acceleration in the current OS/2 or eCS.

In short one can say that binary compatibility is technically possible up to a certain point at least. One can debate about if this is useful or not.

===Why something new? There is Gnome, KDE...===

If you think KDE, GNOME... fit your needs , that's fine, just move on because you have found a solution for your personal computing needs. The people involved
with Voyager so far don't think desktops other than the WPS which are available today fit their needs. Different people, different preferences.

Or to quote [http://en.wikiquote.org/wiki/Larry_wall Larry Wall]: "There's More Than One Way to Do It".

===Why not X?===

Voyager is a desktop OS. We don't see any need for opening a window on a machine located somewhere in China when your monitor is only 50cm away from you.

And, we don't like X. Period.

(Note: We talk about X in terms of Xlib here, we are currently trying to understand the display driver concept of XFree86/Xorg because we would like to be able to use the OpenGL drivers of it).

===This project is too big, you will fail===

Maybe. But honestly without trying you wont know...

==Development==
===Under what license is Voyager released?===
The source is dual licensed. It is covered by the CDDL and the LGPL.

===Where can I download sourcecode?===
Once the license is defined there will be a subversion tree on netlabs.

===Should I still work on OS/2 and eCS applications?===
Sure! OS/2 and eCS will be around for a very long time and Voyager will need quite some time to be mature enough to be usable. But if you intend to support the
Voyager approach any time you should try to code in a portable way. Instead of using the OS/2-API use a portable runtime instead e.g. GLib, NPL or APL. Consider using a cross
platform toolkit for the UI like DynamicWindows, GTK, XUL. Use only standard WPS methods without PM-specific tricks.

If you don't like the Voyager approach anyway, why do you ask in the first place ;)?

===Whats next with Voyager - where are we?===
Ask the oracle :-)

We definitely can't give any assumptions about when we will be ready for a public release. One lesson we definitely learned in the past years with netlabs.org and other software projects is that release plans never work as announced :)

There are some very rough plans at the moment:
* we would like to present some first prototypes of various components at Developer Workshop 2006 in Biel/Bienne. Those components are more or less technology studies for interested developers.
* till Warpstock Europe 2006 we hope to present a basic development setup which makes it easy for other developers to join the project on various platforms. This means you should be able to contribute on OS/2 & eCS, Linux, BSD and probably even MacOS X.

''"Where we go from there is a choice I leave to you."''

Netlabs News

2007-02-12T08:03:03Z

Cinc: /* 5. February - 11. February */ Added Voyager news

[[Category:Netlabs]]
[[Category:Newsletter]]

This page will be used to gather news about netlabs.org and it's projects. 

If you are looking for the bi-weekly newsletter, please go here: [[Netlabs_bi_weekly_newsletter]]
=== 5. February - 11. February ===
* netlabs server
** The webpages at www.netlabs.org are almost on the same level as they used to be from a content point of view
** FTP users still do not work, that needs some more work (LDAP...)
** There will be more enhancements to the server the next two weeks
* FM/2
** Added file associations
** Some new bugs found
** See: http://svn.netlabs.org/fm2/timeline
* kBuild
** AMD64 additions
** Changes in gnumake-header
** See: http://svn.netlabs.org/kbuild/timeline
* kLibC
** Various updates
** See: http://svn.netlabs.org/libc/timeline
* Lucide
** Some bugs reported and a feature request raised
** See: http://svn.netlabs.org/lucide/timeline
* NewView
** Quite some updates
** See: http://svn.netlabs.org/newview/timeline
* Again Updates to the The Config.sys Documentation Project
** Device and Basedev sections were updated
** See: http://www.edm2.com/index.php/The_Config.sys_Documentation_Project/DEVICE_Statements
** See: http://www.edm2.com/index.php/The_Config.sys_Documentation_Project/BASEDEV_Statements
* Voyager
** Quite some Doxygen tags for documentation added to the source
** Fixes, changes, checkins...
** Started work on drag and drop in the desktop
** See: http://svn.netlabs.org/v_nom/timeline, http://svn.netlabs.org/v_desktop/timeline

=== 29. January - 4. February ===
* netlabs server
** Server switch is done
** Many updates to do, but that will go smoothly overtime now
* kBuild
** A load of updates!
** See: http://svn.netlabs.org/kbuild/timeline
* Lucide
** 1.0 GA released
** Various fixes
** updated with Freetype 2.3.1
** See: http://svn.netlabs.org/lucide/timeline
* NewView
** Various command line updates
** See: http://svn.netlabs.org/newview/timeline
* x-ATA
** Added: more Intel ICH chips, more VIA chips, more ATI chips
** Release v1.7.8
** See: http://svn.netlabs.org/xata/timeline
* Updates to the The Config.sys Documentation Project, DEVICE Statements Section
** See: http://www.edm2.com/index.php/The_Config.sys_Documentation_Project/DEVICE_Statements

=== Guidelines for mail gathering and bi-weekly processing ===
This is intended to be a procedure on how to create the bi-weekly newsletter, so that multiple people are able to do it, in case others are away.

The news is gathered on a weekly basis.
Sources for news are various. We know the following:
* [irc://irc.netlabs.org/#netlabs #netlabs] channel, just connect and see what comes by
* http://news.netlabs.org/
* various SVN timelines for the projects that are already in SVN (needs to be listed explicitly?)

There is a mail id on netlabs for mailing out the newsletter to various contacts.
The mail id is: news at netlabs dot org
It uses the following IMAP mailserver: mail dot netlabs dot org

For the start of a new newsletter a copy from the previous one can be made and then copy the new news into it, to make life easy :-)
The easiest way to get the text is grabbing it from the webpage in normal view mode.
Check the text a second time, and align it a bit.
Address it with BCC to the following addresses:
* martin at os2world dot com
* stevew at jafar dot hartnell dot edu
* submit at os2voice dot org
* webmaster at ecomstation dot com
* webredactie at os2-gg dot nl
* ktk at netlabs dot org
* j dot van dot der dot heide at hccnet dot nl
* os2info at gmx dot net

Don't forget the subject line with the next number and of it goes.

After the newsletter is sent the 'Netlabs bi-weekly newsletter' webpage has to be updated. (http://wiki.netlabs.org/index.php/Netlabs_bi_weekly_newsletter). Just copy the news on top of the others and add a heading.

Then the draft version of the bi-weekly page can be emptied and the heading for the next week can be added.

That is basicly the process of the bi-weekly newsletter.

Voyager Discussion

2007-02-07T17:03:14Z

Cinc: /* Technologies to study */

[[Category:Voyager]]
==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]
* [http://www.tango-project.org The Tango Desktop Project] - exists to help create a consistent graphical user interface experience for free and Open Source software.
* [http://www.freesoftwaremagazine.com/articles/accelerated_x?page=0%2C1 XGL v. AIGLX)]
* [http://www.virtualgl.org/ VirtualGL]
* [http://0pointer.de/public/pulseaudio-presentation-lca2007.pdf The PulseAudio Server (PDF)]. A presentation about an audio server for *nix.

===Kernels===
* http://haiku-os.org - OpenBeOS successor
* http://www.ertos.nicta.com.au/software/darbat/ - Darwin on L4

== Design Discussion ==
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? Discussion was moved to a separate page:

[[Ideas for a new Window Manager]]

==== 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). [http://www.ruby-lang.org/en/ Ruby] may be another language worth to be supported.

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]

Voyager FAQ

2007-01-27T12:29:23Z

Cinc: /* Is Voyager yet another Linux distribution? */

[[Category:Voyager]]
=Voyager Frequently Asked Questions=
Assembled by:
* Adrian Gschwend, aka ''ktk''
* Cinc

Intro: 
''"I know that you're afraid. You're afraid of us. You're afraid of change. I don't know the future. I didn't come here to tell you how this is going to end. I came here to tell you how it's going to begin."''

([http://en.wikiquote.org/wiki/Matrix Source] :)
==General==
===What is Voyager?===
Voyager is the codename for the idea of having a replacement OS/2 on top of modern technology. This idea is the result of around 1.5 years of thinking a '''lot''' about what we can do in the future as current OS/2 and [http://www.ecomstation.com/ eComStation] users.
Note that it's absolutely impossible to convey what we plan to do in a few sentences. I made a speech on it at Warpstock Europe 2005 that, by itself, took 1.5 hours so you get the point :)

Before you continue you should probably consult:

* My presentation at [http://warpstock.net/wse2005/presentations/presentations/ Warpstock Europe 2005]. Get the ALL06 PDF.
* My presentation as DivX ([ftp://ftp.netlabs.org/pub/voyager/wse05_all06-1.avi part 1, current situation (360 MB)],[ftp://ftp.netlabs.org/pub/voyager/wse05_all06-2.avi part 2, outlook & Voyager (366 MB)]) or MP3 (available soon). Use WarpVision or VLC 0.8.4a to play (VLC 0.8.2 won't work).
* The [[Voyager]] page in this Wiki and...
* The [http://dir.gmane.org/gmane.org.netlabs.voyager.devel Voyager mailinglist] at gmane.org

Note that our path is firmly set and long past the point of discussion. As a potential contributor, know from the onset, that acceptance of this path is a must. Take it or leave it, it's our choice and we have our reasons.

===How is this releated to OS/2 and eCS?===
A lot and not much ;) Voyager is basically a re-implementation of a lot of ideas already implemented in the [http://en.wikipedia.org/wiki/Workplace_Shell WPS], the Workplace Shell of OS/2, the multimedia subsystem (like IO procedures) and other areas which make OS/2 unique. As mentioned in the ALL06 PDF, the WPS has still unique concepts that are not implemented in any of the free and well-known desktops like [http://www.gnome.org Gnome] or [http://www.kde.org KDE].
Our goal is to get the "WPS and OS/2 feeling" on top of new, (and existing), open source technologies, in a way that's more or less independent of the kernel used.

One of the main concerns of current OS/2 and eCS users is good backward compatiblity. This is addressed [[Voyager_FAQ#Will_Voyager_support_my_OS.2F2_and_eCS_applications.3F | below]].

===How is this related to MacOS X?===
I talk a lot about the MacOS X in my presentation for various reasons:
* The MacOS X Desktop does have a lot in common with the WPS. We're going to limit our talk to some of the ideas and concepts here. The reasons for the similarity are quite simple: Apple, IBM and HP had a company called [http://en.wikipedia.org/wiki/Taligent Taligent] in the 90s which worked on an object oriented OS. The project was cancelled in 1995, but some of the conceptual ideas survived. Some of these made it into the MacOS X which has also been influenced by [http://en.wikipedia.org/wiki/NeXT_Computer NeXT] which also has some ideas in common with OS/2s WPS.
* MacOS X provides a powerful 2D engine called [http://www.apple.com/macosx/features/quartzextreme/ Quartz Extreme], we think this is the way to go today and Voyager has planned something like this utilizing [http://www.cairographics.org Cairo] as the 2D engine.
* MacOS X provides an X implementation for compatiblity with Unix applications. Netlabs.org will provide something similar with [http://everblue.netlabs.org/ Everblue].
* Apple has already solved quite a few problems that we have now with OS/2 and eCS, (no real multiuser system, no real security concept etc). If you want to know more about our plans to deal with this read the [http://developer.apple.com/documentation/Darwin/Kernel-date.html Kernel Programming Guide] at apple.com. It is always a good idea to learn from others as there's no point in re-inventing the wheel.

===Is Voyager yet another Linux distribution?===
No! Voyager is more than just repackaged linux stuff with a pretty desktop (in fact it is more likely BSD stuff...). We will kill some sacred cows of the *nix camp like X as the graphics foundation or so called choice. You won't have ten editors for your config files, you won't have several window managers but one, you won't have a dozen file systems to choose from but only one or two. You get the picture... '''Since there's no decision for the kernel yet the rumours Voyager would use the linux kernel are just - rumours.'''
Voyager won't require you do recompile your kernel every few weeks or hunt down package dependency when installing new apps by providing a standard set of base libs.

===I heard Voyager uses the Linux kernel===
Read the answer to the previous question! For your convenience I highlighted the sentence which may interest you.

I type this very slowly so every OS/2 zealot going berzerk may understand it: There is no decision about which kernel to use, yet. There's no decision about using the Linux kernel, there's not even a discussion about using the Linux kernel. Whenever somebody is telling you Voyager is using the Linux kernel just ignore that.

===Will netlabs.org stop providing software for OS/2 and eCS now?===
'''Definitely''' not! We will continue to provide essential software for OS/2 the next years. Voyager is in our opinion a great option for the future but we know very well that it will take some time until you can use that as full replacement for what you use now.

The best choice you can do at the moment is to work with eComStation, version 2 of eCS will provide some essential enhancements, many of the ideas are planned for Voyager as well. So one could say that Voyager could become something like eComStation 3.0 once.
===How can I support Voyager?===
There are several possiblities:
* We definitely need skilled developers. We have a wide range of tasks available, please consult the [[Voyager]] page to get an impression and join the [http://dir.gmane.org/gmane.org.netlabs.voyager.devel mailinglist] if you can contribute in some form.
* Motivate skilled coders to help on the project. We think that the idea is very tempting and unique and we already successfuly motivated developers outside of the OS/2 and eCS community. This is essential for this project.
* Buy [http://www.ecomstation.com eComStation]. netlabs.org is working closely with SSI and Mensys to provide new software on eCS. Supporting eCS is thus an exellent way to also fund development of Voyager indirectly.
* Buy netlabs.org sponsoring units in the [http://shop.mensys.nl/catalogue/mns_NETLABS.html Mensys] shop, we get 100% of the amount you donate there!
* Present Voyager at your local usergroup. We need to spread the word to motivate people to contribute in any form. For sure you are welcome to show the DivX of the presentation as well.

==Technology==
===Will Voyager support my OS/2 and eCS applications?===
That's a question we can't answer that easy at the moment. For sure it would be nice if we reach that state one day but that depends on quite a lot of things. There are several options:
* use a virtual machine like [http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ XEN] to run OS/2 or eCS in there. Will definitely work but is not a soft migration
* implement the OS/2 base API on an existing Kernel to provide API compatibility. This could even be extended to binary compatibility if we work hard on it.
** [http://www.osfree.org osFree] has something in mind, see [http://www.falvotech.com/projects/os3.php here] as well.
** There is a project at [http://os2linux.sourceforge.net/ Sourceforge] which provides a base OS/2 API already on Linux, written by an IBM employee. This library is not complete yet but provides a base to work on
* implement at least parts of GPI and PM on top of an existing 2D engine like Cairo for PM compatibility. This is a very big task and we are not sure if it is worth doing that but if a group of people volunteers to write that, get in contact with us on the Voyager mailinglist. Note that such a project should definitely integrate well with our idea, otherwise it will not help at all.

Another possiblity might come up with the design of Voyager, at the moment the most likely Glitz backend will be xorg OpenGL drivers, so we would get drivers from the HW-vendors. This opens a new interesting approach for backward compatibility, that would involve the following steps:
* compile Xorg on OS/2 with Innotek LIBC
* get the binary only drivers to work (should work somehow in theory)
* compile Glitz using xorg backend
* recompile GTK2 & all libraries used with Innotek LIBC
* write a GRADD driver that renders using OpenGL, which means it would render into the OpenGL driver of Xorg. Like this it should even be possible to have a windowed PM in Glitz.

The benefit would be that we would also get HW acceleration in the current OS/2 or eCS.

In short one can say that binary compatibility is technically possible up to a certain point at least. One can debate about if this is useful or not.

===Why something new? There is Gnome, KDE...===

If you think KDE, GNOME... fit your needs , that's fine, just move on because you have found a solution for your personal computing needs. The people involved
with Voyager so far don't think desktops other than the WPS which are available today fit their needs. Different people, different preferences.

Or to quote [http://en.wikiquote.org/wiki/Larry_wall Larry Wall]: "There's More Than One Way to Do It".

===Why not X?===

Voyager is a desktop OS. We don't see any need for opening a window on a machine located somewhere in China when your monitor is only 50cm away from you.

And, we don't like X. Period.

(Note: We talk about X in terms of Xlib here, we are currently trying to understand the display driver concept of XFree86/Xorg because we would like to be able to use the OpenGL drivers of it).

===This project is too big, you will fail===

Maybe. But honestly without trying you wont know...

==Development==
===Under what license will Voyager be released?===
The license will be liberal so using Voyager will not be restricted. On the other hand it will assure that Voyager remains open source. It will not be GPL.

===Where can I download sourcecode?===
Once the license is defined there will be a subversion tree on netlabs.

===Should I still work on OS/2 and eCS applications?===
Sure! OS/2 and eCS will be around for a very long time and Voyager will need quite some time to be mature enough to be usable. But if you intend to support the
Voyager approach any time you should try to code in a portable way. Instead of using the OS/2-API use a portable runtime instead e.g. GLib, NPL or APL. Consider using a cross
platform toolkit for the UI like DynamicWindows, GTK, XUL. Use only standard WPS methods without PM-specific tricks.

If you don't like the Voyager approach anyway, why do you ask in the first place ;)?

===Whats next with Voyager - where are we?===
Ask the oracle :-)

We definitely can't give any assumptions about when we will be ready for a public release. One lesson we definitely learned in the past years with netlabs.org and other software projects is that release plans never work as announced :)

There are some very rough plans at the moment:
* we would like to present some first prototypes of various components at Developer Workshop 2006 in Biel/Bienne. Those components are more or less technology studies for interested developers.
* till Warpstock Europe 2006 we hope to present a basic development setup which makes it easy for other developers to join the project on various platforms. This means you should be able to contribute on OS/2 & eCS, Linux, BSD and probably even MacOS X.

''"Where we go from there is a choice I leave to you."''

Voyager FAQ

2007-01-27T12:27:25Z

Cinc: /* I heard Voyager uses the Linux kernel */

[[Category:Voyager]]
=Voyager Frequently Asked Questions=
Assembled by:
* Adrian Gschwend, aka ''ktk''
* Cinc

Intro: 
''"I know that you're afraid. You're afraid of us. You're afraid of change. I don't know the future. I didn't come here to tell you how this is going to end. I came here to tell you how it's going to begin."''

([http://en.wikiquote.org/wiki/Matrix Source] :)
==General==
===What is Voyager?===
Voyager is the codename for the idea of having a replacement OS/2 on top of modern technology. This idea is the result of around 1.5 years of thinking a '''lot''' about what we can do in the future as current OS/2 and [http://www.ecomstation.com/ eComStation] users.
Note that it's absolutely impossible to convey what we plan to do in a few sentences. I made a speech on it at Warpstock Europe 2005 that, by itself, took 1.5 hours so you get the point :)

Before you continue you should probably consult:

* My presentation at [http://warpstock.net/wse2005/presentations/presentations/ Warpstock Europe 2005]. Get the ALL06 PDF.
* My presentation as DivX ([ftp://ftp.netlabs.org/pub/voyager/wse05_all06-1.avi part 1, current situation (360 MB)],[ftp://ftp.netlabs.org/pub/voyager/wse05_all06-2.avi part 2, outlook & Voyager (366 MB)]) or MP3 (available soon). Use WarpVision or VLC 0.8.4a to play (VLC 0.8.2 won't work).
* The [[Voyager]] page in this Wiki and...
* The [http://dir.gmane.org/gmane.org.netlabs.voyager.devel Voyager mailinglist] at gmane.org

Note that our path is firmly set and long past the point of discussion. As a potential contributor, know from the onset, that acceptance of this path is a must. Take it or leave it, it's our choice and we have our reasons.

===How is this releated to OS/2 and eCS?===
A lot and not much ;) Voyager is basically a re-implementation of a lot of ideas already implemented in the [http://en.wikipedia.org/wiki/Workplace_Shell WPS], the Workplace Shell of OS/2, the multimedia subsystem (like IO procedures) and other areas which make OS/2 unique. As mentioned in the ALL06 PDF, the WPS has still unique concepts that are not implemented in any of the free and well-known desktops like [http://www.gnome.org Gnome] or [http://www.kde.org KDE].
Our goal is to get the "WPS and OS/2 feeling" on top of new, (and existing), open source technologies, in a way that's more or less independent of the kernel used.

One of the main concerns of current OS/2 and eCS users is good backward compatiblity. This is addressed [[Voyager_FAQ#Will_Voyager_support_my_OS.2F2_and_eCS_applications.3F | below]].

===How is this related to MacOS X?===
I talk a lot about the MacOS X in my presentation for various reasons:
* The MacOS X Desktop does have a lot in common with the WPS. We're going to limit our talk to some of the ideas and concepts here. The reasons for the similarity are quite simple: Apple, IBM and HP had a company called [http://en.wikipedia.org/wiki/Taligent Taligent] in the 90s which worked on an object oriented OS. The project was cancelled in 1995, but some of the conceptual ideas survived. Some of these made it into the MacOS X which has also been influenced by [http://en.wikipedia.org/wiki/NeXT_Computer NeXT] which also has some ideas in common with OS/2s WPS.
* MacOS X provides a powerful 2D engine called [http://www.apple.com/macosx/features/quartzextreme/ Quartz Extreme], we think this is the way to go today and Voyager has planned something like this utilizing [http://www.cairographics.org Cairo] as the 2D engine.
* MacOS X provides an X implementation for compatiblity with Unix applications. Netlabs.org will provide something similar with [http://everblue.netlabs.org/ Everblue].
* Apple has already solved quite a few problems that we have now with OS/2 and eCS, (no real multiuser system, no real security concept etc). If you want to know more about our plans to deal with this read the [http://developer.apple.com/documentation/Darwin/Kernel-date.html Kernel Programming Guide] at apple.com. It is always a good idea to learn from others as there's no point in re-inventing the wheel.

===Is Voyager yet another Linux distribution?===
No! Voyager is more than just repackaged linux stuff with a pretty desktop. We will kill some sacred cows of the linux camp like X as the graphics foundation or so called choice. You won't have ten editors for your config files, you won't have several window managers but one, you won't have a dozen file systems to choose from but only one or two. You get the picture... '''Since there's no decision for the kernel yet the rumours Voyager would use the linux kernel are just - rumours.'''
Voyager won't require you do recompile your kernel every few weeks or hunt down package dependency when installing new apps by providing a standard set of base libs.

===I heard Voyager uses the Linux kernel===
Read the answer to the previous question! For your convenience I highlighted the sentence which may interest you.

I type this very slowly so every OS/2 zealot going berzerk may understand it: There is no decision about which kernel to use, yet. There's no decision about using the Linux kernel, there's not even a discussion about using the Linux kernel. Whenever somebody is telling you Voyager is using the Linux kernel just ignore that.

===Will netlabs.org stop providing software for OS/2 and eCS now?===
'''Definitely''' not! We will continue to provide essential software for OS/2 the next years. Voyager is in our opinion a great option for the future but we know very well that it will take some time until you can use that as full replacement for what you use now.

The best choice you can do at the moment is to work with eComStation, version 2 of eCS will provide some essential enhancements, many of the ideas are planned for Voyager as well. So one could say that Voyager could become something like eComStation 3.0 once.
===How can I support Voyager?===
There are several possiblities:
* We definitely need skilled developers. We have a wide range of tasks available, please consult the [[Voyager]] page to get an impression and join the [http://dir.gmane.org/gmane.org.netlabs.voyager.devel mailinglist] if you can contribute in some form.
* Motivate skilled coders to help on the project. We think that the idea is very tempting and unique and we already successfuly motivated developers outside of the OS/2 and eCS community. This is essential for this project.
* Buy [http://www.ecomstation.com eComStation]. netlabs.org is working closely with SSI and Mensys to provide new software on eCS. Supporting eCS is thus an exellent way to also fund development of Voyager indirectly.
* Buy netlabs.org sponsoring units in the [http://shop.mensys.nl/catalogue/mns_NETLABS.html Mensys] shop, we get 100% of the amount you donate there!
* Present Voyager at your local usergroup. We need to spread the word to motivate people to contribute in any form. For sure you are welcome to show the DivX of the presentation as well.

==Technology==
===Will Voyager support my OS/2 and eCS applications?===
That's a question we can't answer that easy at the moment. For sure it would be nice if we reach that state one day but that depends on quite a lot of things. There are several options:
* use a virtual machine like [http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ XEN] to run OS/2 or eCS in there. Will definitely work but is not a soft migration
* implement the OS/2 base API on an existing Kernel to provide API compatibility. This could even be extended to binary compatibility if we work hard on it.
** [http://www.osfree.org osFree] has something in mind, see [http://www.falvotech.com/projects/os3.php here] as well.
** There is a project at [http://os2linux.sourceforge.net/ Sourceforge] which provides a base OS/2 API already on Linux, written by an IBM employee. This library is not complete yet but provides a base to work on
* implement at least parts of GPI and PM on top of an existing 2D engine like Cairo for PM compatibility. This is a very big task and we are not sure if it is worth doing that but if a group of people volunteers to write that, get in contact with us on the Voyager mailinglist. Note that such a project should definitely integrate well with our idea, otherwise it will not help at all.

Another possiblity might come up with the design of Voyager, at the moment the most likely Glitz backend will be xorg OpenGL drivers, so we would get drivers from the HW-vendors. This opens a new interesting approach for backward compatibility, that would involve the following steps:
* compile Xorg on OS/2 with Innotek LIBC
* get the binary only drivers to work (should work somehow in theory)
* compile Glitz using xorg backend
* recompile GTK2 & all libraries used with Innotek LIBC
* write a GRADD driver that renders using OpenGL, which means it would render into the OpenGL driver of Xorg. Like this it should even be possible to have a windowed PM in Glitz.

The benefit would be that we would also get HW acceleration in the current OS/2 or eCS.

In short one can say that binary compatibility is technically possible up to a certain point at least. One can debate about if this is useful or not.

===Why something new? There is Gnome, KDE...===

If you think KDE, GNOME... fit your needs , that's fine, just move on because you have found a solution for your personal computing needs. The people involved
with Voyager so far don't think desktops other than the WPS which are available today fit their needs. Different people, different preferences.

Or to quote [http://en.wikiquote.org/wiki/Larry_wall Larry Wall]: "There's More Than One Way to Do It".

===Why not X?===

Voyager is a desktop OS. We don't see any need for opening a window on a machine located somewhere in China when your monitor is only 50cm away from you.

And, we don't like X. Period.

(Note: We talk about X in terms of Xlib here, we are currently trying to understand the display driver concept of XFree86/Xorg because we would like to be able to use the OpenGL drivers of it).

===This project is too big, you will fail===

Maybe. But honestly without trying you wont know...

==Development==
===Under what license will Voyager be released?===
The license will be liberal so using Voyager will not be restricted. On the other hand it will assure that Voyager remains open source. It will not be GPL.

===Where can I download sourcecode?===
Once the license is defined there will be a subversion tree on netlabs.

===Should I still work on OS/2 and eCS applications?===
Sure! OS/2 and eCS will be around for a very long time and Voyager will need quite some time to be mature enough to be usable. But if you intend to support the
Voyager approach any time you should try to code in a portable way. Instead of using the OS/2-API use a portable runtime instead e.g. GLib, NPL or APL. Consider using a cross
platform toolkit for the UI like DynamicWindows, GTK, XUL. Use only standard WPS methods without PM-specific tricks.

If you don't like the Voyager approach anyway, why do you ask in the first place ;)?

===Whats next with Voyager - where are we?===
Ask the oracle :-)

We definitely can't give any assumptions about when we will be ready for a public release. One lesson we definitely learned in the past years with netlabs.org and other software projects is that release plans never work as announced :)

There are some very rough plans at the moment:
* we would like to present some first prototypes of various components at Developer Workshop 2006 in Biel/Bienne. Those components are more or less technology studies for interested developers.
* till Warpstock Europe 2006 we hope to present a basic development setup which makes it easy for other developers to join the project on various platforms. This means you should be able to contribute on OS/2 & eCS, Linux, BSD and probably even MacOS X.

''"Where we go from there is a choice I leave to you."''

Netlabs News

2007-01-14T13:19:10Z

Cinc: /* 1. January - 7 January */ Changed screenshot URL

[[Category:Netlabs]]
[[Category:Newsletter]]

This page will be used to gather news about netlabs.org and it's projects. 

If you are looking for the bi-weekly newsletter, please go here: [[Netlabs_bi_weekly_newsletter]]
=== 8. January - 14 January ===
* netlabs.org server news
** Server configuration is going well
** Initial SVN tests performed succesfully (among other things)
* Developer Workshop 2007
** Is going to be held in the Netherlands on June 23 & 24.
** Location: Cultural Center Griffioen in Amsterdam
** See: http://www.vu.nl/Organisatie/index.cfm/home_subsection.cfm/subsectionid/9DB86C70-F9C7-4704-8C9D9ED46EEDB063
** Watch the wiki page for upcoming news: http://wiki.netlabs.org/index.php/Developers_Workshop_2007
* New QT3 Applications
** KDIFF
** QDVDAuthor
** needs more info
* XWorkPlace Version 1.0.7
** Fixed: Window List size/position (Bug 903)
** Fixed: Bug 902 and 910
** Added: ADDWIDGETS and DELETEWIDGETS setup strings to the XCenter (Bug 906)
** Bug Tracker: http://xtracker.netlabs.org/
** Download: http://hobbes.nmsu.edu/cgi-bin/h-search?key=XWP-1-0-7
* Some PathRewrite New
** needs content
** Temp Download: ftp://ftp.netlabs.org/incoming/ecsprw.wpi
* Canabis
** EXPAT/77 added to build instructions
** XML support added
** Several improvements
** See: http://svn.netlabs.org/canabis/timeline
* FM/2
** Ticket 60 and 61 fixed
** See: http://svn.netlabs.org/fm2/timeline
* kBuild
** Some fixes
** See: http://svn.netlabs.org/kbuild/timeline
* kLIBC
** Some fixes (I/O bugs, signals)
** See: http://svn.netlabs.org/libc/timeline
* NewView
** Various updates
** See: http://svn.netlabs.org/newview/timeline
* UniAud
** ???
* WarpVision
** ???

=== 1. January - 7 January ===
* UniAudio
** latest ALSA tree updates
* WarpVision
** Fixed OGG/MKV/MOV embedded subtitles
** DVD Menu experiments & investigations
* kBuild
** Various small updates
** See: http://svn.netlabs.org/kbuild/timeline
* kLIBC
** Fixed build breaks
** See: http://svn.netlabs.org/libc/timeline
* Lucide Updates
** Unicode clipboard fixes
** Work on loading password protected PDFs
** http://svn.netlabs.org/lucide/timeline
* NewView Updates
** Various small updates
** See: http://svn.netlabs.org/newview/timeline
* Voyager
** Quite a few code checkins in the NOM and desktop trees. New [ftp://ftp.netlabs.org/pub/misc/cinc/voyager/voyager_14_01_2007.jpg screenshot].
** Updates to the [ftp://ftp.netlabs.org/pub/misc/cinc/voyager/Object-design.pdf Object Design document] (PDF)

=== Guidelines for mail gathering and bi-weekly processing ===
This is intended to be a procedure on how to create the bi-weekly newsletter, so that multiple people are able to do it, in case others are away.

The news is gathered on a weekly basis.
Sources for news are various. We know the following:
* [irc://irc.netlabs.org/#netlabs #netlabs] channel, just connect and see what comes by
* http://news.netlabs.org/
* various SVN timelines for the projects that are already in SVN (needs to be listed explicitly?)

There is a mail id on netlabs for mailing out the newsletter to various contacts.
The mail id is: news at netlabs dot org
It uses the following IMAP mailserver: mail dot netlabs dot org

For the start of a new newsletter a copy from the previous one can be made and then copy the new news into it, to make life easy :-)
The easiest way to get the text is grabbing it from the webpage in normal view mode.
Check the text a second time, and align it a bit.
Address it with BCC to the following addresses:
* martin at os2world dot com
* stevew at jafar dot hartnell dot edu
* submit at os2voice dot org
* webmaster at ecomstation dot com
* webredactie at os2-gg dot nl
* ktk at netlabs dot org
* j dot van dot der dot heide at hccnet dot nl
* os2info at gmx dot net

Don't forget the subject line with the next number and of it goes.

After the newsletter is sent the 'Netlabs bi-weekly newsletter' webpage has to be updated. (http://wiki.netlabs.org/index.php/Netlabs_bi_weekly_newsletter). Just copy the news on top of the others and add a heading.

Then the draft version of the bi-weekly page can be emptied and the heading for the next week can be added.

That is basicly the process of the bi-weekly newsletter.

Netlabs News

2007-01-13T00:22:36Z

Cinc: /* 1. January - 7 January */ Voyager screenshot

[[Category:Netlabs]]
[[Category:Newsletter]]

This page will be used to gather news about netlabs.org and it's projects. 

If you are looking for the bi-weekly newsletter, please go here: [[Netlabs_bi_weekly_newsletter]]
=== 8. January - 14 January ===
* New QT3 Applications
** KDIFF
** QDVDAuthor
** needs more info
* XWorkPlace Version 1.0.7
** needs content
* Some PathRewrite New
** needs content
** Temp Download: ftp://ftp.netlabs.org/incoming/ecsprw.wpi

=== 1. January - 7 January ===
* netlabs.org server news
* UniAudio
** latest ALSA tree updates
* WarpVision
** Fixed OGG/MKV/MOV embedded subtitles
** DVD Menu experiments & investigations
* kBuild
** Various small updates
** See: http://svn.netlabs.org/kbuild/timeline
* kLIBC
** Fixed build breaks
** See: http://svn.netlabs.org/libc/timeline
* Lucide Updates
** Unicode clipboard fixes
** Work on loading password protected PDFs
** http://svn.netlabs.org/lucide/timeline
* NewView Updates
** Various small updates
** See: http://svn.netlabs.org/newview/timeline
* Voyager
** Quite a few code checkins in the NOM and desktop trees. New [ftp://ftp.netlabs.org/pub/misc/cinc/voyager/voyager_12_01_2007.jpg screenshot].
** Updates to the [ftp://ftp.netlabs.org/pub/misc/cinc/voyager/Object-design.pdf Object Design document] (PDF)

=== Guidelines for mail gathering and bi-weekly processing ===
This is intended to be a procedure on how to create the bi-weekly newsletter, so that multiple people are able to do it, in case others are away.

The news is gathered on a weekly basis.
Sources for news are various. We know the following:
* [irc://irc.netlabs.org/#netlabs #netlabs] channel, just connect and see what comes by
* http://news.netlabs.org/
* various SVN timelines for the projects that are already in SVN (needs to be listed explicitly?)

There is a mail id on netlabs for mailing out the newsletter to various contacts.
The mail id is: news at netlabs dot org
It uses the following IMAP mailserver: mail dot netlabs dot org

For the start of a new newsletter a copy from the previous one can be made and then copy the new news into it, to make life easy :-)
The easiest way to get the text is grabbing it from the webpage in normal view mode.
Check the text a second time, and align it a bit.
Address it with BCC to the following addresses:
* martin at os2world dot com
* stevew at jafar dot hartnell dot edu
* submit at os2voice dot org
* webmaster at ecomstation dot com
* webredactie at os2-gg dot nl
* ktk at netlabs dot org
* j dot van dot der dot heide at hccnet dot nl
* os2info at gmx dot net

Don't forget the subject line with the next number and of it goes.

After the newsletter is sent the 'Netlabs bi-weekly newsletter' webpage has to be updated. (http://wiki.netlabs.org/index.php/Netlabs_bi_weekly_newsletter). Just copy the news on top of the others and add a heading.

Then the draft version of the bi-weekly page can be emptied and the heading for the next week can be added.

That is basicly the process of the bi-weekly newsletter.

Netlabs News

2007-01-06T19:45:07Z

Cinc: Voyager info

[[Category:Netlabs]]
[[Category:Newsletter]]

This page will be used to gather news about netlabs.org and it's projects. 

If you are looking for the bi-weekly newsletter, please go here: [[Netlabs_bi_weekly_newsletter]]
=== 1. January - 7 January ===
* netlabs.org server news
* UniAudio
* WarpVision
* kBuild
** Various small updates
** See: http://svn.netlabs.org/kbuild/timeline
* kLIBC
** Fixed build breaks
** See: http://svn.netlabs.org/libc/timeline
* Lucide Updates
** Unicode clipboard fixes
** Work on loading password protected PDFs
** http://svn.netlabs.org/lucide/timeline
* NewView Updates
** Various small updates
** See: http://svn.netlabs.org/newview/timeline
* Voyager
** Quite a few code checkins in the NOM and desktop trees
** Updates to the [ftp://ftp.netlabs.org/pub/misc/cinc/voyager/Object-design.pdf Object Design document] (PDF)

=== Guidelines for mail gathering and bi-weekly processing ===
This is intended to be a procedure on how to create the bi-weekly newsletter, so that multiple people are able to do it, in case others are away.

The news is gathered on a weekly basis.
Sources for news are various. We know the following:
* [irc://irc.netlabs.org/#netlabs #netlabs] channel, just connect and see what comes by
* http://news.netlabs.org/
* various SVN timelines for the projects that are already in SVN (needs to be listed explicitly?)

There is a mail id on netlabs for mailing out the newsletter to various contacts.
The mail id is: news at netlabs dot org
It uses the following IMAP mailserver: mail dot netlabs dot org

For the start of a new newsletter a copy from the previous one can be made and then copy the new news into it, to make life easy :-)
The easiest way to get the text is grabbing it from the webpage in normal view mode.
Check the text a second time, and align it a bit.
Address it with BCC to the following addresses:
* martin at os2world dot com
* stevew at jafar dot hartnell dot edu
* submit at os2voice dot org
* webmaster at ecomstation dot com
* webredactie at os2-gg dot nl
* ktk at netlabs dot org
* j dot van dot der dot heide at hccnet dot nl
* os2info at gmx dot net

Don't forget the subject line with the next number and of it goes.

After the newsletter is sent the 'Netlabs bi-weekly newsletter' webpage has to be updated. (http://wiki.netlabs.org/index.php/Netlabs_bi_weekly_newsletter). Just copy the news on top of the others and add a heading.

Then the draft version of the bi-weekly page can be emptied and the heading for the next week can be added.

That is basicly the process of the bi-weekly newsletter.

Voyager

2006-12-29T12:37:53Z

Cinc: Tidied the page by moving the whole contents away :P

[[Category:Voyager]]

The old contents of this page moved [[Voyager_Discussion|here]]. That page contains the ideas which evolved from quite some discussions.

This page will cover the actual implementation of Voyager after the cornerstones are set now.

Voyager Discussion

2006-12-29T12:32:21Z

Cinc: New page with the Voyager discussions and ideas so far. Moved from Voager page here.

[[Category:Voyager]]
==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]
* [http://www.tango-project.org The Tango Desktop Project] - exists to help create a consistent graphical user interface experience for free and Open Source software.
* [http://www.freesoftwaremagazine.com/articles/accelerated_x?page=0%2C1 XGL v. AIGLX)]
* [http://www.virtualgl.org/ VirtualGL]

===Kernels===
* http://haiku-os.org - OpenBeOS successor
* http://www.ertos.nicta.com.au/software/darbat/ - Darwin on L4

== Design Discussion ==
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? Discussion was moved to a separate page:

[[Ideas for a new Window Manager]]

==== 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). [http://www.ruby-lang.org/en/ Ruby] may be another language worth to be supported.

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]

Desktop

2006-12-29T08:30:57Z

Cinc: /* Status */

== Introduction ==

The desktop should resemble the WPS experience. There won't be binary compatibility (if you want that, feel free to add it) but source compatibilty is top priority.

Some cornerstones:

* OO design
* Extendable by just adding new classes like the WPS (subclassing without recompiling)
* Class replacing
* No recompilation for new features
* Drag and drop of almost everything (icons, colors, fonts etc.)
* Scriptable by REXX
* Maybe REXX-classes (classes written in REXX)
* DSOM functionality (not at the beginning but development shouldn't prevent it)
* ...

'''Note:''' Please don't discuss items on this page. Use the discussion page or the [[Voyager]] page.

== Design decisions ==

At this point in time:

* The graphical toolkit is [http://www.gtk.org GTK]
* [http://www.gtk.org GLib] is used as the portability layer
* An object model similar to SOM is the foundation (NOM: Netlabs Object Model)
* GTK will be wrapped into objects to make development easier
* Compiler is gcc 3.3.x (may change later. Compilation on OS/2 should always be possible)
* [http://www.freedesktop.org/wiki/Software_2fdbus D-BUS] will be the foundation for interprocess communication
* Make is gmake

If you have compelling arguments against these decisions feel free to point to a better solution. But be aware that just saying "I don't like it" won't make serious points. Some hundred/thousand/millions lines of code will likely change our minds faster.

== Status ==

(Last change 29.Dec2006)

* The prototype code ([ftp://ftp.netlabs.org/pub/voyager/desktop/images/prototype.jpg screenshot]) is migrated to GTK 2.6.x. See [ftp://ftp.netlabs.org/pub/misc/cinc/vdesktop-gtk.jpg screenshot 1] and [ftp://ftp.netlabs.org/pub/misc/cinc/notebook.jpg screenshot 2]. It's currently running on X only and can be considered a proof of concept. Work is in progress to add more classes and methods and wrap the GTK API into objects.

* Some historical status information can be found on [ftp://ftp.netlabs.org/pub/voyager/desktop/documentation.htm this page].

* The orbit IDL compiler is ported to OS/2 and is the foundation for the Voyager IDL compiler.

* h-file emitter of the Voyager IDL compiler is done

* c-file emitter of the IDL compiler is done

* ih-file emitter is done

* Completely based on gcc. No dependencies on closed code.

== To do ==

The following list is only the most important stuff.

* <strike>Write an IDL compiler</strike>
* <strike>Migrate header files to our own (using IBM stuff atm)</strike>
* Enable class replacing
* Make it distributed (DSOM)
* ...

Desktop

2006-12-29T08:29:45Z

Cinc: Updates

== Introduction ==

The desktop should resemble the WPS experience. There won't be binary compatibility (if you want that, feel free to add it) but source compatibilty is top priority.

Some cornerstones:

* OO design
* Extendable by just adding new classes like the WPS (subclassing without recompiling)
* Class replacing
* No recompilation for new features
* Drag and drop of almost everything (icons, colors, fonts etc.)
* Scriptable by REXX
* Maybe REXX-classes (classes written in REXX)
* DSOM functionality (not at the beginning but development shouldn't prevent it)
* ...

'''Note:''' Please don't discuss items on this page. Use the discussion page or the [[Voyager]] page.

== Design decisions ==

At this point in time:

* The graphical toolkit is [http://www.gtk.org GTK]
* [http://www.gtk.org GLib] is used as the portability layer
* An object model similar to SOM is the foundation (NOM: Netlabs Object Model)
* GTK will be wrapped into objects to make development easier
* Compiler is gcc 3.3.x (may change later. Compilation on OS/2 should always be possible)
* [http://www.freedesktop.org/wiki/Software_2fdbus D-BUS] will be the foundation for interprocess communication
* Make is gmake

If you have compelling arguments against these decisions feel free to point to a better solution. But be aware that just saying "I don't like it" won't make serious points. Some hundred/thousand/millions lines of code will likely change our minds faster.

== Status ==

(Last change 29.Dec2006)

* The prototype code ([ftp://ftp.netlabs.org/pub/voyager/desktop/images/prototype.jpg screenshot]) is migrated to GTK 2.6.x. See [ftp://ftp.netlabs.org/pub/misc/cinc/vdesktop-gtk.jpg screenshot 1] and [ftp://ftp.netlabs.org/pub/misc/cinc/notebook.jpg screenshot 2]. It's currently running on X only and can be considered a proof of concept. Work is in progress to add more classes and methods and wrap the GTK API into objects.

* Some historical status information can be found on [ftp://ftp.netlabs.org/pub/voyager/desktop/documentation.htm this page].

* The orbit IDL compiler is ported to OS/2 and is the foundation for the Voyager IDL compiler.

* h-file emitter of the Voyager IDL compiler is done

* c-file emitter of the IDL compiler is done

* ih-file emitter is done

== To do ==

The following list is only the most important stuff.

* <strike>Write an IDL compiler</strike>
* <strike>Migrate header files to our own (using IBM stuff atm)</strike>
* Enable class replacing
* Make it distributed (DSOM)
* ...

Desktop

2006-12-29T08:26:12Z

Cinc: Status updates

== Introduction ==

The desktop should resemble the WPS experience. There won't be binary compatibility (if you want that, feel free to add it) but source compatibilty is top priority.

Some cornerstones:

* OO design
* Extendable by just adding new classes like the WPS (subclassing without recompiling)
* Class replacing
* No recompilation for new features
* Drag and drop of almost everything (icons, colors, fonts etc.)
* Scriptable by REXX
* Maybe REXX-classes (classes written in REXX)
* DSOM functionality (not at the beginning but development shouldn't prevent it)
* ...

'''Note:''' Please don't discuss items on this page. Use the discussion page or the [[Voyager]] page.

== Design decisions ==

At this point in time:

* The graphical toolkit is [http://www.gtk.org GTK]
* [http://www.gtk.org GLib] is used as the portability layer
* An object model similar to SOM is the foundation (NOM: Netlabs Object Model)
* GTK will be wrapped into objects to make development easier
* Compiler is gcc 3.3.x (may change later. Compilation on OS/2 should always be possible)
* [http://www.freedesktop.org/wiki/Software_2fdbus D-BUS] will be the foundation for interprocess communication
* Make is gmake

If you have compelling arguments against these decisions feel free to point to a better solution. But be aware that just saying "I don't like it" won't make serious points. Some hundred/thousand/millions lines of code will likely change our minds faster.

== Status ==

(Last change 29.Dec2006)

* The prototype code ([ftp://ftp.netlabs.org/pub/voyager/desktop/images/prototype.jpg screenshot]) is migrated to GTK 2.6.x. See [ftp://ftp.netlabs.org/pub/misc/cinc/vdesktop-gtk.jpg screenshot 1] and [ftp://ftp.netlabs.org/pub/misc/cinc/notebook.jpg screenshot 2]. It's currently running on X only and can be considered a proof of concept. Work is in progress to add more classes and methods and wrap the GTK API into objects.

* Some historical status information can be found on [ftp://ftp.netlabs.org/pub/voyager/desktop/documentation.htm this page].

* The orbit IDL compiler is ported to OS/2 and is the foundation for the Voyager IDL compiler.

* h-file emitter of the Voyager IDL compiler is done

* c-file emitter of the IDL compiler is done

* ih-file emitter is done

== To do ==

The following list is only the most important stuff.

* Write an IDL compiler
* Migrate header files to our own (using IBM stuff atm)
* Enable class replacing
* Make it distributed (DSOM)

Desktop

2006-12-29T08:22:54Z

Cinc: /* Design decisions */

== Introduction ==

The desktop should resemble the WPS experience. There won't be binary compatibility (if you want that, feel free to add it) but source compatibilty is top priority.

Some cornerstones:

* OO design
* Extendable by just adding new classes like the WPS (subclassing without recompiling)
* Class replacing
* No recompilation for new features
* Drag and drop of almost everything (icons, colors, fonts etc.)
* Scriptable by REXX
* Maybe REXX-classes (classes written in REXX)
* DSOM functionality (not at the beginning but development shouldn't prevent it)
* ...

'''Note:''' Please don't discuss items on this page. Use the discussion page or the [[Voyager]] page.

== Design decisions ==

At this point in time:

* The graphical toolkit is [http://www.gtk.org GTK]
* [http://www.gtk.org GLib] is used as the portability layer
* An object model similar to SOM is the foundation (NOM: Netlabs Object Model)
* GTK will be wrapped into objects to make development easier
* Compiler is gcc 3.3.x (may change later. Compilation on OS/2 should always be possible)
* [http://www.freedesktop.org/wiki/Software_2fdbus D-BUS] will be the foundation for interprocess communication
* Make is gmake

If you have compelling arguments against these decisions feel free to point to a better solution. But be aware that just saying "I don't like it" won't make serious points. Some hundred/thousand/millions lines of code will likely change our minds faster.

== Status ==

* The prototype code ([ftp://ftp.netlabs.org/pub/voyager/desktop/images/prototype.jpg screenshot]) is migrated to GTK 2.6.x. See [ftp://ftp.netlabs.org/pub/misc/cinc/vdesktop-gtk.jpg screenshot 1] and [ftp://ftp.netlabs.org/pub/misc/cinc/notebook.jpg screenshot 2]. It's currently running on X only and can be considered a proof of concept. Work is in progress to add more classes and methods and wrap the GTK API into objects.

* Some historical status information can be found on [ftp://ftp.netlabs.org/pub/voyager/desktop/documentation.htm this page].

* The orbit IDL compiler is ported to OS/2 and is the foundation for the Voyager IDL compiler.

* h-file emitter of the Voyager IDL compiler is more or less finished (05.Sep.2006).

== To do ==

The following list is only the most important stuff.

* Write an IDL compiler
* Migrate header files to our own (using IBM stuff atm)
* Enable class replacing
* Make it distributed (DSOM)

Desktop

2006-12-29T08:22:30Z

Cinc: /* Design decisions */

== Introduction ==

The desktop should resemble the WPS experience. There won't be binary compatibility (if you want that, feel free to add it) but source compatibilty is top priority.

Some cornerstones:

* OO design
* Extendable by just adding new classes like the WPS (subclassing without recompiling)
* Class replacing
* No recompilation for new features
* Drag and drop of almost everything (icons, colors, fonts etc.)
* Scriptable by REXX
* Maybe REXX-classes (classes written in REXX)
* DSOM functionality (not at the beginning but development shouldn't prevent it)
* ...

'''Note:''' Please don't discuss items on this page. Use the discussion page or the [[Voyager]] page.

== Design decisions ==

At this point in time:

* The graphical toolkit is [http://www.gtk.org GTK]
* [http://www.gtk.org GLib] is used as the portability layer
* An object model similar to SOM is the foundation (NOM: Netlabs Object Model)
* GTK will be wrapped into objects to make development easier
* Compiler is gcc 3.3.x (may change later. Compilation on OS/2 should always be possible)
* [http://www.freedesktop.org/wiki/Software_2fdbus D-BUS] will be the foundation for interprocess communication
* Make is gmake

If you have compelling arguments against these decisions feel free to point to a better solution. But be aware that just saying "I don't like it" wont make serious points. Some hundred/thousand/millions lines of code will likely change our minds faster.

== Status ==

* The prototype code ([ftp://ftp.netlabs.org/pub/voyager/desktop/images/prototype.jpg screenshot]) is migrated to GTK 2.6.x. See [ftp://ftp.netlabs.org/pub/misc/cinc/vdesktop-gtk.jpg screenshot 1] and [ftp://ftp.netlabs.org/pub/misc/cinc/notebook.jpg screenshot 2]. It's currently running on X only and can be considered a proof of concept. Work is in progress to add more classes and methods and wrap the GTK API into objects.

* Some historical status information can be found on [ftp://ftp.netlabs.org/pub/voyager/desktop/documentation.htm this page].

* The orbit IDL compiler is ported to OS/2 and is the foundation for the Voyager IDL compiler.

* h-file emitter of the Voyager IDL compiler is more or less finished (05.Sep.2006).

== To do ==

The following list is only the most important stuff.

* Write an IDL compiler
* Migrate header files to our own (using IBM stuff atm)
* Enable class replacing
* Make it distributed (DSOM)

Voyager Support

2006-12-29T08:16:10Z

Cinc: /* Netlabs Object Model */

[[Category:Voyager]]
Voyager is a very complex projects and it just can be successful when everyone contributes as good as possible. To make it easier for you to join the project we defined some jobs where you might help.

==Documentation==
Good documentation is an important part of Voyager. For various reasons we decided to do the documentation in [http://www.docbook.org DocBook]. This is an XML based format used for many publications, O'reilly books are done with that too. Many other open source projects use this format as a base, it allows us to create any kind of output out of it like HTML or PDF but also more in the future.

The drawback is that it takes some more time to get into DocBook, in the beginning it is easier to use a WYSIWYG application like OpenOffice.org to create the document. Currently two Voyager developers write their documentation in OpenOffice.org.

So one help would be to keep [http://voyager.netlabs.org/ The Design of Voyager] up to date with the OpenOffice.org documents of the two developers. Beside this one might also work on an easy to use way on eCS to work with DocBook.

===DocBook Editors===
At the time writing there are the following options available to edit DocBook in an easier way:

* [http://www.eclipse.org Eclipse] with the [http://vex.sourceforge.net/ Vex] and [http://www.xmlbuddy.com/ XMLBuddy] plugin. Vex is open source and XMLBuddy is free in the entry version which is enough for our needs. Unfortunately we do not have an Eclipse port for eCS yet so this requires to work on one of the supported Eclipse platforms right now.
* [http://www.xmlmind.com/xmleditor/ XMLmind], a standalone Java based XML Editor which seems to support DocBook as well. According to the requirements this should work on eCS but we did not test that yet. It would be nice to set up a package that can be easily installed on eCS.

At Warpstock Europe 2005 there was also a [http://warpstock.net/WSE2005/Presentations/Presentations/#docbook presentation about DocBook] on eCS by Jarda Kačer and Jirka Kosek. It would be a good idea to work together with those guys to get that to work on eCS as well.

===DocBook Syntax===
The best way to learn DocBook is to have a look at the [http://svn.netlabs.org/v_doc/browser/DOV current book], most of the needed tags are probably already used once. Beside this one should have a look at [http://www.docbook.org/tdg/ DocBook: The Definitive Guide], which is available online or as HTML download.

Some remarks:
* Use [http://www.docbook.org/tdg/en/html/xref.html xref] whenever possible to create a reference to another part of the document. This makes reading the book much more interactive.
* For images one should use PNG versions for the web release and PDF for the PDF edition of the book. See the [http://FIXME mediaobject] example in [http://svn.netlabs.org/v_doc/browser/DOV/ch03.xml Chapter 3]. Please make sure that the PNG versions use a size that makes sense for web publishing. We did not do many tests on PDF yet, we have to see how this works regarding scaling.
* We use Subversion to keep a history of the document, this also means that the structure of the document should not change unless there is new content. Because of its XML nature, every editor will use its own indenting for the file. The only valid format to commit to Subversion is the indenting of Vex. So in case your editor changes the layout please make sure that Vex did format it before it gets committed, otherwise we get very big changesets!
* There is an additional <tt>DOCTYPE</tt> declaration in each chapter, the XSLT for transforming it does not like that because it is also defined in <tt>book.xml</tt>. To create the HTML and the PDF version of the book this line gets stripped out automatically by the build process before the document is transformed.
* Do not worry about the online versions, they are done by some scripts. Just make sure your own copy builds correctly in HTML before you commit it.
* Do not forget to commit images as well to the Subversion in case you added some.

==ToDo==
This is a list of documents that need to get maintained.

===The Design of Voyager===
====Netlabs Object Model====
* [ftp://ftp.netlabs.org/pub/misc/cinc/voyager/Object-design.pdf Object Design]
* Author: Chris Wohlgemuth, <tt>cinc-ml at netlabs.org</tt>, Cinc on irc://irc.netlabs.org/netlabs

====Desktop====
* [ftp://ftp.netlabs.org/pub/misc/cinc/voyager/Desktop-design.pdf Desktop Design]
* Author: Chris Wohlgemuth, <tt>cinc-ml at netlabs.org</tt>, Cinc on irc://irc.netlabs.org/netlabs

====Triton====
* [http://svn.netlabs.org/v_triton/browser/trunk/Docs/mmio-general.odt MMIO General] - OpenOffice.org
* Author: Peter Kocsis, <tt>FIXME</tt>, Doodle on irc://irc.netlabs.org/netlabs

===Object-Oriented Interface Design (CUA)===
This is the book written by IBM back in the early nineties, the original title was
* Object-Oriented Interface Design - IBM Common User Access Guidelines ISBN 1-56529-170-0

We never found a PDF version of this book, just a very poor online HTML version. With the help of some scripts we assembled a standalone version of this book. Unfortunately the HTML syntax is very poor and the book lacks the images. Good for you because you can help us on that ;-)

* Get the [http://svn.netlabs.org/v_doc/browser/CUA recent version] of this book in our Subversion
* Install [http://weilbacher.org/Mozilla/builds.html NVU] and open the xhtml file.
* Start to clean it up. The syntax should look like in the beginning, very simple but clean XHTML code, as few <tt>br</tt> as possible, <tt>h1</tt>, <tt>h2</tt> for topic formating and <tt>p</tt> for paragraphs.
* Kill all table of contents and such things in the XHTML version. We will transform the XHTML to DocBook in a second step and DocBook will take care of that.
* And if you are brave try to reproduce the images, at least those that make sense. This book is still available second hand, use that as a reference. For sure it would greatly help if someone finds a PDF version of the original document (in case that exists). It might get pretty tricky to reproduce some of the images because IBM created some sample applications for it, use what makes sense to you. For sure the images should be taken from a recent OS/2 or eCS system.