Changes needed for "LibreOffice 4"

On Thursday 19 of July 2012, Michael Meeks wrote:
 I think one of the first things that need to be done is actually saying
what "LibreOffice 4" means. Looking at the wiki page linked above, apparently
that's not clear at all.

 I see 3 reasons for why we should have LibreOffice 4 (not necessarily
exclusive):

a) for marketing reasons - we want to be like Firefox, we want to match AOOi
(who AFAIK might go to 4.0 somewhen soon), or similar completely
non-technical reasons
b) we do significant user-visible changes, such as UI rework, or something
that make the new LO version quite different from the previous ones
c) we break backwards compatibility

 As a) is not technical at all, there's not much point in discussing it on a
development list. If that needs to be done, we stamp "4" on it and it's done.

 Option b) is actually rather similar to a) in that if it's decided to be
done, we just do it and that's it, it just will be more work. I'm not aware
of anything significant in this area that'd warrant this, so I think we can
ignore this one (correct me if I'm wrong).

 Option c) can mean either stopping supporting some file formats, or breaking
API/ABI compatibility. For file formats we want to do this with binfilter
AFAIK, nothing else, and this is a lot like b) as well in that it's just done
and that's it. Breaking API/ABI compatibility for LibreOffice means breaking
(only) extensions, which depending on the changes may need recompiling,
adjusting or complete overhaul.

 Now, if you look at
http://wiki.documentfoundation.org/Development/LibreOffice4 , a lot of the
stuff there does not belong to the page at all, as it has absolutely nothing
to do with any of the above:

- "get rid of ASCII graphics noise (//=================== etc)" is actually an
EasyHack that just should be created as such, and can be done at any time
without affecting anything else. There are a number of items in the list like
this.

- "de-UNO-ize the ODF import and export filters." is a purely internal matter
that does not affect anything outside of LO core (or am I wrong here?) and as
such it can be done at any time. Again, nothing to do with LibreOffice 4
(unless we want to use "4.0" as an excuse if things go wrong). There are
several more like that.


 So, as long as we decide to do c) when switching to LO4 (which AFAIK we plan
to do, even if c) alone is not the reason), the page first needs to be
cleaned up to contain only items that actually do have something to do with
LibreOffice4.

 And after all this is done, it should be easier to actually talk about LO4,
because we'll know what the talk is actually about. As for the technical
details (i.e. c) ), we'll need to decide how to handle the breakages it'll
cause for extensions. Note that as extensions use only URE (right?), affected
code is actually relatively small (AFAIK sal/, salhelper/, cppu/,
cppuhelper/, udkapi/ and offapi/, not sure about the last one). I see roughly
several ways:

1) We say we don't care about backwards compatibility, and keep possibly
breaking it every release. Extensions will need to check they run with
exactly the same version they were built for.
+ easy for us
- more work for extension developers (#ifdef's , they'll either support just
newest LO, or need to provide several versions)

2) We break compatibility once for 4.0 and keep it again afterwards. IOW like
we've done so far.
+ extensions will need to be updated once and then it'll stay the same for
them
- we need to manage to do this between 3.<last> and 4.0 , which may be quite
some work and risks the KDE4.0 fate and the bad options (release too late,
release too buggy, get stuck with stable 3.x and never stable 4.x); I have
some experience with this from the KDE times and, unless we find out we don't
actually have much work in front of us, we probably don't want to go there

3) = 1)+2) - we break it at 4.0, keep going with 1) until we're confident
enough we can manage 2) again
+ easy for us (we just should end up with decently designed APIs for
extensions, or we may need to do this again)
- more work for extension developer, until we enter 2)

