Talk:List of applications

From ArchWiki
Revision as of 15:31, 9 March 2017 by Kynikos (talk | contribs) (Radical alternative: re 4x)
Jump to navigation Jump to search


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)

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:

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)

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. 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)

IRC clients: Conspire fails to build

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):

  • Conspire — Lightweight, simple, and powerful || conspire-clientAUR

-- Kynikos 17:02, 10 March 2012 (EST)

Multi-Protocol Downloader section

Similarly to command shells, a downloader section is missing. Here we find good the same one: pyLoad#Alternatives JDownloader#Alternatives. 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. -- Flu (talk) 16:37, 8 September 2013 (UTC)

Good plan, +1. -- Kynikos (talk) 05:01, 11 September 2013 (UTC)

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)

Where should "full-stack" scanning software go?

Some software (two examples below, I can add a few more when I have times) provide some set of scanner/camera frontend, image processing, document layout analysis, OCR frontend and document writer. We have categories for almost all of these, but where should software that smoothly incorporates all the above go?

  • Scan Tailor — Image procesing, document layout analyzer, document writer || scantailor-git
  • gscan2pdf — Scans, runs an OCR engine, minor post-processing, creates a document. || gscan2pdfAUR

I had some difficulty finding software that did what I expected/desired, so perhaps others are too. Scientific29 (talk) 01:16, 5 September 2014 (UTC)

ScanTailor is not a "full-stack" software, it does just the image processing. -- Lahwaacz (talk) 07:57, 5 September 2014 (UTC)

AUR3 packages

It's been about half a year since the transition to AUR4, so I think it's time to start slowly removing the references to the old packages that were not migrated. The lists such as this one, its translations, Fonts#Font packages etc. would be a good start, we can wait even longer with normal pages. What do you say? -- Lahwaacz (talk) 13:06, 16 January 2016 (UTC)

+1 from me. -- Alad (talk) 13:17, 16 January 2016 (UTC)
+0.5 from me: ok to trim old package references, but please take it slowly, as I'll probably be interested in verifying other factors such as objective popularity, as happened recently in Window manager. — Kynikos (talk) 04:03, 17 January 2016 (UTC)
Very well, are you interested in checking even the fonts or can I do a swift(er) action there? -- Lahwaacz (talk) 09:42, 17 January 2016 (UTC)
Nah, you can have all the fun you want with fonts. Just make sure to properly clean the floor and walls before leaving though, fonts' blood tends to stain very bad ;) — Kynikos (talk) 03:48, 18 January 2016 (UTC)

What is Xpra, really?

Where should Xpra go? Technically, remote desktop may be applicable, but it's not limited to remote stuff. You can run it locally on another X display.

Technically, all Xpra is is some persistent X sessions that you can attach to and detach from at any time. It's not really a remote desktop thing. Dillebidum (talk) 17:27, 10 January 2017 (UTC)

Does it have to go anywhere? -- Lahwaacz (talk) 18:09, 10 January 2017 (UTC)
Technically, yes. This is the list of applications, so why not? Xpra is a "screen for X". That way, the least vague thing to do would be to split terminal multiplexers into a multiplexers category and there would be two subcategories: terminal and X11. Xpra would, obviously be in X11. I say least vague, since screen is a multiplexer, yet Xpra isn't. The only thing it has in common with screen is the persistent sessions. Dillebidum (talk) 20:37, 11 January 2017 (UTC)
It's just a list of applications, not list of all applications. The point is that there might be other, more appropriate places on the wiki, e.g. improving Allow a program to continue after logoff. -- Lahwaacz (talk) 21:10, 11 January 2017 (UTC)

Mention of pkgstats

Besides the loss of the links between [1] and [2], I'm against the move as I think that pkgstats is too specific to be mentioned in General recommendations. — Kynikos (talk) 10:07, 24 January 2017 (UTC)

I agree it is better served in this article, but also think a short extra mention like "Please consider installing the pkgstats package." in General recommendations#pacman would be useful to sponsor it. --Indigo (talk) 10:28, 1 March 2017 (UTC)
I'm open to a compromise, but since this is more about the packages than the package manager, I'd add the sentence to General recommendations#Repositories instead, so that the installing link can be avoided (pacman has just been introduced), and also I'd avoid "please", perhaps "You may consider installing the pkgstats service". — Kynikos (talk) 12:00, 2 March 2017 (UTC)
Alright, done.[3] --Indigo (talk) 09:28, 3 March 2017 (UTC)

Add Org-mode as a markup language?

