Difference between revisions of "Talk:List of applications"

From ArchWiki
Jump to: navigation, search
(Should we move Partitioning #Partitioning tools to here?: re)
(List of screenshot tools: close)
 
(289 intermediate revisions by 24 users not shown)
Line 1: Line 1:
==Mark common applications? (previously named "What is common?")==
+
== Categorization ==
 +
=== Classification troubles ===
 +
Can "CD/DVD Burning Tools" be considered part of "Multimedia"?
 +
Should "Screen Capture" section be part of "Utilities" or "Multimedia"? --[[User:AlexanderR|AlexanderR]] 21:10, 16 January 2012 (EST)
  
I wonder who defines what is a "common" application. Just one random (potentially bad) example: Among the [https://www.archlinux.de/?page=PackageStatistics pkgstats] users the package "freetalk" is installed by 1.17%. Is that common? If it is, why is another jabber client named "kadu" not common (1.53%)? Of course, I do not know how representative these statistics are. But could they be better than adding everything someone thinks is common (or wants to be common)?
+
:Eh I'm afraid we'll just have to establish a convention: I'd say Burning tools in Multimedia and Screen Capture in Utilities? Let's wait for more opinions. -- [[User:Kynikos|Kynikos]] 07:53, 17 January 2012 (EST)
 
 
One way could be to list all applications in a category that are installed by more than 10% of pkgstats users. If this yields less than 3 applications, list the 3 most common ones regardless of their installation percentage. --[[User:Markus00000|Markus00000]] 09:19, 16 October 2011 (EDT)
 
:<s>Another simpler way would be moving the article to [[List of Applications]], which already redirects here anyway.</s> You can add kadu if you want, I don't see any harm in having a page that tries to group packages/applications by genre independently from their usage share. -- [[User:Kynikos|Kynikos]] 07:39, 17 October 2011 (EDT)
 
::Personally, I would find a page listing only the most commonly used applications for each category, split into graphical and console applications, very helpful. As we all use the same distribution, I found that applications recommendations from Arch users where usually exactly what I was looking for (e.g. Light and Fast Award). Conversely, a long page listing many applications seems to me no more useful than a web or pacman search. --[[User:Markus00000|Markus00000]] 08:22, 17 October 2011 (EDT)
 
:::I'm quite sure that if we do it that way, a discussion like this will be created once a week or so :) You are supposed to decide by yourself what's the best application that you want to use for a particular purpose, not basing your decision on its "popularity" (we'd all be using windoze that way :P ), but reading reviews and user opinions, official documentation and yes, even trying many apps before finding the "right" one.
 
:::By listing only some "common" applications, using a filter that would always be in dispute, we would bias the preference of users, that's the main reason I don't support such a method. What's more, it'd be much harder for new applications to be noted and increase their popularity.
 
:::About the pacman search argument, AFAIK the database doesn't store a "type" property for packages.
 
:::-- [[User:Kynikos|Kynikos]] 08:50, 17 October 2011 (EDT)
 
::::Then the obvious solution is to make [[List of Applications]] list packages, and, in case I or anybody else cares to create it, [[Common Applications]] list the most common applications based on objective pkgstats statistics. Sounds good? --[[User:Markus00000|Markus00000]] 09:10, 17 October 2011 (EDT)
 
:::::We managed to merge two lists of applications ([[Lightweight Applications]] and [[Common Applications]]) just 2 weeks or so ago, because it was difficult maintaining both.
 
:::::As a compromise, I suggest to highlight in bold (or some other way) the objectively most common packages in the list, and write a proper introduction where this method is described.
 
:::::We may also wait a while for more opinions.
 
:::::-- [[User:Kynikos|Kynikos]] 09:20, 17 October 2011 (EDT)
 
:::::Instead of bold (which I don't like at all) we could prepend simple marks like in:
 
:::::* '''[+]''' {{App|[[Firefox]]|The Firefox Web Browser is the faster, more secure, and fully customizable way to surf the web.|http://www.mozilla.com/firefox/|{{Pkg|firefox}}}}
 
::::: or '''[!]''',  '''[*]''', '''+''', '''!''', '''*'''.
 
:::::-- [[User:Kynikos|Kynikos]] 09:36, 17 October 2011 (EDT)
 
:::::: [https://wiki.archlinux.org/index.php?title=Common_Applications&diff=0&oldid=175151 Status?] Should we employ notability guidelines like [http://en.wikipedia.org/wiki/Talk:Dwm#Notability Wikipedia]? ;P -- [[User:Karol|Karol]] 16:25, 25 December 2011 (EST)
 
:::::::Status is open for discussion. My opinion is still the one expressed in my other replies: I'm against any form of filtering, I'm in favour of using marks based on <u>objective</u> (read "indisputable") rules. If some sections become too long they can be moved to other pages or subpages like [[Games]] or [[Backup Programs]] (I'd prefer subpages, so these two examples should be moved). <s>I'm in favour of renaming the page [[List of applications]].</s>
 
:::::::Readers are invited to share their thoughts :)
 
:::::::-- [[User:Kynikos|Kynikos]] 06:43, 26 December 2011 (EST)
 
::::::::<s>+1 for renaming the page [[List of applications]],</s> I'm fine with the marks. What would the objective rules be? -- [[User:Karol|Karol]] 08:05, 26 December 2011 (EST)
 
:::::::::Good, the rule for discerning between common and uncommon apps may be based on [https://www.archlinux.de/?page=PackageStatistics pkgstats] as proposed initially by Markus00000, I'd say ''an application is common when it's installed by more than {{ic|min(10, N*0.75)}}% of pkgstats users, where {{ic|N}} is the percentage of installation of the most common application in the category''. (I hope it's clear, may need to be rephrased, values {{ic|10}} and {{ic|0.75}} may be adjusted)
 
:::::::::We may also find a rule for marking ''lightweight'' applications, any ideas?
 
:::::::::Then we should also find users interested in actually do the marking thing, otherwise if we just end up having 3 or 4 marked entries in the whole article it may not be worth it.
 
:::::::::-- [[User:Kynikos|Kynikos]] 05:57, 27 December 2011 (EST)
 
::::::::::I don't think that determining if some app is lightweight/common or not can be done in the Wiki. There is simply no objective criteria of this. Is [[dwm]] common? Probably less than 1% of GNU/Linux users run it, but among KISS-aware geeks it is very common. Is Opera common enough to be listed? Is Firefox lightweight? Is emacs lightweight? And after such questions.. '''THE EPIC FLAME BEGINS!''' To avoid flames and Wiki-wars, we should not start such classification in the first place. Is not it user's deal &ndash; to determine which app is lightweight and which has the best userbase? IMHO the only thing one can do is to write proper application description and (if enough spare time is present) create article about that app. The rest is for the readers.
 
:::::::::: <s>PS "List of applications" is proper title but I'd suggest "Recommended applications" as more honest.</s>
 
:::::::::: --[[User:AlexanderR|AlexanderR]] 21:26, 2 January 2012 (EST)
 
 
 
== Lightweight Applications ==
 
  
What happened to the list of lightweight applications that used to be on the wiki? Now it redirects here. That list was useful for people (such as myself) who don't want (or can't run) heavyweight apps requiring KDE or Gnome libs. Now we have to pick through the list and find out for ouerselves whether it's light or heavy? How is that an improvement?
+
::As I see, '''CD/DVD Burning Tools''' are already a part of '''Multimedia'''. '''Screen Capture''', I think, must be in '''Utilities'''.
:You can search the page for the word 'lightweight' and you will find e.g. "zathura — Another lightweight PDF viewer similar to apvlv, only lighter".
+
::And there's another question from russian users. '''OCR software''' isn't a reader or viewer, so it must be before or after '''1.9 Note taking organizers''' with corresponding number '''1.9''' or '''1.10'''
:You can access the lightweight list [https://wiki.archlinux.org/index.php?title=Lightweight_Applications&oldid=162352 here]. -- [[User:Karol|Karol]] 16:10, 22 October 2011 (EDT)
+
::UPD. Also, there's a good idea to add in this section some (or all) progs from [[Optical Character Recognition]] -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 05:32, 11 April 2014 (UTC)
::If we decide to implement the idea above to mark the most common apps with a special symbol, we can do the same with lightweight apps, provided we find an objective definition of "lightweight". -- [[User:Kynikos|Kynikos]] 11:19, 30 October 2011 (EDT)
 
:::We still have [[Netbook Games]], which [https://wiki.archlinux.org/index.php/Talk:Common_Applications/Games/Reimplemented isn't perfect either]. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 22:25, 16 September 2012 (UTC)
 
::::That is already discussed in [[Talk:Netbook Games#Merging]], let's only discuss the possibility to define "lightweight" and implement marks for lightweight applications here :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:36, 17 September 2012 (UTC)
 
  
== Further improvement ==
+
:::Um... "Utilities" is practically a default category for applications that don't fit anywhere else: since "Screen capture" is kind of related to "Multimedia", it would probably be better to leave it there (thus changing the opinion I expressed above, I think I'm allowed, after more than 2 years :P ).
# Use GentooWiki/Wikipedia links in place of the current redlinks where possible.
+
:::I'm quite neutral about moving "OCR software" in the tree: it is related to "Scans", but maybe not so closely. I'm also neutral about merging [[Optical Character Recognition]] there: actually that article doesn't contain anything except for a short list of applications, so it could indeed be merged.
# Remove dead links unless they can be fixed somehow.</s> EDIT: both moved to new discussion
+
:::Anyone with a stronger position on the topic? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:12, 11 April 2014 (UTC)
# Clean up last unformatted entries.</s> EDIT: will be continued in separate articles
 
# Add apps
 
## Listed at [http://en.gentoo-wiki.com/wiki/Useful_console_applications this Gentoo article]
 
## <s>from [[Commandline_Tools]]
 
### '''New''': Does mentioning core applications like '''more''', '''less''' etc (like done in [[Commandline_Tools]]) make any sence?</s>
 
# Finally move everything to separate articles.
 
## Add entries from "Arch Package Management" to (separately) [[AUR_Helpers]] and [[Pacman_GUI_Frontends]]
 
## <s>Merge "Graphics and Image Manipulation" with [[Multimedia]]</s>
 
### '''New''': Can "CD/DVD Burning Tools" be considered part of "Multimedia"?
 
### '''New''': Should "Screen Capture" section be part of "Utilities" or "Multimedia"? <s>Should such potentially controversial sections be made top-level?</s>
 
### <s>This especially makes sense because moving top-level parts like [[Common Applications#Backup Programs]] to split articles effectively hides its' internal structure.</s> EDIT: no longer relevant
 
# <s>Rewrite [[Desktop_Environment]] article. Even Wikipedia article, linked from [[Common Applications#Work environment]] is less Ubuntu-ish. Then merge current contents of [[Common Applications#Work environment]] into [[Desktop_Environment]].</s>
 
# <s>'''New''': Split article into several smaller similar to [[Beginners' Guide]]?</s> <s>EDIT: splitting started, last entries should be moved to separate pages (see [[Template:Common Applications navigation]]).</s> EDIT: done
 
<s>--[[User:AlexanderR|AlexanderR]] 03:01, 15 January 2012 (EST)</s><br>
 
<s>--[[User:AlexanderR|AlexanderR]] 22:27, 15 January 2012 (EST)</s><br>
 
<s>--[[User:AlexanderR|AlexanderR]] 01:45, 16 January 2012 (EST)</s><br>
 
<s>--[[User:AlexanderR|AlexanderR]] 08:00, 16 January 2012 (EST)</s><br>
 
--[[User:AlexanderR|AlexanderR]] 21:10, 16 January 2012 (EST)
 
  
:Not sure if that's what you meant in 5.1, but I disagree if you want to merge [[AUR_Helpers]] with [[Pacman_GUI_Frontends]], I think they should be kept separate. -- [[User:Karol|Karol]] 07:47, 3 January 2012 (EST)
+
::::So, I've made corresponding changes in '''Documents''' section. Also I've merged '''Pdf''' and '''DjVu''', because many progs in '''Pdf''' works with DjVu. I've deleted tool '''fbdjvu''', because, as I see, it's merged with '''fbpdf'''.
 +
::::Let's talk if there's another opinions about my changes -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 09:59, 14 April 2014 (UTC)
  
::Re: (I needed a non-indented line here...)
+
:::::Well done, except you forgot to redirect [[Optical Character Recognition]], [https://wiki.archlinux.org/index.php?title=Optical_Character_Recognition&diff=310498&oldid=273112 fixed] now :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:53, 15 April 2014 (UTC)
::# <s>Do you mean you'd use GentooWiki/Wikipedia links in place of the current redlinks?</s> EDIT: fixed directly in the original post <br> I don't have a position yet on this idea, redlinks can have their own purpose too, for example they feed [[Special:WantedPages]] even if it's broken by the i18n template currently... More opinions needed!
 
::# <s>Remove unless they can be fixed somehow</s> EDIT: fixed directly in the original post
 
::# Yes please
 
::# Why not
 
::# <s>This is the most controversial point: what do you mean exactly? You're talking about "separate articles" and then about merging some others, it's not very clear at the moment</s> EDIT: the original post has been modified <br> I would move to separate articles (better subpages) only the sections that have more than N entries (and discuss what the value of N can be)
 
::## Makes sense now
 
::## Also this one seems a good idea
 
::# Please let's discuss this one later, otherwise we are having too many irons in the fire. Also I'd like you to explain better why you moved [[Desktop Environment]] to [[X Desktop Environment]]. I consider it a superfluous change and would like to restore the previous title. The same goes for [[Window Manager]] and [[X Window Manager]]. Please discuss this kind of changes before performing them. More opinions are welcome.
 
::-- <s>[[User:Kynikos|Kynikos]] 08:22, 3 January 2012 (EST)</s>
 
::Finally, please, do '''not''' edit your posts in place, otherwise it's very very difficult to follow the discussion and even more to reply.
 
::-- [[User:Kynikos|Kynikos]] 19:09, 15 January 2012 (EST)
 
  
::: >> please, do '''not''' edit your posts
 
::: Reposting whole lists wastes so much horizontal place :_; Ok, I will care more about readability.
 
::: >> why you moved...
 
::: Thanks for discussing this. I guess, I should explain:
 
::: curently this change may look as a bit superfluous as X is the only base of all major DEs, but this is subject to change due to [[Wayland]] development. There are also surprisingly huge number of Arch users experimenting with lightweight WMs and even framebuffer-based systems. Can such environments be considered "Desktop"? Without doubt, yes. Anyway, until [[Desktop Environment]]'s contents change to something else than redirect to [[X Desktop Environment]] it is not so big deal, is it? And yes, in context of written, [[Window Manager]] currently describes '''X''' Window Managers, not, for example, ones compatible with Wayland or even console dvtm. --[[User:AlexanderR|AlexanderR]] 21:12, 15 January 2012 (EST)
 
:::: I do not think it's fair to change "desktop environments" in "X dekstop environments", because the page on the desktop environments must describe the various projects that are by definition "desktop environments", not because run under X or "Wayland." The same goes for "window manager". I think that this division only creates confusion and is redundant. Within the same article you can mention if a DE runs or less on "Wayland", and how to make it work must be described on the page of DE. Otherwise you risk having in the future some wiki, "Wayland dekstop environments", "X dekstop environments", "X kde", "Wayland KDE", etc. In "desktop environments" there is a table [[# Desktop_Environment Comparison_of_desktop_environments]], add here, a voice on the support or not to X, Wayland, etc.[[User:Veleno77|Veleno]] 06:26, 16 January 2012 (EST)
 
::::: >> ...must describe the various projects that are by definition "desktop environments"
 
::::: Can you please specify this "definition"? The one that is currently present in [[Desktop_Environment]] is almost incorrect and relates to classic X-based DEs only.
 
::::: >> you risk having in the future some wiki, "Wayland dekstop environments", "X dekstop environments", "X kde", "Wayland KDE"
 
::::: There are already [[Wayland]] article with explicit instructions for kwin... Can it be considered the first sign of danger :) ? --[[User:AlexanderR|AlexanderR]] 08:00, 16 January 2012 (EST)
 
::::::First thing I admit it's not easy to follow this discussion and your edits, AlexanderR, but I also have to say that the idea of [[Template:Common Applications navigation]] is quite brilliant ^^ I liked it. However, please, I wouldn't like to repeat myself, do not edit your posts, just add new replies or even consider creating new discussions, like for all those '''New'''s in the list. I'd like to ask you to remove the new additions to your old post and move them to a new discussion or even some subdiscussions (subsections) of this very discussion.
 
::::::About the X/Wayland problem, I'd like not to "cross our bridges before coming to them": Wayland is still a marginal and experimental project, when we will start having more Wayland-related articles and some kind of conflict with X-related articles will actually rise we will change the titles appropriately. Until then, however, I'd stick with the previous policy where X is assumed unless stated otherwise.
 
::::::-- [[User:Kynikos|Kynikos]] 19:10, 16 January 2012 (EST)
 
::::::: >> I admit it's not easy to follow this discussion and your edits
 
::::::: Sorry for this &ndash; I copied last questions to new discussions (and thanks for mentioning subsections).
 
::::::: >> I'd like not to "cross our bridges before coming to them"
 
::::::: Ok, I agree, such edits should at least follow improvements in articles instead of preceding them. I undone both. I guess, this thread can be safely removed now.
 
::::::::Before creating too many Common Applications subpages and navigation templates, perhaps we should first settle [[#Improving the title]]? -- [[User:Pointone|pointone]] 23:04, 16 January 2012 (EST)
 
:::::::::(Reopened) I guess we're too late for that... :) That would have been better indeed, I've replied to your answer to [[#Improving the title]], let's make a decision and do the rename soon. -- [[User:Kynikos|Kynikos]] 07:31, 17 January 2012 (EST)
 
  
===Summary of related changes===
+
I have submitted a AUR package for {{AUR|sendanywhere}}, a cross-platform p2p file sharing utility (similar to Pushbullet, but with standalone software client). I am not sure under which section I should include it. It is definitely not FTP based or bittorrent based. Should it go under '''Downloaders''' or '''Communications'''; also, shall I start a new subsection, maybe called '''p2p file sharing/pushing'''?  [[User:Jadelord|Jadelord]] ([[User talk:Jadelord|talk]]) 11:17, 6 January 2016 (UTC)
* [[Backup Programs]] - Restructured
 
* [[Commandline Tools]] - <s>Partially</s> merged with [[Common Applications]]
 
* [[Common Applications]] - Split in several subpages, à la [[Beginners' Guide]]
 
** [[Common Applications/Internet]] - Split from [[Common Applications]]
 
** [[Multimedia]] -> [[Common Applications/Multimedia]] - Merge between [[Multimedia]] and [[Common Applications]]
 
** [[Common Applications/Utilities]] - Split from [[Common Applications]]
 
** [[Common Applications/Documents]] - Split from [[Common Applications]]
 
** [[Common Applications/Security]] - Split from [[Common Applications]]
 
** [[Scientific Applications]] -> [[Common Applications/Science]] - Merge between [[Scientific Applications]] and [[Common Applications]]
 
** [[Common Applications/Other]] - Split from [[Common Applications]]
 
** [[Games]] -> [[Common Applications/Games]] - Merge between [[Games]] and [[Common Applications]] with splitting some bits into [[Gaming]]
 
*** [[Common Applications/Games/Free]] - Split from [[Common Applications/Games]]
 
*** [[Common Applications/Games/Reimplemented]] - Split from [[Common Applications/Games]]
 
*** [[Common Applications/Games/Commercial]] - Split from [[Common Applications/Games]]
 
*** [[Common Applications/Games/Emulators]] - Split from [[Common Applications/Games]]
 
*** [[Common Applications/Games/MMO]] - Split from [[Common Applications/Games]]
 
* [[Games]] -> [[Gaming]] - Split from [[Games]] with some bits merged from [[Netbook Games]]
 
* [[Netbook Games]] - Moved some content to [[Common Applications]] and [[Gaming]]
 
* [[OCR]] -> [[Optical Character Recognition]] - Split from [[Common Applications]]
 
* [[Sound]] -> [[Sound system]] - Some modifications
 
* [[Template:Common Applications navigation]] - used in [[Common Applications]]
 
* [[Template:Games navigation]] - used in [[Common Applications/Games]]
 
* [[Template:AUR?]] - used in [[Common Applications/Games/MMO]]
 
  
== Categorization ==
+
:I've just created [[List_of_applications/Internet#Other_P2P_networks]], I think that's the best place for the moment. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:11, 7 January 2016 (UTC)
=== Core apps ===
 
Does mentioning core applications like '''more''', '''less''' etc (like done in [[Commandline_Tools]]) make any sence? --[[User:AlexanderR|AlexanderR]] 21:10, 16 January 2012 (EST)
 
:See also: [[Core Utilities]]. -- [[User:Pointone|pointone]] 23:13, 16 January 2012 (EST)
 
::I added the "Pager" entry there quite recently as a replacement for the [[most]] article, which was just 1 line of text. Note that ''most'' is not a core application, I don't know if we should have a "Pagers" section in Common Applications... thoughts? -- [[User:Kynikos|Kynikos]] 07:49, 17 January 2012 (EST)
 
  
=== Classification troubles ===
+
=== Link subpages instead of transcluding them ===
Can "CD/DVD Burning Tools" be considered part of "Multimedia"?
 
Should "Screen Capture" section be part of "Utilities" or "Multimedia"? --[[User:AlexanderR|AlexanderR]] 21:10, 16 January 2012 (EST)
 
:Eh I'm afraid we'll just have to establish a convention: I'd say Burning tools in Multimedia and Screen Capture in Utilities? Let's wait for more opinions. -- [[User:Kynikos|Kynikos]] 07:53, 17 January 2012 (EST)
 
 
 
=== Split up completely? ===
 
 
Just wondering if it would be better to completely split the article up into separate articles, rather than transcluding everything back in as templates. Perhaps just include links and a brief summary of each category in the top-level page, maybe something along the lines of:
 
Just wondering if it would be better to completely split the article up into separate articles, rather than transcluding everything back in as templates. Perhaps just include links and a brief summary of each category in the top-level page, maybe something along the lines of:
  
{{box | | This page has various categories of programs and points to lists of programs in those categories. It is a useful starting point for finding a program for a specific application. [Introduce console versus graphical.]
+
{{META Box | | This page has various categories of programs and points to lists of programs in those categories. It is a useful starting point for finding a program for a specific application. [Introduce console versus graphical.]
  
 
'''[[Common Applications/Internet | Internet]]''' including network configuration, and clients or browsers for web sites, FTP, file sharing, chat and email messaging, web feeds, and microblogging
 
'''[[Common Applications/Internet | Internet]]''' including network configuration, and clients or browsers for web sites, FTP, file sharing, chat and email messaging, web feeds, and microblogging
Line 160: Line 50:
  
 
:I think the main problem here is that if I'm looking for a particular subcategory I have to guess under which main category it can be, while currently, with the comprehensive ToC, that task is easier. Possible compromise: maintain a "manual" Table of Contents in the top-level page, with links to the various subpages/subsections. Let's hear more opinions. -- [[User:Kynikos|Kynikos]] 07:53, 26 January 2012 (EST)
 
:I think the main problem here is that if I'm looking for a particular subcategory I have to guess under which main category it can be, while currently, with the comprehensive ToC, that task is easier. Possible compromise: maintain a "manual" Table of Contents in the top-level page, with links to the various subpages/subsections. Let's hear more opinions. -- [[User:Kynikos|Kynikos]] 07:53, 26 January 2012 (EST)
 +
 +
: The page is gigantic and loads very slowly on my internet connection, so I think splitting into subpages is a good idea. Maybe the page length could also be reduced by only having the top 5 most used/useful apps for each category. I am hesitate about that suggestion as I have also found some more obscure but very useful things on this page, but it has gotten to be so unwieldy to  navigate now. We could also have the "alternative to" website under a "see also" section as well as links to other external linux package lists.[[User:Meskarune|Meskarune]] ([[User talk:Meskarune|talk]]) 20:34, 12 August 2018 (UTC)
 +
 +
::155KB isn't that much on the modern web, every website containing a large image is larger. The page is already split in subpages, which you can access using the top navigation. Reducing the apps per category is not in question. Navigating the pages shouldn't be an issue if you use the ToC / Ctrl+F. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 03:39, 13 August 2018 (UTC)
 +
 +
:::155KB may be the size of the wikicode, but the resulting HTML version of [[List of applications]] is about 1.1MB, which is a lot even for "modern web"... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]])
 +
 +
::::Wrong, 155KB is the transferred size of the HTML if it's [[Wikipedia:Brotli|br]] compressed. For gzip it's 170KB. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 07:27, 13 August 2018 (UTC)
  
 
==See also visibility==
 
==See also visibility==
Line 200: Line 98:
 
#**Links are not evident at a glance unlike the solutions above. -- [[User:Kynikos|Kynikos]] 07:38, 24 January 2012 (EST)
 
#**Links are not evident at a glance unlike the solutions above. -- [[User:Kynikos|Kynikos]] 07:38, 24 January 2012 (EST)
  
== IRC clients: Conspire fails to build ==
+
== Order of things? ==
 +
 
 +
Is there any special order to these lists?
 +
 
 +
For instance, under "Internet" it would seem more intuitive to begin with "Network Managers", then "Browsers", then a section for "Downloaders". and so on.
 +
[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 00:51, 20 January 2014 (UTC)
 +
 
 +
:"Intuitive" is subjective, I'd just simply use alphabetical order, although I know it's not used anywhere at the moment... -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 21:07, 20 January 2014 (UTC)
 +
 
 +
::Call it chronological? i.e. an order in which people (especially beginners) would think of setting things up - network, browser, communication, downloads, media etc.
 +
::The problem with alphabetical lists is that even if we decide on "correct" terms for things, some people will, i.e., look for 'console', and others for 'terminal'.
 +
::[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 14:10, 21 January 2014 (UTC)
 +
 
 +
:::Eheh a similar objection could be made for the "chronological" order, which, as I said, is subjective, e.g. some people may want to install messaging apps before p2p or vice versa. Maybe what you really mean is a "dependency" order, i.e. if in a group of sections there's one that lists applications (e.g. network managers) that may be necessary for applications in other groups to work, then put it at the top. I can agree with that, also because other sections like the various "Other" should instead better be kept at the bottom. All the in-between sections, though, should be sorted alphabetically: the problem of synonyms would affect any kind of odering we may choose, and in general it affects all kinds of word lists (e.g. dictionaries), so users are used to dealing with it.
 +
:::If you're willing to do the reordering, please do it in several little edits, not a single big one.
 +
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:13, 22 January 2014 (UTC)
 +
 
 +
::::Yes, having "Other" at the end is exactly the kind of order I mean.
 +
::::[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 15:25, 22 January 2014 (UTC)
 +
 
 +
== List dead projects or not? ==
 +
[https://wiki.archlinux.org/index.php?title=List_of_Applications/Multimedia&diff=next&oldid=296040 Kino is dead], it doesn't even have a maintainer in the AUR. Is it OK to remove dead-but-still-working applications from the list in the wiki? -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 14:16, 3 February 2014 (UTC)
 +
 
 +
:I wouldn't really know what's best to do, but if the application is confirmed to be still working, ''keep''ing it in the list should be the default action until somebody proves that listing it is counterproductive in some way. Of course a note about the EOL should be added if restored. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:50, 4 February 2014 (UTC)
 +
 
 +
[http://www.afterstep.org/aterm.php The aterm project website] has been directing people to use urxvt instead since 2008. I've noticed quite a few projects in the maintainer-doesn't-even-advise-using-it category on this page and I don't see what purpose they serve. [[User:RyneEverett|Ryne Everett]] ([[User talk:RyneEverett|talk]]) 02:26, 13 December 2014 (UTC)
 +
 
 +
:Well, the apps whose ''upstream'' maintainers explicitly discourage using them can indeed be removed, possibly making sure that any indicated alternative is already present in this list, adding it otherwise. Just note that, taking your post literally, "not advising to" is different from "discouraging to" (the aterm case falls indeed in the latter case) :) Please state the reason for removing applications from the list using the edit summary. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:32, 14 December 2014 (UTC)
 +
 
 +
::I propose a deprecation warning, especially in the security subpage. there are numerous projects listed, that might still work, but are not developed anymore. this renders them insecure, as malware recognition needs to keep up with developement. This concerns rkhunter, chkrootkit and also the currently unlisted unhide. [[User:Fordprefect|Fordprefect]] ([[User talk:Fordprefect|talk]]) 12:35, 2 September 2016 (UTC)
 +
 
 +
:::I think it's too soon to talk on warnings like that when there's hundreds of dead AUR packages on the list... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:41, 2 September 2016 (UTC)
 +
 
 +
::::Well, for packages meant to improve security concerning malware, frequent updates are no bonus, but crucial. a simple note would help users distinguish more and less active projects. [[User:Fordprefect|Fordprefect]] ([[User talk:Fordprefect|talk]]) 17:17, 2 September 2016 (UTC)
 +
 
 +
:::::At least rkhunter is still in the official repos, and John Horne, the [http://rkhunter.cvs.sourceforge.net/viewvc/rkhunter/rkhunter/files/ACKNOWLEDGMENTS current] main developer is still answering posts in the [https://sourceforge.net/p/rkhunter/mailman/rkhunter-users/ mailing list]. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 01:12, 3 September 2016 (UTC)
 +
 
 +
== Scope of the page ==
 +
 
 +
It seems that this page is becoming a bloated index for all possible "lists" on the wiki, or maybe even the whole wiki itself. There are other pages to help users find what they are looking for, e.g. [[Table of contents]], [[General recommendations]] and of course the full-text search. Therefore I think that the [[List of applications]] should be a ''comprehensible'' list of the most common categories of application software and not a ''comprehensive'' list of everything. I believe that the index pages can have separate targets and cooperate with each other to provide a complete picture instead of overlapping and hindering readability by linking to each other.
 +
 
 +
I propose the following:
 +
 
 +
* remove [[List_of_applications/Workspace#Command_shells]] - one does not look for an alternative shell "just because", but to solve some specific problem or inconvenience, which is out of the reach of this page ([[General_recommendations#Console_improvements]] covers it quite nicely)
 +
* <s>I do not consider the things linked from [[List_of_applications/Workspace#Bootsplash]] to be "applications" and would like it removed. An explicit link to [[:Category:Bootsplash]] could be added to [[General_recommendations#Appearance]], although it already links to its parent category: [[:Category:Eye candy]].</s>
 +
* remove [[List_of_applications/Workspace#Display_managers]], [[List_of_applications/Workspace#Desktop_environments]], [[List_of_applications/Workspace#Window_managers]] and [[List_of_applications/Workspace#Composite_managers]] - the topic is much better covered in [[General_recommendations#Graphical_user_interface]] (the two packages from [[List_of_applications/Workspace#Window_managers]] could be moved to [[General_recommendations#Console_improvements]])
 +
* <s>remove [[List_of_applications/Workspace#Accessibility]]</s> - it is a topic of its own, not just about selecting applications
 +
* <s>remove [[List_of_applications/Utilities#Databases]]</s> - they are certainly not utilities (so much less applications), but complex systems consisting of many deamons, utilities and interfaces designed to work together
 +
* <s>remove the [[List_of_applications/Internet#Web_Servers]] section:</s>
 +
** <s>merge [[List_of_applications/Internet#LAMP_stack]] to [[Server#LAMP]]</s> - I doubt it is useful for an average user
 +
** <s>remove [[List_of_applications/Internet#Wiki_engines]]</s> - it is very incomplete and like above, not useful
 +
** <s>move [[List_of_applications/Internet#Content_management.2C_social_networks.2C_blog_publishers]] back to [[List_of_applications/Internet#Blog_engines]]</s>
 +
** <s>move [[List_of_applications/Internet#Cloud_storage_servers]] under [[List_of_applications/Internet#File_sharing]]</s>
 +
 
 +
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:44, 2 March 2017 (UTC)
 +
 
 +
:I've undone most of the structural changes to [[List of applications]] (starting with [https://wiki.archlinux.org/index.php?title=List_of_applications/Workspace&oldid=469393]) due to their one-sided nature. A radical restructure of one of the most popular wiki articles requires a consensus that isn't (yet) reached here. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:38, 15 March 2017 (UTC)
 +
 
 +
:About Display managers et al., perhaps we should just have a general header such as "Graphical user interface" and link to [[General recommendations#Graphical user interface]]. The idea is that the sections in question contain little more than single wiki links and as such add TOC entries to little benefit. As touched upon in [[#Merge sections to category pages]], a comprehensive TOC is already served by [[Table of Contents]] and there's no need for this page to compete. We could remind users of this by placing a link to [[Table of contents]] somewhere at the top.
 +
:Other sections such as [[List_of_applications/Other#Window_tilers]] could further be moved to their respective articles (here [[Window manager]]) to have all information in one place.
 +
:If this approach works out, we could use it to reduce [[List of applications/Other]] and [[List of applications/Utilities]] in size and merge the articles accordingly, as a compromise until a better approach is agreed upon in [[#Merge sections to category pages]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:48, 15 March 2017 (UTC)
 +
 
 +
::I think that "Graphical user interface" is too general, it might attract items or crosslinks to other sections for anything with a GUI. We might call it "Custom desktop environment" or something like that to group [[List_of_applications#Taskbars_.2F_panels_.2F_docks]], [[List_of_applications#Application_launchers]], [[List_of_applications#Wallpaper_setters]], [[List_of_applications#Virtual_desktop_pagers]], [[List_of_applications#Logout_dialogue]] and probably also [[List_of_applications#Screen_lockers]]. It could contain links to [[General recommendations]], [[Window manager]] etc. but I wouldn't merge them anywhere until the recategorization discussed in [[#Merge sections to category pages]] is finished. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:15, 15 March 2017 (UTC)
 +
 
 +
:::See [https://wiki.archlinux.org/index.php?title=List_of_applications/Other&diff=470830&oldid=470804], [https://wiki.archlinux.org/index.php?title=List_of_applications/Other&diff=470831&oldid=470830].
 +
:::I've kept [[List of applications/Other#Window managers]], [[List of applications/Other#Window tilers]] and [[List_of_applications/Other#Taskbars_.2F_panels_.2F_docks]] (latter could use a simpler name?) under the same [[List of applications#Desktop environments]] header because they're equally a part of a [[Desktop environment]] just like e.g. an application launcher is. We can always remove those items later on a restructure. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:10, 15 March 2017 (UTC)
 +
 
 +
::::Some more candidates:
 +
::::*[[List of applications/Utilities#Files]]. Naming the header "files" is ambiguous at best; "File management" would be better but there's already [[List of applications/Utilities#File managers]]...
 +
::::*[[List_of_applications/Utilities#Disk_usage_display]] could fit under the more general [[List of applications/Utilities#System monitoring]], however [[List_of_applications/Utilities#Disk_usage_display]] is right next to it. However, [[List_of_applications/Utilities#Partitioning_tools]] is also a "disk" related topic.
 +
::::*[[List_of_applications/Utilities#Keyboard_layout_switchers]] may be better suited for [[List_of_applications/Other#Desktop_environments]]. Then again it's related to [[List_of_applications/Utilities#Input_methods]]
 +
::::So yes, I've also taken on the hard task of properly classifying entries in the "Other" categories. Though I would say completing this will make discussing proper alternatives easier. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:41, 15 March 2017 (UTC)
 +
 
 +
=== Merge sections to category pages ===
 +
 
 +
Warning: extreme brainstorming, join at your own risk.
 +
 
 +
I agree with Lahwaacz about the fact that this page is becoming bloated and overlapping with the other index pages. However I also think that the very existence of this article (and its subsections) encourages Idomeneo1's approach, and honestly I don't think it's Simple anymore to understand what to keep here and what not, what to interlink where and what not etc., any solution still looks a bit arbitrary to me.
 +
 
 +
I was thinking, perhaps we could kill this page completely and merge the various sections in the appropriate Category pages, taking the chance to improve the [[Table of contents|Category tree]], possibly also creating empty categories if needed, which would function as placeholders in that case, or each Category could still contain a main section and some subsections. I think that our current [[Table of contents]] already has some resemblance with the ToC of this article, so that scope overlapping/duplication may be the root cause of the parent discussion. Categories can also have multiple parents, which would address the current problem of having to interlink sections of this article with each other. Another advantage is that users would get more used to look into the Category page of an article, not only to find related articles, but now also to find related software that may not have wiki articles. Another advantage is that when creating an article about a piece of software it's already clear where to categorize it.
 +
 
 +
Disadvantages: we lose the ability to see all the applications in the same page. (and...?)
 +
 
 +
Last thing, I think that this idea would look the best if the app lists were changed to tables, as we discussed a long time ago in [[Talk:List of games]] and now I tried in [[User:Kynikos/App]]. [[Template:App]] can be changed to create a table row very easily, but I'd also like to discuss restructuring it as shown at the bottom of [[User:Kynikos/App#Terminal emulators]], which IMO gives info less redundantly.
 +
 
 +
Enough :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 18:12, 5 March 2017 (UTC)
 +
 
 +
:Currently we have a rule that if category A has a subcategory B, pages in B cannot be categorized also in A. I'd imagine that the application lists/tables would follow similar rule to avoid duplication, so we'd also lose the ability to see all applications in category A on the same page. Depending on how the actual categorization would look like, this might be important disadvantage - consider e.g. the subsections of [[List_of_applications#File_sharing]].
 +
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:33, 5 March 2017 (UTC)
 +
 
 +
::Personally I don't think that viewing the whole [[List of applications#File sharing]] section in the same page is so useful; seeing its section structure in the ToC is useful, but that would be preserved in the automated category tree. As I wrote, we could allow subsections in Category pages, for example to keep non-specific distinctions like console/graphical or client/server. We could also instruct toc.py to read section headings in Category pages and show them in the generated ToC (perhaps only under [[:Category:Applications]]). Finally, it wouldn't be a violation of the DRY principle if we also generated pages that collate the contents of some Categories and their descendants, of course protecting them from manual editing. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:56, 6 March 2017 (UTC)
 +
 
 +
:::On second thought, [[:Category:Applications]] currently has only 2 levels of subcategories so I think the problem mentioned above does not apply. If more levels appear in the future, I'd imagine it would be for a reason and even then it might not be so terrible. The parent tables or their captions might even contain a link to the subcategory tables to make them more visible instead of duplicating them. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:25, 8 March 2017 (UTC)
 +
 
 +
:::On third thought, we might even start with splitting up this very page, i.e. do [[#Link subpages instead of transcluding them]] + an autogenerated ToC list of sections on all subpages. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:33, 8 March 2017 (UTC)
 +
 
 +
::::I'm still in favor of [[#Link subpages instead of transcluding them]], it works as an improvement and a compromise for me. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:31, 9 March 2017 (UTC)
 +
 
 +
:I was actually thinking that for applications which have a wiki page, browsing [[:Category:Applications]] instead of this page should give basically the same results (maybe some small subsections are squashed together, but that's not a problem). To make things simple(r), we might just say that topics which have most pages outside of [[:Category:Applications]] don't belong here and should be linked externally. Usually such topics have an introduction page, such as [[Server]], [[Xorg]] or [[Desktop environments]]. There would be a huge problem with "Utilities" and "Security" though. Also this approach would probably not cut the bloat enough.
 +
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:33, 5 March 2017 (UTC)
 +
 
 +
::As I said, I think that trying to find a clear rule to define what belongs in this page or not is too hard, there are too many blurred cases, as also seen in the parent discussion. IMHO the bloat problem of this article can't be reduced to only some sections in [[List of applications/Workspace]]: I like your "I think that the List of applications should be a comprehensible list of the most common categories of application software and not a comprehensive list of everything", but to me "List of applications" practically does sound like "List of everything", which is why I say that the problem is the whole article itself. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:19, 8 March 2017 (UTC)
 +
 
 +
:::Well think that we can cut it in halves: I don't see many problems with [[List of applications/Internet]], [[List of applications/Multimedia]], [[List of applications/Documents]] and [[List of applications/Science]] - they are all with individual sections or even list entries, but the overall scope is clear. On the other hand, most of the "applications" listed on the remaining pages, [[List of applications/Workspace]], [[List of applications/Utilities]], [[List of applications/Security]] and [[List of applications/Other]], fall simply under "Utilities". From what the current page looks like, I think it's roughly like "Desktop utilities", "System administration utilities", "Security utilities" and (shrugs) "Other utilities", but there are many overlaps so it's probably not very useful to make this differentiation and it would be better to call them just "Utilities". Btw. I think that the category tree has generally the same problem with arbitrary decisions: somehow I don't see a common idea behind [[:Category:Command shells]] under [[:Category:Applications]] and [[:Category:Desktop environments]] under [[:Category:System administration]]. So that's the problem - do you see a way out? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:29, 8 March 2017 (UTC)
 +
 
 +
::::Let's use the branch above about the destiny of this article.
 +
::::About the categories, as you say the problem is similar, I don't think there's much to do other than solve case by case: I'm in favor of moving [[:Category:Command shells]] and also [[:Category:Status monitoring and notification]] and [[:Category:Terminal emulators]] under [[:Category:System administration]]. Another thing that I'd do is rename [[:Category:Networking]] to [[:Category:Network administration]], and move only to [[:Category:Applications]] what doesn't fit there anymore, in particular [[:Category:Internet applications]], [[:Category:Telephony and voice]] and probably also [[:Category:Remote desktop]], plus possibly recategorize some articles which are currently directly under [[:Category:Networking]]. At that stage I would also consider renaming [[:Category:System administration]] to [[:Category:Host administration]] to remark the ''ideal'' complementarity of the two *_administration categories.
 +
::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:31, 9 March 2017 (UTC)
 +
 
 +
:The category tree / table of contents lists wiki pages, not apps - an app would have to have a special wiki page just to be mentioned, and even then, there is old cruft in the wiki pages as well. And that is ''much'' harder to clean up than a list.
 +
:I definitely agree the categories need improvement.
 +
:--[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 00:09, 7 March 2017 (UTC)
 +
 
 +
::Probably I didn't explain it very clearly, but my idea would be to merge the various lists here (turned into tables) in the editable part of Category pages, e.g. [[:Category:Getting and installing Arch]], so applications wouldn't need a wiki page to be mentioned there. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:49, 7 March 2017 (UTC)
 +
 
 +
:::I like tables, especially sortable ones, though I'm not sure how they simplify things.
 +
:::An option could be to break the lists down into smaller sections, which could then be included in their respective wiki pages, as well as in a master list-of-apps page.
 +
:::An issue I see with the current [[Table of Contents]] is that it is entirely manually structured - no headings. How is a category tree "automated"? Does this automation preserve included lists/tables/cross-links?
 +
:::--[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 00:00, 8 March 2017 (UTC)
 +
 
 +
::::Tables in this case more than simplifying would reduce bloat, since many entries would be reduced to one line (at least on wide screens), and the various fields (name, description, website, packages) would be neatly and rationally separated, making it much easier to scan for the needed info. Tables are also a more standard and often preferred way to list and compare applications e.g. on Wikipedia.
 +
::::About breaking the lists further and merging them into specific wiki pages, I'd be in favor if you want to discuss specific cases. However what is merged into other articles can't be duplicated in a "master list-of-apps page".
 +
::::[[Table of contents]] is completely generated by a [https://github.com/lahwaacz/wiki-scripts/blob/master/toc.py bot], there's no manual structuring. I'm not sure what you mean with your question about preserving included lists etc.
 +
::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:00, 8 March 2017 (UTC)
 +
 
 +
:::::Your [[User:Kynikos/App]] trial is a great approach, but I'm unconvinced tables being a good format for this information. If you look at the sections, each table has different column widths (for a reason, but not neat). There are too many other variances: the current template app allows for short or longer descriptions, a single bot comment may shift column width for a whole table, etc. Worst: Even on a wide screen (which can't be a precondition in my view) table data would always break URLs, which is neither readable nor a neat, positive presentation. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:07, 8 March 2017 (UTC)
 +
 
 +
::::::Just clarifying that my plan was to eventually switch to the format at the bottom of [[User:Kynikos/App#Terminal_emulators]], which doesn't display urls explicitly. Other modifications in the 3-column table solution that I see as advantages would be to resolve the current [[Template:App]]'s redundancy of always requiring to show the app's packages even when there is a dedicated article which already lists them. However I acknowledge that the idea of using tables isn't attracting much positive feedback, so ok, I'll keep it for the future generations ^^ — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:12, 9 March 2017 (UTC)
 +
 
 +
::::::: Ok, thanks. Not displaying URLs would help, yes. Still I don't believe we would be able to make column width look neat across sections. Nested tables (for neatness) are not an option re maintainability. I see your point about showing duplication with the packages, but particularly in this list it can also be quite helpful to click through to content of alternative packages directly. It's not that a dedicated article would have immediate info on that. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:23, 15 March 2017 (UTC)
 +
 
 +
:::::What I was suggesting was to break these lists up further into smaller "include" pages, such as Browsers, Window managers, File managers, etc etc, on separate, single "include" pages that could be simply "included" on the respective wiki pages, as well as the category pages, as well as the list of apps. This would provide simplicity, visibility, and coherence, so a whole bunch of app lists don't need to be maintained separately.
 +
:::::--[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 23:56, 8 March 2017 (UTC)
 +
 
 +
::::::Hmmm every time that you added, split or removed an included page you'd have to remember to update all the articles that include it, and also you wouldn't be able to include section headings because their levels would have to adapt to the host articles, so it wouldn't be very easy to maintain. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:31, 9 March 2017 (UTC)
 +
 
 +
:::::::That would be true of any new wiki pages. The idea is to break the lists up into logical units that could be included on multiple pages and categories. Then, when you update the actual lists, such as fixing/removing broken links, you would only need to do it once, instead of editing multiple pages for every list edit.
 +
:::::::--[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 01:33, 10 March 2017 (UTC)
 +
 
 +
:::::::: I think to a large extent the app list in this article is it's own meta information, and that diminishes the more we break it down into smaller (&detached) units. When I try to apply your idea to e.g. [[List of applications#Screen lockers]] (same goes for "file manager", "browsers" examples to me), it's hard to picture where we would want to include that list but easy to imagine it can be helpful to link to from, say, a window manager article. Even '''if''' that "screen locker" unit would list 100% applicable packages for window manager A and B, is it really that helpful to include the full list in A and B? Likewise I don't see how that section can be broken down into more units, such attempt is bound to be very arbitrary in every case. Not simple. What would be a practical example of an include unit with two targets? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:30, 15 March 2017 (UTC)
 +
 
 +
:I have to disagree. Categories pose an important way to navigate wiki articles. Placing long lists of applications (that mostly don't have wiki articles) at the top of category pages would mean that you often have to scroll down category pages to reach their index and thus preventing you from quickly navigating the wiki by categories. –[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 09:19, 31 December 2017 (UTC)
 +
 
 +
::I agree with [[User:Larivact|Larivact]] points. On main topic, I favour splitting existing list pages in separate articles like [[Web browser]], [[Screen locker]] etc. This would give us more space to have sufficiently detailed explanation what each type of software is and does and would make more sense in context of topic-based wiki. As for respective categories we can have {{ic|The main article for this category is [[Web browser]].}} disclaimer like on [[w:Category:Web_browsers|wikipedia]]. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 17:42, 26 February 2018 (UTC)
 +
 
 +
:::I concur, I created [[#Merge sections to dedicated articles]] and [[Template:Cat main]]. On a side note I don't think we need to explain what each type of software is, linking the respective Wikipedia article should suffice.--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:29, 11 May 2018 (UTC)
 +
 
 +
:''[The following related post was copied here from [https://wiki.archlinux.org/index.php?title=Talk:Bottle&oldid=490503#Archive Talk:Bottle#Archive]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:45, 27 April 2018 (UTC)]''
 +
:In general I think it's a bit unfair and counterintuitive though that the better documentation a piece of software has (or the better it works in general), the lesser visibility (and search references) it gets in our wiki (the software runs fine out of the box (good!) => no need for installation/configuration/troubleshooting sections => no wiki article; the software needs distro-specific guidance to be set up (less good / bad) => need for installation/configuration/troubleshooting sections => wiki article allowed). This may also be related to [[Talk:List_of_applications#Merge sections to category pages]], i.e. our Categories could link all current/popular options and point to the upstream docs, and ''possibly'' also to our articles for Arch-specific adaptations.
 +
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:27, 17 September 2017 (UTC)
 +
 
 +
::The purpose of the ArchWiki is to provide information, not SEO. If we list all current/popular options on category pages we obstruct the navigability of our information (see my point above).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 19:21, 10 May 2018 (UTC)
 +
 
 +
=== Merge sections to dedicated articles ===
 +
 
 +
[[User:Svito|Svito]] proposed to split up [[List of applications]] into separate articles like [[Web browser]], [[Screen locker]] etc.
 +
 
 +
I think that's the best approach because of the following advantages:
 +
 
 +
* no two co-existing categorization systems like we currently have ([[List of applications]] and MediaWiki categories), instead just MediaWiki categories
 +
* articles can easily be linked and found via search
 +
* it does not obstruct navigating the wiki by categories like [[#Merge sections to category pages]] does
 +
 
 +
As this approach would make categories more important, I think we should firstly implement [[Mediawiki talk:Common.css#Move categories under h1]].
 +
 
 +
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:25, 11 May 2018 (UTC)
 +
 
 +
:[[#Merge sections to category pages]] would have required to reproduce a tree of categories under [[:Category:Applications]] similar to the ToC of this article. I don't mind this solution, but would you still create the additional categories, which in several cases would of course only contain the respective List page, or would you for example put all the split list articles from [[List of applications#Multimedia]] under the same [[:Category:Multimedia]]? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:45, 20 May 2018 (UTC)
 +
 
 +
::Latter would make sense as having category for just one article would be odd. I would still keep this page to have list of links to all lists of applications. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 17:18, 21 May 2018 (UTC)
 +
 
 +
:::Opposite for me, I support the category-tree way, at the cost of having one- (this proposal) or zero-article ([[#Merge sections to category pages]]) categories.
 +
:::If this page ends up still being required to show the tree of application lists which reside under common categories, then splitting loses much of its point in my view.
 +
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:32, 22 May 2018 (UTC)
 +
 
 +
=== Replace with external interface ===
 +
 
 +
On second thought I am not convinced of [[#Merge sections to dedicated articles]] either. MediaWiki is just unsuited for a well-categorized list of applications. Especially since applications can be in multiple categories. A real radical alternative would be to <ins>outsource &</ins> convert the List of applications to text files in a Git repository. A text file would have the name of the package and could look like this:
 +
{{bc|<nowiki>name=Thunderbird
 +
description=Feature-rich email client from Mozilla written in GTK+.
 +
url=http://www.mozilla.org/thunderbird/
 +
tags=email client,news aggregator,usenet client,irc client,xmpp client,twitter client</nowiki>}}
 +
These files could then be converted to a static HTML site or queried via a hypothetical command-line interface.
 +
 
 +
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 16:46, 20 May 2018 (UTC)
 +
 
 +
:I would not dismiss original subject of how and where we want to display application lists on the wiki. You touch on entirely different topic that is browsing application lists outside the wiki, for which existing web interfaces could be improved for. It is inevitable that we would want to use upstream metadata from packages themselves and periodically generate application lists without editor intervention. I strongly believe we can take baby steps and reuse existing standards as much as possible:
 +
:* Merge sections to dedicated articles, leave links to all of them here
 +
:* Transform all lists into tables, fill in all metadata
 +
:* Explore if we can use [https://www.freedesktop.org/wiki/Distributions/AppStream/ AppStream] for our metadata, if not - contribute to AppStream spec so we can
 +
:* Push our metadata to upstream projects using AppStream, so we don't have to maintain it
 +
:* <s>Write scripts to periodically generate specific application tables on pages</s>
 +
:* Add AppStream support to existing web interfaces
 +
:* Have a root beer with [[User:City-busz|City-busz]]
 +
:<s>Before any of it let's agree to split this discussion first(again)</s>
 +
:-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 20:41, 20 May 2018 (UTC)
 +
 
 +
::I think you missed my point, I proposed to outsource the list of applications from MediaWiki. It's not an entirely different topic, it's an entirely different solution to our categorization problem.
 +
::The main feature and biggest problem of the [[List of applications]] is categorization, upstream metadata won't help us with this because <ins>advanced</ins> categorization needs to be done centrally.
 +
::I regard AppStream as irrelevant as it doesn't deal with advanced categorization like the [[List of applications]] does.
 +
::--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 16:11, 21 May 2018 (UTC)
 +
 
 +
:::Defining category structure is not AppStream job and neither of [https://standards.freedesktop.org/menu-spec/menu-spec-latest.html#additional-category-registry Desktop Menu Specification]. It is completely up to the software if and how to display and organize those and there is no restrictions on number of categories software can belong to. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 20:04, 21 May 2018 (UTC)
 +
 
 +
:::I did miss your point. Can you be more specific what that would mean for fate of this article, its content and existing category structure? -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:51, 21 May 2018 (UTC)
 +
 
 +
::::The [[List of applications]] would no longer be on the ArchWiki but a different website, perhaps {{ic|archlinux.org/apps}}. It would still link to the ArchWiki. The metadata from which the website gets generated could be on GitHub <s>or, perhaps a better idea, in a single page on the ArchWiki</s>. The existing content & categorization would need to be converted by a script (with some human intervention required to map sections to tags and merge apps present in multiple categories).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 17:42, 21 May 2018 (UTC)
 +
 
 +
:::::Then AppStream would be more than suitable for this. See [https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#sect-Metadata-GenericComponent GenericComponent] for example, relying on [https://standards.freedesktop.org/menu-spec/menu-spec-latest.html#additional-category-registry Desktop Menu Specification] for valid Category definitions. Contributing missing category definitions should not be a problem provided we will have multiple examples in our wiki needing them, especially because we as [[Arch Linux]] community have always worked upstream rather than downstream. In the end this benefits not just Arch Linux, but everyone who already uses AppStream and upstream projects. Many applications already support the spec with existing categories, and ArchLinux already supports AppStream for official repositories with {{Pkg|archlinux-appstream-data}}. Finding a way to use AppStream with AUR would be a next step.
 +
:::::If we to terminate this article and to use GitHub or dedicated page to maintain our metadata, this would still require people to create pull requests or wiki accounts just to add their software to the list and we would still be manually adding and removing software when it goes in or out of repositories or AUR. If we to use AppStream for metadata and contribute it to upstream projects, projects using it would automatically appear in our generated lists as they enter the repo or AUR, but also software center applications across all distributions. Of course we would still need to contribute our metadata to new projects without it.
 +
:::::I understand your reluctance to not deal with any existing solution, I like your idea, <s>but I hate any prospect of downstream metadata, damned it be</s>.
 +
:::::-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 19:34, 21 May 2018 (UTC)
 +
 
 +
::::::While the [[List of applications]] tries to meticulously categorize the whole software world, the Desktop Menu Specification strives get you a nice little GUI menu of your installed applications. These are two completely different motives. The Desktop Menu Specification lacks so many categories that it is utterly unsuitable for the [[List of applications]]. And they will not accept our categories as they do not make sense for a desktop menu. Like I said advanced categorization needs to be done centrally.
 +
::::::--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 05:08, 22 May 2018 (UTC)
  
Moving here Conspire from the IRC clients section, since it's reported to fail to build and it had been commented in the list (bad practice):
+
:::::::You seem to be mistaken Main categories with [https://standards.freedesktop.org/menu-spec/menu-spec-latest.html#additional-category-registry Additional categories], which I link description of from previous page here just for convenience: {{ic|can be used to provide more fine grained information about the application}}. They are just "tags" in conventional sense, but better yet explicitly defined as a standard. We are exactly ones in position to add more Additional categories to the spec, as application developers can't really have a say in it individually, nor they have any real incentive (yet) to bother adding them. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 09:17, 22 May 2018 (UTC)
  
* {{App|Conspire|Lightweight, simple, and powerful|http://nenolod.net/|{{AUR|conspire-client}}}}
+
::::::::Outsourcing the metadata to upstream would mean that we could no longer effectively maintain or control it. This would reduce its quality and objectiveness.--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:26, 22 May 2018 (UTC)
  
-- [[User:Kynikos|Kynikos]] 17:02, 10 March 2012 (EST)
+
:::::::::I created [[User:Svito/List of applications|draft with tentative additional categories]] I will be working on, but I changed my mind on idea of using it to generate tables on the wiki, which you just proven to me is terrible idea. I completely agree we don't need this article if we to have better means of finding software and its alternatives. I will try to improve existing specs for metadata we would like exposed by applications, but in the meanwhile I'm not opposed to your solution as well. Sorry for my stormy language before. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 13:24, 22 May 2018 (UTC)
  
== Discussion on subpages ==
+
::::::::::Usually console applications don't have AppStream metadata, nor desktop file. The categories of Desktop Menu Specification don't give us the details and flexibility what we need, and upstream give sometimes inaccurate details that we need to fix from an objective view.
  
I think all discussions from subpages (e.g. [[Talk:List_of_Applications/Internet]]) should be moved here, following the example of [[Talk:Beginners' Guide]]. Perhaps this could be a general rule ([[Help_talk:Style]] would have to be excluded)? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:33, 5 August 2013 (UTC)
+
::::::::::Personally I like the simplicity what MediaWiki provides, and I don't see much benefit from using a custom metadata system. Of course if anyone create and setup a better interface for listing and comparing applications, we can consider to remove application lists from Arch Wiki.--[[User:City-busz|City-busz]] ([[User talk:City-busz|talk]]) 14:03, 22 May 2018 (UTC)
  
:Well yes, it would be better if they were merged here. About making a rule, maybe it should concern only subpages that are included in a single main page, just like [[List of Applications]] and [[Beginners' Guide]] (and do we have any other examples? I can't think of any right now...). -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:10, 5 August 2013 (UTC)
+
== <s>List of screenshot tools</s> ==
  
::Good points... I'll move the discussions here and add a note to start new discussions here. When/if there are more pages like this, I think some rule should be made. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 5 August 2013 (UTC)
+
There is a suitable page dedicated to the topic, so the content should be in one place. It's not like that every list of applications present on the wiki must be unconditionally on this page. {{Unsigned|17:38, 10 May 2018‎|Lahwaacz}}
  
== Multi-Protocol Downloader section ==
+
:I would prefer to keep the list of screenshot tools on [[List of applications/Multimedia]] page rather than moving it back to the [[Taking a screenshot]] page. Screencast tools are also listed on that page, which is a similar topic. I think we should keep software lists in one page until a decision happen to split them into multiple articles/categories as described in [[#Merge sections to category pages]]. --[[User:City-busz|City-busz]] ([[User talk:City-busz|talk]]) 17:53, 10 May 2018 (UTC)
  
Similarly to command shells, a downloader section is missing. Here we find good the same one: [[pyLoad#Alternatives]] [[JDownloader#Alternatives]].
+
::If there's a dedicated article the App list belongs there, or do you also want to move the App lists of [[Desktop environment]], [[Window manager]], [[Display manager]] to [[List of applications]]? But I agree that screenshot tools and screencast tools belong together, which is why [[Special:Diff/520859|I propose]] to move both to [[Screen capture]].--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 05:46, 11 May 2018 (UTC)
Plus aria2, curl, wget, kget should be added. Is it ok? Could you point me more downloaders?
 
As kget and aria2 would be doubled we can do a "Multi-Protocol Downloader" section like [[List_of_Applications#Multi-Protocol Clients]] and delete original entries liting supported protocols. -- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 16:37, 8 September 2013 (UTC)
 
  
:Good plan, +1. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:01, 11 September 2013 (UTC)
+
:::[[Desktop environment]], [[Window manager]], [[Display manager]]: these are not simply desktop applications, and require specific configuration, so it's reasonable to put them into separated articles. There is no specific configuration needed for screenshot and screencast tools, these are individual applications, therefore I would prefer to keep them together with other multimedia applications. Or if it's preferred to put these list into separated articles, then we should split the list completely, and create individual articles for raster graphics editors, for vector graphics editors and so on.--[[User:City-busz|City-busz]] ([[User talk:City-busz|talk]]) 10:22, 11 May 2018 (UTC)
  
== Should we move [[Partitioning #Partitioning tools]] to here? ==
+
::::If there was nothing else but the list on the [[Screen capture]] page, I would agree with you that it's better to keep the list in [[List of applications]]. But that's not the case, similarly to [[Clipboard#List_of_clipboard_managers]] and likely many other pages I can't think of right now. Splitting the [[List of applications]] completely is a different topic since there would be only the lists on the newly created pages. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:24, 11 May 2018 (UTC)
  
I am wondering that it is there, not here. -- [[User:Acgtyrant|acgtyrant]] ([[User talk:Acgtyrant|talk]]) 13:24, 22 December 2013 (UTC)
+
:::::I created [[‎#Merge sections to dedicated articles]] for that different topic.--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:33, 11 May 2018 (UTC)
  
:I don't think this is a good idea, they would be completely out of context here. Note that many sections in [[List of Applications]] just link to the main article on this wiki, e.g. [[List_of_Applications#Clipboard_managers]] or [[List_of_Applications#Desktop_environments]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:35, 22 December 2013 (UTC)
+
:::::I moved the screenshot and screencast tools to [[Screen capture]].--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 18:20, 26 July 2018 (UTC)

Latest revision as of 17:30, 18 August 2018

Categorization

Classification troubles

Can "CD/DVD Burning Tools" be considered part of "Multimedia"? Should "Screen Capture" section be part of "Utilities" or "Multimedia"? --AlexanderR 21:10, 16 January 2012 (EST)

Eh I'm afraid we'll just have to establish a convention: I'd say Burning tools in Multimedia and Screen Capture in Utilities? Let's wait for more opinions. -- Kynikos 07:53, 17 January 2012 (EST)
As I see, CD/DVD Burning Tools are already a part of Multimedia. Screen Capture, I think, must be in Utilities.
And there's another question from russian users. OCR software isn't a reader or viewer, so it must be before or after 1.9 Note taking organizers with corresponding number 1.9 or 1.10
UPD. Also, there's a good idea to add in this section some (or all) progs from Optical Character Recognition -- Kycok (talk) 05:32, 11 April 2014 (UTC)
Um... "Utilities" is practically a default category for applications that don't fit anywhere else: since "Screen capture" is kind of related to "Multimedia", it would probably be better to leave it there (thus changing the opinion I expressed above, I think I'm allowed, after more than 2 years :P ).
I'm quite neutral about moving "OCR software" in the tree: it is related to "Scans", but maybe not so closely. I'm also neutral about merging Optical Character Recognition there: actually that article doesn't contain anything except for a short list of applications, so it could indeed be merged.
Anyone with a stronger position on the topic? -- Kynikos (talk) 14:12, 11 April 2014 (UTC)
So, I've made corresponding changes in Documents section. Also I've merged Pdf and DjVu, because many progs in Pdf works with DjVu. I've deleted tool fbdjvu, because, as I see, it's merged with fbpdf.
Let's talk if there's another opinions about my changes -- Kycok (talk) 09:59, 14 April 2014 (UTC)
Well done, except you forgot to redirect Optical Character Recognition, fixed now :) -- Kynikos (talk) 12:53, 15 April 2014 (UTC)


I have submitted a AUR package for sendanywhereAUR, a cross-platform p2p file sharing utility (similar to Pushbullet, but with standalone software client). I am not sure under which section I should include it. It is definitely not FTP based or bittorrent based. Should it go under Downloaders or Communications; also, shall I start a new subsection, maybe called p2p file sharing/pushing? Jadelord (talk) 11:17, 6 January 2016 (UTC)

I've just created List_of_applications/Internet#Other_P2P_networks, I think that's the best place for the moment. — Kynikos (talk) 03:11, 7 January 2016 (UTC)

Link subpages instead of transcluding them

Just wondering if it would be better to completely split the article up into separate articles, rather than transcluding everything back in as templates. Perhaps just include links and a brief summary of each category in the top-level page, maybe something along the lines of:

This page has various categories of programs and points to lists of programs in those categories. It is a useful starting point for finding a program for a specific application. [Introduce console versus graphical.]

Internet including network configuration, and clients or browsers for web sites, FTP, file sharing, chat and email messaging, web feeds, and microblogging

Multimedia including viewers, players and editors for raster, vector, 3D, CAD, audio and video, GUI capture, systems for accessing audio devices, audio CD rippers, and e-book programs.

Utilities, which covers package management, file managers including space usage, compression and merge tools, optical disc burning, clipboards, GUI taskbars.

Documents: readers for printable files like PDFs, office suites, word processors, spreadsheets, text search, OCR

Security: firewalls; file, network and log monitoring, scanning and analysis; backup

Games: native and emulators

Science: calculators, visualisation, design, programming environments and other tools for maths, chemistry, biology, astronomy, electronics and physics

Other: note taking and scheduling; translation; desktop environments and window managers; terminals; OS monitors; text editors

See also [other general lists of programs]

Smaller individual pages would be nicer, because often I’m only interested in programs for a specific application, such as (in the past) Science#Electronics, and Multimedia#GUI players (audio). Even using the TOC, I think currently it’s too easy to get lost or overwhelmed. Vadmium 00:18, 26 January 2012 (EST).

I think the main problem here is that if I'm looking for a particular subcategory I have to guess under which main category it can be, while currently, with the comprehensive ToC, that task is easier. Possible compromise: maintain a "manual" Table of Contents in the top-level page, with links to the various subpages/subsections. Let's hear more opinions. -- Kynikos 07:53, 26 January 2012 (EST)
The page is gigantic and loads very slowly on my internet connection, so I think splitting into subpages is a good idea. Maybe the page length could also be reduced by only having the top 5 most used/useful apps for each category. I am hesitate about that suggestion as I have also found some more obscure but very useful things on this page, but it has gotten to be so unwieldy to navigate now. We could also have the "alternative to" website under a "see also" section as well as links to other external linux package lists.Meskarune (talk) 20:34, 12 August 2018 (UTC)
155KB isn't that much on the modern web, every website containing a large image is larger. The page is already split in subpages, which you can access using the top navigation. Reducing the apps per category is not in question. Navigating the pages shouldn't be an issue if you use the ToC / Ctrl+F. --Larivact (talk) 03:39, 13 August 2018 (UTC)
155KB may be the size of the wikicode, but the resulting HTML version of List of applications is about 1.1MB, which is a lot even for "modern web"... -- Lahwaacz (talk)
Wrong, 155KB is the transferred size of the HTML if it's br compressed. For gzip it's 170KB. --Larivact (talk) 07:27, 13 August 2018 (UTC)

See also visibility

Does somebody have any idea on how to improve the visibility of the See also section? -- Kynikos 07:13, 23 January 2012 (EST)

Its probably not in good style, but could we add an article overview, and have an article summary section containing the see also links?--Leocp1 16:59, 23 January 2012 (EST)
@Leocp1 What links are you talking about? Wiki links already should be covered by Template:Article_summary_wiki), among others I'd prefer to see only important ones (like links to software home page, documentation, own wiki etc) included included in the template. --AlexanderR 19:11, 23 January 2012 (EST)
I've written a summary in the subsection below and added some other ideas: currently I think solution 4 may be the tidiest and best looking, otherwise I'd try solution 1 as a second choice. Please add your opinions there so we can make a better decision.
@AlexanderR We're talking about the See also links at the bottom of the article, not the links specific to each application, which should stay in the proper App template and/or the related wiki article (I'm not sure if that's what you meant).
-- Kynikos 07:38, 24 January 2012 (EST)
Who in the world uses this links at all? Wikipedia does not have any links at the bottom of articles except proofs of written or ones in categories templates. We do not provide proofs.. Or do we? And it would be great to see statistics of clicks on such links... --AlexanderR 08:01, 24 January 2012 (EST)
Not sure if I'm on the same page as you, but many Wikipedia articles have 'External links' section at the bottom, below the references and above the 'Related articles' part. Have a look at e.g. http://en.wikipedia.org/wiki/Uefi article. It has 'See also', 'References' and 'External links' sections. -- Karol 08:43, 24 January 2012 (EST)


Ideas so far

  1. Move all see-also links to article summary --Leocp1 16:59, 23 January 2012 (EST)
    • PROS:
      • Currently style compliant (but see related con) -- Kynikos 07:38, 24 January 2012 (EST)
    • CONS:
      • There's little room for long URLs and/or descriptions, unless we want to see ugly line wrapping. -- Kynikos 07:38, 24 January 2012 (EST)
      • It's possible that in the future the style for article summaries will be reformed not to allow external links anymore, requiring them to be in See also sections only. -- Kynikos 07:38, 24 January 2012 (EST)
  2. Move only important see-also links to article summary --AlexanderR 19:11, 23 January 2012 (EST)
    • PROS:
      • Same as 1.
      • No problems with line wrapping. --AlexanderR 23:48, 3 February 2012 (EST)
      • In many articles links to site/Wikipedia/etc. are already located in random places in text. Placing them all into single template at the top will hardly make "See also" section less visible than now. --AlexanderR 23:48, 3 February 2012 (EST)
    • CONS:
      • Same as 1.
      • The See also section will be even more "buried" at the bottom of the article, becoming practically useless. -- Kynikos 07:38, 24 January 2012 (EST)
  3. Find a new name instead of "See also", move the section at the top, as the first section (and change its layout, e.g. use 2 columns?). -- Kynikos 07:38, 24 January 2012 (EST)
    • PROS:
      • Links are immediately accessible and there's room for long URLs and descriptions. -- Kynikos 07:38, 24 January 2012 (EST)
    • CONS:
      • Incosistent with the other articles, may look ugly. -- Kynikos 07:38, 24 January 2012 (EST)
  4. Link to #See also from the introduction, with a sentence that enhances its visibility. -- Kynikos 07:38, 24 January 2012 (EST)
    • PROS:
      • Style compliant. -- Kynikos 07:38, 24 January 2012 (EST)
      • The main content of the article is still shown first. -- Kynikos 07:38, 24 January 2012 (EST)
    • CONS:
      • Links are not evident at a glance unlike the solutions above. -- Kynikos 07:38, 24 January 2012 (EST)

Order of things?

Is there any special order to these lists?

For instance, under "Internet" it would seem more intuitive to begin with "Network Managers", then "Browsers", then a section for "Downloaders". and so on. Idomeneo1 (talk) 00:51, 20 January 2014 (UTC)

"Intuitive" is subjective, I'd just simply use alphabetical order, although I know it's not used anywhere at the moment... -- Kynikos (talk) 21:07, 20 January 2014 (UTC)
Call it chronological? i.e. an order in which people (especially beginners) would think of setting things up - network, browser, communication, downloads, media etc.
The problem with alphabetical lists is that even if we decide on "correct" terms for things, some people will, i.e., look for 'console', and others for 'terminal'.
Idomeneo1 (talk) 14:10, 21 January 2014 (UTC)
Eheh a similar objection could be made for the "chronological" order, which, as I said, is subjective, e.g. some people may want to install messaging apps before p2p or vice versa. Maybe what you really mean is a "dependency" order, i.e. if in a group of sections there's one that lists applications (e.g. network managers) that may be necessary for applications in other groups to work, then put it at the top. I can agree with that, also because other sections like the various "Other" should instead better be kept at the bottom. All the in-between sections, though, should be sorted alphabetically: the problem of synonyms would affect any kind of odering we may choose, and in general it affects all kinds of word lists (e.g. dictionaries), so users are used to dealing with it.
If you're willing to do the reordering, please do it in several little edits, not a single big one.
-- Kynikos (talk) 07:13, 22 January 2014 (UTC)
Yes, having "Other" at the end is exactly the kind of order I mean.
Idomeneo1 (talk) 15:25, 22 January 2014 (UTC)

List dead projects or not?

Kino is dead, it doesn't even have a maintainer in the AUR. Is it OK to remove dead-but-still-working applications from the list in the wiki? -- Karol (talk) 14:16, 3 February 2014 (UTC)

I wouldn't really know what's best to do, but if the application is confirmed to be still working, keeping it in the list should be the default action until somebody proves that listing it is counterproductive in some way. Of course a note about the EOL should be added if restored. -- Kynikos (talk) 15:50, 4 February 2014 (UTC)

The aterm project website has been directing people to use urxvt instead since 2008. I've noticed quite a few projects in the maintainer-doesn't-even-advise-using-it category on this page and I don't see what purpose they serve. Ryne Everett (talk) 02:26, 13 December 2014 (UTC)

Well, the apps whose upstream maintainers explicitly discourage using them can indeed be removed, possibly making sure that any indicated alternative is already present in this list, adding it otherwise. Just note that, taking your post literally, "not advising to" is different from "discouraging to" (the aterm case falls indeed in the latter case) :) Please state the reason for removing applications from the list using the edit summary. -- Kynikos (talk) 02:32, 14 December 2014 (UTC)
I propose a deprecation warning, especially in the security subpage. there are numerous projects listed, that might still work, but are not developed anymore. this renders them insecure, as malware recognition needs to keep up with developement. This concerns rkhunter, chkrootkit and also the currently unlisted unhide. Fordprefect (talk) 12:35, 2 September 2016 (UTC)
I think it's too soon to talk on warnings like that when there's hundreds of dead AUR packages on the list... -- Alad (talk) 15:41, 2 September 2016 (UTC)
Well, for packages meant to improve security concerning malware, frequent updates are no bonus, but crucial. a simple note would help users distinguish more and less active projects. Fordprefect (talk) 17:17, 2 September 2016 (UTC)
At least rkhunter is still in the official repos, and John Horne, the current main developer is still answering posts in the mailing list. — Kynikos (talk) 01:12, 3 September 2016 (UTC)

Scope of the page

It seems that this page is becoming a bloated index for all possible "lists" on the wiki, or maybe even the whole wiki itself. There are other pages to help users find what they are looking for, e.g. Table of contents, General recommendations and of course the full-text search. Therefore I think that the List of applications should be a comprehensible list of the most common categories of application software and not a comprehensive list of everything. I believe that the index pages can have separate targets and cooperate with each other to provide a complete picture instead of overlapping and hindering readability by linking to each other.

I propose the following:

-- Lahwaacz (talk) 14:44, 2 March 2017 (UTC)

I've undone most of the structural changes to List of applications (starting with [1]) due to their one-sided nature. A radical restructure of one of the most popular wiki articles requires a consensus that isn't (yet) reached here. -- Alad (talk) 14:38, 15 March 2017 (UTC)
About Display managers et al., perhaps we should just have a general header such as "Graphical user interface" and link to General recommendations#Graphical user interface. The idea is that the sections in question contain little more than single wiki links and as such add TOC entries to little benefit. As touched upon in #Merge sections to category pages, a comprehensive TOC is already served by Table of Contents and there's no need for this page to compete. We could remind users of this by placing a link to Table of contents somewhere at the top.
Other sections such as List_of_applications/Other#Window_tilers could further be moved to their respective articles (here Window manager) to have all information in one place.
If this approach works out, we could use it to reduce List of applications/Other and List of applications/Utilities in size and merge the articles accordingly, as a compromise until a better approach is agreed upon in #Merge sections to category pages. -- Alad (talk) 14:48, 15 March 2017 (UTC)
I think that "Graphical user interface" is too general, it might attract items or crosslinks to other sections for anything with a GUI. We might call it "Custom desktop environment" or something like that to group List_of_applications#Taskbars_.2F_panels_.2F_docks, List_of_applications#Application_launchers, List_of_applications#Wallpaper_setters, List_of_applications#Virtual_desktop_pagers, List_of_applications#Logout_dialogue and probably also List_of_applications#Screen_lockers. It could contain links to General recommendations, Window manager etc. but I wouldn't merge them anywhere until the recategorization discussed in #Merge sections to category pages is finished. -- Lahwaacz (talk) 15:15, 15 March 2017 (UTC)
See [2], [3].
I've kept List of applications/Other#Window managers, List of applications/Other#Window tilers and List_of_applications/Other#Taskbars_.2F_panels_.2F_docks (latter could use a simpler name?) under the same List of applications#Desktop environments header because they're equally a part of a Desktop environment just like e.g. an application launcher is. We can always remove those items later on a restructure. -- Alad (talk) 18:10, 15 March 2017 (UTC)
Some more candidates:
So yes, I've also taken on the hard task of properly classifying entries in the "Other" categories. Though I would say completing this will make discussing proper alternatives easier. -- Alad (talk) 17:41, 15 March 2017 (UTC)

Merge sections to category pages

Warning: extreme brainstorming, join at your own risk.

I agree with Lahwaacz about the fact that this page is becoming bloated and overlapping with the other index pages. However I also think that the very existence of this article (and its subsections) encourages Idomeneo1's approach, and honestly I don't think it's Simple anymore to understand what to keep here and what not, what to interlink where and what not etc., any solution still looks a bit arbitrary to me.

I was thinking, perhaps we could kill this page completely and merge the various sections in the appropriate Category pages, taking the chance to improve the Category tree, possibly also creating empty categories if needed, which would function as placeholders in that case, or each Category could still contain a main section and some subsections. I think that our current Table of contents already has some resemblance with the ToC of this article, so that scope overlapping/duplication may be the root cause of the parent discussion. Categories can also have multiple parents, which would address the current problem of having to interlink sections of this article with each other. Another advantage is that users would get more used to look into the Category page of an article, not only to find related articles, but now also to find related software that may not have wiki articles. Another advantage is that when creating an article about a piece of software it's already clear where to categorize it.

Disadvantages: we lose the ability to see all the applications in the same page. (and...?)

Last thing, I think that this idea would look the best if the app lists were changed to tables, as we discussed a long time ago in Talk:List of games and now I tried in User:Kynikos/App. Template:App can be changed to create a table row very easily, but I'd also like to discuss restructuring it as shown at the bottom of User:Kynikos/App#Terminal emulators, which IMO gives info less redundantly.

Enough :) — Kynikos (talk) 18:12, 5 March 2017 (UTC)

Currently we have a rule that if category A has a subcategory B, pages in B cannot be categorized also in A. I'd imagine that the application lists/tables would follow similar rule to avoid duplication, so we'd also lose the ability to see all applications in category A on the same page. Depending on how the actual categorization would look like, this might be important disadvantage - consider e.g. the subsections of List_of_applications#File_sharing.
-- Lahwaacz (talk) 21:33, 5 March 2017 (UTC)
Personally I don't think that viewing the whole List of applications#File sharing section in the same page is so useful; seeing its section structure in the ToC is useful, but that would be preserved in the automated category tree. As I wrote, we could allow subsections in Category pages, for example to keep non-specific distinctions like console/graphical or client/server. We could also instruct toc.py to read section headings in Category pages and show them in the generated ToC (perhaps only under Category:Applications). Finally, it wouldn't be a violation of the DRY principle if we also generated pages that collate the contents of some Categories and their descendants, of course protecting them from manual editing. — Kynikos (talk) 05:56, 6 March 2017 (UTC)
On second thought, Category:Applications currently has only 2 levels of subcategories so I think the problem mentioned above does not apply. If more levels appear in the future, I'd imagine it would be for a reason and even then it might not be so terrible. The parent tables or their captions might even contain a link to the subcategory tables to make them more visible instead of duplicating them. -- Lahwaacz (talk) 18:25, 8 March 2017 (UTC)
On third thought, we might even start with splitting up this very page, i.e. do #Link subpages instead of transcluding them + an autogenerated ToC list of sections on all subpages. -- Lahwaacz (talk) 18:33, 8 March 2017 (UTC)
I'm still in favor of #Link subpages instead of transcluding them, it works as an improvement and a compromise for me. — Kynikos (talk) 15:31, 9 March 2017 (UTC)
I was actually thinking that for applications which have a wiki page, browsing Category:Applications instead of this page should give basically the same results (maybe some small subsections are squashed together, but that's not a problem). To make things simple(r), we might just say that topics which have most pages outside of Category:Applications don't belong here and should be linked externally. Usually such topics have an introduction page, such as Server, Xorg or Desktop environments. There would be a huge problem with "Utilities" and "Security" though. Also this approach would probably not cut the bloat enough.
-- Lahwaacz (talk) 21:33, 5 March 2017 (UTC)
As I said, I think that trying to find a clear rule to define what belongs in this page or not is too hard, there are too many blurred cases, as also seen in the parent discussion. IMHO the bloat problem of this article can't be reduced to only some sections in List of applications/Workspace: I like your "I think that the List of applications should be a comprehensible list of the most common categories of application software and not a comprehensive list of everything", but to me "List of applications" practically does sound like "List of everything", which is why I say that the problem is the whole article itself. — Kynikos (talk) 15:19, 8 March 2017 (UTC)
Well think that we can cut it in halves: I don't see many problems with List of applications/Internet, List of applications/Multimedia, List of applications/Documents and List of applications/Science - they are all with individual sections or even list entries, but the overall scope is clear. On the other hand, most of the "applications" listed on the remaining pages, List of applications/Workspace, List of applications/Utilities, List of applications/Security and List of applications/Other, fall simply under "Utilities". From what the current page looks like, I think it's roughly like "Desktop utilities", "System administration utilities", "Security utilities" and (shrugs) "Other utilities", but there are many overlaps so it's probably not very useful to make this differentiation and it would be better to call them just "Utilities". Btw. I think that the category tree has generally the same problem with arbitrary decisions: somehow I don't see a common idea behind Category:Command shells under Category:Applications and Category:Desktop environments under Category:System administration. So that's the problem - do you see a way out? -- Lahwaacz (talk) 19:29, 8 March 2017 (UTC)
Let's use the branch above about the destiny of this article.
About the categories, as you say the problem is similar, I don't think there's much to do other than solve case by case: I'm in favor of moving Category:Command shells and also Category:Status monitoring and notification and Category:Terminal emulators under Category:System administration. Another thing that I'd do is rename Category:Networking to Category:Network administration, and move only to Category:Applications what doesn't fit there anymore, in particular Category:Internet applications, Category:Telephony and voice and probably also Category:Remote desktop, plus possibly recategorize some articles which are currently directly under Category:Networking. At that stage I would also consider renaming Category:System administration to Category:Host administration to remark the ideal complementarity of the two *_administration categories.
Kynikos (talk) 15:31, 9 March 2017 (UTC)
The category tree / table of contents lists wiki pages, not apps - an app would have to have a special wiki page just to be mentioned, and even then, there is old cruft in the wiki pages as well. And that is much harder to clean up than a list.
I definitely agree the categories need improvement.
--Idomeneo1 (talk) 00:09, 7 March 2017 (UTC)
Probably I didn't explain it very clearly, but my idea would be to merge the various lists here (turned into tables) in the editable part of Category pages, e.g. Category:Getting and installing Arch, so applications wouldn't need a wiki page to be mentioned there. — Kynikos (talk) 08:49, 7 March 2017 (UTC)
I like tables, especially sortable ones, though I'm not sure how they simplify things.
An option could be to break the lists down into smaller sections, which could then be included in their respective wiki pages, as well as in a master list-of-apps page.
An issue I see with the current Table of Contents is that it is entirely manually structured - no headings. How is a category tree "automated"? Does this automation preserve included lists/tables/cross-links?
--Idomeneo1 (talk) 00:00, 8 March 2017 (UTC)
Tables in this case more than simplifying would reduce bloat, since many entries would be reduced to one line (at least on wide screens), and the various fields (name, description, website, packages) would be neatly and rationally separated, making it much easier to scan for the needed info. Tables are also a more standard and often preferred way to list and compare applications e.g. on Wikipedia.
About breaking the lists further and merging them into specific wiki pages, I'd be in favor if you want to discuss specific cases. However what is merged into other articles can't be duplicated in a "master list-of-apps page".
Table of contents is completely generated by a bot, there's no manual structuring. I'm not sure what you mean with your question about preserving included lists etc.
Kynikos (talk) 15:00, 8 March 2017 (UTC)
Your User:Kynikos/App trial is a great approach, but I'm unconvinced tables being a good format for this information. If you look at the sections, each table has different column widths (for a reason, but not neat). There are too many other variances: the current template app allows for short or longer descriptions, a single bot comment may shift column width for a whole table, etc. Worst: Even on a wide screen (which can't be a precondition in my view) table data would always break URLs, which is neither readable nor a neat, positive presentation. --Indigo (talk) 21:07, 8 March 2017 (UTC)
Just clarifying that my plan was to eventually switch to the format at the bottom of User:Kynikos/App#Terminal_emulators, which doesn't display urls explicitly. Other modifications in the 3-column table solution that I see as advantages would be to resolve the current Template:App's redundancy of always requiring to show the app's packages even when there is a dedicated article which already lists them. However I acknowledge that the idea of using tables isn't attracting much positive feedback, so ok, I'll keep it for the future generations ^^ — Kynikos (talk) 16:12, 9 March 2017 (UTC)
Ok, thanks. Not displaying URLs would help, yes. Still I don't believe we would be able to make column width look neat across sections. Nested tables (for neatness) are not an option re maintainability. I see your point about showing duplication with the packages, but particularly in this list it can also be quite helpful to click through to content of alternative packages directly. It's not that a dedicated article would have immediate info on that. --Indigo (talk) 21:23, 15 March 2017 (UTC)
What I was suggesting was to break these lists up further into smaller "include" pages, such as Browsers, Window managers, File managers, etc etc, on separate, single "include" pages that could be simply "included" on the respective wiki pages, as well as the category pages, as well as the list of apps. This would provide simplicity, visibility, and coherence, so a whole bunch of app lists don't need to be maintained separately.
--Idomeneo1 (talk) 23:56, 8 March 2017 (UTC)
Hmmm every time that you added, split or removed an included page you'd have to remember to update all the articles that include it, and also you wouldn't be able to include section headings because their levels would have to adapt to the host articles, so it wouldn't be very easy to maintain. — Kynikos (talk) 15:31, 9 March 2017 (UTC)
That would be true of any new wiki pages. The idea is to break the lists up into logical units that could be included on multiple pages and categories. Then, when you update the actual lists, such as fixing/removing broken links, you would only need to do it once, instead of editing multiple pages for every list edit.
--Idomeneo1 (talk) 01:33, 10 March 2017 (UTC)
I think to a large extent the app list in this article is it's own meta information, and that diminishes the more we break it down into smaller (&detached) units. When I try to apply your idea to e.g. List of applications#Screen lockers (same goes for "file manager", "browsers" examples to me), it's hard to picture where we would want to include that list but easy to imagine it can be helpful to link to from, say, a window manager article. Even if that "screen locker" unit would list 100% applicable packages for window manager A and B, is it really that helpful to include the full list in A and B? Likewise I don't see how that section can be broken down into more units, such attempt is bound to be very arbitrary in every case. Not simple. What would be a practical example of an include unit with two targets? --Indigo (talk) 22:30, 15 March 2017 (UTC)
I have to disagree. Categories pose an important way to navigate wiki articles. Placing long lists of applications (that mostly don't have wiki articles) at the top of category pages would mean that you often have to scroll down category pages to reach their index and thus preventing you from quickly navigating the wiki by categories. –Larivact (talk) 09:19, 31 December 2017 (UTC)
I agree with Larivact points. On main topic, I favour splitting existing list pages in separate articles like Web browser, Screen locker etc. This would give us more space to have sufficiently detailed explanation what each type of software is and does and would make more sense in context of topic-based wiki. As for respective categories we can have The main article for this category is Web browser. disclaimer like on wikipedia. -- Svito (talk) 17:42, 26 February 2018 (UTC)
I concur, I created #Merge sections to dedicated articles and Template:Cat main. On a side note I don't think we need to explain what each type of software is, linking the respective Wikipedia article should suffice.--Larivact (talk) 15:29, 11 May 2018 (UTC)
[The following related post was copied here from Talk:Bottle#Archive. -- Kynikos (talk) 16:45, 27 April 2018 (UTC)]
In general I think it's a bit unfair and counterintuitive though that the better documentation a piece of software has (or the better it works in general), the lesser visibility (and search references) it gets in our wiki (the software runs fine out of the box (good!) => no need for installation/configuration/troubleshooting sections => no wiki article; the software needs distro-specific guidance to be set up (less good / bad) => need for installation/configuration/troubleshooting sections => wiki article allowed). This may also be related to Talk:List_of_applications#Merge sections to category pages, i.e. our Categories could link all current/popular options and point to the upstream docs, and possibly also to our articles for Arch-specific adaptations.
-- Kynikos (talk) 16:27, 17 September 2017 (UTC)
The purpose of the ArchWiki is to provide information, not SEO. If we list all current/popular options on category pages we obstruct the navigability of our information (see my point above).--Larivact (talk) 19:21, 10 May 2018 (UTC)

Merge sections to dedicated articles

Svito proposed to split up List of applications into separate articles like Web browser, Screen locker etc.

I think that's the best approach because of the following advantages:

  • no two co-existing categorization systems like we currently have (List of applications and MediaWiki categories), instead just MediaWiki categories
  • articles can easily be linked and found via search
  • it does not obstruct navigating the wiki by categories like #Merge sections to category pages does

As this approach would make categories more important, I think we should firstly implement Mediawiki talk:Common.css#Move categories under h1.

--Larivact (talk) 15:25, 11 May 2018 (UTC)

#Merge sections to category pages would have required to reproduce a tree of categories under Category:Applications similar to the ToC of this article. I don't mind this solution, but would you still create the additional categories, which in several cases would of course only contain the respective List page, or would you for example put all the split list articles from List of applications#Multimedia under the same Category:Multimedia? -- Kynikos (talk) 15:45, 20 May 2018 (UTC)
Latter would make sense as having category for just one article would be odd. I would still keep this page to have list of links to all lists of applications. -- Svito (talk) 17:18, 21 May 2018 (UTC)
Opposite for me, I support the category-tree way, at the cost of having one- (this proposal) or zero-article (#Merge sections to category pages) categories.
If this page ends up still being required to show the tree of application lists which reside under common categories, then splitting loses much of its point in my view.
-- Kynikos (talk) 10:32, 22 May 2018 (UTC)

Replace with external interface

On second thought I am not convinced of #Merge sections to dedicated articles either. MediaWiki is just unsuited for a well-categorized list of applications. Especially since applications can be in multiple categories. A real radical alternative would be to outsource & convert the List of applications to text files in a Git repository. A text file would have the name of the package and could look like this:

name=Thunderbird
description=Feature-rich email client from Mozilla written in GTK+.
url=http://www.mozilla.org/thunderbird/
tags=email client,news aggregator,usenet client,irc client,xmpp client,twitter client

These files could then be converted to a static HTML site or queried via a hypothetical command-line interface.

--Larivact (talk) 16:46, 20 May 2018 (UTC)

I would not dismiss original subject of how and where we want to display application lists on the wiki. You touch on entirely different topic that is browsing application lists outside the wiki, for which existing web interfaces could be improved for. It is inevitable that we would want to use upstream metadata from packages themselves and periodically generate application lists without editor intervention. I strongly believe we can take baby steps and reuse existing standards as much as possible:
  • Merge sections to dedicated articles, leave links to all of them here
  • Transform all lists into tables, fill in all metadata
  • Explore if we can use AppStream for our metadata, if not - contribute to AppStream spec so we can
  • Push our metadata to upstream projects using AppStream, so we don't have to maintain it
  • Write scripts to periodically generate specific application tables on pages
  • Add AppStream support to existing web interfaces
  • Have a root beer with City-busz
Before any of it let's agree to split this discussion first(again)
-- Svito (talk) 20:41, 20 May 2018 (UTC)
I think you missed my point, I proposed to outsource the list of applications from MediaWiki. It's not an entirely different topic, it's an entirely different solution to our categorization problem.
The main feature and biggest problem of the List of applications is categorization, upstream metadata won't help us with this because advanced categorization needs to be done centrally.
I regard AppStream as irrelevant as it doesn't deal with advanced categorization like the List of applications does.
--Larivact (talk) 16:11, 21 May 2018 (UTC)
Defining category structure is not AppStream job and neither of Desktop Menu Specification. It is completely up to the software if and how to display and organize those and there is no restrictions on number of categories software can belong to. -- Svito (talk) 20:04, 21 May 2018 (UTC)
I did miss your point. Can you be more specific what that would mean for fate of this article, its content and existing category structure? -- Svito (talk) 16:51, 21 May 2018 (UTC)
The List of applications would no longer be on the ArchWiki but a different website, perhaps archlinux.org/apps. It would still link to the ArchWiki. The metadata from which the website gets generated could be on GitHub or, perhaps a better idea, in a single page on the ArchWiki. The existing content & categorization would need to be converted by a script (with some human intervention required to map sections to tags and merge apps present in multiple categories).--Larivact (talk) 17:42, 21 May 2018 (UTC)
Then AppStream would be more than suitable for this. See GenericComponent for example, relying on Desktop Menu Specification for valid Category definitions. Contributing missing category definitions should not be a problem provided we will have multiple examples in our wiki needing them, especially because we as Arch Linux community have always worked upstream rather than downstream. In the end this benefits not just Arch Linux, but everyone who already uses AppStream and upstream projects. Many applications already support the spec with existing categories, and ArchLinux already supports AppStream for official repositories with archlinux-appstream-data. Finding a way to use AppStream with AUR would be a next step.
If we to terminate this article and to use GitHub or dedicated page to maintain our metadata, this would still require people to create pull requests or wiki accounts just to add their software to the list and we would still be manually adding and removing software when it goes in or out of repositories or AUR. If we to use AppStream for metadata and contribute it to upstream projects, projects using it would automatically appear in our generated lists as they enter the repo or AUR, but also software center applications across all distributions. Of course we would still need to contribute our metadata to new projects without it.
I understand your reluctance to not deal with any existing solution, I like your idea, but I hate any prospect of downstream metadata, damned it be.
-- Svito (talk) 19:34, 21 May 2018 (UTC)
While the List of applications tries to meticulously categorize the whole software world, the Desktop Menu Specification strives get you a nice little GUI menu of your installed applications. These are two completely different motives. The Desktop Menu Specification lacks so many categories that it is utterly unsuitable for the List of applications. And they will not accept our categories as they do not make sense for a desktop menu. Like I said advanced categorization needs to be done centrally.
--Larivact (talk) 05:08, 22 May 2018 (UTC)
You seem to be mistaken Main categories with Additional categories, which I link description of from previous page here just for convenience: can be used to provide more fine grained information about the application. They are just "tags" in conventional sense, but better yet explicitly defined as a standard. We are exactly ones in position to add more Additional categories to the spec, as application developers can't really have a say in it individually, nor they have any real incentive (yet) to bother adding them. -- Svito (talk) 09:17, 22 May 2018 (UTC)
Outsourcing the metadata to upstream would mean that we could no longer effectively maintain or control it. This would reduce its quality and objectiveness.--Larivact (talk) 11:26, 22 May 2018 (UTC)
I created draft with tentative additional categories I will be working on, but I changed my mind on idea of using it to generate tables on the wiki, which you just proven to me is terrible idea. I completely agree we don't need this article if we to have better means of finding software and its alternatives. I will try to improve existing specs for metadata we would like exposed by applications, but in the meanwhile I'm not opposed to your solution as well. Sorry for my stormy language before. -- Svito (talk) 13:24, 22 May 2018 (UTC)
Usually console applications don't have AppStream metadata, nor desktop file. The categories of Desktop Menu Specification don't give us the details and flexibility what we need, and upstream give sometimes inaccurate details that we need to fix from an objective view.
Personally I like the simplicity what MediaWiki provides, and I don't see much benefit from using a custom metadata system. Of course if anyone create and setup a better interface for listing and comparing applications, we can consider to remove application lists from Arch Wiki.--City-busz (talk) 14:03, 22 May 2018 (UTC)

List of screenshot tools

There is a suitable page dedicated to the topic, so the content should be in one place. It's not like that every list of applications present on the wiki must be unconditionally on this page. —This unsigned comment is by Lahwaacz (talk) 17:38, 10 May 2018‎. Please sign your posts with ~~~~!

I would prefer to keep the list of screenshot tools on List of applications/Multimedia page rather than moving it back to the Taking a screenshot page. Screencast tools are also listed on that page, which is a similar topic. I think we should keep software lists in one page until a decision happen to split them into multiple articles/categories as described in #Merge sections to category pages. --City-busz (talk) 17:53, 10 May 2018 (UTC)
If there's a dedicated article the App list belongs there, or do you also want to move the App lists of Desktop environment, Window manager, Display manager to List of applications? But I agree that screenshot tools and screencast tools belong together, which is why I propose to move both to Screen capture.--Larivact (talk) 05:46, 11 May 2018 (UTC)
Desktop environment, Window manager, Display manager: these are not simply desktop applications, and require specific configuration, so it's reasonable to put them into separated articles. There is no specific configuration needed for screenshot and screencast tools, these are individual applications, therefore I would prefer to keep them together with other multimedia applications. Or if it's preferred to put these list into separated articles, then we should split the list completely, and create individual articles for raster graphics editors, for vector graphics editors and so on.--City-busz (talk) 10:22, 11 May 2018 (UTC)
If there was nothing else but the list on the Screen capture page, I would agree with you that it's better to keep the list in List of applications. But that's not the case, similarly to Clipboard#List_of_clipboard_managers and likely many other pages I can't think of right now. Splitting the List of applications completely is a different topic since there would be only the lists on the newly created pages. -- Lahwaacz (talk) 14:24, 11 May 2018 (UTC)
I created ‎#Merge sections to dedicated articles for that different topic.--Larivact (talk) 15:33, 11 May 2018 (UTC)
I moved the screenshot and screencast tools to Screen capture.--Larivact (talk) 18:20, 26 July 2018 (UTC)