Ideas

Note: This page is extremely unorganized like most of my todo-lists I do at home. Feel free to add your ideas here. We hopefuly organize that a bit better one day...

• eComStation is very nice in my opinion (ktk speaking here :-) but updating it is still a major pain in the ass. We need a easy and stupid proof way updating it. And *please* in a non-GUI version too!

MultiMedia Improvements

There seems to be two ways to achive Multimedia Improvements

Enhancing the native MMOS2 Infrastructure

There should be goals like:

• Complete Open Source Replacement of all the MMOS2 files
• Create a Bundle package of all Open souce CODECs
• Re-energize the OS2 Multimedia Infrastructure Project
• add proper streaming support to IO Storage procedures, like this CWMM classes could handle more than just Icecast streams (the current one fail because they don't get the expected header

The projects that can be integrated are:

• TiMidity MCD for OS/2 (midi)
• MMAudio Pak 2 for OS/2 (MP3, Vorbis, FLAC)
• CW-Multimedia classes (Prokushev) Unfortunately, CWMM Classes not open source. As result, can't be extended. Another problem is no IDL files for CWMM Classes or MMOS/2 Classes. As result, classes can't be extended. Only solution is restore IDL files from IR or using class information from MMPARTS.DLLs. Or ask Chris to open source his classes or, at least, to publish IDL files
• Quickmotion (Quickmotion's Tom Harding told there there could be a change to open source it if we find an developer for it

Enhancing NON MMOS2 related Multimedia (like WarpVision)

This seems something that Vladest might tackle with WarpVision: VLC media player

UnixOS2

There is a ports-like system for UnixOS2 in the works at the moment but I'm not really happy with that one and I doubt that we will be enough people for maintaining all that stuff ourself (dependencies and so on...).

When I use Linux I often work on Gentoo, which has really the best source-based ports system I've ever seen (and I know BSD too so it's not the only ports-system I know ;).

At the moment the ports system is quite Linux oriented but at the moment there is a complete rewrite of the portage-system in progress. They call it portage-ng. One of the targets is cross-platform support for stuff like BSD or MacOS so I really vote for OS/2 support as well :). It's too early at the moment to really have a look at it but we should definitely do that as soon as possible.

The discussion about portage-ng is here

Update September 04: I talked to the guys who work on portage-ng. It looks like portage-ng is not really dead but at least progressing very slowly. Meanwhile, a group of MacOS X users created a portage for MacOS X so it looks like it does work on BSD-like systems too. So that changes the todo list a bit:

TODO:

