Talk:List of applications

From ArchWiki
Jump to: navigation, 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)

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 ~~~~!