Difference between revisions of "ESchemes"
(→OS Skinning/Schemeing) |
|||
| Line 9: | Line 9: | ||
(Files for the eSchemes project can now be found at the [http://betazone.ecomstation.com eComstation Betazone]) | (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 === | === Introduction === | ||
Revision as of 20:08, 29 June 2007
OS Skinning/Schemeing
(Files for the eSchemes project can now be found at the 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)
