What is the status of the layout manager and the related "new" format to describe dialogs

[Juergen Schmidt-3]

Hi,

i would like to know the current status of the layout manager and the
related "new" format for dialogs. It's a long time since i have heart
something about this project.

Is it a dead project or is somebody waiting that others will continue or
finish it? As far as i know parts of the code is checked in but not used
somewhere.

Looking forward to get some new info related to this project.

Juergen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Juergen Schmidt-3]

Juergen Schmidt wrote:
> Hi,
>
> i would like to know the current status of the layout manager and the
> related "new" format for dialogs. It's a long time since i have heart
heart  -> heard ;-)

> something about this project.
>
> Is it a dead project or is somebody waiting that others will continue or
> finish it? As far as i know parts of the code is checked in but not used
> somewhere.
>
> Looking forward to get some new info related to this project.
>
> Juergen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jan Nieuwenhuizen-2]

Op donderdag 05-11-2009 om 21:58 uur [tijdzone +0100], schreef Juergen
Schmidt:

Hi Juergen,

> i would like to know the current status of the layout manager and the
> related "new" format for dialogs. It's a long time since i have heard
> something about this project.

Latest development took place in layoutdialogs02 cws November 2008,
which was finally integrated in May 2009 (in DEV300m47); essentially
over 6 months for the equivalent of a `git|hg commit').

However, the patches to enable these new dialogs by default

    http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-default-enable-config_office.diff

and to optionally enable latest experimental development

    http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-disable-experimental.diff

apparently got reverted upon integration.

Matthias Bauer--after tirelessly helping to get layoutdialogs2
integrated--then kindly added thes patches to his mba32issues02 cws.
Sadly that cws got integrated only in dev300_m60 (another 4 months
later), and the --enable-layout default and --enable-layout-experimental
patches were removed [or reverted] again.

This means that layout has been essentially stalled for about 10
months due to [failing] upstream procedures.  In the mean time,
Novell has put active development support of layout dialogs on hold
in favour of dramatically improving .xlsx support.

> Is it a dead project or is somebody waiting that others will continue or
> finish it?

That depends on how you look at it :-)  I just fixed a bug
reported in the Debian build related to find and replace.
We all know that shipping code is the best [only?] way to get
new user/ developer engagement; so as that is happening now,
I have renewed hope.  Maybe someone should write a paper sometime
about `ship early, ship often.' ;-)

Currently [only] a couple of simple dialogs have been converted

    Zoom
    Word Count
    Find and Replace
    Move/Copy Sheet
    Insert Sheet
    String Input
    Delete Sheet

An attempt has been made (in layout-disable-experimental) to convert
a single tab of two tabbed dialogs

    Sort/Options [tpsort]
    Format Cells/Numbers [numfmt]

While this partly works, the resulting layout'ed TAB does not
accept mouse input, it accepts only keyboard input.  This
currently blocks further conversion of complex dialogs.  I
would very much appreciate help with this.

I have been waiting/hoping/praying for these two layout patches
to make it into upstream.  With these patches, I could ask
a VCL guru to do

   ./configure --enable-layout-experimental; make

and help debug or shed some light on this mouse/keyboard
issue.

> As far as i know parts of the code is checked in but not used
> somewhere.

Layout dialogs have been enabled in the go-oo development builds since
spring 2007 and in shipped binaries since August 2008.

> Looking forward to get some new info related to this project.

What is needed as a next step is for someone to create a whole
lot of determination, friendliness, patience and stubbornness and
integrate the latest layout patches from go-oo, ie

    http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-default-enable-config_office.diff
    http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-disable-experimental.diff
    http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-accessibility-dispose-only-once.diff
    http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-localize-fix-sc.diff
    http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-post-cws-layoutdialogs2-edit-noop-reversal.diff
    http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-post-cws-layoutdialogs2-mysteriously-missing.diff

and then fix the --enable-layout-experimental mouse problem.

HTH,
Greetings,
Janneke.

--
Jan Nieuwenhuizen <janneke@...> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl    | http://lilypond.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Juergen Schmidt-3]

Jan Nieuwenhuizen wrote:

