Gentoo Wiki:Suggestions/Archive

__NEWSECTIONLINK__ Feel free to add suggestions for our Wiki on this page. To add a new topic, click on the "+" page tab. (This might be hidden under the "more" menu.) Remember to sign your remarks with  (4 tildes), or use the "Signature and timestamp" button text-bottom|link=|signature button in the editor toolbar. See also Help:Signatures.

Stalled discussions and Archive
For discussions that have not had contributions in a long time see the Stalled discussions page. For completed discussions see the archive subpages:


 * Archive subpage 1 (oldest)
 * Archive subpage 2
 * Archive subpage 3 (newest)

Print to PDF and/or Export to EBook File Format?
I prefer reading long articles on my EBook Device (Kindle DXG). Seeing most documents being published in PDF, or some sites even providing EBook formats. Thankfully, my device can handle PDF but some can't. As for the Amazon Kindle's, I've seen really good results using kindlegen on converting EPUB to MOBI, but using kindlegen on HTML with TABLE TAGS produces poor MOBI files. As such, I usually use PDF files for computer technical documents. Also, kindlegen (aka mobigen) is binary only (proprietary). A couple months ago, I mirrored the entire Gentoo Documentation just to convert XML to HTML using gorg, and then kindlegen to convert to MOBI. This is very tedious for EBook users! I manage quite well as I use the console, but avoid Calibre due to it's package bloat and lack of command line only. (Calibre requires X for it's command line tool.) Probably the simple solution for now, for simple articles would be to ensure a 'Print to PDF' option. Lengthy articles such as the Gentoo Handbook and EBuild/EClass documentation, would be nice to have an EBook format. Signed: Roger 19:09, 15 November 2011 (UTC)

I second this motion as far as PDF and ePUB goes. I even submitted a wish/bug to Gentoo's Bugzilla about this. Hook 00:14, 24 March 2012 (UTC)

Count my vote as well for this notion. --Maffblaster (talk) 19:16, 3 February 2015 (UTC)

Definition of Macros
Dear wiki-admins,

You should define some macros as soon as possible for things like referencing portage packages, infoboxes for software that autocomplete from portage information, general infoboxes for software that include fields such as 'deprecated by', and create categories for each of the Gentoo projects (Hardened, etc.) so that relevant articles can be grouped together in a way that makes sense for users coming from other sources of documentation.

Voltaire 00:02, 2 August 2012 (UTC)


 * We will definitely also need one for man pages. Like 'man 5 corosync.conf' should be possible to define with a quick macro that makes it obviously possible to type at the terminal but also clickable in-wiki to go to a hosted, HTML version of the man page.  This should be the latest version auto-built out of portage, or preferably a diffed history of versions. This sort of cross-linking is precisely where a lot of Linux documentation falls down and where the Gentoo community could showcase its pragmatism. Voltaire 00:30, 4 August 2012 (UTC)

A few suggestion
For Users
 * Display last modify date and last modify editor on each wiki page to let user know about the status of the docs.
 * Having Version tag, if the package need some different configuration we can have a version tag there to change the need but not the whole page. Even-thought gentoo are always updated it is still good to kept some history.
 * Kernel Template should have a format for kernel version -- it will be easier for other to understand and update.
 * Files Template should have some way to indication changes required. Current way is to paste the whole file and looking for changes are not good for users.

For Editor
 * New Page Template -- There should be a new page template which something like prerequisite, kernel requirement, emerge application files changes blah blah blah until the End to rc-update. This would be good for new and old editor as in future when there are some new things can be added in.
 * Kernel Template should be easier to use so should have a field like enable or disable and the kernel_module_name/the long name
 * Conflict in changes should have diff on top before the editor/content, this is easier to verify.

--dcmwai (talk) 05:10, 19 February 2014 (UTC)


 * ill second the need for version tagging configurations. samba 3 vs samba 4 are radical departures from each other.666threesixes666 (talk) 05:14, 19 February 2014 (UTC)

Template for well known overlays
It would be nice to have a wiki template to create links to well known overlays pointing to more information about those. I'm typically linking either to gpo.zugaina.org overlay pages, occasionally to the actual repositories. It would be nice to have a unified target, whether it is zugaina, an equivalent, or even a wiki space where more information can be specified.

--Pavlix (talk) 14:46, 1 January 2015 (UTC)

Consistency in article titles
I would like to suggest moving the GNOME "configuration" page to GNOME/HOWTO in order to match the title style of the other HOWTO articles. Either that or change HOWTO articles to "X/Configuration" instead of having "HOWTO" in title of the articles. This would maintain consistency throughout the wiki and make the titles easier to search. I could make the changes myself but I would need admin privileges to move a page and it's probably best to actually have input on this type of change... ;) I can continue to post other inconsistencies as I discover them.

Articles using "Configuration" in their titles:

GNOME/Configuration

Xorg/Configuration

Articles using "HOWTO" in their titles:

Openbox/HOWTO

Xfce/HOWTO

--Maffblaster (talk) 19:16, 3 February 2015 (UTC)


 * I think "HOWTO" does not really convey much information about the guide, so I prefer to use a noun or title that reflects the content better. If the guide is about the configuration of a tool or service, then "Configuration" makes more sense.
 * I wouldn't go as fas as to start moving/renaming articles because of this - first work on content, we can rename later when there's a global consensus to do so ;-)
 * --SwifT (talk) 18:38, 2 March 2015 (UTC)


 * I have compiled a longer list of the "HOWTO" articles in my user space area. When we are ready to make a decision on this it will be easy to migrate them to new locations. I think the term "Guide" would work best for most of the renamed articles since many of them cover not only configuration, but concepts, installation, Kernel features, suggestions, etc. In my opinion using the term "Guide" would be more descriptive of what the article is for while at the same time allowing for a broader range of content inside each article. What do you think? --Maffblaster (talk) 18:36, 7 April 2015 (UTC)

