30 Sep
2020
30 Sep
'20
1:36 a.m.
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
--
Slávek
30 Sep
30 Sep
9:20 a.m.
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
2:22 p.m.
New subject: Wiki - individual application page(s)
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
5:58 p.m.
New subject: Wiki - individual application page(s)
Dne st 30. září 2020 Michael via tde-users napsal(a):
My idea is for each application an individual page with a categorization
determining where it belongs - to which summaries it should be listed.
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)
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
--
Slávek
1 Oct
1 Oct
3:30 a.m.
New subject: Wiki - individual application page(s)
On Wednesday 30 September 2020 12:58:17 pm Slávek Banko via tde-users wrote:
The data we want is already somewhere, where is pretty much the issue, it’s
pretty scattered and incomplete.
Example: KMail
Dne st 30. září 2020 Michael via tde-users napsal(a):
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.
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)
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! > 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
11:34 a.m.
New subject: Wiki - individual application page(s)
On Wed, 30 Sep 2020 22:30:21 -0500
Michael via tde-users <ml-migration-agent(a)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(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)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
11:37 p.m.
New subject: Wiki - individual application page(s)
On Thursday 01 of October 2020 05:30:21 Michael via tde-users wrote:
The data we want is already somewhere, where is pretty much the issue,
it’s pretty scattered and incomplete.
Example: KMail
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
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):
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.
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)
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! > 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
____________________________________________________
2 Oct
2 Oct
3:37 p.m.
New subject: Wiki - individual application page(s)
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...
8:01 p.m.
New subject: Wiki - individual application page(s)
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(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)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
17 Dec
17 Dec
1:12 a.m.
New subject: Wiki - individual application page(s)
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:
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
--
Slávek
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...
____________________________________________________
20 Dec
20 Dec
4:39 p.m.
New subject: Wiki - individual application page(s)
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:
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 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. 
21 Dec
21 Dec
2:38 a.m.
New subject: [users] Wiki - individual application page(s)
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:
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
--
On Friday 02 of October 2020 17:37:02 Michael via
tde-users wrote:
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(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt
op.org 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. 
1461
days inactive
1543
days old
12 comments
7 participants
participants (7)
-
deloptes -
E. Liddell
-
J Leslie Turriff -
Michael -
Michele Calgaro -
Slávek Banko -
Stefan Krusche