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@xxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxx > 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 -- ____________________________________________________ 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