• set up a basic package with latest GCC and Innotek LIBC. The basic package contains all tools and libraries needed to compile Python with Innotek LIBC.
• as soon as Python compiles we need to wrap together emerge on OS/2. This might get a bit tricky because it also heavily relies on shell scripts. So whatever shell we gonna use, it must be as close as possible to bash (if not bash anyway, it looks like the stuff is not that portable to other shells).
• once we get portage to work properly we need to create ebuilds for the basic libraries. At the first stage there is no rsync server needed to do this but it will definitely get handy sooner or later (shouldn't be a problem but needs to be set up).
• implement more and more ebuilds for all kind of packages
• and in a later stage create a bootstrap-package that also compiles GCC and all other tools (that won't be an easy task :)

PM

We need to port some toolkits or finish the current ports:

• qt - more soon, looks good
• GTK2: Samm proposed to work on it, will give an estimate of time soon
• wxWindows: Port quite up to date but the PM parts in it are definitely not yet done or very buggy -> fix (probably dmik)
• SWT: will be done when Eclipse is done -> dmik

Also, it would be nice to have updated public PM controls. This should be done with one DLL subclassing these public controls, and extending and/or fixing their behaviour. Things to fix/implement should be:

• Remove 64K limits in some of the controls
• Create extended MLE control (understanding HTML tags maybe?)
• Automatically drop-down list of combobox, when clicked (like DragText does)

WPS

• replace background image dialog, it should be possible to point that to another directory than \os2\bitmap

Note: This is already possible and a lot of software to make things like slideshows out of it exists also. - lp

• replace the file dialog, Gnome 2.6 does that very nicely (screenshot will follow).
• replace the Icon rendering, should be able to handle stuff like PNG as well and in best case also SVG

Note: Don't think we must replace Icon rendering. But adding MMPM IO procs for PNG and SVG is good idea.

Note: File dialog is not a WPS issue. But it can be implemented via WPS class. I consider it is good idea to move to object world. - prokushev. Can you describe that a bit with more details prokushev? - ktk

Yes. File dialog placed in PMCTLS.DLL. We can do such trick:

1. move PMCTLS.DLL to PMOLDCTL.DLL
2. write new PMCTLS.DLL with forwarders to PMOLDCTL.DLL
3. In WinFileDlg (new PMCTLS.DLL) we must check, is WPS exist? If exist, then just create WPS object (with name like WPOpenFileFolder or something like this) and monitor it (wait result from it). As result our open file object can be replaced and/or extended by standard SOM features. If no WPS exists then call or old WinFileDlg or our own implementation of open file dialog (for systems without WPS)

WPOpenFileFolder is subclass of WPFolder with changed reaction on open objects in it. If object is folder then go deep. If object then close WPOpenFileFolder and notify our new WinFileDlg. Comment: You can't do that with a WPFolder subclass because it expects every inserted object to be an existing object. So you will end with copies of each object. You have to create something different or override *a lot of methods* in your WPFolder subclass to get this done properly. And a lot of probably means every ,ethod introduced by WPFolder.

(Cornelis): One more problem with that method: An application can call WinFileDlg providing an own dialog ressource and handling the dialog messages in its own way! I cannot see how this case could be handled with the WPS method. The only "solution" I can imagine at the moment: Also check for custom ressources or custom dialog function and if they exist, do not call the WPS file dialog. I don't know how many applications use these features - but I am afraid that quite a lot do it...(!??)

Something like this.

And yes, it can be part of XWP.

BTW, how about move Doodle Screen Saver to XWP? ;)

BTW 2 : Why dont add also LSwitcher to XWP ?

Cinc: I oppose the idea to add every single utility in the world to XWP. Maintaining the XWP code is difficult enough right now because of complexitiy. Adding Utilities to XWP means they are not available for people not using XWP (for whatever reason).

What about Backup / Restore / Portability of WPS objects !??

(Cornelis): One serious disadvantage of the WPS gets even worse with all new and derived classes: There is no way to save the WPS with it's "objects" in an open format in order to port them to another system or to a new installation! I know there are programs like Open Desktop and other WPS backup and restore tools, but they all only work with a set of "normal" objects, like folder objects, program objects etc., ask their properties and store them somehow. But neither would these tools find any newly defined objects (like already the "Workframe" objects of VAC/C++ 3.0), nor would they save any extended features (like the content of the "Environment" settings page of XWP extended "program objects").

This is a conceptual problem, because in an "object oriented world" any saving/restoring program should not have to know anything about the properties of the WPS objects, but just have to call a standard function that has to be defined for each and every object: "getAllProperties" or such. And then restore it with the corresponding "setAllProperties" call. While all derived classes would have to implement versions of these functions.

Without knowing any internal details of the WPS I assume that such functions do not exist, so their introduction would not be easy. Would it be possible at all? Did anybody ever think about such an issue?

Cinc: No there isn't such a function. Nevertheless it's possible to emulate it by overriding wpSave*() methods in one base class and telling the class to save the internal variables by calling wpSaveImmediately(). In the wpSave*() override you can catch the information. Restoring the data on recreation is more difficult, though, but there may be a similar way.

Porting Windows 32 Applications with ODIN Tutorial

It would be nice if there is a tutorial on how to use odin to port open source win32 apps to OS/2.

Drivers Development Skeleton

A skeleton driver that can be used for writing drivers. More importantly, a hands on/hand holding tutorial for writing drivers. Writing drivers is a daunting project, but is necessary for OS/2 to survive in the long run.

USB Drivers

• PCMCIA driver for USB2.0 cards for laptops. Right now, laptops with USB1.0 built in cannot be upgraded

to USB2.0 with PCMCIA cards.

• USB driver for enabling RSJ to talk to external CDRW drives.

Note: It is better to make some changes in OS2CDROM.DMD code, so that it will allow to issue SCSI commands without need to open device. I made some checks, and found that it is possible to get CDROM Id control, open/close tray via OS2CDROM SCSI interface, but drive must have loaded media for the first to obtain device handle.

External list

• The Warp Wishlist maintained by Kris Lake.

Open Source OS/2 Strategy and Follow up of Open Components

An strategy with the final goal to have OS/2 open sourced.
More than a development project it had to be an integration project of open source software for OS/2, like an information site to follow up all the open source replacement for OS/2 closed components. On this site we will list the open source project available for OS/2 and the closed component that is replacement.

Ex:

• Newview.exe -> replaces View.exe -> License GNU GPL
• XWorplace
• HandyFTP
• Doodles Screen Saver
• lSwitcher
• etc, etc

Plan to make replacement for:

• command line programs like "xcopy.exe, attrib.exe, etc" (some tools already exists as part oof osFree project)
• Enhanced and replacements of CMD commands (some tools already exists as part of osFree project)
• Replace of some closed DLLs (some DLLs already exists as part oof osFree project)

Open Source OS/2 Distribution

Build a OS/2 distribution with open source replacements on it. Of course that many people says it is too hard, but we need to start with something. It can start creating an OS/2 distribution that is focused in Open Source components, and bundle on it, dssaver,xworplace,lswitcher, xfree, emx, warpin, usbres, etc. (bitmaps, icons and drivers too)

To don't start it as a too complex project it can be something similar to the UpdCD project, that requires license of Warp 4.52 or eCS to build an updated image.
We can ask help from UpdCD project to create an install image (that will require the OS/2 CD) that contains open source software on it replacing the closed components. And keep evolving this project and replacing components until in some years it can work without licensing OS/2 from IBM.

One may think about an open source distribution you simply install over an existing installed system

osFree project

I want to remember to all about existing of osFree project (site at [1]). At the present time it is collection of open-source replacement of closed OS/2 components. It includes:

• Customized 4OS2 as cmd.exe replacement (mostly integration to common build system and moving 'not must have' commands to stand-alone executibles)

Remark (Cornelis): But 4OS2 is not Open Source!?? It's Freeware AFAIK!(?) Otherwise: Why not consider the 32-bit Command Line, together with the "OS/2 command line utilities" by Jonathan de Boyne Pollard [2] ? These aren't Open Source either (also Freeware), but very solid and mainly focused on extending the CMD.EXE functionality and make it fully 32-bit. Extensions are the tools. (Why 32 bit? Well, I use it together with make, which "feeds" the command line interpreter sometimes with commands of several thousand charecters - much more than CMD.EXE would ever digest!) Furthermore: 4OS2 is just "set free abandonware", while there is still a person behind the 32-bit Command Line Interpreter...

Remark (LightElf): 4OS2 IS Open Source (GPL as far as I remember). Now it hosted at Scitech.

(Cornelis:) This is what I find at Scitech: [3] But that contains just binaries! This is not to contradict you; I only didn't ever hear about an Open Sourced 4OS2, and still I cannot find it where you say it is!? But please correct me! For the rest: Open Source or not - I would still point out to not forget the "32 bit command line interpreter"! (Maybe the status could even change if there is a good point being made by the right person at the right time??)

(Prokushev): 32-bit comandline interpreter depends on 32-bit vio/kbd API. If no 32-bit API then no 32-bit CMD ;) If vio/kbd will be implemented then just recompilation of 16-bit CMD.EXE will move CMD.EXE to 32bit world ;) Nothing hard here.

