Hi Jacob,
There was/has/is already discussion regarding replacing VCL but specific searches of the mailing lists turned up only a few comments on probably replacing VCL, more broad searching turned up too many threads to read through, so I hope you'll forgive me if I'm beating a dead horse (hopefully I'm not).
No, you're not - VCL is alive and will probably be accompanying us for a while...
From what I understand the VCL has a lot of problems including: - Lack of sufficient documentation - It's outdated - It's difficult to port the graphics to new systems? (I'm thinking of Aqua when I say this) - OOo relies on the internals of VCL not just an API - It's difficult to create new dialogs and other UI elements - It requires serious hacking to use native widgets (I think I've read about plugins: VCL/GTK; VCL/QT; Others?) - VCL is absolutly positions everything making multi-lingual interfaces difficult as some things are longer in different languages.
Most of those points are valid but at least some are may be not as bad you might think.
- Porting: I think the lack of an Aqua port is not only due to the complexity of VCL. VCL comes with an X11 and a Win32 implementation that provide the same functionality on quite different platforms. Additionaly, there is a Java implementation that serves as the base for NeoOffice/J. In other words, there are fully functional VCL implementations for 3 major APIs. It should be possible to derive another one.
- Native widgets: the current solution provides native widget support in a quite seamless manner, as widgets are just drawn but never instatiated. Instantiating them would bring us much more trouble as we would have to deal with their focus behaviour, message handling and may be lack of advanced text output capabilities. On the other hand the advantage for the user would be minimal.
- Plugins: the plug-in architecture allows porters to easily add support for different toolkits. Especially if a new toolkit should be supported on an already supported platform the effort to do so can be rather small. For instance the gtk plug-in inherits a lot of functionality from the X11 implementation and only adds toolkit specific windowing and input functionality (i.e. event handling).
The other problems you mention are probably better candidates to attack, as they have a direct influence on the end user and, if properly solved, could remarkably improve the quality of OOo.
- dynamic widget layout / resource editor: I think this is the most important thing to do as it would simplify the creation of new dialogs and could even improve the look of existing ones. The problem with OOo's UI is the high effort to change it. Simplifying this process should be the most important goal in this area as it would allow for easier customization and of course would make the process of changing existing dialog layouts less painful.
One possible solution would be to define a new API that controls have to fulfill to be properly layouted by some layout manager. The API would be implemented by the existing VCL controls, but would not be restricted to VCL. Because hints for the layout manager must be defined externally (hopefully interactively by a resource editor) the existing resource system must at least be extended or may be fully replaced. Especially the latter might bring us an editor for free if we would use existing standards here like eg XUL.
Stephan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
