::Good points... I'll move the discussions here and add a note to start new discussions here. When/if there are more pages like this, I think some rule should be made. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 5 August 2013 (UTC)

::Good points... I'll move the discussions here and add a note to start new discussions here. When/if there are more pages like this, I think some rule should be made. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 5 August 2013 (UTC)

−

−

== 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?

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.

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)

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.

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

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.

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

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)

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

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!

Remove unless they can be fixed somehow EDIT: fixed directly in the original post

Yes please

Why not

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)

Makes sense now

Also this one seems a good idea

Please let's discuss this one later, otherwise we are having too many irons in the fire. Also I'd like you to explain better why you moved Desktop Environment to X Desktop Environment. I consider it a superfluous change and would like to restore the previous title. The same goes for Window Manager and X Window Manager. Please discuss this kind of changes before performing them. More opinions are welcome.

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.

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.

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)

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

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

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)

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)

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)

Link to #See also from the introduction, with a sentence that enhances its visibility. -- 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.

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

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

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.

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.

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?

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 ^^

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?

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.

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.

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.

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.

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)

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:

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)