Re: [dev] Re: About the OOo dialog layouting patches
On Mon, 2007-12-03 at 09:24 +0100, Mathias Bauer wrote: > IMHO we just need some coordination. Then we all agree ! :-) bother - there was some serious flameage potential in this one. > 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. Sure, binning modal dialogs is a great goal to have; it's just not our goal just now. Of course - working together towards that wherever possible makes total sense. > 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. > 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. Sure :-) > (BTW: the Zoom dialog perhaps isn't the best choice as it will be > replaced in OOo3.0.) Oh; good stuff - and nice to know. > >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. > 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. > what would you say if the same code that drives the font > toolbar control was used in the font control in the formatting > "dialog"? I'd say code-sharing & complexity reduction rocks ;-) 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. HTH, Michael. > -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] interface-announce feedback
Frank Schönheit - Sun Microsystems Germany wrote: Hi Bernd, Hi Frank, This can even be automated (sic!), since for the feature mail, you need to specify a project, anyway, which means the mail goes to [EMAIL PROTECTED] Adding some additional "feedback to [EMAIL PROTECTED]" should be easily possible, /me thinks. Just adding that mentally to a nice-to-have-and-probably-quickly-implementable-feature-wishes-for-eis-list in my head. Just noticed that interface announcements I sent today (via EIS, going to [EMAIL PROTECTED]) contain a line Send feedback to dev@openoffice.org Is this a result of our discussion here? Yes! And well it looks like it needs some adjustment after it´s first incarnation. I find it somewhat unfortunate: Even if I specify an affected project (dba, in my case), then the line refers to dev@openoffice.org, where it should be [EMAIL PROTECTED] That´s because it has been implemented just like suggested using the "you need to specify a project, anyway" of a feature-mail. What we see here is a side effect on an api-changes-mails which do not specify a project defaulting to the developer mailing list than instead. Also, for interface discussions, at least of general nature where no particular project is affected, I'd say that [EMAIL PROTECTED] is in fact the appropriate feedback channel. api-changes mails just have to be handled differently to feature-mails *sigh*. So the question is what shall we do for api changes mails as opposed to feature-mails. Just always use [EMAIL PROTECTED] or look at the ModulesAffected list and direct to appropiate project specific list? If the later is the case what do we do if more than one module is affected? I think it would be best to just use interface-discuss for api-changes-mails, what do you think? Ciao Frank Ciao, Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: About the OOo dialog layouting patches
Caolan McNamara wrote: > On Mon, 2007-12-03 at 09:24 +0100, Mathias Bauer wrote: >> 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. (*) > > A concern is that the great is made the enemy of great and the bar for > initial entry of the much-needed new layouting ability is made dependant > on an extended set of requirements that pushes it further into the > future. We're talking about widget layout for many years and this is the > closest we've seen to date. Just getting it *in* without disrupting > existing dialogs seems the vital bit. Yes, exactly that's what I want to see happening: get the layouter and the new resource format integrated and in a next step build upon it: convert existing dialogs, create new UI etc. 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]
[dev] build breaker in SRC680 m238
Hi, there is still one build breaker in m238. Please update the file sw/source/core/fields/docufld.cxx to revision 1.48 cvs diff -r1.46 -r1.48 docufld.cxx CVS wrapper -- version: 1.101 Index: docufld.cxx === RCS file: /cvs/sw/sw/source/core/fields/docufld.cxx,v retrieving revision 1.46 retrieving revision 1.48 diff -r1.46 -r1.48 7c7 < * $Revision: 1.46 $ --- > * $Revision: 1.48 $ 9c9 < * last change: $Author: ihi $ $Date: 2007/11/26 15:29:04 $ --- > * last change: $Author: ihi $ $Date: 2007/12/03 14:25:25 $ 1200a1201 > break; 1205d1205 < break; Cheers, Ivo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] interface-announce feedback (was: [dev] feature feedback channels)
Hi Bernd, >> This can even be automated (sic!), since for the feature mail, you need >> to specify a project, anyway, which means the mail goes to >> [EMAIL PROTECTED] Adding some additional "feedback to >> [EMAIL PROTECTED]" should be easily possible, /me thinks. > > Just adding that mentally to a > nice-to-have-and-probably-quickly-implementable-feature-wishes-for-eis-list > in my head. Just noticed that interface announcements I sent today (via EIS, going to [EMAIL PROTECTED]) contain a line Send feedback to dev@openoffice.org Is this a result of our discussion here? I find it somewhat unfortunate: Even if I specify an affected project (dba, in my case), then the line refers to dev@openoffice.org, where it should be [EMAIL PROTECTED] Also, for interface discussions, at least of general nature where no particular project is affected, I'd say that [EMAIL PROTECTED] is in fact the appropriate feedback channel. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] presenter view extension + fast search
Hi, I'm Powerpoint user - would like to migrate to OOo Impress (for our church presentations). I have 2 remarks: - based on screenshots and specification ( http://wiki.services.openoffice.org/wiki/Presenter_View) I still miss possibility to see more than one slide ahead. Is there any plan for implementing such a Powerpoint-like feature? - one more thing I would mention here is that we need really fast text search in presentation with over 1000 slides. Does anyone have any hint for this in OOo? Because in Powerpoint it works OK for us.
Re: [dev] Re: About the OOo dialog layouting patches
Hi Jan,
I like what you do, please go on.
Regards,
Christian
Jan Nieuwenhuizen wrote:
Christian Lippka - Sun Microsystems Germany writes:
Hi Christian,
I very much enjoy your work for the dialog layouting on your blog[1].
Everyone interesting in user interface work for OOo should have a
look at it.
Thanks! If you read it carefully, you will have noticed that I just did
some polishing up till now, most of the job was done by Ricardo Cruz and
Michael Meeks.
I just have one minor RFE. You try to mimic the original dialog
designs as best as possible to have a proof of concept that
your layouting can replace existing OOo dialogs with ease.
Thanks, yes, for simple dialogs we already can.
I think you proofed your concept and we should start focusing
on how to improve the dialogs. And one thing I would love to
see is that the common dialog control buttons ("ok", "cancel",
"help", "previous", "next", etc. ) are not part of the layout.
Yes, that's actually quite high on the TODO list. The current idea is
to have a special kind of that will do the rearanging and
layouting of any Cancel/OK/Help buttons contained in it.
So the layout information should only be given for the controls
that form the client area of the dialog. But the control buttons
should just be marked as "i'm used!" and the LayoutDialog should
decide where to place them.
Yes, that's the idea.
And while I think your minimal way to layout existing dialogs
is very good, when do you think is a good time to discuss how
new dialogs should be implemented using your LayoutDialog?
I think we'll need Michael in this discussion: Michael, what do you
think?
Please keep up your good work, but don't waste to much time
making the layouted dialogs look like the ugly original dialogs :)
Thanks. As a matter of fact, I suspended most of my layout work now to
resync, update & qa the prerequisite awtfixes1 cws.
Greetings,
Jan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: About the OOo dialog layouting patches
Caolan McNamara wrote: On Mon, 2007-12-03 at 09:24 +0100, Mathias Bauer wrote: 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. (*) A concern is that the great is made the enemy of great and the bar for initial entry of the much-needed new layouting ability is made dependant on an extended set of requirements that pushes it further into the future. We're talking about widget layout for many years and this is the closest we've seen to date. Just getting it *in* without disrupting existing dialogs seems the vital bit. No one wants to interrupt it, not even me even if some people read it that way. As I initially stated, what Jan is doing is a step in the right direction. But as we learn that even try to discuss what to do next is nailed down, from one side or the other. If you are the bad guy no matter what you say I will just shut up now and do some work. Its just no fun anymore Christian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: About the OOo dialog layouting patches
On Mon, 2007-12-03 at 09:24 +0100, Mathias Bauer wrote: > 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. (*) A concern is that the great is made the enemy of great and the bar for initial entry of the much-needed new layouting ability is made dependant on an extended set of requirements that pushes it further into the future. We're talking about widget layout for many years and this is the closest we've seen to date. Just getting it *in* without disrupting existing dialogs seems the vital bit. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: About the OOo dialog layouting patches
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]