(Cornelis): The "32-bit commandline interpreter" and the "OS/2 commandline utilities" are existing freeware products, running on existing OS/2 or eCS systems, so it's even easier! The only "problem": it's freeware, not open source.

(Prokushev): And "32-bit commandline interpreter" is actually just uses CONAPI which just wrapper around old 16-bit API. Don't see any differents with stnadard 16-bit CMD.

(Cornelis): There are a lot of advantages! Please go and LOOK AT IT and READ THE DESCRIPTIONS before you make your statements! [4] Actually besides all advantages for the user (like no more limitations in command line length etc., while maintaining the most possible compatibility with CMD.EXE) it indeeds is NOT a wrapper around the old 16-bit API, but it uses the "32-bit Unicode Console API" [5] which replaces completely the old 16-bit API functions you mention.

(Prokushev): "32-bit Unicode Console API" is wrapper around old 16-bit API. It closed source. 32-bit CMD is also closed source. And uses 16-bit wrapper. Actually, CONAPI.DLL uses CON3216.DLL which IS wrapper.

(Cornelis): For me this "discussion" is getting a bit irrational now: I never intended to engage in such a stupid "faith war" for a piece of software!

But ok, if it's so important: Several levels "further down" from the 32-bit command interpreter you do indeed still hit 16-bit functions. But what's the problem with that? As long as there are 16-bit drivers this will always be the case! The important points for me are:

