One thing that I think that I understood is how to clearly identify a WPS application.
In simple (and maybe incomplete) words a WPS application is an application that creates a new WPS class or that overrides an existing WPS class by creating a new one with extra functionality.
With that in mind I started to create a list of the OS/2-eCS WPS application on the OS2World Wiki.
Check it out at: http://www.os2world.com/wiki/index.php/Workplace_Shell_based_Applications
jueves, 26 de diciembre de 2013
jueves, 5 de diciembre de 2013
Learning about Workplace Shell
Why WPS?
I'm learning more about WPS with time, but I still think that is a valid approach for creating the resources that manage the OS/2-eCS desktop.
The Re-usability idea
When you create a new class to create a new object on WPS you don't start from scratch. You have several other classes that you can re-use to build your class (WPClass, WPObject...all)
Look for example the HWman class replacement. The goal of this was to improve some issues that the original "Hardware Manager" has. The author did not start creating a "Hardware Manager" by scratch. He made a "child" of the hardware manager class (HWManager) and replaced (overide) only the functionality that has the issues. So in fact he coded less.
Expandable
You can also expand the functionality of objects on the WPS. By creating a "child" of the classes you can expand
Just look again the HWman class replacement. The author fixed the behavior of a close source program. I had never saw that, in general if you don't have the source code of the program, you can not expand it or improve it.
This is something that was never seen in the "close source software" world. If you want to add a feature to Windows ScreenSaver for example, you will have to write a complete replacement for it. While with OS/2 WPS you can copy the close sourced class and only code the feature missing.
Down Side
But I also think there are some downsides:
- We depend on the old IBM somcompiler. (sc.exe)
- We need to learn how WPS works before improving it / replacing it with OSS components.
- Having this flexibility also grows the complexity. We need to have and understanding on how are the WPS Classes structured.
Actions:
For the moment my actions are simple on this subject:
- Trying to include more documentation about WPS on the EDM/2 Wiki
- I'm trying to document the UML visual design of WPS Classes (attachment included).
If anybody wants to help me with this starting point I will appreciate it. It does not matter if only have some minutes at week.
My UML is very rusty.
- UML in PNG format.
- Argo UML file
I'm learning more about WPS with time, but I still think that is a valid approach for creating the resources that manage the OS/2-eCS desktop.
The Re-usability idea
When you create a new class to create a new object on WPS you don't start from scratch. You have several other classes that you can re-use to build your class (WPClass, WPObject...all)
Look for example the HWman class replacement. The goal of this was to improve some issues that the original "Hardware Manager" has. The author did not start creating a "Hardware Manager" by scratch. He made a "child" of the hardware manager class (HWManager) and replaced (overide) only the functionality that has the issues. So in fact he coded less.
Expandable
You can also expand the functionality of objects on the WPS. By creating a "child" of the classes you can expand
Just look again the HWman class replacement. The author fixed the behavior of a close source program. I had never saw that, in general if you don't have the source code of the program, you can not expand it or improve it.
This is something that was never seen in the "close source software" world. If you want to add a feature to Windows ScreenSaver for example, you will have to write a complete replacement for it. While with OS/2 WPS you can copy the close sourced class and only code the feature missing.
Down Side
But I also think there are some downsides:
- We depend on the old IBM somcompiler. (sc.exe)
- We need to learn how WPS works before improving it / replacing it with OSS components.
- Having this flexibility also grows the complexity. We need to have and understanding on how are the WPS Classes structured.
Actions:
For the moment my actions are simple on this subject:
- Trying to include more documentation about WPS on the EDM/2 Wiki
- I'm trying to document the UML visual design of WPS Classes (attachment included).
If anybody wants to help me with this starting point I will appreciate it. It does not matter if only have some minutes at week.
My UML is very rusty.
- UML in PNG format.
- Argo UML file
Suscribirse a:
Entradas (Atom)