I think few of the devs ever read the Design forum (???)
There are a some nice GUI designs, mostly done with a drawing program. So I thought it would be great to make those designs available inside ROS. Some of them (I think kokodin made a good and quite good programmable design) could be done by changing the user32 code, but it's not a good idea to make theming by changing user32 code. So I had the following idea: all code really needed to draw the GUI elements could be exported into an external dll (gui.dll or something like that) so some basic theming would be pretty easy and still fast. We would only need a kind of GUI API that would allow changing most things, but would not be too complex. What do you think of this? If you think it's a good idea, I would try to outsource the gui code out of user32 and try to develop a basic and a secondary (based on kokodin's design) dll.
On Saturday 27 May 2006 22:36, Timo Kreuzer wrote:
I think few of the devs ever read the Design forum (???)
There are a some nice GUI designs, mostly done with a drawing program. So I thought it would be great to make those designs available inside ROS. Some of them (I think kokodin made a good and quite good programmable design) could be done by changing the user32 code, but it's not a good idea to make theming by changing user32 code. So I had the following idea: all code really needed to draw the GUI elements could be exported into an external dll (gui.dll or something like that) so some basic theming would be pretty easy and still fast. We would only need a kind of GUI API that would allow changing most things, but would not be too complex. What do you think of this? If you think it's a good idea, I would try to outsource the gui code out of user32 and try to develop a basic and a secondary (based on kokodin's design) dll.
This is similar to what MS did in XP. They made the GDI depend on another DLL for all interface drawing. IIRC, this interface isn't detailed anywhere on MS's site, but the last time I looked was late 2001 so that could have changed.
If ROS aims to be NT4 compliant implementing this system isn't necessary. However, for themeing, I can see it being very useful. I haven't checked the QT license in a long time, but it's quite possible that ROS could ship with interfaces based on GTK, QT and any other X widget set imaginable. This would, I believe, provide a major point of difference between ROS and Windows and potentially help draw more users to the project.
DRH
On Saturday 27 May 2006 15:18, D. Hazelton wrote:
I haven't checked the QT license in a long time, but it's quite possible that ROS could ship with interfaces based on GTK, QT and any other X widget set imaginable. This would, I believe, provide a major point of difference between ROS and Windows and potentially help draw more users to the project.
Qt is licensed under the GPLv2 ;) Well, except for the proprietary-licensed one, but that's only for those wishing to make non-free software, it doesn't add any benifits over the free software Qt.
This is similar to what MS did in XP. They made the GDI depend on another DLL for all interface drawing. IIRC, this interface isn't detailed anywhere on MS's site, but the last time I looked was late 2001 so that could have changed.
In simple terms, what uxtheme and the theme APIs do is as follows: For non-client area themeing (i.e. window borders and the other stuff thats applied to all windows), there is an undocumented API in user32 (RegisterUserAPIHooks) which is used by uxtheme to hook certain user32 APIs to do the non client area drawing etc. Client area drawing is done via a manifest that selected comctl32 version 6.0 which basicly replaces the system classes for things like buttons, list boxes and so on with new versions that are properly themed. There is also a Themes service, how that fits into it I dont know.
For ReactOS, the key things we need are: 1.A unxtheme.dll that implements all the same published APIs microsofts does (ideally including support for .msstyles files) 2.Proper support for SxS, activation contexts, manifests and such to correctly load the right dlls for client-area themeing. 3.Some kind of implementation of themed controls that works the same way as microsofts (which means we need a comctl32.dll that overrides the standard controls with themed versions) and 4.Some way to do non-client area themeing. One option is to do what MS did and have our uxtheme call an API exposed from user32 to allow it to override certain user32 APIs. The other option is to simply have user32 always read the theme data and always draw some kind of "themed" non-client area (even if the "theme" is just the default windows look) Which option is right for ReactOS I dont know.
Isn't uxtheme.dll (Common Controls 6, Themeing Service) already designed for this purpose? Programs that are themeable already are linked to Common Controls 6 or dynamically pull in uxtheme.dll
On Sun, 2006-05-28 at 00:36 +0200, Timo Kreuzer wrote:
I think few of the devs ever read the Design forum (???)
There are a some nice GUI designs, mostly done with a drawing program. So I thought it would be great to make those designs available inside ROS. Some of them (I think kokodin made a good and quite good programmable design) could be done by changing the user32 code, but it's not a good idea to make theming by changing user32 code. So I had the following idea: all code really needed to draw the GUI elements could be exported into an external dll (gui.dll or something like that) so some basic theming would be pretty easy and still fast. We would only need a kind of GUI API that would allow changing most things, but would not be too complex. What do you think of this? If you think it's a good idea, I would try to outsource the gui code out of user32 and try to develop a basic and a secondary (based on kokodin's design) dll.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
D. Hazelton -
Jonathan Wilson -
Justin Haygood -
Mike Swanson -
Timo Kreuzer