1. The 32-bit CMD offers a full 32-bit interface for programmers, which is designed after a later abandoned 32-bit interface by IBM. So if any programmer would use that interface, all options are open to later replace the 16-bit code two levels "further down" later on, no changes being necessary to the software.

2. The user doesn't suffer from any old size limits any more either, like a limited command line length.

3. The command syntax is very closely compatible with the CMD.EXE syntax, and where it is changed in order to make it more consistent, these extensions can be optionally turned off.

For these three reasons the 32-bit command interpreter is more future oriented than a thing like 4OS2: That one has nice extras, but is much less compatible with CMD.EXE, which generates problems in certain cases. A high degree of compatibility even in details has many advantages, because software developers or script writers etc. can rely on a specific surrounding. Keep in mind all the troubles we have already with the two REXX "flavors" on current OS/2 systems: A developer can NOT rely on an existing "classic REXX" or "Object REXX" surrounding! This would be the same with 4OS2 becoming part of a "new OS/2 standard".

Concerning the source license: 32-bit command interpreter is freeware, not open source. 4OS2 was claimed to be open source above, but nobody could until now give us an URL of the sourcecode, so this looks at least dubious: It seems that 4OS2 is also just "freeware", not open ource. Cinc: as LightElf already pointed out 4OS2 is open source. There're even different versions floating around made by people who grabbed the source and fixed some bugs. No I don't have the URL handy. Google should help there.

And only for that reason I asked to consider also the 32-bit command interpreter, besides of course also 4OS2.

(Cristiano): 4OS2 definitely IS open-source. If you search on hobbes, you'll even find two different and somewhat incompatible code branches. One is the "official" Scitech branch, the other is a branch made by some private individual, starting from the original JPSoft source code (i.e. not building on Scitech code). If you want to know better, ask Michal Necasek (SP?) of Scitech. He'll tell you what's the current state of 4OS2 code, where you can get the source, and more.

• ReginaREXX as REXX replacemend (still missed 16-bit wrappers). Subject to change to Open Object REXX.
• Replacement of many command-line tools (like attrib, ansi, chkdsk, etc.). Mostly without error handling.
• THE as TEDIT replacement
• Some forwarder DLL's (like VIOCALLS, MOUCALLS, etc.)
• FreePM sources (because FREPM seems to be discontinued)
• other things.

CVS controlled by ktk, so anyone free to contact with him to have access. osFree site can be used for above things. To do it just contact me (prokushev here). But another general thing is it's time to make one general open-source components repository with common build environment with general goal to create open-source OS/2. And, again, osFree can be good place for it. osFree not limit in languages (except common build environment). C, C++, Fortran & Pascal currently in use. Perl is coming (REXX compatible API for Perl, if possible, is planned).

Really, main goal of osFree subsection is to point above project already exists.

Insted of talking HOW OS/2 must be open-sourced (from the kernel to WPS or from WPS to the kernel) I propose (prokushev here) just start collect already existent things. Thing happen if try to do them.

Kernel Free (OS/2 Kernel with License GPL)

To release to the kernel of the system on the part of IBM and other companies.

Cinc: why GPL?

BTW using a GPL kernel wont allow to create *any* closed source software because you're not allowed to link it to GPL code dynamically. So much for the GPL hype...

WarpModem

The general idea will be to make a commun interphase (like Windows 95) for analog modems on your OS/2 system called "Warp Modem". Programs that uses the modem will had comunicate to "Warp Modem" to get the configuration of the modem and it status. This will be useful for OS/2 user, because he will not configure the modem on each OS/2 application that uses the modem.

What will be good is to have a "Modems" icons inside the OS/2 System Setup folder.

http://www.os2world.com/pictures/articles/SystemSetup.jpg

