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!

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 most of the controls (e.g. MLE)
• 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
• 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.

Something like this.

And yes, it can be part of XWP.

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

USB

USB Todo's

External list

• The Warp Wishlist maintained by Kris Lake.