Hi all,
the fifth service on the migration list is wiki.
-- Migration status --
A new wiki has been created, data from the existing one has been migrated. User accounts have not been migrated, so users must create new ones.
-- What needs to be done --
A new TDE skin remains to be created.
Some wiki pages deserve to be updated - for example, Project RoadMap, Nightly Builds,...
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.
-- More ideas and suggestions?
Does everything work fine with the new mailing lists? Do you have any other ideas and suggestions?
Cheers
Am Mittwoch, 30. September 2020 schrieb Slávek Banko via tde-users:
Hi all,
the fifth service on the migration list is wiki.
-- Migration status --
A new wiki has been created, data from the existing one has been migrated. User accounts have not been migrated, so users must create new ones.
-- What needs to be done --
A new TDE skin remains to be created.
Some wiki pages deserve to be updated - for example, Project RoadMap, Nightly Builds,...
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.
Sounds good.
-- More ideas and suggestions?
Does everything work fine with the new mailing lists? Do you have any other ideas and suggestions?
The new mailing list works just fine from my POV.
Thank you for all the improvements, Slávek. Much appreciated! I'm happy to see that the TDE project is still alive and well!
Cheers
Kind regards, Stefan
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?
Hangman in the current Menu (Debian) for visualization:
Menu - Edutainment (<Categorization) - - Languages (<Categorization) - - - KHangMan (<App) - Games (<Categorization) - - Games for Kids (<Categorization) - - - KHangMan (<App)
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? - - ????
C) What data do we want on the Categorization page(s)? (if used) - - Apps - - {basically anything from App above} - - ????
# # #
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
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.
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!
Cheers
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
On Wed, 30 Sep 2020 22:30:21 -0500 Michael via tde-users ml-migration-agent@trinitydesktop.org wrote:
Package: kmail-trinity
Package: (Debian) kmail-trinity (Gentoo) trinity-base/kmail (Red Hat) [probably something else] (Slackware) [probably something else] (Arch) [probably something else]
There may be more than that—I've just made a conservative estimate here that different package format = different nomenclature system. And there's probably a cleaner way to arrange it.
E. Liddell
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
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
On Thursday 01 October 2020 06:37:00 pm Slávek Banko via tde-users wrote:
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).
Well crap.
Is there any automated way to get a list of all the programs?
# # #
Just installing everything and looking in /opt/trinity/bin/ doesn't seem to work either? I see a bunch of slaves, launchers, helpers and such...
Michael via tde-users wrote:
Well crap.
Is there any automated way to get a list of all the programs?
On debian it is done when building the packages - actually from the control file. But you have only the package name and not exactly what is in the package. This is in the various scripts for this package.
# # #
Just installing everything and looking in /opt/trinity/bin/ doesn't seem to work either? I see a bunch of slaves, launchers, helpers and such...
no forget this., however if you do dpkg -S it will tell you the package, but again it is nonsense. It must be doable from out of the code base.
I just wonder why would this be necessary, when there are man pages anyway. Mostly people care what is the purpose of some software, not in which package it is (I must admit I did not read the whole thread)
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Friday 02 of October 2020 17:37:02 Michael via tde-users wrote:
On Thursday 01 October 2020 06:37:00 pm Slávek Banko via tde-users wrote:
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).
Well crap.
Is there any automated way to get a list of all the programs?
# # #
Just installing everything and looking in /opt/trinity/bin/ doesn't seem to work either? I see a bunch of slaves, launchers, helpers and such... ____________________________________________________
Hi Michael,
I seem to have a fairly successful procedure. During the preparation of the PHP routing script for creating new issues in TGW, I needed to get a table that would contain all the binaries (including games and KCM modules) and information about the git repository to which it belongs.
I have used Contents files that are accessible in the apt repository to find all the files that are of interest. From this I found information about the corresponding deb package name. And by searching in the "control" files in the git repository tde-packaging, I found the corresponding git repository for each binary (each application).
It seems to me that this table, or more precisely the procedure for obtaining it, could be useful for automating the retrieval of information and creating the initial look of wiki pages for applications. In that procedure, finding descriptions from the corresponding deb package could be added, which could serve as a basis for descriptions on the wiki pages. At the same time, information about the git repository will be useful for users to search for and create issues for applications.
What do you think about that?
Note: Thank you Leslie for your suggestion.
Cheers
On Wednesday 16 December 2020 07:12:32 pm Slávek Banko via tde-users wrote:
On Friday 02 of October 2020 17:37:02 Michael via tde-users wrote:
On Thursday 01 October 2020 06:37:00 pm Slávek Banko via tde-users wrote:
Is there any automated way to get a list of all the programs?
Hi Michael,
I seem to have a fairly successful procedure. During the preparation of the PHP routing script for creating new issues in TGW, I needed to get a table that would contain all the binaries (including games and KCM modules) and information about the git repository to which it belongs.
I have used Contents files that are accessible in the apt repository to find all the files that are of interest. From this I found information about the corresponding deb package name. And by searching in the "control" files in the git repository tde-packaging, I found the corresponding git repository for each binary (each application).
It seems to me that this table, or more precisely the procedure for obtaining it, could be useful for automating the retrieval of information and creating the initial look of wiki pages for applications. In that procedure, finding descriptions from the corresponding deb package could be added, which could serve as a basis for descriptions on the wiki pages. At the same time, information about the git repository will be useful for users to search for and create issues for applications.
What do you think about that?
Note: Thank you Leslie for your suggestion.
I think that’s definitely the way to go. It’s going to probably add a few too many individual application pages that are actually slaves, launchers and whatnot, but, really that’s not that big a deal.
To me the only way to remove the ‘excess’ would be to take the auto-created binaries table and then manually remove those that aren’t actually applications. The downside is it’s now manual, and if some new application gets added to TDE, then someone has to remember to add it to the app pages script.
# # #
Although that last sentence made me realize my assumption; that this is going to be run on a scheduled basis? If this is a run once then it’d be a different workflow and manually removing all the ‘cruft’ would be a good idea.
# # #
In either option (run once, run scheduled) I can do the automate ‘load into wiki’ part. I’ll need:
- Copy of the current wiki to install in a dev environment. - All the deb packages, full apt repository?, complete git repository?, or whatever to extract ‘info’ from. - That table (, the scripts to build it, or the .bash_history of the commands you used to create it). - A finished example wiki individual application page to work against.*
* Anyone good at UIX? Want to create a wiki page for KWrite?
Best, Michael
On 2020-12-20 10:39:41 Michael via tde-users wrote:
On Wednesday 16 December 2020 07:12:32 pm Slávek Banko via tde-users wrote:
On Friday 02 of October 2020 17:37:02 Michael via tde-users wrote:
On Thursday 01 October 2020 06:37:00 pm Slávek Banko via tde-users wrote:
Is there any automated way to get a list of all the programs?
Hi Michael,
I seem to have a fairly successful procedure. During the preparation of the PHP routing script for creating new issues in TGW, I needed to get a table that would contain all the binaries (including games and KCM modules) and information about the git repository to which it belongs.
I have used Contents files that are accessible in the apt repository to find all the files that are of interest. From this I found information about the corresponding deb package name. And by searching in the "control" files in the git repository tde-packaging, I found the corresponding git repository for each binary (each application).
It seems to me that this table, or more precisely the procedure for obtaining it, could be useful for automating the retrieval of information and creating the initial look of wiki pages for applications. In that procedure, finding descriptions from the corresponding deb package could be added, which could serve as a basis for descriptions on the wiki pages. At the same time, information about the git repository will be useful for users to search for and create issues for applications.
What do you think about that?
Note: Thank you Leslie for your suggestion.
I think that’s definitely the way to go. It’s going to probably add a few too many individual application pages that are actually slaves, launchers and whatnot, but, really that’s not that big a deal.
To me the only way to remove the ‘excess’ would be to take the auto-created binaries table and then manually remove those that aren’t actually applications. The downside is it’s now manual, and if some new application gets added to TDE, then someone has to remember to add it to the app pages script.
# # #
Although that last sentence made me realize my assumption; that this is going to be run on a scheduled basis? If this is a run once then it’d be a different workflow and manually removing all the ‘cruft’ would be a good idea.
# # #
In either option (run once, run scheduled) I can do the automate ‘load into wiki’ part. I’ll need:
- Copy of the current wiki to install in a dev environment.
- All the deb packages, full apt repository?, complete git repository?, or
whatever to extract ‘info’ from.
- That table (, the scripts to build it, or the .bash_history of the
commands you used to create it).
- A finished example wiki individual application page to work against.*
- Anyone good at UIX? Want to create a wiki page for KWrite?
Best, Michael ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt op.org
Would it be possible to insert a line into the package description of those components that are "slaves, launchers and whatnot" so that the table-building script could filter them out? (Actually, such a classification entry might be helpful in general, as well.)
Leslie --
-
deloptes -
E. Liddell
-
J Leslie Turriff -
Michael -
Michele Calgaro -
Slávek Banko -
Stefan Krusche