Link colors
I've noticed that visited links on pages such as AMD64/FAQ are almost completely indistinguishable from the surrounding normal text (I'm using Google Chrome on a Windows 8 machine with an LCD monitor). Is the visited-link color darker than it used to be? Can it be lightened a bit? - dcljr (talk) 23:46, 11 February 2015 (UTC)
 * Hmm. Looks OK again on my Firefox/Gentoo/LCD combo here at home. The Windows machine I was using just had an exceptionally narrow font (relative to the screen resolution, anyway), which made seeing the color on visited links really difficult. And BTW, probably any other article here would be a much better example, since the article I cited has very few internal links in it. That's just the article I happened to be working on at the time. [g] - dcljr (talk) 18:58, 12 February 2015 (UTC)


 * I did have my own difficulties seeing visited links at times, so let's try a different color now. Feedback welcome (it may take a while for all caches to update the CSS). —a3li 18:42, 27 February 2015 (UTC)

Gentle introduction
Seems like we need a general introduction to Gentoo Linux article (we don't already have one, right?) that covers why one would choose this distro over any of the others and, let's be honest, why one might not want to use it. (The Handbook is too oriented towards the actual installation process to serve this purpose well.) - dcljr (talk) 22:28, 14 February 2015 (UTC)


 * Hi Dcljr, a similar article called Benefits_of_Gentoo does exist, but as the title suggests it only lists the benefits. Maybe some disadvantages could be added, the layout changed, and it could be moved to the title you suggested? I would be willing to help with this, as I do have some disadvantages in mind. What do you think? --Maffblaster (talk) 19:57, 17 February 2015 (UTC)


 * You should add this to the Gentoo Wiki:Requested Articles page! —a3li 18:44, 27 February 2015 (UTC)

Homepage Infobox internal link capability
I was working on the Gentoolkit article today (it is on my list of articles to clean up) and I came across a problem: there is no way for me to properly add a link to the Infobox for an internal homepage. The homepage Infobox presumes the homepages for various software is external to the wiki. In the case of Gentoolkit (Project:Portage-Tools) the homepage is now local to the wiki. I'm sure this applies to other Gentoo-original tools that have moved their project pages to the wiki. Right now links will always appear to be "pointing" to an external location (the up-arrow graphic following the link) when that no longer the case for certain projects. My suggestion is to enable the ability to link internally for homepage Infoboxes. --Maffblaster (talk) 19:51, 17 February 2015 (UTC)

Formatting of keywords
I've just created Template:Keyword for formatting mentions of keywords (like ). I chose &lt;code> tags for no particularly compelling reason. Interested parties should discuss there how we should format keywords on this wiki. - dcljr (talk) 00:17, 21 February 2015 (UTC)

CSS formatting of headers: needs more colour
As a prospective new Gentoo user, I make a heavy use of this wiki in general and of the Installation Guide in particular. Two things stroke me from the start: 1) is the high quality of the documentation, for which I am very grateful to the wiki editors. 2) the poor css styling of headers which make scanning a page very difficult. The table of content at the top of each page make the structure of the page very clear. However, scanning down the the page, I must concentrate on noticing the subtle font changes to figure out where the headers are (html h2, h3, h4, etc.). Generally speaking, I find it very difficult to follow a structure on all sites that rely on subtle font style and font size differences to suggest headings. I think the css styling must include colours and styling that make the hierarchy of headings very clear (user coloured background, coloured underlines, coloured fonts, etc.). The result must achieve two goals: a) make scanning a article for a specific heading very easy. b) show clearly the hierarchy. This is all the more important for long pages, like the full installation guide on one page. Thanks. Augustin (talk) 12:38, 25 February 2015 (UTC)


 * Thanks for your feedback. Tackling this is difficult, as fixing this too much will disturb the reading flow even more.
 * I've changed two things: The headings are slightly increased in size and &lt;h2> has a slight border on the bottom to give pages some structure, like on the original Wikipedia skin. Using colors or colored backgrounds is something that would distract more than help in my opinion. Then again, I really hate having these overly long pages, but that cannot be helped. :(
 * The changes can take a day or two to pass through all caches, but do let me know if it improves things for you. —a3li 19:17, 27 February 2015 (UTC)