4) We do 2), but we smooth it out with a transition period (backwards
compatibility wrappers). I believe that a number of the LO4 changes can be
done in a compatible way with just a little more work (I have quite some
experience there from the KDE times too). For example, the
com::sun::star::* -> uno:: change is probably doable in 3.x by introducing
the new names that would map to old ones. This would allow us to test this
already in LO core without affecting extensions. Another example, if we
change rtl::OUString, we may rename and change it for LO4 and keep the old
one for backwards compatibility. In short, this is 3) where we put more work
into not breaking extensions.
+ extensions will need to be updated once, or possibly even not at all
- may need some extra work (although it's a question of how much)
- possibly some code duplication (although the old code may be later removed,
so this may be just having a time overlap with the new/old code)
- if LO4 needs to be out soon for whatever reason, we may not have the time


 I'm not going to say which solution would be the best, because it depends on
what we expect from "LibreOffice4" (how much we are actually going to change,
how much we care about extensions, etc.). So for that, we should first decide
on what "LibreOffice4" will mean.

 Summary:
- it needs to be said what we expect from "LibreOffice4"
- the wiki page with technical tasks needs to be cleaned up
- we need to decide how to deal with the fact that LO4 will break backwards
compatibility

--
 Lubos Lunak
 [hidden email]
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

2012/7/20 Lubos Lunak <[hidden email]>:
For me the 4 Version would be different from other versions, if the
office suite includes a browser and a messenger
http://interface.sf.net and http://dooble.sf.net

Like MS Office 360 has Skype and Cloud.
Regards Randolph
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Hi Randolph,

On Fri, 2012-07-20 at 17:29 +0200, Randolph D. wrote:
> For me the 4 Version would be different from other versions, if the
> office suite includes a browser and a messenger

        This is a developer list. Please move this suggestion to the discuss
list. It is fine to have vision & suggestions of this kind - as long as
they are backed by real code, patches etc. :-)

        This is the 2nd time I've had to write essentially the same mail on
exactly this topic to you in the same week. I love your idea - as long
as it is backed by the hard-work required to produce the code, to make
it happen :-)

        Thanks,

                Michael.

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Fri, 2012-07-20 at 17:20 +0200, Lubos Lunak wrote:
>  Now, if you look at
> http://wiki.documentfoundation.org/Development/LibreOffice4 , a lot of the
> stuff there does not belong to the page at all, as it has absolutely nothing
> to do with any of the above:

        Can you edit the page to separate the pieces that you don't believe
require ABI change from those that do ?

> - "de-UNO-ize the ODF import and export filters." is a purely internal matter
> that does not affect anything outside of LO core (or am I wrong here?)

        that depends on whether crazy people have tried to hook into / use
those interfaces from their scripts etc. Anything exposed is scripting /
plugin-authors is liable to their random walk attacks of this nature :-)

>  Summary:
> - it needs to be said what we expect from "LibreOffice4"

        Very true; I've used it to refer to the ABI breakage we've been needing
for a long time to cleanup our accumulating cruft issues.

> - the wiki page with technical tasks needs to be cleaned up

        It'd be great if you could do that separation :-) please don't delete
anything though - some tasks are rather succinct but useful to retain.

> - we need to decide how to deal with the fact that LO4 will break backwards
> compatibility

        Of course, we need some good technical ideas. In particular, I'd love
some stub / skel libraries and clever bridging with old names to rid us
of the com::sun::star evils ;-)

        ATB,

                Michael.

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

ok michael, you wrote friendly, so all ideas given. but I wounder why
Lubos is allowed to write about a marketing brainstorming :-)

2012/7/20 Michael Meeks <[hidden email]>:
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Hi,
I have some ideas :

1. rewrite whole LO (writer, base etc.) from scratch, which would make all documents unable to open in 3.x. This is very important task, mainly because of MS Office and the future of LO. The whole thing with plugins should be same as with documents.
   
2. make a very long period of testing (beta1/2/3,rc1/2/3/ and then stable 4.0). Even longer then we have know. I think we should release 4.0 with almost no bugs.
   
3. kick Draw and Math-parts out of LO. Either make it as plugin or just kill it. 1) nobody uses it (Math> Latex; Draw > photoshop, corel, gimp etc.); 2) installer can be smaller.  