Org-mode is a markup language, but it is tied to the Emacs text editor. Any editor can produce valid org markup, but at present, only Emacs can export that markup to pdf, .tex, html, etc.

Org-mode is such a great markup language, but I wonder if being tied to the Emacs means we should omit it. What do ya'll think?

—This unsigned comment is by JoshuaBranson (talk) 16:43, 18 February 2017‎. Please sign your posts with ~~~~!

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)

1. Applications that require a LAMP stack, such as Blog engines, Cloud storage, and Content managers like Drupal and Wordpress see widespread use, and most were already listed here. The variety of server options that they require also belong here. Server apps should also be in their own section (and linked to, from the client section), because their purpose and implementation is distinct. And when you set up a server, it is useful to have a list of server apps. Users looking for clients apps are not going to be looking for server apps until they're setting up a server.
"I doubt it is useful for an average user" - what exactly is an "average user"? This is an opinion that is quite frankly not true.
Also, if some section seems incomplete, then improve it, instead of simply using its incompleteness as an argument for removing it.
2. The biggest bloat in this list are all the dead links.
3a. The Table of contents is a list of wiki pages. It does not include any apps that don't happen to have one, including ones that work out of the box and don't need one.
3b. If General recommendations were to take on the information in these lists - there are eight lists here - then that page would become bloated. It wouldn't be a bad idea in fact to link from General Recommendations to the relevant section in this list.
3c. You search when you already know exactly what you're looking for. Lists are for finding new apps you didn't know about.
4. Databases: all apps are "complex systems" in many ways. And there are several dbases to choose from.
5. I agree that basic things like core-utils should not be on this list. (However, Linux users in particular do explore alternatives "just because".)
6. I think a Bootsplash is still a workspace option and should be represented here. (I've never used one, but I think others would consider trying one if they come across the option.)
7. I think Accessibility should not be overlooked. Linking to an detailed article is fine.
8. I also seem to need to emphasize that I have not "bloated" this list, but am trying to make it more coherent.
--Idomeneo1 (talk) 23:53, 2 March 2017 (UTC)
Let's take it one at a time. It seems you want to take all applications which have something to do with a client-server model, split the server part away from the client's category and create one big category of these server things. Well, then for starters "Web Servers" is not the right name for it. But I'll dispute even the existence of such section on this page, regardless of its name, for two reasons:
  1. Selecting applications to set up a (web or whatever) server takes more then a short entry in a list. One needs to consider the concrete usecase and often even a combination of applications as a whole rather than each application separately for its purpose. Hence this topic belongs to the Server page, where more details can be provided. Of course this page could link to it.
  2. The current way is to split sections according to software categories (i.e. their purpose), not based on whether they require the LAMP stack, have to be run on server or simple desktop will suffice. I'd say this corresponds with how people search for software first they have a purpose, then they concern with what they need to run the software.
-- Lahwaacz (talk) 10:02, 3 March 2017 (UTC)
A server is more than a LAMP stack - not all server apps used on the web require LAMP stacks.
Users look for client apps and server apps for very different reasons.
Also the Server page provides little guidance on selecting LAMP components, and none of the options provided on this list. Most apps can be used on a number of server/dbase combinations, and it's up to the user to settle on what works best for them, just as with any other application.
--Idomeneo1 (talk) 23:20, 3 March 2017 (UTC)
Obviously various servers run all sorts of software, often even client software to communicate with other servers. The separation of software based on where it runs (server or desktop) is impossible, often it can be both. A "Servers" section that you propose would be a catch-all section which would evenutally become impossible to read and maintain. Categorization based on the software purpose is much more useful in my view.
As for LAMP, I proposed to merge the List_of_applications/Internet#LAMP_stack section to the Server page, not to remove it without compensation.
-- Lahwaacz (talk) 08:52, 4 March 2017 (UTC)
Yes, you can run whatever apps you like on your box. If you're setting up a server you have different needs than if your just setting up a regular box. Someone looking for a chat app doesn't need to have chat servers listed, and a person setting up a server most likely already has their apps, and would like server apps in one place. If I, say, wanted chat apps and servers all listed together, I would just search for "chat" or "XMPP" in the pkg dbase. Lists like this should "add value" for the user over simple searches.
--Idomeneo1 (talk) 00:21, 7 March 2017 (UTC)

Radical alternative

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 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 #Split up completely? + an autogenerated ToC list of sections on all subpages. -- Lahwaacz (talk) 18:33, 8 March 2017 (UTC)
I'm still in favor of #Split up completely?, 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. 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) 15:31, 9 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)