Difference between revisions of "Talk:List of applications"

From ArchWiki
Jump to navigation Jump to search
(For me it is ok, of course. -- Flu)
Line 384: Line 384:
Plus aria2, curl, wget, kget should be added. Is it ok? Could you point me more downloaders?
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)
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)

Revision as of 05:01, 11 September 2013

Mark common applications? (previously named "What is common?")

I wonder who defines what is a "common" application. Just one random (potentially bad) example: Among the 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)?

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. --Markus00000 09:19, 16 October 2011 (EDT)

Another simpler way would be moving the article to List of Applications, which already redirects here anyway. 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. -- 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. --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.
-- 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? --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.
-- Kynikos 09:20, 17 October 2011 (EDT)
Instead of bold (which I don't like at all) we could prepend simple marks like in:
  • [+] Firefox — The Firefox Web Browser is the faster, more secure, and fully customizable way to surf the web.
http://www.mozilla.com/firefox/ || firefox
or [!], [*], +, !, *.
-- Kynikos 09:36, 17 October 2011 (EDT)
Status? Should we employ notability guidelines like Wikipedia? ;P -- 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 objective (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). I'm in favour of renaming the page List of applications.
Readers are invited to share their thoughts :)
-- Kynikos 06:43, 26 December 2011 (EST)
+1 for renaming the page List of applications, I'm fine with the marks. What would the objective rules be? -- Karol 08:05, 26 December 2011 (EST)
Good, the rule for discerning between common and uncommon apps may be based on pkgstats as proposed initially by Markus00000, I'd say an application is common when it's installed by more than min(10, N*0.75)% of pkgstats users, where 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 10 and 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.
-- 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 – 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.
PS "List of applications" is proper title but I'd suggest "Recommended applications" as more honest.
--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?

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".
You can access the lightweight list here. -- Karol 16:10, 22 October 2011 (EDT)
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". -- Kynikos 11:19, 30 October 2011 (EDT)
We still have Netbook Games, which isn't perfect either. -- 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 :) -- Kynikos (talk) 13:36, 17 September 2012 (UTC)

Further improvement

  1. Use GentooWiki/Wikipedia links in place of the current redlinks where possible.
  2. Remove dead links unless they can be fixed somehow. EDIT: both moved to new discussion
  3. Clean up last unformatted entries. EDIT: will be continued in separate articles
  4. Add apps
    1. Listed at this Gentoo article
    2. from Commandline_Tools
      1. New: Does mentioning core applications like more, less etc (like done in Commandline_Tools) make any sence?
  5. Finally move everything to separate articles.
    1. Add entries from "Arch Package Management" to (separately) AUR_Helpers and Pacman_GUI_Frontends
    2. Merge "Graphics and Image Manipulation" with Multimedia
      1. New: Can "CD/DVD Burning Tools" be considered part of "Multimedia"?
      2. New: Should "Screen Capture" section be part of "Utilities" or "Multimedia"? Should such potentially controversial sections be made top-level?
      3. This especially makes sense because moving top-level parts like Common Applications#Backup Programs to split articles effectively hides its' internal structure. EDIT: no longer relevant
  6. 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.
  7. New: Split article into several smaller similar to Beginners' Guide? EDIT: splitting started, last entries should be moved to separate pages (see Template:Common Applications navigation). EDIT: done

--AlexanderR 03:01, 15 January 2012 (EST)
--AlexanderR 22:27, 15 January 2012 (EST)
--AlexanderR 01:45, 16 January 2012 (EST)
--AlexanderR 08:00, 16 January 2012 (EST)
--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. -- Karol 07:47, 3 January 2012 (EST)
Re: (I needed a non-indented line here...)
  1. Do you mean you'd use GentooWiki/Wikipedia links in place of the current redlinks? EDIT: fixed directly in the original post
    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!
  2. Remove unless they can be fixed somehow EDIT: fixed directly in the original post
  3. Yes please
  4. Why not
  5. 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 EDIT: the original post has been modified
    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)
    1. Makes sense now
    2. Also this one seems a good idea
  6. 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.