This program will show us the modems that are configured on our system. If the systems has two ore more modems it will shows us all modems that we had configure.

To make this configuration we can start using the Doug Bissett's modem configuration list (http://www.os2warp.be/modems/modem.lst)

On this menu we can see the "Add...", "Properties...", "Delete..." and "Test..."

http://www.os2world.com/pictures/articles/Warp%20Modem%20GUI.jpg

Add button will show us the instruccions to add a new modem

http://www.os2world.com/pictures/articles/Modem%20Config.jpg

(picture taken from ATT Dialer)

The "Test..." button will be a tool to test it is working. A good idea is the one from ATT dialer too. http://www.os2world.com/pictures/articles/Modem%20Tester.jpg

(picture taken also from Att Dialer)

"Properties..." will show us something similar to the "Add" window to change the modem configuration.

I think "ADD" should support "Installing" the modem using the windows "drivers" i.e. the inf-files which contain the AT seq. used for certain operations which an application can then query or call via an published API.

"Remove..." will ask us for confimartion to delete that modem

And the app should seperate the physical modem from multiple configurations one could have. i.E. a Modem has a max speed of 36.000 baud but I should be able to create a fax configuration with would setup the modem to lets say 14.400 etc.

Other tools

So, what kind of software will be good to integrate with Warp modem ?

All programs that used a analog modem can take advante of this. Developers of Phone dialers, Fax, Internet Dialers, Voice Phone, RAS, BBS software..etc..etc..

http://www.os2world.com/pictures/articles/Modem%20Selector.jpg

Documentation

This project will need a good documentation so developers that wants to uses the OS/2 Warp Modem configuration can access it easily for their phone/fax/modem applications.

Wish list

1. Open Source Project / free license GNU GPL.
2. C++ or Java development.

This is just a development idea, there is nothing coded on this direction. The pictures in some cases are just fake to explain the posibilities of this project.

OS Skinning/Schemeing

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.

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 sum it up:

• Change ALL the colors (like ColourManager/2, SysColors)
• Change title-bar controls (eStyler and CandyBarZ)
• Change pushbuttons (eStyler and CandyBarZ)
• Change check-boxes and radio-buttons (Window Themes, ColourManager/2, CandyBarZ)
• Change (indipendently, or remove some of the) window borders (CandyBarz)
• Change icons (Icon themes)
• Change titlebars (eStyler, Styler/2, ColourManager/2, CandyBarZ)
• 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)

Any taker? ;-)