--
@Malcjohn


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On 20/07/12 18:27, Randolph D. wrote:
> ok michael, you wrote friendly, so all ideas given. but I wounder why
> Lubos is allowed to write about a marketing brainstorming :-)

Lubos writes about _what_?

On 20/07/12 17:20, Lubos Lunak wrote:
> a) for marketing reasons [...]
>
>  As a) is not technical at all, there's not much point in discussing it on a
> development list. If that needs to be done, we stamp "4" on it and it's done.

please learn to read.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Fri, Jul 20, 2012 at 06:33:20PM +0200, john malc <[hidden email]> wrote:
>    1. *rewrite whole LO*

I know, it's Friday, but still... ;-)

Some reading: http://www.joelonsoftware.com/articles/fog0000000069.html
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Friday 20 of July 2012, john malc wrote:
 You are welcome to start your own office suite from scratch, but if you
actually do, you'll soon find out that it'll take you ages to get anywhere
near to what LibreOffice is now.

 I didn't mention it explicitly, but since this is a development list, I
expect discussion about what _realistically_ can be done. If you want just to
post some random unfounded ideas on which you are not going to actually work,
please take it elsewhere, such as the discuss list.

--
 Lubos Lunak
 [hidden email]
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Friday 20 of July 2012, Michael Meeks wrote:
> On Fri, 2012-07-20 at 17:20 +0200, Lubos Lunak wrote:
> >  Now, if you look at
> > http://wiki.documentfoundation.org/Development/LibreOffice4 , a lot of
> > the stuff there does not belong to the page at all, as it has absolutely
> > nothing to do with any of the above:
>
> Can you edit the page to separate the pieces that you don't believe
> require ABI change from those that do ?

 I can, but I don't think I know enough to know about all of them. I can mark
some as questionable though.

> > - "de-UNO-ize the ODF import and export filters." is a purely internal
> > matter that does not affect anything outside of LO core (or am I wrong
> > here?)
>
> that depends on whether crazy people have tried to hook into / use
> those interfaces from their scripts etc. Anything exposed is scripting /
> plugin-authors is liable to their random walk attacks of this nature :-)

 Hmm. That makes it something we should take into consideration then, but that
consideration may be quickly over with saying that it's internal API and as
such we don't care about people who abuse it.

--
 Lubos Lunak
 [hidden email]
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

john malc wrote:
> I have some ideas :
>
Again the reminder that ideas or discussions _without_ any intention
to work on them *in the code*, are off-topic here. Please move them
to [hidden email] (subscribe via email to
[hidden email]).

Thanks for keeping this list focused,

-- Thorsten

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Fri, Jul 20, 2012 at 06:33:20PM +0200, john malc wrote:
> Hi,
> I have some ideas :
>    3. kick Draw and Math-parts out of LO. Either make it as plugin or just
>    kill it. 1) nobody uses it (Math> Latex; Draw > photoshop, corel, gimp
>    etc.);

Can we see the numbers, please?

> 2) installer can be smaller.

You _are_ aware of the fact that Math is tiny compared to the other apps
in LibreOffice (not mentioning the core libs that _must_ be installed)
and that Draw shares practically all of its code with Impress, are you?

D.
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Lubos Lunak wrote:
>  Hmm. That makes it something we should take into consideration then, but that
> consideration may be quickly over with saying that it's internal API and as
> such we don't care about people who abuse it.
>
There's more nuance required here I think. Substantial use of
"unstable" API still leaves us with noticeable repercussions on the
extension ecosystem, that we might want to have *once*, and not
spread over multiple releases.

Cheers,

-- Thorsten

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On 07/20/2012 12:50 PM, Lubos Lunak wrote:

You can remove it from the list.  I'm the one who added it because back
then we were tasked with listing all major architectural changes of
which this was certainly one.  But in the end this work doesn't really
affect the existing UNO API, and we are already working on that for 3.7
(one of Daniel's GSOC tasks).

So, it's safe to remove it IMO.

Kohei


--
Kohei Yoshida, LibreOffice hacker, Calc


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Friday 20 of July 2012, Lubos Lunak wrote:
 Done. I'm rather unsure about a number of them, and I may have misplaced
others, so please check.

--
 Lubos Lunak
 [hidden email]
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Friday 20 of July 2012, Thorsten Behrens wrote:
> Lubos Lunak wrote:
> >  Hmm. That makes it something we should take into consideration then, but
> > that consideration may be quickly over with saying that it's internal API
> > and as such we don't care about people who abuse it.
>
> There's more nuance required here I think. Substantial use of
> "unstable" API still leaves us with noticeable repercussions on the
> extension ecosystem, that we might want to have *once*, and not
> spread over multiple releases.

 Even if people actually do use our internal APIs, that doesn't mean we have
to leave it that way. And that does not necessarily mean hiding it
intentionally. If we are going to make the effort to keep those APIs stable,
we may as well just make them public.

 And, in general, if it's likely that some internal APIs might be used from
the outside, then we should consider a way of avoiding that. If it's
internal, somebody is going to change it somewhen. So we should hide it, or
maybe somehow visible mark it as such and add "if you find this useful,
contact us about about it public", or so. Being afraid to change internal
interfaces just because somebody from the outside might be using that is just
lame (incidentally, that's another thing I have experience with).

--
 Lubos Lunak
 [hidden email]
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Friday 20 of July 2012, Lubos Lunak wrote:
>  And after all this is done, it should be easier to actually talk about
> LO4, because we'll know what the talk is actually about. As for the
> technical details (i.e. c) ), we'll need to decide how to handle the
> breakages it'll cause for extensions. Note that as extensions use only URE
> (right?), affected code is actually relatively small (AFAIK sal/,
> salhelper/, cppu/, cppuhelper/, udkapi/ and offapi/, not sure about the last
> one).

 By the way, could somebody please confirm this or list the things where we do
need to care about stability to the outside world? I know ure/source/README
has a list of libraries, but this is not only about libraries.

--
 Lubos Lunak
 [hidden email]
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Hi Thorsten,

On Friday, 2012-07-20 19:03:41 +0200, Thorsten Behrens wrote:

> Lubos Lunak wrote:
> >  Hmm. That makes it something we should take into consideration then, but that
> > consideration may be quickly over with saying that it's internal API and as
> > such we don't care about people who abuse it.
> >
> There's more nuance required here I think. Substantial use of
> "unstable" API still leaves us with noticeable repercussions on the
> extension ecosystem, that we might want to have *once*, and not
> spread over multiple releases.

Well, an API not being marked as published exactly tells authors that
the piece may change or go away at any given time, not bound to any
major release or whatsoever.

But it should be possible to determine at least vaguely the clear text
names of services, interfaces and properties an extension uses so maybe
we could setup some "scan your extension" service where one can throw an
extension in and get a list of API used and maybe split in sections
stable, unstable and questionable ...

  Eike

--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Fri, 2012-07-20 at 19:59 +0200, Lubos Lunak wrote:
>  By the way, could somebody please confirm this or list the things where we do
> need to care about stability to the outside world? I know ure/source/README
> has a list of libraries, but this is not only about libraries.

        In the worst case, documents contain StarBasic macros that do the
oddest things using the most tangled UNO APIs you can think of :-)
Including FooInterface7 - the 7th attempt to get it right, highlighting
again the lack of a need for fundamental extensibility ;-)

        The IDL is also compiled into JAR files that are necessary to link Java
plugins; configuration keys are also part of the ABI; and ideally the
behaviour is also predictable.

        Of course, most of this is a myth; the chart2 re-write had some very
substantial changes to the UNO object model built-in, and IIRC almost
no-one complained: then again chart2 was much prettier than chart1
so ... perhaps that's why.

        The real problem is, that there's no good way of telling what UNO / C++