-- Kynikos 08:22, 3 January 2012 (EST)
Finally, please, do not edit your posts in place, otherwise it's very very difficult to follow the discussion and even more to reply.
-- 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. --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.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 :) ? --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 News 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.
-- Kynikos 19:10, 16 January 2012 (EST)
>> I admit it's not easy to follow this discussion and your edits
Sorry for this – 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? -- 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. -- Kynikos 07:31, 17 January 2012 (EST)

Summary of related changes


Core apps

Does mentioning core applications like more, less etc (like done in Commandline_Tools) make any sence? --AlexanderR 21:10, 16 January 2012 (EST)

See also: Core Utilities. -- 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? -- Kynikos 07:49, 17 January 2012 (EST)

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)

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:


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

Games - classification method

Currently, games are first divided in Free/Reimplemented/Commercial/Emulators/MMO and only then they are grouped by genre. I'd like to see the opposite, i.e. first group by genre (also in Template:Games navigation) and only inside each genre make the distinction between native/emulators, free/commercial and whatever distinction better suits that particular genre.

Note that this topic has already been briefly touched on in Talk:Common_Applications/Games/MMO#MMOG by me and AlexanderR, but more opinions are needed.

-- Kynikos 08:45, 5 February 2012 (EST)

+1 -- when browsing games, one would logically search by genre first. The genre classification scheme is more consistent with the other Common Applications pages, too, where applications are organized by type first, then by UI/platform (graphical or console). -- pointone 12:25, 4 March 2012 (EST)
In my opinion the classification is really confusing (not very KISS! ;)) It's hard to guess whether a game should belong to Native - Reimplemented or Native - Commercial, or MMO (some of them are also commercial). There is a Humble Indie Bundle section, but a game cannot be categorized this way, since all HIB games are also sold by other means (like Steam - which also has its own section). Besides Native - Free is sorted by genre, but it's the only one. Some entries use the Application template, other do not, some entries are not even games (see the Quake part). All this can be treacherous because if you look only in the wrong sections, you might miss some games. So you end up using the browser search function... In the end sections become rather useless. My suggestion:
  1. Merge the Netbook Games page.
  2. Create a game template which features the genres (should always be a list, since it's hard to stick to one precise genre), the license (proprietary), optionnaly the distribution system (Steam, HIB).
  3. The article should only contain a list of games sorted alphabetically. That's the only KISS-way to sort, after all.
  4. Move Emulators to a separate article.
  5. Digital Distribution should be removed / merged into the rest of the list.
-- Ambrevar (talk) 07:51, 5 July 2013 (UTC)
  1. Agreed, see also Talk:Netbook Games#Merging
  2. I haven't understood what you mean, sorry, maybe you can give an example... What about adapting Template:Games navigation to the new classification?
  3. I think a classification by genre is feasible and welcome, and in any case I'm not sure if your idea would conflict with 2.
  4. Well, yes, after all emulators are not "games"; another possibility would be moving them to List of Applications/Other; also consider a link from Gaming, or even moving the list there?
  5. Consider moving it to Gaming?
-- Kynikos (talk) 12:25, 5 July 2013 (UTC)
1. OK
2. I meant a new Game template based on the App template. So basically it would look like
{{game|Name|Genre|Description|License|Official website|Pkg|Distribution (optional)}}
3. The problem with classification by genre is that it is not always obvious, nor it is absolute. Just like for music or movies. A lot of games haved mixed genre.
  • You can use precise subgenres to overcome this issue, but as games add up and various genres get added, you'll quickly end up having as much genres as games.
  • Or you could use fuzzy genre names, so that you make sure there is no ambiguity. But then categorization will not be so useful. And still, some games will never fit in one single category.
I believe genre-sorting it is bad for the wiki for many reasons:
  • The reader may not find a game if looking in the wrong category (and he/she assumes it will not be anywhere else).
  • The writer may add a game in a category that may seem strange to the majority, but OK to a minority
  • The writer may add a game in a category but was unaware that it is already in another category.
All the aforementioned reasons are actually the same that were invoked for merging Netbook Games in the first place.
If we treat genre as a tag (as in the template), then you can add as many genres as you like so that anyone can find it satisfactory. The reader can still search by genre using the browser.
4. The emulator section is not huge, so I agree it is worth considering to move it to Gaming.
5. Idem.
Off-topic: the "li" tag is the only decent way I've found to nest indented lists, but there is this annoying "1." remaining. Any clue? :/
-- Ambrevar (talk) 13:19, 5 July 2013 (UTC)
(Using # only supports simple lists, if you want to nest something you have to use <ol> and <li> for the whole list; anyway in this case it's easier to keep it simple and hard-code the numbers ;) (fixed, btw))
2/3. Ok, now I get what you mean with the Game template, and of course I agree with the observations you make in 3. Just to mention it, a further alternative could be using a sortable table with short labels representing the genres, if they are only a few (broad genres):
Name A B C D Description Website Packages
FooBar x x lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum lorem ipsum https://www.archlinux.org/ foobar
However using genre tags or a table would require modifying each entry in the list (big, almost irreversible job), so I'd say let's first try to restructure the current list by using simple sections for the various genres and see what it looks like after the job is finished; the games whose main genre is so hard to define can be temporarily put in a Miscellaneous, Other or Mixed section, and we'll see how many of them end up there: if they are not so many I think we can find a simpler solution than using tags (e.g. just arbitrarily choose one of the genres they would belong to). For the genre titles we can take inspiration from wikipedia:Video game genres.
-- Kynikos (talk) 15:08, 5 July 2013 (UTC)
Actually I was first thinking of a table, but I wasn't aware that MediaWiki had native support for sortable ones. Unfortunately this does not really solve the issue, because we cannot limit the number of genre. The Wikipedia article is endorsing my point: it lists 46 genres! I do not think it is possible to have a finite number of genre columns. Is there any chance a filter table would be available too? I mean the one with an edit field in the header row. This way there would be only one genre column with arbitrary, yet normalized content, which the reader can filter. That would be a much better solution in my opinion. And yes, it would require modifying the complete article, but I think it is easily feasible using external tools like Emacs and/or AWK (I'm currently editing this page from Emacs). -- Ambrevar (talk) 16:26, 5 July 2013 (UTC)
Of course the table method should make use of only a restricted number of categories, say the top ones in wikipedia:Video game genres; yes, it wouldn't allow people to add more categories (easily), this could be seen either as a disadvantage or an advantage... AFAIK there's no way we can have a filterable table :(
Anyway you've probably overlooked a bit the last part of my post: since with the tag idea we should first put all the games in a single list and reorder them alphabetically, I think it's really worth it to try to sort them in some genre sections first, and see how it goes: we don't have to use all the 46 sections in wikipedia:Video game genres, I guess the best way would be to start with the top-level categories, and then see how many games go into each of them; if a top category hosts "too many" games (20? 50? ...) it can be split in subcategories and so on. All the games whose main category is not obvious can be temporarily put in a separate section.
-- Kynikos (talk) 02:47, 6 July 2013 (UTC)
Sorry for the misunderstanding, I got your point, I was just meaning the Wikipedia's way to list genres is not trivial. Anyway, let's reach a consensus and move on: I'll merge the Netbook Games article, create a Game template based upon the App template, and put all game entries in their respective Genre section. Any thought about this?
-- Ambrevar (talk) 08:48, 6 July 2013 (UTC)
For the moment please leave the App template, let's do one step at a time:
  1. First thing go on with merging Netbook Games, some adaptations will be required to other articles, like the warnings at the top of List of Applications/Games and others.
  2. The following step will be merging all the subpages of List of Applications/Games into List of Applications/Games itself.
  3. Then replace the current sections in List of Applications/Games with the top ones in wikipedia:Video game genres: Action, Action-adventure (if we really need it), Adventure, Role-playing, Simulation, Strategy and Others; maybe keep the subsections of List of Applications/Games/Free and move them like their counterparts in wikipedia:Video game genres.
After that we'll see what to do, whether to create a Game template, use a table, move the sections to separate subpages... I know you may think I'm being too conservative, however the truth is that I do like changes, but only as long as they are well planned in advance, I don't like the do-then-fix approach too much :P This is just to tell you that I really appreciate your will to help with this big restructuring! Thank you ^^
-- Kynikos (talk) 14:38, 6 July 2013 (UTC)
Alright, we may proceed at a more reasonable pace. Before proceeding I made some research on Linux game lists, and found this one: icculus.org. It is very up to date and complete; only a few games from Arch Wiki are not included there, but it has much more games overall. The list has filters! Besides they seem open to contribution. Since Icculus is a well established reference, I'm wondering if it is not more productive to contribute by adding the few missing games to Icculus rather than duplicating their amazing work in this Wiki. After all, this belongs to Arch philosophy: contribute upstream!
Following this direction, we would only need to replace all links to List of Applications/Games and Netbook Games with a redirection to Icculus. The emulators/steam/desura part can still be merged in Gaming. What do you think about it?
-- Ambrevar (talk) 12:49, 7 July 2013 (UTC)
I'm always in favour of avoiding duplication of external resources, especially when they are very good ones like icculus.org's table. However in this case, like explained in Help:Style#Hypertext metaphor, our list is indeed giving Arch adaptations, i.e. it's linking to any existing articles for the games, and, even more importantly, to their package names/pages. That's why I'm against deleting it.
Nonetheless, we could finally come to a conclusion in Talk:List of Applications#See also visibility and greatly improve the visibility of external links, to which icculus.org should be already added.
-- Kynikos (talk) 12:47, 8 July 2013 (UTC)

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
http://nenolod.net/ || conspire-clientAUR

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

Games - the big merge

I roughly finished reorganizing the gaming articles.

There may be some mistakes, but I'm tired of editing this page for now. The descriptions of the new entries are rather poor, but I wasn't in the mood.

You will notice that I didn't respect Wikipedia categorization for the genres. Actually I tried first, then I came to the conclusion that it would be a complete non-sense. I just couldn't figure out where more than half of the games should fit. So I decided to leave existing genres.

The obsolete pages are still there and complete. I've added a Delete template on all of them. I was wondering how the deletion process happens on Arch Wiki: do we just remove the content and add a #REDIRECT to the right place?

I updated all english pages that were linking to the obsolete pages.

There is still a lot of games to add, like those from the Humble Bundles or from Steam.

-- Ambrevar (talk) 17:03, 14 July 2013 (UTC)

Impressive contribution!! Thank You <3
Really, I also appreciate how tidy and organized you've been, even finishing the job with this enlightening summary, well done, this was a tough job ^^
About the "deletion process", there are two possibilities: either redirect the pages as you suggest, or completely delete the titles; I'll go with the former, since those titles have been around for a while and they may have been linked from external resources; this way we're also keeping their history browseable by everybody.
-- Kynikos (talk) 17:23, 16 July 2013 (UTC)
Thanks for the moral support! :p This was not easy, but not that hard either; it only took me a few hours. A good editor really helps (can't stand writing in a web browser anymore).
You may have noticed that the formatting is strange for sub-entries (this is new in fact) like for Doom. The link is not properly aligned. I've tried with '**' but this is worse. The 'App' template may need to be fixed to support indentation.
Thanks for the deletions by the way.
-- Ambrevar (talk) 12:22, 17 July 2013 (UTC)
Unfortunately the App template won't support indentation, this was discussed in [1]. I guess the only viable alternatives are making subsections for Doom etc. or just wlisting the various spinoffs as normal applications (no indentation), I'll leave you the choice, unless you have other ideas. -- Kynikos (talk) 11:40, 18 July 2013 (UTC)
Yes! I'm always in favor for a single page, less dispersive. But this page will become a very big long list. Are you sure it's fair to mention the games are not in the official repositories or AUR. I think that in this page there must be only games available on Arch Linux. At most you can do a section called "steam" where to put only the weblink to the list of steam games. At the end this is the Arch Wiki. Veleno (talk) 21:35, 18 July 2013 (UTC)

Steam/Desura markets related

What about avoid all Steam/Desura/whatever game entries and just point to their Linux market link? After all their list is the most up to date. I am sure they are able to advertise their games better than us... Something like:

Games markets

  • Steam — What Steam is. Provided by Company name.
Linux games link || steam
Linux games link || desuraAUR

A similar list is present in Gaming.

-- Flu (talk) 08:23, 29 August 2013 (UTC)

This is a rather complicate problem that can be extended to the whole List of Applications and that comes from the fact that there's not a clear policy on what apps can be added or not. I can think of two possible policies, each with some disadvantages:
  1. list everything that can be made to run on (Arch) Linux; this would leave the current steam entries where they are; the problem is that the list would lose focus on Arch Linux and risk duplicating other existing external lists
  2. list only applications that have an official package, a PKGBUILD in the AUR or an article in the ArchWiki; this would let us remove the steam entries; the problem is that applications that don't have a package (yet) should be removed as well, search for example for the entries with "not packaged? (search in AUR)" in the list
Maybe we need a compromise policy; also, I think it's worth to split this discussion from the original one.
-- Kynikos (talk) 04:33, 31 August 2013 (UTC)
My try:
- If there is a PKGBULD, put it.
- if it is available through a market (for now the problem should be limited to games), do not put it.
- else put list it albeit "not packaged". Those entries are already ugly.
-- Flu (talk) 18:04, 31 August 2013 (UTC)
I think you have a point in saying that the problem is limited to games, so I'd say let's implement #Split games list and then apply there my proposal #2 policy. -- Kynikos (talk) 05:10, 4 September 2013 (UTC)

Split games list

I'd like to propose to move List of Applications/Games to List of Games and just link to it instead if transcluding it here. The various subpages of List of Applications are transcluded here mainly to make it easier to search for an application without knowing where it's been categorized; however, this doesn't give any advantage when searching for games, so they can be safely split. This would also make the list shorter and tidier. Finally, as proposed in #Steam/Desura markets related, games should probably be added to the list under special policies, and keeping them in a separate list would make it easier to enforce a different policy. -- Kynikos (talk) 05:10, 4 September 2013 (UTC)

For me it is ok, of course. -- Flu (talk) 18:28, 8 September 2013 (UTC)

Discussion on subpages

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)? -- Lahwaacz (talk) 08:33, 5 August 2013 (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...). -- Kynikos (talk) 11:10, 5 August 2013 (UTC)
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. -- Lahwaacz (talk) 13:18, 5 August 2013 (UTC)

Shell interpreters

I see there is not a list of shell to include Bash,Zsh,Fish,Oh,Csh,Ksh. As the shell is a critical part of a system it could be prudent to avoid suggestions. My opinion is for showing the choice. Any comments? -- Flu (talk) 18:02, 30 August 2013 (UTC)

I like the idea, then you could even add a link to the new section from General Recommendations#Alternative shells. -- Kynikos (talk) 04:08, 31 August 2013 (UTC)
Take a look:
-- Flu (talk) 17:46, 31 August 2013 (UTC)
Good job! About the topics in Talk:Command Shell I haven't formed an opinion yet. Closing this meanwhile. -- Kynikos (talk) 04:28, 4 September 2013 (UTC)

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)