> Op donderdag 05-11-2009 om 21:58 uur [tijdzone +0100], schreef Juergen
> Schmidt:
>
> Hi Juergen,
>
>> i would like to know the current status of the layout manager and the
>> related "new" format for dialogs. It's a long time since i have heard
>> something about this project.
>
> Latest development took place in layoutdialogs02 cws November 2008,
> which was finally integrated in May 2009 (in DEV300m47); essentially
> over 6 months for the equivalent of a `git|hg commit').
>
> However, the patches to enable these new dialogs by default
>
>     http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-default-enable-config_office.diff
>
> and to optionally enable latest experimental development
>
>     http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-disable-experimental.diff
>
> apparently got reverted upon integration.
>
> Matthias Bauer--after tirelessly helping to get layoutdialogs2
> integrated--then kindly added thes patches to his mba32issues02 cws.
> Sadly that cws got integrated only in dev300_m60 (another 4 months
> later), and the --enable-layout default and --enable-layout-experimental
> patches were removed [or reverted] again.

do you know the reasons for that?

>
> This means that layout has been essentially stalled for about 10
> months due to [failing] upstream procedures.  In the mean time,
> Novell has put active development support of layout dialogs on hold
> in favour of dramatically improving .xlsx support.
>
>> Is it a dead project or is somebody waiting that others will continue or
>> finish it?
>
> That depends on how you look at it :-)  I just fixed a bug
> reported in the Debian build related to find and replace.
> We all know that shipping code is the best [only?] way to get
> new user/ developer engagement; so as that is happening now,
> I have renewed hope.  Maybe someone should write a paper sometime
> about `ship early, ship often.' ;-)
>
> Currently [only] a couple of simple dialogs have been converted
>
>     Zoom
>     Word Count
>     Find and Replace
>     Move/Copy Sheet
>     Insert Sheet
>     String Input
>     Delete Sheet
>
> An attempt has been made (in layout-disable-experimental) to convert
> a single tab of two tabbed dialogs
>
>     Sort/Options [tpsort]
>     Format Cells/Numbers [numfmt]
>
> While this partly works, the resulting layout'ed TAB does not
> accept mouse input, it accepts only keyboard input.  This
> currently blocks further conversion of complex dialogs.  I
> would very much appreciate help with this.
>
> I have been waiting/hoping/praying for these two layout patches
> to make it into upstream.  With these patches, I could ask
> a VCL guru to do
>
>    ./configure --enable-layout-experimental; make
>
> and help debug or shed some light on this mouse/keyboard
> issue.

mmh, creating a clean cws (according to the project rules) should be
probably sufficient. I think that would be much better than integrating
it on the master directly where the code is not really used so far.

Other people would be able to take look on this cws, could review the
changes and could give feedback.

>
>> As far as i know parts of the code is checked in but not used
>> somewhere.
>
> Layout dialogs have been enabled in the go-oo development builds since
> spring 2007 and in shipped binaries since August 2008.
>
>> Looking forward to get some new info related to this project.
>
> What is needed as a next step is for someone to create a whole
> lot of determination, friendliness, patience and stubbornness and
> integrate the latest layout patches from go-oo, ie
>
>     http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-default-enable-config_office.diff
>     http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-disable-experimental.diff
>     http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-accessibility-dispose-only-once.diff
>     http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-localize-fix-sc.diff
>     http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-post-cws-layoutdialogs2-edit-noop-reversal.diff
>     http://cgit.freedesktop.org/ooo-build/ooo-build/tree/patches/dev300/layout-post-cws-layoutdialogs2-mysteriously-missing.diff
>
> and then fix the --enable-layout-experimental mouse problem.

again, i think it would be more helpful if you would create a cws, work
on it as usual, test and finalize it. And what is more important work
closely with the experts during the development cycle. I think it
doesn't scale very well if you work weeks or months on the go-oo code
line and provide a bunch of patches only.

I would to like to see at least or expect a complete picture how we want
handle this in the future. This includes one format for dialog
descriptions for core dialogs as well as for extension ...

This is my personal opinion ;-)

Juergen



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jan Nieuwenhuizen-2]

Op vrijdag 06-11-2009 om 13:31 uur [tijdzone +0100], schreef Juergen
Schmidt:
> Jan Nieuwenhuizen wrote:
> > Op donderdag 05-11-2009 om 21:58 uur [tijdzone +0100], schreef Juergen
> > Schmidt:

> > patches were removed [or reverted] again.
> do you know the reasons for that?

I don't know, there must a bug in openoffice.org's "commit" command?

> again, i think it would be more helpful if you would create a cws, work
> on it as usual, test and finalize it.

