Reassigning issue + add cloph on CC

ericb->obrmac

If I'm not too wrong, the mai work has to be done in scp2, and cloph is willing to help for that issue.
Can you see with him ?   Thanks in advance

Setting keyword

O.k., let's start.

The following patch (against m199) modifies the tree for both OSX version (aqua and X11) in the way that 
it treats the MacOS directory as "program" directory and thus moves everything up for one level.

The only aqua related thing is the replacement of "soffice" script with a symbolic link.

The only thing missing is a "sed" line which changes Info.plist to contain "soffice" instead of "droplet" for 
the aqua version. 

Created attachment 42533 [details]
Patch to scp2 to tweak bundle structure

It doesn't seem to be necessary to move the stuff to different places.

Just modifying Info.plist to point to program/soffice.bin and building desktop
module is enough.

(probably when extracting the package from the dmg there are some other files
written that require the additional moving around of things - but when the
modified Info.plist is alread in the dmg, things work out-of-the-box)

Adding to Meta Issue.

ericb->oliver

I have tested your patch, but something is wrong, and when I try to launch OpenOffice.org, I have a 
message saying the bundle is damaged.

Maybe some part is not at the good place ?

ericb->obrmac

Can me make a point for that issue ? 

I just confirmed that changing Info.plist in desktop to point to program/soffice
(with soffice being a symbolic link to soffice.bin) does also work for me. So I
am going to remove the tree relocating part from this patch.

BTW: changing Info.plist in the created bundle did not work for me, it seems the
change has to happen before osacompile ?! 

So I am going to introduce a s/droplet/program\/soffice/ in desktop unless this
causes problems for debugging with Xcode. Is the symbolic link approach sufficient
to work around Xcode's problem with '.' executables ?

Created attachment 43982 [details]
Patch against aquavcl01 (m202)

The second version of the patch includes changes in framework/desktop, but needs
to be updated as soon as aquavcl01 gets resynced.

For me, the office installed from the created dmg launches fine, but does not
have native menus.

ericb->obrmac

Oliver,

I tested your patch, and everything seem ok for me ( wizards, Base - just started - )

Short patch, big effects :  thank you very much : !  :)


@pavel : maybe we could resync with a recent milestone, then Oliver will adapt the patch to the last 
changes in desktop and instsetoo_native  (macosxversioning cws or something)  ?



P.S. :  for native menus, just comment Pavel changes in vcl/aqua/source/window/salmenu.cxx

Created attachment 44379 [details]
new patch after m208 resync

ericb->obrmac

I have adapted your patch to m208 (just two huncks to be modified ). 

A quick try let me see it works as expected : double click on the fina bundle, ... et hop  :) 

Can you confirm it is ok, and commit everything in aquavcl01 ?

Thanks

Michael Sicotte reported a bug with the previous patch : in the main menubar, we see soffice.

I'll attach a new patch to make OpenOffice.org appear instead  :-)

Created attachment 44417 [details]
New patch using OopenOffice.org instead of soffice as application name

Created attachment 44421 [details]
Correct fix instead of broken hack

The patch above fixes the issue properly. The aquabundle4.diff was a hack and broken.

ericb->mox

Explain why the previous patch was broken, instead of present things like you do is more constructive 
*for all*

Thanks in advance to keep that in mind.

Created attachment 44423 [details]
new patch:  versioning + use OpenOffice.org (instead of soffice ) as application name

ericb->mox

Thanks for the correct versioning, but this is not complete : we see soffice in the main menubar.

New patch fixing that is attached

Created attachment 44424 [details]
should-be-fully-working patch, with _correct_ fixes

As there were some more discussions on the list about this issue, can we please
summarize what exactly we want to achive with this patch ?

What exactly does not work when using the program/soffice approach ? And: wasn't
there an issue with gdb and '.' executables ?

Created attachment 44656 [details]
Complete patch, verified on X11 too, including Mox's changes too

Attached the IMHO correct patch.

All changes verified with Oliver. thanks to all contributors.

The latest patch looks good. 

Although I can't apply it to my test tree directly, because the patch has "+++
instsetoo_native_new/..." -style paths. It's a small thing, but a bit uncomfortable.

ericb->mox

How do you apply this patch ?

patch -p0 <i73693_test5.diff

in $SRC_ROOT works without any glitch on OpenOffice.org tree ... 

changes commited in aquavcl01

as discussed on IRC, Oliver will create a cws, and once integrated, the resync will solve everything.

IMHO, this issue is ( first step) fixed.

ericb->obr

did you find some time to create the cws we discussed ?

I commited a slightly modified version of test5.diff to CWS aquabundle, but will additionally change 
soffice.bin to soffice-bin before marking this issue as fixed.

ericb->obr

Ok, I'll check the sources, and test everything tomorrow afternoon (or later if
changes are not complete)

Created attachment 45501 [details]
Patch to rename soffice.bin to soffice-bin

The last patch renames soffice.bin to soffice-bin on MacOS X. However, I found a problem with the X11 
build: with this change, the "sofficerc" UNO bootstrap file is no longer recognized as matching to soffice-
bin, leading to the macosxrc.txt file (needed for aqua like colors) being ignored.

Assuming that we might consider renaming other ".bin" binaries to "-bin" as well, probably the right thing 
to do is to add "-bin" to the recognized file extension list in sal/rtl/source/bootstrap.cxx.

My understanding is that file extension is defined with the ".", not the amount
of letters. For example Mac OS X can have "foo.applescript", with the
.applescript correctly identified as an extension.

Thus, I thought soffice-bin would be treated as extensionless thing. 

Even if the "-bin" -extension would be specific to the OOo universe, are we
shooting our foot? I could imagine stuff silently breaking with Mac or non-Mac
platforms adding files like flash-bin-image.dat

Yeah, thought about that too. However, since soffice-bin _is_ currently treated
as extension-less thing, actually that is the problem: we would need to rename
"sofficerc" to "soffice-binrc" to get it recognizes again.

Another option would be to only use "soffice" for the binary, but how should we
name the start script for X11 then ?

OTOH we could reduce the risk of mis-interpretation by only treating "-bin" at
the end of the name as something to cut off. The existing code in rtl/bootstrap
does pretty much the same thing with ".exe" and ".bin" (and does not handle any
generic file extension).

I just stumbled about this issue without really understanding what it's all
about. But, please be very carefull in renaming something into -bin and take
that as 'extension'. I'm not sure what kind of tooling relies on '.' as
extension delimiter. Things like crash mail resolution, f.e. 
I do not know anything will break, but I'm afraid things may break.

Something that would make sense in the general UNIX world too:
Rename soffice to soffice.sh     (i.e. the shell script. Most people use the GUI
anyway)
Rename soffice.bin to soffice    (IMHO happens to be the most "Apple-like"
alternative too)

The above should work, if I understand the situation correctly.

A bit more Apple-likeness, would be to rename sofficerc to sofficerc.txt or some
other extension. But that's not so important though. 

I have submitted issue 77967 to discuss the Xcode problem further. For this issue, just ignored the latest 
patch (not commited).

Tested on X11 build : no problem so far

Issue verified fixed in aquabundle cws. Change will be integrated in both ( X11 and aqua versions )

Aquabundle is now integrated. Can we close this issue now?

Yes.