All-arches handbook sections
Unless I'm missing something, we have per-arch pages for parts and sections of the Handbook (e.g., Handbook:AMD64/Full/Installation and Handbook:AMD64/Installation/Disks), but we don't have pages for parts and sections that could be used for any arch. I don't mean that the pages would contain actual arch-agnostic instructions, but that they would simply link to separate pages for all the different arches (like Wikipedia disambiguation pages, except that [most] incoming links wouldn't be mistakes that need correcting, they would be intentional). That way, in an arch-agnostic article about a piece of hardware or software, for example, we could link to pages like Handbook:Installation or Handbook:Installation/Disks that would then allow users to get to the arch-specific Handbook pages they need. Right now, a lot of links to sections within the handbook seem to link to the X86 version specifically, for no good reason. - dcljr (talk) 00:00, 4 March 2015 (UTC)
 * Here's a good example of why this is needed: at Handbook:Main Page, it says, "If you are still not certain which architecture to pick, please read the first section of the Gentoo Handbook's second chapter (Choosing the Right Installation Medium) as this will elaborate on the supported platforms." But it doesn't link to anything, because by definition no particular version of the Handbook would be appropriate to link to. If we had a page Handbook:Installation/Media that linked to every existing arch-specific version of itself, then we could link to that. - dcljr (talk) 20:20, 4 March 2015 (UTC)


 * To be specific, we would need (note "Expand" link):


 * Handbook:Blocks/Booting
 * Handbook:Blocks/Bootloader
 * Handbook:Blocks/Disks
 * Handbook:Blocks/HWReqs
 * Handbook:Blocks/Kernel
 * Handbook:Blocks/ProfileChoice
 * Handbook:Full
 * Handbook:Full/Installation
 * Handbook:Full/Networking
 * Handbook:Full/Portage
 * Handbook:Full/Working
 * Handbook:Installation/About
 * Handbook:Installation/Base
 * Handbook:Installation/Bootloader
 * Handbook:Installation/Disks
 * Handbook:Installation/Finalizing
 * Handbook:Installation/Kernel
 * Handbook:Installation/Media
 * Handbook:Installation/Networking
 * Handbook:Installation/Stage
 * Handbook:Installation/System
 * Handbook:Installation/Tools
 * Handbook:Networking/Advanced
 * Handbook:Networking/Dynamic
 * Handbook:Networking/Extending
 * Handbook:Networking/Introduction
 * Handbook:Networking/Modular
 * Handbook:Networking/Wireless
 * Handbook:Portage/Advanced
 * Handbook:Portage/Branches
 * Handbook:Portage/CustomTree
 * Handbook:Portage/Files
 * Handbook:Portage/Tools
 * Handbook:Portage/Variables
 * Handbook:Working/EnvVar
 * Handbook:Working/Features
 * Handbook:Working/Initscripts
 * Handbook:Working/Portage
 * Handbook:Working/USE
 * (I think I got everything there.) And possibly Handbook:Blocks, Handbook:Installation, Handbook:Networking, Handbook:Portage, and Handbook:Working (currently we don't have even arch-specific versions of these pages — e.g., Handbook:X86/Blocks — so I'm not sure they'd be needed). Admins would have to create these pages, of course. Would someone like to see a mockup of what I have in mind, or is that sufficiently obvious? - dcljr (talk) 01:50, 3 April 2015 (UTC)

Contrast
This wiki suffers more and more from poor or unnecessary contrast so that it looks “better”.

This text is gray, it isn’t black. It’s gray text on a gray background, not white.

Commands are now white text on black backgrounds, in a sea of white.

It looks pretty, but it makes it hard to read.* ¦ Reisio (talk) 01:16, 16 March 2015 (UTC)
 * &lt;off topic>Re *: Ironic that on a site about text readability, much of the text is obscured by badly placed and sized (and completely unnecessary, BTW) "buttons". (For example, the last two words of the "Let's start with the casus belli!" button fall off the end of the red background, making them unreadable; and the whole button covers up the text "Low-contrast font color and unreadable texts? To hell with them!", making those words unreadable, as well.) This is the case on my FF31.3, anyway. Very poorly designed site!&lt;/off topic> - dcljr (talk) 02:07, 16 March 2015 (UTC)
 * To actually address the issue being raised: I agree that the contrast in the regular text could stand to be increased a bit. And the size of the text should also be increased (but not hardcoded in px!). (I have to use a couple of Ctrl-+'s to make this site usable. The [//forums.gentoo.org/ forums] I have to magnify even more.) I don't have much of a problem with the light-on-dark commands, but the colored text in the command boxes (i.e., the prompt) often fades into the background. - dcljr (talk) 02:31, 16 March 2015 (UTC)


 * While I'm inclined to join dcljr in ridiculing the website you linked (It lags while scrolling?!?!), here's an objective take on it: I checked out two bad examples on that site. As we're talking about 256 shades of grey here, we can compare the contrast (0=black, 255=white):


 * I think 199/255 is reasonable while the others indeed are in the range of terrible to bad. That being said, should I receive more feedback on the font contrast as the theme rolls out to more Gentoo pages, I'll revisit this.


 * Next up: Font size: Them being px sizes is an issue recognized upstream that will be fixed in the next major version of Bootstrap. I do not agree they should be larger by default. Considering the various devices our web sites are viewed on, the size is a good default. Should your preferences or circumstances require larger font sizes, you have already found the fix, and I think browsers zoom nicely these days and remember the settings just fine as well. —a3li 13:03, 17 March 2015 (UTC)

2¢ I wasn't even expecting a reply. ¦ Reisio (talk) 22:23, 20 March 2015 (UTC)
 * To conclude that a contrast of 199 out of 255 is less hard to read than 102 or 40 is obviously correct, but to ask the question "How much unnecessarily low contrast is reasonable?" is a bit absurd. The point of text is to be read, we’ve used black on white for ages, it has good contrast, it makes reading easier, it makes the point of text easier.


 * Black on white (on modern screens) is too much contrast for most people and would decrease readability. The current default text (#333 on #fafafa) passes WCAG 2.0 at AAA level with flying colours. There is really no need to change this. — yngwin (wiki admin) (talk) 10:08, 7 April 2015 (UTC)


 * I swear I don’t mean this to be insulting—I wouldn’t say it if I meant it to be insulting—but that is the most ridiculous thing I’ve read since the April Fools about the couple selling golden tickets in Florida. ¦ Reisio (talk) 04:28, 8 April 2015 (UTC)


 * You're so easily amused. Thanks for playing! — yngwin (wiki admin) (talk) 14:12, 8 April 2015 (UTC)


 * If all font sizes were relative (in "%", and possibly "em" or "ex"), then which platform people are using would not be an issue, no? And most non-desktop platforms I've seen can zoom just as easily as desktop browsers. - dcljr (talk) 00:09, 18 March 2015 (UTC)