Re: [libreoffice-design] Requirements for extension site
On 10/16/18 12:05 AM, toki wrote: > ... 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. Cheers, Heiko -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/design/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [libreoffice-design] Requirements for extension site
On 10/13/18 7:52 AM, Heiko Tietze wrote: > 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 > discussion. 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? Yes. 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 supported; * 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. No extension may have more than one top level category. Do templates delivered as an extension belong under "extension" or "template"? Examples can be found at http://sourceforge.net/projects/ooop/files/Extension/2.4.0.4/ . 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. >Logo: 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 example: * 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
Re: [libreoffice-design] Requirements for extension site
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. jonathon -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/design/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [libreoffice-design] Requirements for extension site
For me the next step would be to get feedback how will help to update the extension page. I will help. My skills are design stuff. I know css and php. Cor Nouws schrieb am Sa., 13. Okt. 2018, 11:13: > Heiko Tietze wrote on 13-10-18 09:52: > > > document is shared on > > https://nextcloud.documentfoundation.org/s/E5RX5xK6jxQPLdK and open for > > discussion. > > 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. > > Cheers, > Cor > > > 1) https://listarchives.libreoffice.org/global/design/msg08889.html > > -- > Cor Nouws > GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28 A038 E49D 7365 B134 80A6 > - vrijwilliger https://nl.libreoffice.org > - volunteer https://www.libreoffice.org > - Member Board The Document Foundation > - http://www.nouenoff.nl / https://www.mijncloudoffice.nl > > -- > To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org > Problems? > https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette > List archive: https://listarchives.libreoffice.org/global/design/ > Privacy Policy: https://www.documentfoundation.org/privacy > -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/design/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [libreoffice-design] Requirements for extension site
Heiko Tietze wrote on 13-10-18 09:52: > document is shared on > https://nextcloud.documentfoundation.org/s/E5RX5xK6jxQPLdK and open for > discussion. 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. Cheers, Cor 1) https://listarchives.libreoffice.org/global/design/msg08889.html -- Cor Nouws GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28 A038 E49D 7365 B134 80A6 - vrijwilliger https://nl.libreoffice.org - volunteer https://www.libreoffice.org - Member Board The Document Foundation - http://www.nouenoff.nl / https://www.mijncloudoffice.nl -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/design/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [libreoffice-design] Requirements for extension site
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 discussion. Thanks for sharing that. That looks indeed like a very promising approach to finding the core functionality that is needed. Best, Bjoern -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/design/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [libreoffice-design] Requirements for extension site
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 > discussion. Thanks for sharing that. That looks indeed like a very promising approach to finding the core functionality that is needed. Best, Bjoern -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/design/ Privacy Policy: https://www.documentfoundation.org/privacy
[libreoffice-design] Requirements for extension site
Hi all, 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 discussion. Cheers, Heiko -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/design/ Privacy Policy: https://www.documentfoundation.org/privacy
