ESchemes

From NikiWiki
Revision as of 12:00, 19 May 2005 by Cris (talk | contribs) (OS Skinning/Schemeing)
Jump to: navigation, search

OS Skinning/Schemeing

(Files for the eSchemes project can now be found at the eComstation Betazone)


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:

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.

Prokushev: Project started. Search alpha versions at eComStation Betazone. Help I actually need:

  1. I need some approach to patch PMMERGE.DLL to fix/replace 4 functions.
  2. Testers ;)

Cris: I am interested in being a beta tester. I'll download the alphas ASAP.

Regarding how to patch PMMERGE: you can use the approach used to apply caching to the flushing of user and system INIs. That is: you rename the original PMMERGE to something else (internally also); then you build a DLL called PMMERGE, which intercepts ALL of the original PMMERGE functions and redirects them to the original (renamed) DLL, but for the 4 functions you want to replace/fix. Once you've done your things in those 4 functions, you have the choice to return to the caller (replace) or to forward the call to the original PMMERGE DLL (fix).

Prokushev: Actually, this approach will not work for internal function. As result, Until ALL controls will be replaced, no correct scheme colors.

Cris: I am having some problems with the alpha of eSchemes. I wrote a couple messages on the forum, but got no reply till now. Could you please monitor the forum, Prokushev? I know the forum still isn't in the forums list, but you can access it directly via the link in the docs.

Prokushev: Monitoring already ;)