(Cinc: I've got some time this weekend, just wait till monday ;-D)

(more comments below)

---

I (prokushev here) want to say I am already working in this area (since summer 2004. I recieved ColourManager/2 sources in june or july, don't remember now ;)). Project consist of different pieces:

1. Command-line tool which will apply scheme. Goal is to establish scheme file format and create core of software.
2. WPS classes for scheme file and schemes preview folder. Uses commandline tool.
3. PM scheme editor (as replacement of standard Scheme editor) with preview function.
4. PM classes for "without rebooting" controls change.

Cinc: is this source available somewhere? What's the license?

Prokushev: No. Closed source, most probably, because project aimed by eCoSoftware. Most probably sources will be available to MenSys also (this is not under my control). Actually, I looked closely to CandyBarZ and most of things already there ;). May be the product will be based on it (as result it will be under GPL). Only thing I'd like to see - closer integration with WPS.

Cinc: CandyBarZ *IS NOT* licensed under the GPL! and it will not, otherwise I'll pull all my code from it which will not leave too much of a product...).

Prokushev: CandyBarZ already contains GPLed code. As a result the whole package become GPLed. You can't do anything with it.

Most problematic part is PMMERGE.DLL fixing (we need to fix 2 functions: WinSetControlColors and WinQueryControlColors). I have no idea how to do this (ColourManager/2 method of control colors fixing doesn't solve the problem because it breaks the original logic and drops a lot of features).

Cinc: why do we need to fix these functions? Please elaborate.

Prokushev: Ok. Let's play the game. Any control (in original PM logic) must get color in following order: 1. PresParam; if none then 2. Local Contol Colors table (via winqurycontrolcolors); if none then 3. Global Control Colors table (via winqurycontrolcolors); if none then 4. SysColor; if none then 5. Hardcoded color.

Actually, to allow user to have control on colors step 5 must never be performed. This is as everything should work. If such logic is right, then the standard Scheme editor would allow users to change any color via system colors. If no such logic then the user would need to edit EVERY controls' color. LOTS of colors.

But things doesn't work, because WinSetControlColors can't change some color values. Ideally, WinSetContolColors should allow to set ANY value to a SYSCLR_* constant. Actually, some colors can be set to SYSCLR_* values, some can only be set to RGB_* values, and some can't be changed at all (hardcoded). As a result we can't control ALL colors, only a subset. ColourManager/2 partally solves the problem by setting CCI table to RGB_* values. But... If you use CM/2 then you have no d'n'd sopport in scheme palette, and you need to reboot the system to set ALL colors to new values. Also you have lot of small color problems with application.

We need a complex solution of this problem. Actually, the scheme must be changed on the fly, without any reboot. To do this, we need WC which allows us to set control bitmaps on the fly (like eStyler/2 does), we need to restore original Control Colors Table logic (replace PMMERGE functions) and lot of other small steps.

And, main thing, we must remember about the WPS. At the present time eCS includes various utils which replaces WPS functionality and, as result, we have different 'Properties dialogs' from various programs (as example, eClock has such problem) (Cris: isn't this due to the fact that eClock is created with Syibil? Sibyl controls are not real PM controls... they are only lookalikes. Prokushev: No. It's because no original WPClock class was replaced to call eClock config tool. As minimum. As maximum eClock configuration must be done via WPS class at all. As example. If I'll replace standard Scheme editor by my own (which written on Sibyl) then I need replace original SchemeEditor class to call my editor. So all thing will be done ok. Any program which will call SchemeEditor class will actually call new Scheme Editor). If we replace WPS classes by PM utils then 'WPS wrapper' must be created, at least.

Regarding the 'Icon Theme' tool: actually, we need something more complex, to allow us to change ANY attribute of WPS objects, not only Icons.

Personally I'm not interesting to work on this project 'totally for free' because I have interest in other areas.

Cris: I would be interested in helping with some money, if Adrian considered this to be added to the "funding" made by Netlabs.

Port of coLinux

I would like to see the 'Session' capabilities of OS/2 expanded upon. While a port of coLinux ( http://www.colinux.org/ ) wouldn't be a true session, this could be a step toward this goal. Especially if an IFS driver could be written to allow the disk image to be mounted.

Netlabs runtime distribution

Create a set of runtime libraries filling the voids of OS/2. For example including an additional Rexx utility DLL with much needed functions, a set of standard window classes for use in programs (see also PM and open source distribution above). The following classes should be easily implementable (Cinc: I've got already some code for them):

• Progress bar
• Separator
• URL control (control which shows a URL and starts the browser on click)
• ...

Everything should be extremly hassle free to install. So in the end every user has it on the system and developers can be sure to find that. If not they may just write in the readme: "Prerequisite: Netlabs runtime Distribution".

It's not necessary every developer reinvents the wheel again and again. A good starting point is the WPS toolkit IMHO: http://wpstk.netlabs.org/ (don't be fooled by the term WPS in the name, it contains also general purpose functions). The following general purpose functions should be added to WPSTK:

• Query function to get the common OS/2 directories (e.g. ?:\OS2\DLL)
• Function to get the users home directory
• General purpose about box using a predefined look
• Function to start the default OS/2 browser
• ...

There is also quite a lot of helper stuff in xwphelpers from XWorkplace. At the moment it's quite difficult to use them because you have to compile it in your own application so probably we should use parts of it and put it into WPSToolkit as well. We would have to check the licensing issues however because xwphelpers are GPLed and WPSToolkit will most probably be based on BSD or MPL or something alike (more liberal than GPL). If xwphelpers are using GPL (and not LGPL) they are useless for this project anyway. Nobody will (and should) use a GPLed library.

There should be some general libraries in there as well like:

• libxml
• rexxml (REXX interfaces for libxml)
• libpng (proposal by nickk IIRC)

We should add some functions extending PM/GPI to deal with unicode/locales. For example a unicode/locale/whatever aware WinDrawText() function. Maybe we even should patch WinDrawText() and friends to be unicode aware by default.