That's what I did about a year ago, and we retried again half a year
ago.  Just maybe I'll attempt it yet another time.  Otoh, in some
circles people might say that I'm unable to learn or take a hint if
I did that.

Anyway, here it is

    http://hg.services.openoffice.org/cws/layoutdialogs3

> And what is more important work  closely with the experts during
> the development cycle.

Experts: please have a look and work closely with me on this!  :-)

> I think it doesn't scale very well if you work weeks or months on
> the go-oo code line and provide a bunch of patches only.

As I understand it (CMIIW) the Go-oo project was not created to--and
does not exist to--give developers another repository to "work weeks
or months" and provide "patches only".

When I commit code to Go-oo, chances are that a binary will be built
from them and shipped to users within a week.  Sometimes within hours.
Also, upstream often did [does?] not build ootb, and it's impossible for
me to fix the build within a reasonable time frame [ie: hours].  I
can fix the go-oo build within an hour if it's broken, if someone
doesn't beat me to it ;-)

In my case with layout dialogs, it allowed me to get OO.o binaries
shipped with dialogs enabled for more than a year now...while upstream
cannot even build them yet?  Possibly the fresh layoutdialogs3 builds,
let's all pray it won't have bits removed upon/after integration and
'commit' takes less than half a year this time.

> I would to like to see at least or expect a complete picture how we want
> handle this in the future.

That's grand, please send a patch!

Greetings,
Janneke.

--
Jan Nieuwenhuizen <janneke@...> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl    | http://lilypond.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Juergen Schmidt-3]

Jan Nieuwenhuizen wrote:

> Op vrijdag 06-11-2009 om 13:31 uur [tijdzone +0100], schreef Juergen
> Schmidt:
>> Jan Nieuwenhuizen wrote:
>>> Op donderdag 05-11-2009 om 21:58 uur [tijdzone +0100], schreef Juergen
>>> Schmidt:
>
>>> patches were removed [or reverted] again.
>> do you know the reasons for that?
>
> I don't know, there must a bug in openoffice.org's "commit" command?

mmh, sounds strange

>
>> again, i think it would be more helpful if you would create a cws, work
>> on it as usual, test and finalize it.
>
> That's what I did about a year ago, and we retried again half a year
> ago.  Just maybe I'll attempt it yet another time.  Otoh, in some
> circles people might say that I'm unable to learn or take a hint if
> I did that.
>
> Anyway, here it is
>
>     http://hg.services.openoffice.org/cws/layoutdialogs3
>
>> And what is more important work  closely with the experts during
>> the development cycle.
>
> Experts: please have a look and work closely with me on this!  :-)

did i mentioned that i am no expert here, i am more interested in the
the outcome especially to use it for extensions

>
>> I think it doesn't scale very well if you work weeks or months on
>> the go-oo code line and provide a bunch of patches only.
>
> As I understand it (CMIIW) the Go-oo project was not created to--and
> does not exist to--give developers another repository to "work weeks
> or months" and provide "patches only".
>
> When I commit code to Go-oo, chances are that a binary will be built
> from them and shipped to users within a week.  Sometimes within hours.
> Also, upstream often did [does?] not build ootb, and it's impossible for
> me to fix the build within a reasonable time frame [ie: hours].  I
> can fix the go-oo build within an hour if it's broken, if someone
> doesn't beat me to it ;-)

well it's probably because you work the whole day with this repository
and that go-oo follows a different philosophy. But i don't want to talk
about this it was addressed often enough ...
I even don't like everything as it is but i accept it because of the
project rules ;-)

>
> In my case with layout dialogs, it allowed me to get OO.o binaries
> shipped with dialogs enabled for more than a year now...while upstream
> cannot even build them yet?
mmh, the questions is more why. Did you expect that other make it
working? A complete cws based on hg that build and run would be probably
integrated very fast if all criteria match the rules. And keeping such a
cws upstream shouldn't be also a problem.

  Possibly the fresh layoutdialogs3 builds,
> let's all pray it won't have bits removed upon/after integration and
> 'commit' takes less than half a year this time.
>
>> I would to like to see at least or expect a complete picture how we want
>> handle this in the future.
>
> That's grand, please send a patch!
no, probably not. I was thinking more about a wiki page where the
concepts are described, a spec of the new format, how to migrate
existing dialogs etc. A growing collection of important info where
people can find all the stuff they need to use it.

