Michael Meeks wrote:
>> If we want to do this for OpenOffice.org, we should decide about this
>> now. Because in that case we will need to rewrite lots of the modal
>> dialogs anyway. So replacing them now with a 1:1 layouted modal dialog
>> is just wasted resources. Changing a modal dialog to a non modal one
>> is more than just moving the controls to another window, trust me.
>
> This can be read as "please stop what you are doing, now" ;-)
I don't think so. IMHO we just need some coordination.
I didn't read Christian's statement as a plea to do everything in one
step, as I understood he just opted for agreeing on the general goal. We
won't redesign and rewrite all existing dialogs into non-modal panes at
once. 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. (*)
There are many other dialogs that still can benefit from the conversion
you are currently doing but - as mentioned in another private
communication between us - it would be great to have the layouter as a
code unit usable for new work first, so that we can create new UI based
on it. Converting the dialogs as you started is no contradiction to
that, it's a supplement. (BTW: the Zoom dialog perhaps isn't the best
choice as it will be replaced in OOo3.0.)
>> But for most dialogs that only present some settings I dream of
>>
>> Reference< XPropertyDialog > xDialog( xFactory->loadFromResource(
>> "dialogs/graphics/shapetransform.xml" ) );
>> xDialog->setPropertyValue("x", Any( nShapePosX ) );
>> xDialog->setPropertyValue("y", Any( nShapePosY ) );
> ..
>> xDialog->getPropertyValue("x") >>= nShapePosX;
>> xDialog->getPropertyValue("y)" >>= nShapePosY;
>
> IMHO, this is naive :-) in Gnome we tried to do a set of APIs like this
> for the simpler case of "settings & preferences" to make generic widgets
> that would bind to configuration keys, and it turned out to not map that
> well to reality there.
>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).
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).
Ciao,
Mathias
(*) Just as an outline what we could do here (and what we are currently
evaluating): what would you say if the same code that drives the font
toolbar control was used in the font control in the formatting "dialog"?
If you could use either toolbars or panes and not as nowadays have the
same funtionality placed (and implemented!) in several places?
It also would be nice to create new UI components that can be installed
as extensions and users could select one at runtime. Etc. etc.
--
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]
