On Thu, 2007-02-22 at 09:11 +0100, Mathias Bauer wrote: > Hi, > > this mail goes to dev@gsl.openoffice.org and [EMAIL PROTECTED] Please > follow up on the gsl list. > > Philipp Lohmann - Sun Germany wrote: > > > Clemens Eisserer wrote: > >> What do you think about writing out a summer-of-code slot this year > >> for enhancing VCL. > >> VCL itself is a great toolkit and I guess because of > >> not-existing-manpower it will be used for another couple of years, but > >> I think it lacks some features of modern toolkits. > > > > Ah, a diplomat :-) > > > >> Some areas which could be improved: > >> - Performance. Sometimes slow, sometimes bad feeling. E.g. menus in > >> OpenOffice, Support for doublebuffering > > > > Both valid. The menu thing may extend to framework, though. > > > >> - Layout Managers. Implement Layout-Managers (already existing?) and > >> adopt important dialogs to use them. > > > > A long term wish of mine. There even were two attempts at writing > > Layouting code, one by mmeeks, one by cmc. Both had already progressed > > to a demo dialog. However there was no resolution about which way to go > > finally. > > I think we deadly need something like that. Currently extensions are > restricted to non-resizable dialogs and IMHO that is one of the biggest > barries to a better usability of extensions. I think we need to be able > to "dock" extension GUI elements like we can dock our navigator. This > will need a layouter as the strategy of our "internal" elements > (overwriting a virtual "resize" method) does not apply to "external" ones. > > Perhaps it's time to revive one of the pilots? AFAIK Christian Lippka > also invested some time for it.
I'm still rather a fan of my springs approach, though sadly my original implementation was utter rubbish. What I thought might be convenient with the springs idea was that... a) There is a java SpringLayout things in the awt so springs are fairly familiar b) It's possible to incrementally change dialogs and leave old one working like they always did while adding springs to new ones, I was (and still am) a bit frightened of the more extensive rework of dialog ideas where stuff like valid values are tested for in javascript which becomes part of the dialog description. c) And it seemed plausible to add a SpringLayout api to our uno one along the lines of the java one so that extensions could describe their dialogs' layout I reworked my implementation of springs in java and submitted it to libgcj as an implemenation of the sun java equivalent. So the work went *somewhere* at least, I always meant to re-work that final java one back into c++ and take up the "show it can work for the more complicated tab dialog layout" case challenge. C. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
