Michael Meeks wrote: >> But it would be good and nice to actually start now with some of >> them. As an example, I would like to convert all "Format-whatever" >> dialogs into parts of a formatting pane. In fact we are currently >> discussing ways to implement that with the developers from RedFlag2000. >> And we will need the layouter for this. (*) > > This sounds cool; and of course the layouter can do that for you; I > guess co-ordination-wise, the first step is to get awtfixes1 included - > and then, the 1st cut of the layout/ code into a CWS, split & integrated > where sensible into toolkit/ and that merged.
Sounds like a good plan. (dialogs with property set style API) >> >From my own experience I *know* that for many dialogs this API can work >> and in different form it works that way already. A good example are the >> mentioned "Format - ... " dialogs that currently communicate with the >> applications exactly that way (not using Any but SfxItemSets - just the >> same thing in a different shape). > > Well - but the SfxItemSets themselves are often not simply construted > by a plain dialog (I imagine) - there is code in that dialog that deals > with the various exclusions, extensions and so on that inevitably drift > into such cases: "Indiviual words" is only an option when Font Effects > is not "without" or whatever, or "Raise/lower by" is only set when > either super/sub-script and not 'Automatic' etc. etc. I'm not sure if I understand correctly. If you mean that in such dialogs is code that deals with different combinations of properties: sure, the properties (items) are not always orthogonal. That doesn't mean that the API "items in - items out" doesn't work for a lot of them. I didn't talk about the *implementation* of a dialog as a kind of property browser, I talked about the *interface* that applications see and use. >> There are counter examples but using a property style API in dialogs >> where possible would be nice. In other cases other APIs may be more >> appropriate. The abstract interfaces we created in our "Dialog Diet" >> work some time ago might be a good hint how some of them can look (in >> case you wanted to stay with C++ interfaces). > > Hokay; it would be interesting to read, but as I say - this is not our > focus, certainly not just yet. It isn't my current focus also. I just wanted to support Christian's POV that having dialogs with an attribute/property style API would be nice and possible in many cases. And I wanted to mention that converting dialogs does not need to stop on the resource file level. > Anyhow - it sounds like you guys would like to hack on layout, if so - > you're most welcome, there should be no problem with that: though of > course, making that easy requires getting the ABI breakage in awtfixes1 > included. Yes, you mentioned that already. IIRC it was a new virtual method in the VCL Window class? That shouldn't be a problem, especially not on a code line towards 3.0 Beta. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
