22 Feb
2014
22 Feb
'14
11:21 p.m.
On 02/22/2014 05:12 PM, Darrell wrote:
That is a good checklist. kxmledit is a package that is is very good shape. It's
khelpcenter files integrate perfectly with TDE, you have no additional work to
do. Take a look:
http://www.3111skyline.com/dl/dt/trinity/ss/kxmleditor-khelp.jpg
--
David C. Rankin, J.D.,P.E.
When you push
the source to the git-tree, we will need to update the kmenu
location. It currently installs to:
I don't mind adding new packages. I have a long list of candidates I'll post.
Yet when adding new packages I urge using a check list to ensure the new package meets
current Trinity standards and not the shoddy standards of kde-look.org and sourceforge.net
KDE3 packages.
Basically, I busted my ass the past month fixing a horribly broken and embarrassing help
handbook system. I am not about to let that hard work disintegrate every time we add a new
app.
Here is a starter check list. I derived this check list from my recent work with the help
handbooks, which exposed a lot of crappy and lazy work by the original developers as well
as other bugs.
New package addition check list:
1. Create a bug report (enhancement request) for any new candidate package.
That way anything listed below that can not be resolved has a place holder.
Do not proceed past this step unless a bug report is opened.
2. Convert as necessary to current TQt3 requirements.
This process needs to be openly documented to encourage other people to perform some
of the work.
3. Verify the package builds on at least three different distros.
Typically Debian-based, RPM-based, and then an independent such as Arch or Slackware.
4. Verify a help handbook exists.
* If none exists, then add a "We Apologize" shell handbook.
* Verify the shell handbook template is updated to reference the new app.
5. For existing help handbooks, review the header information:
* Update the DocType declaration.
* Update internal entities (for example, &kde;->&tde;).
* Do not add internal entities to general.entities (tdelibs).
* Add copyright information for &tde-team;.
* Add author information for &tde-authors;.
* Update release date.
* Update version.
* Remove versions from handbook title information.
* Ensure all header information satisfies current layout standards.
6. Verify the help handbook opens when selecting the handbook from the Help menu.
7. When secondary help handbooks are included, verify the additional handbook is
available in the Help menu.
Look at the kate Help menu as an example (kate plugins handbook).
* Verify the additional help handbook populates the help handbook table of contents.
8. Verify a Help button is available in the configuration dialogs.
9. For certain configuration Help buttons, verify the help handbook opens to the correct
handbook section rather than the top of the handbook.
* Create additional *.desktop files to support opening to specific handbook sections.
10. Review existing *.desktop files:
* Categories key must satisfy existing launcher menu structure.
* The app populates only one launcher menu category.
* Superfluous menu options are silenced in the launcher menu (such as kbarcode).
* The Icon key references an icon that actually exists.
* The icon appears in the launcher menu.
* The icon appears the help handbook table of contents.
* The DocPath key references the correct location of the help handbook
The correct location is index.html and not appname.html.
* Both a Name and GenericName key are defined to satisfy Description/Name and
Name/Description menu users.
* Verify Trinity supports new or obscure mimetypes specified.
11. Verify i18n files are reviewed or added.
This is a draft check list.
