before (or maybe in parallel to) checking whether Askbot is usable as a
platform for LibreOffice extensions we should clearly define what
requirements are needed. There is a very old document circulating In the
other thread, which _describes_ the state of the current site. Based on
these insights we created a new document for a new hosting platform. The
document is shared on
https://nextcloud.documentfoundation.org/s/E5RX5xK6jxQPLdK and open for
After reading through the comments on the other thread I'd like to
outline a scenario: We do provide access to Firefox Personas (Tools >
Options > Personalization) (being reworked currently) where the user can
place an image in the background of the toolbar/notebookbar. Those
themes are a great success with gazillions of contributions. It's a bit
embarrasing that we have to access data from another project and could
host those images ourself.
As a user you probably don't know about this option to extend the
program. So we should give access to it from the place where it is
listed. You want to browse, sort and filter by different kind of
attributes, mark favorites, load.
As creator of, let's say the pink theme for best integration into the
dreamland desktop, you have no idea about sharing data, meaning the
upload must be easy. There are a couple of settings needed such as
license where a wizard like guidance makes sense. But in the end as less
info as possible to make the upload a breeze.
Some "cornercases" (actually secondary requirements) have to be
considered. Our current platform requires maintainers to state the
compatibility with every new release (which is again a very code
oriented view). And maintainer likely don't want to be in charge
forever. My take here is to switch to a community based approach and
flag non-working extensions as outdated/orphaned. Communication between
creator/maintainer and user is essential in open source. Maybe the
dreamland has some unicorns that should be added.
Hope all this becomes clear with the shared document and the mockups.
Am 13-Oct-18 um 10:14 schrieb Bjoern Michaelsen:
> Hi Heiko,
> On Sat, Oct 13, 2018 at 09:52:01AM +0200, Heiko Tietze wrote:
>> Based on these insights we created a new document for a new hosting platform.
>> The document is shared on
>> https://nextcloud.documentfoundation.org/s/E5RX5xK6jxQPLdK and open for
> Thanks for sharing that.
> That looks indeed like a very promising approach to finding the core functionality
> that is needed.
Thanks, I added some comments, suggestions. And text (Ctrl+Shft+E starts
/ stops tracking changes ;) )
I didn't (yet) look in the mail from Andreas_k (1) to add/compare but
think the set we are looking for, can be nice and basic.
On 10/13/18 9:13 AM, Cor Nouws wrote:
> Thanks, I added some comments, suggestions. And text (Ctrl+Shft+E starts
Picking up a comment made by Heiko:
«If the release would be a property of the project we could remove a lot
of needed interactions. Drawback is that only one release is stored.
Does that make sense?»
This raises the idea that perhaps extensions.git.libreoffice.org should
be a thing. A self-hosted git repository.
Bot-driven, it would clone the developer's site, build the extension,
and create the catalogue.
Lot more thinking needs to be done about how to construct it, write the
automation bots, etc.
Still doesn't solve the issue of "not enough volunteers".
Also means yet another piece of software that TDF has to look after.
Responding here, cause it is easier for me.
(Not sure why the site let me download it once, without logging in, but
when I tried to downloading it from my main system, it insisted on a
password. And of course I failed the ReCapcha.)
(For starters, why on earth is everything "default style"? All markup
done manually‽‽‽ )
>If an extension is broken would be reported by users not the author.
Some authors are pro-active, in determining if their extension is broken
in a new version of LibO.
There are also edge cases where an extension may run:
* Only on one platform; Eg: Windows, but not Linux or Mac OS X. Android,
but not Linux, Windows, or Mac OS X, etc.
* Only with a specific language User Interface. IIRC, JILT is an example;
* RUn only when another extension is also installed. By way of example,
CMath requires CMathCAS to be installed.
>Most of those are already in the metadata of an extension.
Neither the current collected set of meta data, nor the set proposed
within the document include every datapoint from Dublin Core, nor of its
successor. If metadata is to be provided, at least do Dublin Core, if
not its successor.
>homepage. Is this really needed?
It isn't uncommon for developer/creator to use something other than
their email address for:
* providing alpha/beta versions of extensions/templates;
* feedback mechanism, be it a mailing list, or bugzilla or something else;
* Additional documentation;
For when the extension, or template appears to be abandoned, the
homepage as oft as not:
* states that the extension is no longer being developed, maintained, or
* has switched to commercial distribution and support only;
* However, there is at least one vendor who declaims all knowledge of a
LibO extension for their product;
>Categories: Would strongly recommend to change this into single
selection of category (dictionary, clipart, color palette...) with
single selection and scope (Writer, Calc..) with multi selection.
In essence I agree.
There are a couple of corner cases, but they can be solved as they come
up. Off hand, the only three examples I can think of, are an Accounting
package, and a Project Management Package, both of which utilise Base,
Calc, and Write, and a Business Startup package, which either utilises
Calc, Impress, and Write, or just Impress and Calc.
I've seen reference to a corporate house style that appear to include
colour palettes, dictionaries, fonts, and templates for Write, Calc,
Impress, Draw, Math, and Base. If anything along those lines escapes
from their corporate guard, simply make "House Style" a top level category.
As a user, I like seeing the logo, because it makes it more apparent if
I found the extensions/template I want.
By way of example, there are two extensions that assist with Greek
characters _Ancient Greek_ and Polytonic Greek_. In a pinch, they sort
of overlap, but for writing in Biblical Greek, the former is slightly
more functional. Telling a Bible Study class that they want the
extension with a red logo makes it far more likely that everybody in the
class will get the "correct" extension.
On the flipside, both Simplified Chinese Punctuation bar, and
Traditional Chinese punctuation bar use the same logo. Really hard to
differentiate between the two, by logo alone.
Furthermore, as oft as note, taht logo is the identifier on whichever
toolbar it places itself upon.
>Extension most certainly contain a description of themselves.
They do, but as oft as not, that description is inadequate. By way of
* Which versions of GedCom does the GedCom Import extension support?
* Which playback devices does the Transcriber extension support?
* Which Braille printers does ODT2Braille support? (Ignoring that that
extension appears to be abandoned.)
>If the release would be a property of the project we could remove a lot
of needed interactions.
At the expense of requiring yet more volunteers, and cash, perhaps
setting up extensions.git.libreoffice.org that is used exclusively to
create extensions, templates, palettes, fonts, clip-art, etc. that is
used by LibO should be done. This way, if the item has the appropriate
license, a LibO volunteer could take over maintaining the item. Umm,
maybe not extensions, per se, but certainly templates, sound-effects,
and all the other things that are deliverable as .oxt files.
Either a bot, or an individual could walk through each project, flagging
it for missing items ---- license.md, readme.md, metadata.md, etc.
>Publishing Data, Expiration Date, Why?
Publishing date can give one an idea of which version of LibO it should
work with. Expiration date, is because sometimes an external API that
the extension relies, closes, with an announcement made months, or even
years before. I'd give an example, but thanks to the miracle of
simultaneous hard drive failure, I can't. (In backing up my hard drive,
both drives simultaneously failed, thereby losing all of the extensions,
and notes I have on them, for roughly the past decade. (Four TB flew
into the digital aether. ) A similar thing happened when I previously
tried, and failed to back up a storage drive. That time I lost my notes
from circa 2001 through circa 2010.)
>Categorization: Language: single, multi. Why should the release differ
from the project.
After I've drawn a mockup, and written dummy code that demonstrates how
it works, I'll submit an RFE to redesign/redo the entire language
selection. Rounding, there are 1.07E+010 possible combinations.
First step is to make it easy to jump from any combination to any other
combination, in three or less hops, whilst providing no more than 7
choices per hop.
Anyway, getting back to the topic, there are templates for languages
that are not found in any of the ISO 639 # lists, that use writing
systems not found in any variant of ISO 15924 # lists. If those were to
be uploaded to the template, or extension side of things, they would, by
necessity, different from the project.
>Totally unclear to me. Add new > "Extension linked release" and
This gets back to Extension s designed for use with specific templates.
If you don't have the template, the extension won't work, and if you
don't have the extension, the template won't work. There are two or
three combinations in either the LibO or AOo repository. (The
aforementioned Accounting, Project Management, and Business Startup
packages could be squeezed into this group, as an example, but they are
a slightly different case.)
> publish, re-release, and hide releases
This is when there is an issue with something within the item, that can
probably be easily remedied. By way of example, a DMCA take down notice.
>Adrian wants to cut, copy/paste, delete and rename a release. Don't
understand this feature. Is it about the additional info?
This mainly has to do with forks, but can occasionally be due to
Also, sometimes as in my _Graphology Templates 0.6_ release, I had half
a dozen individual templates, as well as one very big template. Being
able to cut/paste/rename can be useful. However, this type of thing is
probably better done on a development site, rather than the distribution
My main rant is for extensions that neither identify themselves once
installed, nor provide any clues as to what functionality they bring to
For some extensions, once installed, there is nothing to tell what they
are supposed to do, unless one plays with them.
My pet peeve is extensions that create their own toolbar, and call it
_Add-On 2_ (Anaphraseus is one culprit. This gets into design flaws made
by extension creators.)
Many thanks for your comments; me needs some time to understand everything in detail. Just two general remarks: The document consists of a copy from the old discussion taken from GDrive to our LOOL instance (not all comments are mine) and a new part on top thinking ahead. My idea is to make the platform as simple as possible with the least effort for maintainers. And I have primarily non-code contributions in mind, like color palettes, images, icons etc. (that I would like to see improve). Of course we have to cover also a the Git-like workflow and your idea is tempting.