View source for Eschemes discussion

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:

# Command-line tool which will apply scheme. Goal is to establish scheme file format and create core of software.
# WPS classes for scheme file and schemes preview folder. Uses commandline tool.
# PM scheme editor (as replacement of standard Scheme editor) with preview function (part of WPS class).
# 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:
# PresParam; if none then
# Local Contol Colors table (via winqurycontrolcolors); if none then
# Global Control Colors table (via winqurycontrolcolors); if none then
# SysColor; if none then
# 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:
# I need some approach to patch PMMERGE.DLL to fix/replace 4 functions.
# 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 ;)

==Tango-Project==

I found a nice project which aims to provide Icons & similar look & feel for many things:
* http://tango-project.org/Tango_Desktop_Project

-ktk


[[Category:eSchemes]]