Hi Knut,
On Tue, 2011-07-26 at 23:20 +0200, Knut Olav Bøhmer wrote:
> > Sadly I don't know. I imagine you need to avoid the splash binary -
> > and
> > run soffice.bin. I would be tempted to remove soffice.exe rename
> > soffice.bin -> soffice.exe and debug that way.
>
> I found it.
> devenv /debugexe program args
Great ;-)
> I had to "cd URE\bin\" because I got an error message about sal3.dll.
> Why does we have two binaries?
Well - one in theory is a small binary that passes its arguments to the
main 'factory' process that is running: this speeds up the 2nd launch.
Unfortunately the 'small-ness' of that binary is bloated to (was it 3 or
6 Mb I forget) by all the embedded icons needed for associating that
with the umpteen file-types we support [ or something ].
> > Oooh ! and if you can build / debug on windows :-) perhaps you could
> > help fix the dumb-ness that we duplicate many megabytes of icons between
> > soffice.bin and soffice.exe (?) it requires only a small set of hacks I
> > think.
>
> Do you have more information?
Those same icons are then all present in soffice.bin as well in order
to get window icons correct. Instead of that we should just be loading
the window icons from our images.zip [ where they also live ], and
setting them on the window at run-time I think.
That is what we do for the gtk+ backend, cf. GtkSalFrame::SetIcon and
just needs replicating for Windows - so we can drop that duplication.
gtk+ has a means of doing this for windows, so there is the API support
there somewhere.
HTH,
Michael.
--
michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
