Talk:List of applications
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)
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.- 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)
remove List_of_applications/Workspace#Accessibility- it is a topic of its own, not just about selecting applicationsremove List_of_applications/Utilities#Databases- they are certainly not utilities (so much less applications), but complex systems consisting of many deamons, utilities and interfaces designed to work togetherremove the List_of_applications/Internet#Web_Servers section:merge List_of_applications/Internet#LAMP_stack to Server#LAMP- I doubt it is useful for an average userremove List_of_applications/Internet#Wiki_engines- it is very incomplete and like above, not usefulmove List_of_applications/Internet#Content_management.2C_social_networks.2C_blog_publishers back to List_of_applications/Internet#Blog_enginesmove List_of_applications/Internet#Cloud_storage_servers under List_of_applications/Internet#File_sharing
-- 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:
- 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. -- Alad (talk) 17:41, 15 March 2017 (UTC)
- Some more candidates:
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-line 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-line 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. 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 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
- 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)
- We wouldn't need to keep a page linking all lists, the category tree suffices and we could also use Category:Lists of software. Do you still oppose this, considering that your proposal goes against semantics and common practice? Categories are for categorization, pages for content. Furthermore categories would require redirects to be maintained to facilitate linking and discovering. --Larivact (talk) 16:07, 17 October 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 GitHubor, 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)
- The List of applications would no longer be on the ArchWiki but a different website, perhaps
- 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)
- You seem to be mistaken Main categories with Additional categories, which I link description of from previous page here just for convenience:
- 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)