Issue 97814

i tend to set this issue on won't fix because i think it doesn't make sense.
The feature that everybody wants is to make galleries deployable as extensions.
That is of course already planned, see issue 70412. I think this tool is not
necessary when have this feature and i don't see a reason to include it in the SDK.

I suggest to leave in the base layer until issue 70412 is fixed. When the
feature becomes available you should create an appropriate gallery extension and
bundle it. 

> i tend to set this issue on won't fix because i think it doesn't make sense.
> The feature that everybody wants is to make galleries deployable as extensions.

Then you still need to create the .sh/.sgv etc. files, don't you?
And that's what gengal does.

> That is of course already planned, see issue 70412. I think this tool is not
> necessary when have this feature and i don't see a reason to include it in the
> SDK.

And how would you create the files you need to put into the oxt then?

.shm files that is.

> And how would you create the files you need to put into the oxt then?

Doing it manually on every new version of openclipart (or whatever else shipping
cliparts) is a) unneeded manual work b) tedious c) error-prone, so gengal was done
to have tool doing this.

*If* Issue 7042 still needs the "old" files, gengal still has to stay even after it.

i don't have really understand what gengal does exactly and maybe you can
summarize it.  

jsc: ok...

Basically it's like the following:
 - a OOo gallery item consists of three files (sg??.{sdg,sdv,thm}
 - gengal creates them out of a filelist of images (like you would do manually
   in the OOo UI in the gallery with "New Theme.." (which btw probably means new
   topic/subject, but anyway) - though afair with the (minor) difference
   that gengal lnks to the files and does not embed then.
 - Those files currently are put into the OOo install dir. From Debian lennys
   openclipart-openoffice.org package
(http://packages.debian.org/openclipart-openoffice.org):

$ dpkg -L openclipart-openoffice.org
/.
/usr
/usr/lib
/usr/lib/openoffice
/usr/lib/openoffice/share
/usr/lib/openoffice/share/gallery
/usr/lib/openoffice/share/gallery/sg70.sdg
/usr/lib/openoffice/share/gallery/sg70.sdv
/usr/lib/openoffice/share/gallery/sg70.thm
[...]

If we now look at e.g.
http://extensions.services.openoffice.org/project/oxygenoffice-gallery which is
an extension containing clipart/gallery stuff we
see in gallery/ the exact files a "normal" "New Theme..." in OOo (or gengal)
would create. In fact, I know that OOOP actually does use gengal.

So gengal is still needed for external people to create those files, be it that
those files end up in OOos dir or in an oxt. See it as a external tool for
creating extensions or add-ons. What the SDK is: OpenOffice.org "software
development kit". Those .shm/.sgv/.thm files are also software ;-)

at the moment we will let this tool where it is. Shift target to 3.2

accepted for further investigation

how we move forward with this issue depends on issue 70412. Set target to 3.x
because i don't see that i will do anything here in a 3.2 timeframe. 

jsc: I don't see at all what this issue has to do with issue 70412...

issue 70412 is about what files the gallary expects/gengal creates. That is not
relevant in any case where gengal is located (in the "normal" install or in the
SDK).

If you aim to get rid of gengal, this is impossible unless you change the
gallery to an other format and get rid of all those sg*.* files (which need to
be created by gengal, even if they are shipped inside extensions or whatever)

it is no direct relation to 70412 that is correct. But i would like to see this
issue fixed first and then we can decide how we can make it easy for developers
to provide galleries as oxt.

Until that i won't fix this issue and won't integrate it in the SDK. It's fine
as it is until we have a better solution. So please let the target as it is. It
doesn't make sense to set a target where i know for sure that i won't fix it in
this time frame. 

Reset assigne to the default "issues@openoffice.apache.org".