On Thursday 01 of October 2020 05:30:21 Michael via tde-users wrote:
> On Wednesday 30 September 2020 12:58:17 pm Slávek Banko via tde-users
wrote:
> > Dne st 30. září 2020 Michael via tde-users napsal(a):
> > > On Tuesday 29 September 2020 08:36:07 pm Slávek Banko via tde-users
> >
> > wrote:
> > > > Hi all,
> > > >
> > > > I have an idea that pages with information about individual
> > > > applications could be created in the wiki, so that an overview of
> > > > these pages can replace the list of applications, which is
> > > > statically on the main web.
> > >
> > > A long time ago I was going to do this. The problem I ran into was
> > > knowing where, and the existing format(s) of, the data needed to
> > > pull from to do a programmatic build of that page. It also seems
> > > that the data is somewhat distribution delineated (or just used
> > > differently by each distribution)?
> > >
> > > My thoughts on questions that need answering before anyone starts:
> > >
> > > A) How do we want the Wiki page(s) structured?
> > > - - One page per App w/ no categorization?
> > > - - Categorization with all Apps in that group listed on one page?
> > > - - One page per App w/ Categorization to every group it could be
> > > listed in? - - Something else?
> >
> > My idea is for each application an individual page with a
> > categorization determining where it belongs - to which summaries it
> > should be listed.
>
> That'd be my vote.
>
> > > Hangman in the current Menu (Debian) for visualization:
> > >
> > > Menu
> > > - Edutainment (<Categorization)
> > > - - Languages (<Categorization)
> > > - - - KHangMan (<App)
> > > - Games (<Categorization)
> > > - - Games for Kids (<Categorization)
> > > - - - KHangMan (<App)
> >
> > Yes, my idea was categorizing that way. I suppose it would be a good
> > idea for each level to be generated as individual pages so that the
> > list of applications isn't terribly long.
> >
> > I don't know if it will be possible to use any module / extension that
> > could generate these category overview pages, or if there will be a
> > need to prepare some automation that will generate these pages and
> > insert them into the Wiki. But that's probably not important at the
> > moment.
> >
> > > B) What data do we want on the Apps page(s)?
> > > - - Name (whose/which name?)
> > > - - Description (^)
> > > - - Command to run?
> > > - - Package(s) it’s in?
> > > - - Menu(s) it’s in?
> > > - - Icon?
> > > - - ????
> >
> > Very good design. I assume that the name should be the one that the
> > application uses as its name in the About dialog. There could probably
> > be two descriptions - a brief description and a detailed description.
> >
> > Do you have any idea that information for such application information
> > cards could be extracted in some way? I am afraid that this will
> > require, above all, manual effort.
> >
> > > C) What data do we want on the Categorization page(s)? (if used)
> > > - - Apps
> > > - - {basically anything from App above}
> > > - - ????
> >
> > For the category overview pages I had an idea:
> > - Name
> > - Brief description
> > - Icon
> >
> > > # # #
> > >
> > > As a big fuzzy guess, whatever currently builds the menus seems like
> > > a logic place to start from...
> > >
> > > Injecting the data into the Wiki is most likely trivial. If nothing
> > > else it’s just dup a test bed somewhere and use raw SQL ‘till it
> > > works...
> > >
> > > As a suggestion, I’d use a page(s) on the new Wiki to hash all this
> > > out. Using the new Wiki also allows creating multiple example
> > > structures/pages thereby supporting some sort of eventual choice
> > > decision by the whole group.
> > >
> > > my 2 cents,
> > > Michael
> > > ____________________________________________________
> >
> > Thank you for your interest in this task!
>
> The data we want is already somewhere, where is pretty much the issue,
> it’s pretty scattered and incomplete.
>
> Example: KMail
>
> >> Menu Entry:
>
> Name: KMail
> Description: Mail Client
>
> >> KMail About
>
> TDE Email Client
>
> >> $ apt-cache show kmail-trinity
>
> ####
> Package: kmail-trinity
> Source: tdepim-trinity
> {snip}
> Description: Trinity Email client
> KMail is a fully-featured email client that fits nicely into the TDE
> desktop. It has features such as support for IMAP, POP3, multiple
> accounts, mail filtering and sorting, PGP/GnuPG privacy, and inline
> attachments. .
> You need to install tdepim-tdeio-plugins if you want to use IMAP or
> mbox files, and/or tdebase-tdeio-plugins if you want to use POP3.
> .
> This package is part of Trinity, and a component of the TDE PIM module.
> See the 'tde-trinity' and 'tdepim-trinity' packages for more
> information. .
> Homepage: http://kmail.kde.org/
> ####
>
> Which leads nicely into the reliability for the data found being an
> issue...
>
> http://kmail.kde.org/ doesn’t even exist anymore ... And...
>
> KMail Handbook
>
> “Although KMail can be considered reliable you should keep backups of
> your messages, that is, just copy the files and folders in ~/Mail
> (including the hidden ones that start with a dot) to a safe place.”
>
> Now I’m curious just how long ago mail messages were moved out of the
> ~/Mail structure ;)
>
> # # #
>
> Anyway, skipping the data pulling, the page layouts would be the first
> steps.
>
> Best,
> Michael
> ____________________________________________________
It can be seen that using package information as a basis for application
wiki pages could help improve this information :)
However, it is important to think not only about how different the
granularity of packages can be in individual distributions, but also that
not every program has a separate package. For example, kwrite is included
in package kate-trinity (deb packaging).
Cheers
--
Slávek
Attachment:
signature.asc
Description: This is a digitally signed message part.
____________________________________________________ tde-users mailing list -- users@xxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxx Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@xxxxxxxxxxxxxxxxxx