By the way i think you would be faster if you would implement the
dialogs new from scratch. Maybe some helper would be also helpful.

Juergen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Michael Stahl-3]

On 09/11/2009 16:43, Jan Nieuwenhuizen wrote:
> When I commit code to Go-oo, chances are that a binary will be built
> from them and shipped to users within a week.  Sometimes within hours.
> Also, upstream often did [does?] not build ootb, and it's impossible for
> me to fix the build within a reasonable time frame [ie: hours].  I
> can fix the go-oo build within an hour if it's broken, if someone
> doesn't beat me to it ;-)

actually, afaik, if a tagged OOo milestone does not build (especially on a
supported platform like linux/x86), and you are certain that it's a bug in
OOo and not your environment, you can file a "P1" issue, attach a patch,
and expect that patch to be committed for the next milestone.
assign the issue to your favorite release engineer, and put your second
favorite on CC:, just in case your favorite happens to be on vacation.

>
> Greetings,
> Janneke.

regards,
michael

--
Death put his skull on one side. IT'S A SMALL THING, he added.
YOU _COULD_ HAVE HAD ETERNITY.
'I know,' said Mort. 'I've been very lucky.'
 -- Terry Pratchett, "Mort"


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Mathias Bauer]

Jan Nieuwenhuizen wrote:

> Op vrijdag 06-11-2009 om 13:31 uur [tijdzone +0100], schreef Juergen
> Schmidt:
>> Jan Nieuwenhuizen wrote:
>> > Op donderdag 05-11-2009 om 21:58 uur [tijdzone +0100], schreef Juergen
>> > Schmidt:
>
>> > patches were removed [or reverted] again.
>> do you know the reasons for that?
>
> I don't know, there must a bug in openoffice.org's "commit" command?

No, I was "guilty". I made the changes in the CWS but had problems again
to compile it on all platforms with all three #define variants. As I
wanted to get my CWS into 3.2, I finally decided to remove the
"experimental" stuff from it and come back to that later in another CWS.
Sorry, I forgot to notify you about that.

> When I commit code to Go-oo, chances are that a binary will be built
> from them and shipped to users within a week.  Sometimes within hours.
> Also, upstream often did [does?] not build ootb, and it's impossible for
> me to fix the build within a reasonable time frame [ie: hours].  I
> can fix the go-oo build within an hour if it's broken, if someone
> doesn't beat me to it ;-)

You miss Jürgen's point: it's fine that your code compiles in your go-oo
code base, but that does't necessarily mean that it does the same in the
upstream code base. We always have problems integrating larger patches
that have been created on older milestones, and from my own experience I
had this in both layout CWS I have worked on together with you. Don't
get me wrong, that's not a complaint, just a fact. I hope you remember
that I tried to support you with integrating the code as good as I
could, but I wonder whether I can justify that effort for each layouting
contribution.

> In my case with layout dialogs, it allowed me to get OO.o binaries
> shipped with dialogs enabled for more than a year now...while upstream
> cannot even build them yet?  Possibly the fresh layoutdialogs3 builds,
> let's all pray it won't have bits removed upon/after integration and
> 'commit' takes less than half a year this time.

You should remember that your code didn't compile on Windows and Solaris
at all and I had a hard time getting that fixed (remember the namespace
trouble on Windows?). And every new change has the risk to break the
build again if you only compile and test it on Linux.

>> I would to like to see at least or expect a complete picture how we want
>> handle this in the future.
>
> That's grand, please send a patch!

Well, what Jürgen asked for is not doable in code. He asks for the
perspective: does it make sense to continue with this approach if you
take the number of converted dialogs per man month / year and compare it
with the number of existing dialogs? In the same time we perhaps could
have re-written more dialogs from scratch, using your layout code in the
toolkit module, perhaps with another API that does not sacrifice
modularization in favor of trying to keep the old dialog code as much as
possible.

[Explanation for my modularization concerns: we both already found out
that your current approach will either move more controls and dialogs
into the toolkit module (e.g. you had moved SvxLanguageBox into toolkit)
or creates the need to export the layout core so that the controls can
stay in their library. Perhaps a component based approach (I didn't say
UNO component, just component ;-)) would be better from a modularization
POV.]

These are only some thoughts, no verdict. I never had enough time to
dive deep enough into your code to decide if my concerns are justified
or just paranoia. It would be nice to develop a common understanding
about that.

Regards,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamformba@...".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...