interfaces people are actually using in their binary / proprietary
extensions. Unfortunately (apparently) there is no signature that we can
unwind from use of an interface - though that could be altered for the
future. That result still amazes me - surely there is some in-lined
class / type information somewhere. Eike's idea of running 'strings' on
a few binary exensions seems like a great one - if we have a bazillion
duplicate ::com::sun::star's in our binaries, surely others must have
been infected too ;-)

        Then again - how much sympathy for the proprietary world we should have
is unclear. Then again - some binary proprietary plugins are
indispensable to some segments - eg. Quebec has some great French /
grammer checker to help those french-as-a-second-language writers, or in
Germany the Dudencorrector seems popular etc. etc.

        But - yes, getting hard numbers; and better hard lists of which
interfaces are actually used out in the wild would be awesomely useful
when making this sort of decision :-) Any help collecting that is -much-
appreciated.

        ATB,

                Michael.

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On 07/20/2012 05:20 PM, Lubos Lunak wrote:
>   Option c) can mean either stopping supporting some file formats, or breaking
> API/ABI compatibility. For file formats we want to do this with binfilter
> AFAIK, nothing else, and this is a lot like b) as well in that it's just done
> and that's it. Breaking API/ABI compatibility for LibreOffice means breaking
> (only) extensions, which depending on the changes may need recompiling,
> adjusting or complete overhaul.

Breaking API compatibility is not only about breaking extensions.  It
also affects scripting (aka macros, that "Tools - Macros" stuff, which
can also be embedded in documents) and external code interfacing with LO
(like unoconv).

>   And after all this is done, it should be easier to actually talk about LO4,
> because we'll know what the talk is actually about. As for the technical
> details (i.e. c) ), we'll need to decide how to handle the breakages it'll
> cause for extensions. Note that as extensions use only URE (right?), affected
> code is actually relatively small (AFAIK sal/, salhelper/, cppu/,
> cppuhelper/, udkapi/ and offapi/, not sure about the last one). I see roughly
> several ways:

Yes, all the above (incl. offapi), plus more: Java, Python, CLI language
bindings; URP; officecfg/registry/schema; ...

Having old and new coexist side by side has a lot of merit, indeed.
This also includes bridging, where UNO could detect that two components
are incompatible with each other and place a (manually or automatically
implemented) bridge in between that can map between the two worlds.
However, this is not without drawbacks:
- Even if some mechanism was initially only intended as a temporary,
removing it again can easily be delayed for quite a while (cf.
binfilter), leading to increased overall complexity for practically
unlimited amounts of time.
- Bridge code can be poorly tested, making it useless in practice.
(Like for an old extension that uses some obscure feature, for which
bridging has never been tested by the developers.  The old extension
would be discovered to be dysfunctional in new LO by users, just as if
there had been no special bridge code available, but at the increased
cost overall of having to write the bridge code in the first place.)

A few thoughts on "the com::sun::star::* -> uno:: change":  The
com-sun-star prefix is used in at least two places:

1  As a namespace for UNOIDL definitions in udkapi/offapi (which leads
to like-named namespaces, packages, etc. in the various language
bindings; and to usage of string literals for service/singleton access,
at least for old-style ones).

2  As a namespace (C++), package (Java), etc. for language-binding
specific entities (like C++ com::sun::star::uno::Reference and Java
com.sun.star.uno.UnoRuntime).

Whether renaming can be done compatibly is highly variable:  For
example, many C++ entities could be renamed with typedefs, while some
could not (templates, at least with C++98 with which we are stuck for
now).  What could work better for C++ is a namespace alias (but maybe
not "namespace uno = com::sun::star" as it could cause confusion in
existing code that also uses "namespace com::sun::star::uno;").  On the
other hand, no such tricks are available in Java.

My personal take is that such a rename causes way too much deliberate
breakage to be worth it.  (After all, a name is just a name.  Lots of
projects are stuck with outdated naming, like the NextStep "ns" prefix
in Mac OS X.)

Stephan
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice