Jacob,
a lot of valid points you mentioned, and a lot of work to do...
I don't want to comment to the points (see mailing list archive topics on "graphics" and "chrome"), I just want to give you the hint that I wouldn't replace VCL with 1 new Architectures, but with 2.
VCL is used for 2 things:
1) Chrome This is all about the widgets
2) Graphics This is mainly how the applications draw into the document area
Using an other technology for the widgets might be reasonable.
You might be able to change all GUI code some day, and remove widget functionality from VCL.
Replacing the graphics functionality will be very very hard...
Having good API which is used for new implementations helps, but changing all the code using VCL directly will be a hard job.
And VCL has a lot of important things for font and I18N issues built in.
So if you want to do something into this direction, I suggest to concentrate on the chrome first. I have the feeling you do that anyway.
And please - if you do so, call it "chrome", not "graphics", in further discussions.
BTW - I think we already use some new API for the graphics in the new drawing layer...
HTH, Malte.
Jacob Floyd wrote:
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).
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.
So basically VCL is the train of the 19th centrury chugging away, we can get it to work, and pump enough 'coal' in it to get it going, but there's only so much you can do (maybe that's a bad analogy... Oh well. It's what came to mind) So let's create a something new a 21st century train that's environmentally friendly (or a Graphics Layer that's multi-platform multi-language friendly...)
From what I understand (and I've not delved into the code yet, nor have I found a good document on VCL... or any other efforts to change the Graphics layer) we need the following: A new graphics abstracition layer with: - A well documented API - Pluggable Multi-platform interface (to port to a new platform or widget set like GTK, QT, AQUA, wxWindows, etc all that would be needed is a plugin type thing that interfaces with widget/graphics API to use the native widget/graphics system on the new port) - The system needs to be fairly dynamic for multi-lingual capabilities (meaning no pixel perfect positioning, I think) so that things resize for different amounts of text. - We would probably want to have a list of widgets, and what they do, that each of the plugins simply interpret to the native widget set. Everything that needs to display something would simply tie into the abstraction layer and say it needs a type of control (a dialog box, check box, scroll bars, whatever other generic stuff we might need) and approximately where to position it (center of window, under mouse/cursor, ... etc)
I think that we should leave VCL as it is, as we develop such an API/abstraction layer (what's the proper terminology for these things?). Then when we complete something in the abstraction layer we go through and replace the use of VCL with the equivalent in the new layer, probably rewriting some (a lot of) sections of the code to make them work without being dependent on VCL. Then after we have what we believe is a fully functional graphics layer we would comment out all of the VCL code, compile OOo and see if we succeeded in removing all references to VCL.
Once such an graphics layer is created and working, I think we will get some of the todos done (like the multi-lingual problems). I'd also like to, at that point, make a kind of GUI builder (as mentioned in the todo list) that uses the new API to quickly create OOo UI that is then converted to native UI by the platform dependent plugins mentioned earlier.
Another thing we might want to do is make this layer easy to use in another project (other than OOo). I think that if such a layer were picked up by more projects we would end up getting a lot of patches and fixes that got sent to us which would mean it would become better much fasterr. We'd also want to make the GUI builder available.
Another thing with the GUI Builder: We might want to include it with OOo, and use it as a way to 'customize' all the options dialogs, so that users can choose which options they use the most, thereby reducing some of the problems it seems have been created when deciding to remove the ability to change an option from the options that some users hail as wonderful while others find it akin to FLOSS blasphemy (or something like that).
I suggested some things on OOo Disscuss list about the options dialog box, and so decided to go look up how feasilble they were. As I want anything I do to be forward compatible, and it seamed that VCL was eventually going to be removed, I figured I wouldn't bother trying to change anything to do with the current Options dialog unitl the underlying technology was scalably up to par. Thus this letter.
Please note that I can read code and figure out what it does fairly quickly, but as for writing it, I'm too new to programming and thus it takes me a little longer than some (probably a lot of) people to code anything. I will need help as I delve into such a project as this.
If we begin somehting like this, I think I'll first look for anything that other people have already created in this field and possilby reuse the code (license permitting) to help us get this off the ground.
Please comment and let me know where we are on this, and what needs to happen to make this go throough, or what ever else is already happening that I can help with to get things where I want them to be.
Thanks! Jacob Floyd
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
