Wikipedia talk:User access levels/Archive 1

message: Does the "patrol" mean that if somebody with that ability looks at a page and decides that it's okay, *I*, who have not seen the page, will never see it on Recent Changes?  I want to make that determination for myself.
What is going to happen to all of the broad sysop powers that we currently have?  Will we automatically be given all of the authority, none of it, or parts of it?  RickK 07:36, Nov 20, 2004 (UTC)
:You can hide patrolled edits from recent changes if you want to. You don't have to. It's similar to the "hide logged in users" option on recent changes now. 
:As the system currently stands, you start off with no levels at all. I strongly expect this will change before it goes live here so sysops now will basically have the same powers in 1.4. The difference is that non-admins will be able to apply for new lower levels if they want to. Angela. 11:15, Nov 20, 2004 (UTC)
::Is everybody who's now a sysop going to have to re-apply for adminship?  RickK 00:07, Nov 21, 2004 (UTC)
:::The way I understand it, those who are currently admins will remain so and will retain all the same abilities. There will be the potential for non-admins to request certain permissions short of full adminship. (I highly doubt all current admins would have to re-apply - it would be a huge inconvenience.) Rdsmith4— Dan | Talk 03:14, 22 Nov 2004 (UTC)
thread_title:  Questions 

message: Is there an "edit protected page" capability?  Or is it implied by some other capability?  —AlanBarrett 10:12, 27 Nov 2004 (UTC)
replies: text: It's currently implied by "protect". It'd make more sense for it to be separate (but still implied by "protect"). -- Cyrius|✎ 16:46, 27 Nov 2004 (UTC)
thread_title:  edit protected page 

message: I think that "view deleted page" should be separate from the "undelete" capability.  —AlanBarrett 10:13, 27 Nov 2004 (UTC)
replies: text: In general I'm with the people who want to split "undelete" (as above), "delete" (into pages and images), "protect" (into protect and edit-protected), etc. Not that I feel we will want to make a practise of splitting them apart (especially not right away), but rather because I think that if we're going to change this part of the interface, we should do it all at once, and not dribble additions on later. I would assume that these changes are only an incremental amount of work for a developer (now that admin has already been split into a large number of different capabilities) so I don't feel too bad about requesting "just one more small change"! Noel (talk) 13:41, 10 Dec 2004 (UTC)
thread_title:  view deleted page 

message: As an anon so briefly noted, the new permissions system is now being held back until Mediawiki 1.5. Brion Vibber says that they're aiming for February with 1.5. -- Cyrius|✎ 19:30, 3 Dec 2004 (UTC)
thread_title:  1.5 

message: This is may not be the right page for this question - so point me somewhere else if necessary. Why is unwatchedpages an Admin funtion. Surely this would be a good tool for Reg Users to have, to help deal with Vandalism and/or Inappropriate pages?
Your thoughts please Lethaniol 12:32, 10 December 2006 (UTC)
replies: text: The basic thought is, if it was an all-users permission, it would be the equivalent of Wikipedia:Easiest pages to vandalize. Since anyone can create an account, and hundreds of vandal accounts are created each day, it would serve as a quick-reference list of pages that could be easily vandalized, and if done so subtly (so as to not raise red-flags with RC patrollers) could remain vandalized for months, because nobody is watching them. The original intent of having the special page, as I understand it, was so admins could find unwatched pages and watch them for vandalism and other problems, rather than to have a quick-hit list for potential vandals. Essjay (Talk) 01:18, 11 December 2006 (UTC)
replies: text: So why not make it a long-standing member type thing, like editing semi-protected pages. —The preceding unsigned comment was added by Comperr (talk • contribs) 00:39, 15 February 2007 (UTC)
replies: text: Editing semi-protected pages doesn't require you to be a long-standing member, it only requires about 4 days. Opening up unwatchedpages would require much longer than that. --Tango 12:15, 13 April 2007 (UTC)
thread_title:  Unwatchedpages 

message: This table seems to be out of date. It doesn't mention semiprotecting, and doesn't distinguish between newly registered users and users that have been around a few days. Also, there is the new ipblock-exempt permission. Can someone that knows precisely how things are now update this table? (I could try, but it would be guesswork.) --Tango 17:43, 10 January 2007 (UTC)
thread_title:  Out of date 

message: Ahem, I see that "banned users" (and only they) can "patrol" and "asksql". Excuse me, but this seems to be nonsense. Afaik, "asksql" is a (now abandoned) feature once available to sysops and patrol is probably open to all (registered?) users, when it is enabled on the wiki. Am I completely mistaken on this? --Mbimmler 10:48, 11 March 2007 (UTC)
thread_title:  Banned users 

message: Isn't siteadmin editing the MediaWiki interface? mrholybrain's talk 00:00, 13 April 2007 (UTC)
replies: text: No, this priv is called 'editinterface', while 'siteadmin's are responsible for locking database. And let me assure you, stewards can't lock it. Even more, I checked: developer permission gives you access to Special:Lockdb, but it says that lock file is not writable for the web server, that's why I marked siteadmin as depreciated. MaxSem 06:56, 13 April 2007 (UTC)
replies: text: Fine. mrholybrain's talk 10:28, 13 April 2007 (UTC)
thread_title:  siteadmin 

message: The diagram on the page here differs from what is described here. I would have corrected it myself, but I don't know which is right. --P4wn4g3 03:31, 2 May 2007 (UTC)
thread_title:  An Inconsistent Description 

message: The table marks various cells as (two shades of) green, yellow, red, or black. Yet nowhere is there a key to explain what these colors mean. Of course, another problem is that many people can't distinguish red from green. Tualha (Talk) 02:02, 14 July 2007 (UTC)
replies: text: Red is disabled/blocked, yellow is "special" (EG. Click the link to see the userlist), green is applicable and I'm assuming lighter green is "Because you have to have permission to do this at lower levels" or some such. A key would be usefull. 68.39.174.238 15:00, 20 July 2007 (UTC)
thread_title:  "The colors..." 

message: Isn't this merely an extended version of the steward level?? --Solumeiras talk 16:13, 10 January 2008 (UTC)
replies: text: I believe it's just nominal. The steward and founder levels are separate but I don't think 'founder' has anything extra with it. Just Jimbo vanity. -- 213.152.52.38 (talk) 16:59, 9 April 2008 (UTC)
thread_title:  Founder user access level 

message: The table differentiates between these; there are no groups with only one of the two on wikimedia wikis - keeping them separate would still be informative if they are separate permissions in mediawiki, but it needs to be clear just what is associated with each permission. —Random832 16:13, 10 January 2008 (UTC)
thread_title:  deletedhistory and undelete 

message: Wikipedia:User access levels#New users says: "They are also not required to answer a CAPTCHA at any time". At Wikipedia:Help desk#External Link check a one day old account says that a CAPTCHA is required to add external links. Has there been a change? PrimeHunter (talk) 17:00, 7 March 2008 (UTC)
replies: text: I think it was corrected now. Autoconfirmed accounts aren't required to enter the CAPTCHA, new users still have to. -- 213.152.52.38 (talk) 17:04, 9 April 2008 (UTC)
thread_title:  CAPTCHA required for new accounts 

message: Because I can't find it anywhere - how can I (or in practoice a bot of mine) check whether a given user is a newbie (less than four days) or not? Pseudomonas(talk) 19:40, 2 April 2008 (UTC)
replies: text: There are some scripts being developed for this, I've heard. In the meanwhile, you can use http://en.wikipedia.org/w/index.php?title=Special:Log&limit=500&type=newusers&user=USERNAME to see when an account was created.  Just subtract 4 from that date, if the difference is a negative number, then that user is a newbie.   shows you today's date. -- penubag  (talk) 02:18, 15 April 2008 (UTC)
replies: text:  Thanks :) Pseudomonas(talk) 08:19, 15 April 2008 (UTC)
thread_title:  Checking user groups 

message: Enough cluttering up the page history . The important thing as far as I'm concerned is that, while the RfA/RfB process on en.wiki ensures that no one will ever be promoted to 'crat without first becoming an admin, there is no requirement in the MediaWiki software for that hierarchy, so it would be inaccurate of us to suggest in the table or text that it was the case.  If a crat were ever to be promoted without being an admin, I expect it would be considered a gross abuse of rights for them to unilaterally promote themselves to sysop, in the same way it would be considered highly inappropriate for a crat who is also a bot operator to flag one of their own bots without first going through WP:BRFA. Happy‑melon 09:41, 15 April 2008 (UTC)
replies: text: Exactly. All requests to stewards to assign a crat flag without a +sysop are denied. However, technically crats aren't automatically sysops and shouldn't be described as @those who can do same things as sysops plus promote users and bots". MaxSem(Han shot first!) 09:44, 15 April 2008 (UTC)
replies: text: But note that this table is not on mediawiki.org. While it may technically be possible, this page is about user rights on this site where all bureaucrats are admins. Mr.Z-man 15:26, 15 April 2008 (UTC)
replies: text: And so we've made a note of that fact above the table; perhaps a similar note should be added to the #Bureaucrats section also.  But it would be misleading to colour the cells in the table for Bureacrat/protect or Bureaucrat/delete green, because that is not what is happening.  Happy‑melon 15:38, 15 April 2008 (UTC)
replies: text: That table has its own problems. If I ever get really bored and have a couple hours of free time, I plan on redoing it. Mr.Z-man 19:23, 20 April 2008 (UTC)
replies: text: What do you think is wrong with it? It's certainly not perfect, but I can't think of a better way of presenting the information. Happy‑melon 08:30, 21 April 2008 (UTC)

text: Aren't crats able to remove the Bot flag? MBisanz talk 02:26, 21 April 2008 (UTC)
replies: text: Yes they can: I've corrected the table. Happy‑melon 08:30, 21 April 2008 (UTC)
thread_title:  Crats and sysops 

message: Wow, is it just me or is there a sudden surge in vandalism to this page? Sockpuppets anyone? -- penubag  (talk) 01:01, 1 May 2008 (UTC)
replies: text: I've semi-protected - it's not an article or discussion, and there's clear evidence that, when the semi-protection expires, the vandalism returns immediately. Happy‑melon 09:25, 1 May 2008 (UTC)
replies: text:  Still seems persistent. It's sock puppetry, who would edit this page as their first edit? -- penubag  (talk) 02:34, 6 May 2008 (UTC)
thread_title:  Vandalism 

message: What does Inherited mean exactly? Does it mean that a right is assumed for that usergroup but the right is not granted? So an administrator not in the group autoconfirmed would denied to move a page, but they inherit it because they are not revoked from the autoconfirmed group when promoted to an admin.  -- penubag  (talk) 02:13, 10 May 2008 (UTC)
replies: text: Does this mean that a bureaucrat 'inherits' admin rights? -- penubag  (talk) 05:03, 12 May 2008 (UTC)
replies: text: Admins are explicitly autoconfirmed; crats don't automatically inherit sysops' rights. MaxSem(Han shot first!) 05:23, 12 May 2008 (UTC)
replies: text: So sysop accounts automatically get the ability to use e.g. movepage even if the account is newer than four days? --Random832 (contribs) 15:16, 20 May 2008 (UTC)
replies: text: I don't think that's the case; although I'm prepared to be proved wrong, I don't think that's how the software works.  Someone with a personal wiki want to test it? Happy‑melon 15:18, 20 May 2008 (UTC)
thread_title:  Inherited 

message: There has been some back-and forth regarding the definition for this group, I've set it to a very basic explanation as it does exist--but will leave it to this talk page for the need for further information. — xaosflux Talk 13:28, 23 May 2008 (UTC)
replies: text: I think the locus of the dispute - that there should be some independent reference for a fact in the wikipedia namespace - is utterly ludicrous.  Happy‑melon 13:49, 23 May 2008 (UTC)

text: Note, my only personal argument is that there should be a description of this group, but don't really have an opinion as to the inclusion of the history of it. — xaosflux Talk 13:58, 23 May 2008 (UTC)
replies: text: The 'founder' group exists on en.wiki, therefore its existence should be noted on this page - that much, I think, is indisputable.  I really can't understand what's wrong with the original wording. Happy‑melon 14:02, 23 May 2008 (UTC)
replies: text: I question the claim that it was created as a "mark of respect for Jimmy Wales, founder of Wikipedia". If this was authorized by the Board, there should be some documentation. Otherwise, I think it's likely Wales himself did (or ordered some developer to do) this. Bramlet Abercrombie (talk) 14:25, 23 May 2008 (UTC)
replies: text: What makes you assume that it would need to be authorised by the board? As long as we don't impinge on WMF's legal isolation (ie host copyrighted material, egregiously violate WP:OR, etc) there's no need for the board to 'authorise' anything, and they're far too busy to do so.  As long as we're in line with their values, they have many other better things to do than micromanage our user-rights choices .  The 'founder' usergroup is not implemented on any other wikimedia project (see wikimedia's actual config files), which is evidence against it being implemented by either the devs or Jimbo.  Besides, it's completley useless - Jimbo already has steward rights on meta, so he can make any rights changes there.  'founder' gives him local access to all user-rights and to Special:Makesysop, which he's never going to use, even on himself (as he's an admin anyway).  There's no possible use for the group other than as a mark of respect. Happy‑melon 19:05, 23 May 2008 (UTC)
replies: text: Well, who's "we"? Ordinary users can hardly create new user access levels. Only developers can do that; they might do so on their own initiative, or by order of some authority, or indeed after a community decision, but in the case of a community decision a record should be on the wiki somewhere, and I can't find such. I agree it's functionally useless, only serving to bolster the Jimbo cult (and to support his "sole founder" myth), but the question is who initiated this? The passive-voice statement "it was created as a mark of respect" is a bit dubious if it may have been Wales who created it as a mark of respect for himself. Bramlet Abercrombie (talk) 19:21, 23 May 2008 (UTC)
replies: text: What makes you so suspicious that it was his own initiative? Happy‑melon 19:26, 23 May 2008 (UTC)
replies: text: The fact that he's self-aggrandizing all the time, this would be typical. And I find it unlikely anyone else would do this on their own initiative. Bramlet Abercrombie (talk) 19:33, 23 May 2008 (UTC)
replies: text: Well that's your opinion, to which you're fully entitled. I'm going to e-mail the developers to get a comment from their side. Happy‑melon 20:11, 23 May 2008 (UTC)

text: I assume those "other Wikipedians" told you that in private, or was there an on-wiki discussion? Bramlet Abercrombie (talk) 10:22, 24 May 2008 (UTC)
replies: text: Why does it matter?? Happy‑melon 15:50, 24 May 2008 (UTC)
replies: text: Because it wouldn't be appropriate to give the impression that the community at large expressed its respect for Wales when it didn't. Bramlet Abercrombie (talk) 16:41, 24 May 2008 (UTC)
replies: text: I wasn't under the impression that the original wording implicated anyone in the group's creation. The version you've just added, which gives the impression that it was entirely Starling's idea, is less accurate than the intermediate version.  WP:AGF extends to all namespaces, you know - why is it so difficult to accept the possibility that there might not be any conspiracy here? Happy‑melon 16:53, 24 May 2008 (UTC)
replies: text: By not implicating anyone, the original version implicated a collective decision. Apparently it was pretty much Starling's decision, backed up maybe by a handful of people on IRC. Bramlet Abercrombie (talk) 19:15, 24 May 2008 (UTC)
replies: text: Would you consider the text as it stands after my edit just now to be a fair representation of events? Happy‑melon 19:25, 24 May 2008 (UTC)
replies: text: The unspecified talk about "requests" is still misleading, suggesting that there was some widespread movement for this, which there wasn't. Unless Tim Starling can name the people who "requested" this, he should take the sole responsibility. Also, I don't think "sinecure" is the right word here; all user rights are sinecures in that they only involve rights and no obligations to do anything. Bramlet Abercrombie (talk) 21:22, 24 May 2008 (UTC)
replies: text: You appear to be of the opinion that the creation of this user group constitutes a mistake for which "responsibility" (=blame?) needs to be assigned; as I've said, you are welcome to that opinion, but I don't think very many people would agree with it.  Is there any particular reason why we shouldn't trust Starling to be telling the truth just a few lines above? I agree, on re-reading, that sinecure doesn't quite mean what I thought it did - can you think of a better word to sum up the nature of the group? Happy‑melon 21:58, 24 May 2008 (UTC)
replies: text: I'm not saying what he said isn't the truth, it's just not the complete truth since "other Wikipedians" isn't specified. In all likelihood it was just a few people, otherwise there would be a record of an on-wiki discussion about it. Whether that makes it a mistake is a question anyone can answer for themselves. I'm just saying the page should make clear what the facts are. As to the nature of the group, you might say it's a pure "status symbol" for Wales if it doesn't add to the powers he already has without it. Bramlet Abercrombie (talk) 22:31, 24 May 2008 (UTC)
thread_title:  'founder' group 

message: Very new users who try to upload an image are brought to Autoconfirmed users. I edited Autoconfirmed users to give these new users better insight into where the restrictions derive (e.g., the MediaWiki software itself).  indicates at the bottom that "From MW 1.12, you can create your own groups into which users are automatically promoted (as with autoconfirmed and emailconfirmed) using $wgAutopromote." I presumed this meant bureaucrats since that same MediWiki List of Groups indicates that bureaucrat are "users who by default can change other users' rights." If some other group does this, please change the sentence. I included the info about an alternate (a remote one at that) to the 4/10 software scheme so that new users don't think Wikipedia is a heartless machine run by computers and more willing to continuing editing after being prevented from uploading their image, moving a page, etc.. -- JohnABerring27A (talk) 21:57, 12 June 2008 (UTC)
replies: text: $wgAutopromote is a setting that can only be changed by system administrators (like Tim Starling or Brion VIBBER). —{admin} Pathoschild 03:29:04, 20 June 2008 (UTC)
thread_title:  Edits to Autoconfirmed users 

message: Since many new users may read this page, would it be prudent to clarify en.wiki and en.wikipedia as (en.wikipedia.org / English wikipedia)?
Shouran (talk) 03:16, 10 November 2008 (UTC)
thread_title:  en.wiki 

message: I thought that to be WP:Autoconfirmed, your account needs to be both four days old and have ten edits.  Is this correct?
Domas Mituzas and ProvidentialPrudence have both been involved in Grawp-themed page move vandalism for Amyotrophic lateral sclerosis and VeggieTales respectively.  The first editor's contribution history lists zero edits.  The second's lists five.  But they were both able to move pages. Why is this?  WhatamIdoing (talk) 03:32, 14 February 2009 (UTC)
thread_title:  Page move vandalism 

message: How do I know how many edits I have? Dpalme (talk) 23:00, 31 March 2009 (UTC)
replies: text: If you want to know your edit count go to your contributions page, go to the bottom, were you will see a number of tools, including User rights, Edit count, Articles created, and files uploaded. Click on 'Edit count' and you will go to Toolserver.org, were you find your top ten most edited articles, month edits, and percents of templates, talk pages, articles, and WP pages, and much more. A quicker way to find out is to go to your preferences and it will show an edit count there. --The High Fin Sperm Whale (Talk • Contribs) 01:28, 4 January 2010 (UTC)
thread_title:  How many edits 

message: Might it be wise to have a kind of Trusted Editor category? The potential benefits of this include not having to contact an administrator should they want to edit something. A potential candidate should prove that they can make non-controversial edits and have the ability to think things through. They should also have a good track record among other users. This person could act as sort of a quasi administrator.
Other abilities could include:
*Page deletion, but another administrator has to confirm it
*Not being affected by a rate limit
*View deleted history
*Editing locked pages that only administrators can edit
This ability could speed up the backlog of some of the things here. I know that there are probably those out there who either support or are against this proposal, so add ideas that you see fit. Kevin Rutherford (talk) 02:25, 22 February 2009 (UTC)
replies: text: I think that we'd much rather make these people be full admins.  WhatamIdoing (talk) 19:11, 23 February 2009 (UTC)
thread_title:  Trusted Editor 

message: There is currently a poll on the autopromotion of reviewers at Wikipedia talk:Reviewers#Poll on autopromotion, for the trial implementation of flagged protection and patrolled revisions. For information, see general documentation and overview. All users are invited to comment, and to participate in the elaboration of a reviewing guideline as well. Cenarium (talk) 13:47, 12 April 2009 (UTC)
thread_title:  Poll on reviewer autopromotion for flagged protection and patrolled revisions 

message: When I created my account I could not create articles until I was autoconfirmed. Why? Daniel Christensen (talk) 16:05, 12 April 2009 (UTC)
replies: text: You can create articles regardless of autoconfirmation. Ruslik (talk) 16:51, 12 April 2009 (UTC)
replies: text: Maybe you were instead trying to edit an locked article?  I hear those are easy to mix up...Fuzbaby (talk) 19:50, 19 May 2009 (UTC)
thread_title:  What the Hell? 

message: Once you have an account, can you change the name of your account, or would that wreak havoc? --The High Fin Sperm Whale (talk) 02:00, 9 June 2009 (UTC)
replies: text: See WP:CHU. Ruslik_Zero 19:27, 9 June 2009 (UTC)
thread_title:  Changing the name 

message: As an admin, I can (obviously) see the flags at Special:Userrights, including the flags I don't have the ability to change, which appear "grayed out."  However, a non-admin sees "Your account does not have permission to assign user rights."  Is there a reason he doesn't just see the same page with all of the boxes "grayed out"?  It seems like a good idea, especially since this is the best place to check what permissions a given user has.  --Philosopher Let us reason together. 04:59, 27 June 2009 (UTC)
replies: text: You could request an enhancement at bugzilla:. Cenarium (talk) 16:01, 20 September 2009 (UTC)
replies: text: The bottom of contributions pages have a "User rights" link anybody can see. Maybe this should be mentioned at Wikipedia:User access levels. PrimeHunter (talk) 13:21, 25 November 2009 (UTC)
thread_title:  Who can see Special:Userrights 

message: Please see and comment here. Thanks, Cenarium (talk) 16:02, 20 September 2009 (UTC)
thread_title:  Turning Autoconfirmed into an explicit userright 

message: Hello, I am busy with a school project, and I cannot upload images, how do I get confirmed as a user? I have to complete this page  —Preceding unsigned comment added by Super Warmonkey (talk • contribs) 12:41, 25 November 2009 (UTC)
replies: text: Your account is old enough and you have 4 edits so you just need to make 6 more edits to any page to become autoconfirmed. You can upload images right away to Wikimedia Commons at http://commons.wikimedia.org and use them in Wikipedia. But see also Wikipedia:FAQ/Organizations,Wikipedia:Notability, Wikipedia:Reliable sources. Advertising statements like "has qualified and determined teachers and faculty, giving individual attention to each and every pupil" increase the risk that a page will be considered spam and deleted. PrimeHunter (talk) 13:15, 25 November 2009 (UTC)
thread_title:  Help 

message: Moved to Wikipedia talk:User access levels/RFC on autoconfirmed status required to create an article, on request.  Reason:  Section is getting too big. davidwr/(talk)/(contribs)/(e-mail) 23:41, 27 December 2009 (UTC)
thread_title:  RFC on autoconfirmed status required to create an article 

message: I have made a table showing who can give/revoke certain rights.
Granted	Inherited	Denied
  	    	 
                               	Confirmed	Bot	Sysop	Bureaucrat	Rollbacker	Checkuser	Autoreviewer	Oversight	Boardvote	Import	Ipblock-Exempt	Edit Filter managers	Acccount Creator	Steward	Founder
Anonymous users                	         	   	     	          	          	         	            	         	         	      	              	                    	                	       	
(Auto)Confirmed/Registered User	         	   	     	          	          	         	            	         	         	      	              	                    	                	       	
Bot                            	         	   	     	          	          	         	            	         	         	      	              	                    	                	       	
Sysop                          	+/-      	   	     	          	+/-       	         	+/-         	         	         	      	+/-           	+/-                 	+/-             	       	
Bureaucrat                     	         	   	+    	+         	+/-       	         	+/-         	         	         	      	+/-           	+/-                 	+/-             	       	
Rollbacker                     	         	   	     	          	          	         	            	         	         	      	              	                    	                	       	
Checkuser                      	         	   	     	          	          	         	            	         	         	      	              	                    	                	       	
Autoreviewer                   	         	   	     	          	          	         	            	         	         	      	              	                    	                	       	
Oversight                      	         	   	     	          	          	         	            	         	         	      	              	                    	                	       	
Boardvote                      	         	   	     	          	          	         	            	         	         	      	              	                    	                	       	
Import                         	         	   	     	          	          	         	            	         	         	      	              	                    	                	       	
Ip-block-Exempt                	         	   	     	          	          	         	            	         	         	      	              	                    	                	       	
Edit Filter managers           	         	   	     	          	          	         	            	         	         	      	              	                    	                	       	
Acount Creator                 	         	   	     	          	          	         	            	         	         	      	              	                    	                	       	
Steward                        	+/-      	+/-	+/-  	+/-       	+/-       	+/-      	+/-         	+/-      	+/-      	+/-   	+/-           	+/-                 	+/-             	+/-    	+/-
Founder                        	+/-      	+/-	+/-  	+/-       	+/-       	+/-      	+/-         	+/-      	+/-      	+/-   	+/-           	+/-                 	+/-             	+/-    	+/-
I thought it could be included in this article so people know who can grant them a particular right, if you agree with me feel free to add it. Thanks Paul2387 16:50, 17 January 2010 (UTC)
replies: text: Seems like overkill to be honest, it would be much easier to simply having a passage saying admins can do x, crats can do x and y and stewards can do x, y and z. I suppose if you really want a table then you should take out everyone who can't do anything at all, a huge block of red is pointless--Jac16888Talk 21:13, 20 January 2010 (UTC)
replies: text: I tend to agree, it would be easier to convey this information with words, considering that three quarters of the table is just "denied." Beeblebrox (talk) 21:18, 20 January 2010 (UTC)

text: I have improved the above table and it can be seen below:
Granted	Inherited	Denied
  	    	 
          	Confirmed	Confirmed	Bot 	Bot 	Sysop	Sysop	Bureaucrat	Bureaucrat	Rollbacker	Rollbacker	Checkuser	Checkuser	Autoreviewer	Autoreviewer	Oversight	Oversight	Boardvote	Boardvote	Import	Import	Ipblock-Exempt	Ipblock-Exempt	Edit Filter managers	Edit Filter managers	Acccount Creator	Acccount Creator
          	give     	take     	give	take	give 	take 	give      	take      	give      	take      	give     	take     	give        	take        	give     	take     	give     	take     	give  	take  	give          	take          	give                	take                	give            	take
Sysop     	         	         	    	    	     	     	          	          	          	          	         	         	            	            	         	         	         	         	      	      	              	              	                    	                    	                	
Bureaucrat	         	         	    	    	     	     	          	          	          	          	         	         	            	            	         	         	         	         	      	      	              	              	                    	                    	                	
Steward   	         	         	    	    	     	     	          	          	          	          	         	         	            	            	         	         	         	         	      	      	              	              	                    	                    	                	
Founder   	         	         	    	    	     	     	          	          	          	          	         	         	            	            	         	         	         	         	      	      	              	              	                    	                    	                	
Feel free to comment on it and if you like it feel free to add it to the main article. Paul2387 13:42, 21 January 2010 (UTC)

text: What is 'confirmed bot'? Ruslik_Zero 14:08, 21 January 2010 (UTC)
replies: text: A bot which has a more perfect bond with God. Or, it might be that you missed the line between Confirmed and Bot--Jac16888Talk 15:10, 22 January 2010 (UTC)

text: On a friend's wiki, she found that if you made a non-admin a 'crat, they didn't inherit the admin properties - they couldn't block users, delete pages or protect pages. I don't know what version of MediaWiki they are using, but are you sure that enwiki 'crats would have the admin rights as well? I know no one's ever been a 'crat without being an admin, but I was just curious. -- PhantomSteve/talk|contribs\ 07:43, 2 April 2010 (UTC)
replies: text: I have done some tests on my own wiki I set up today and crats alone (without admin bit) can't delete pages or block users, however if the rights are changed in the LocalSettings.php then Crats can be given those rights, could someone do a experiment(test) on wikipedia and report back here - maybe someone could create a test account and only add crat rights. Please Leave your reports in the relevent sections below. Paul2387 10:57, 2 April 2010 (UTC)
thread_title:  User Rights Table 

message: Behold: 
Granted	Inherited	Denied
  	    	 
          	Confirmed	Confirmed	Rollbacker	Rollbacker	Autoreviewer	Autoreviewer	Filemover	Filemover	Ipblock-Exempt	Ipblock-Exempt	Bot 	Bot 	Edit Filter managers	Edit Filter managers	Acccount Creator	Acccount Creator	Sysop	Sysop	Bureaucrat	Bureaucrat	Checkuser	Checkuser	Oversight	Oversight	Boardvote	Boardvote	Import	Import
          	give     	take     	give      	take      	give        	take        	give     	take     	give          	take          	give	take	give                	take                	give            	take            	give 	take 	give      	take      	give     	take     	give     	take     	give     	take     	give  	take
Sysop     	         	         	          	          	            	            	         	         	              	              	    	    	                    	                    	                	                	     	     	          	          	         	         	         	         	         	         	      	
Bureaucrat	         	         	          	          	            	            	         	         	              	              	    	    	                    	                    	                	                	     	     	          	          	         	         	         	         	         	         	      	
Steward   	         	         	          	          	            	            	         	         	              	              	    	    	                    	                    	                	                	     	     	          	          	         	         	         	         	         	         	      	
Founder   	         	         	          	          	            	            	         	         	              	              	    	    	                    	                    	                	                	     	     	          	          	         	         	         	         	         	         	      	
By the way, why do we list Jimmy/Founder here when he can do everything? We should remove that, as in all honesty, it adds just as little as including the Anonymous users section, which can do none of these things, and was also cut. Sven Manguard Wha? 01:01, 16 April 2011 (UTC)
thread_title: Beautified and updated for File Mover

message: accounts that are more than four days old and have made at least 10 edits are considered autoconfirmed
This is shouting out to be increased, it should better be at least  two weeks and at least 200 edits as it is right now it is very easy to create new accounts and be disruptive daily at the same article, I can't see a benefit in having this so low, at this level semi protection is worthless. A good faith account with a 100 edits will easily say hey, can you make this edit for me, what will we lose by raising this level to a point to deter trolls and vandals? Off2riorob (talk) 00:47, 10 February 2010 (UTC)
replies: text: This isn't exactly the same proposal, but a review of this rfc will show what you are up against here. It would only stop them from vandalizing semi-protected articles anyway. Beeblebrox (talk) 02:01, 10 February 2010 (UTC)

text: That was my objective from the change, I will have a read of the link, thanks.. as far as BLP articles and the flagged revision goes, if we semi protected all BLP articles and raised the auto confirmed level, many of the disruptive editors would simply go away. Off2riorob (talk) 02:07, 10 February 2010 (UTC)

text: Actually the 4 days are counted since the date of registration, not of first edit. Cenarium (talk) 23:49, 3 April 2010 (UTC)

text: We'll have the usergroup of reviewers with WP:FPPR which does include an intermediary protection level (to handle cases like Seraffin, persistent targeted disruption). Patrolled revisions will give us a much better monitoring capability as well. So the autoconfirmed threshold would not need to be raised. Cenarium (talk) 23:49, 3 April 2010 (UTC)
thread_title:  We should raise the level of auto confirmation 

message: Well, I can't remember where it was but I encountered the rare case of a discussion (talk) page blocked for anonymous edits!! That means I cannot even request changes (grammar in this case) anymore. However, WP had a page where we could request these changes, I just cannot remember it anymore. Can anyone please help me out? -andy 85.179.125.6 (talk) 07:09, 13 February 2010 (UTC)
replies: text: Try the protecting admin's talk page, then WP:RFPP. -- zzuuzz (talk) 12:49, 13 February 2010 (UTC)
replies: text: You could also file a request at requests for page protection, which has a section for requesting edits to protected pages.By the way, the other two discussions you just posted in are extremely stale, and it's unlikely you'll receive any reply, in fact this edit  was the first edit to that talk page in nearly five years, and the page it is a talk page of is marked as "historical and inactive." Beeblebrox (talk) 16:45, 13 February 2010 (UTC)
thread_title:  Do IPs still have the way to request a change on a page except via the discussion page? 

message: What is the researcher user group (see here)? Thanks, -- Black Falcon (talk) 05:02, 22 April 2010 (UTC)
replies: text: See Special:ListGroupRights.  They can see deleted histories, but not deleted text, for research purposes.  Log Happy‑melon 08:51, 22 April 2010 (UTC)
replies: text: Ah, I see. Thank you, -- Black Falcon (talk) 17:09, 22 April 2010 (UTC)
thread_title:  Researcher? 

message: Hello. I understand the "researcher" permission is a relatively new one. How does one go about obtaining/requesting this right? It is not yet documented on the traditional "request-for-permissions" page. My user-page should contain the pointers sufficient to demonstrate I do Wikipedia research. Thanks, West.andrew.g (talk) 02:36, 4 June 2010 (UTC)
thread_title:  Obtaining Research Rights 

message: Proposed here. Cenarium (talk) 16:28, 12 June 2010 (UTC)
thread_title:  Proposal to rename Autoreviewer to Autopatroller 

message: Nano-X Based on the original mini-X tutorial by David I. Bell
2000/10/3 Revision 1.0
This is a simple tutorial on using the Nano-X graphics system.  Much of this is a lot easier to understand if you are familiar to X.  I am not going to try to explain every concept in detail here, nor how to put it all together to make really fancy programs.  Instead, I am only going to tell you just enough to let you make some simple graphics programs which work.  Experience with simple test programs will enable you to build much fancier graphics programs much easier than trying to decipher what I could tell you.
I am assuming that you basically know what a screen, pixels, colors, keyboards, mice, buttons, and windows are.  However, you probably don't know exactly what the properties of windows in this system are.  Also, you might not know two other concepts which are important here, which are graphics contexts and events.  So these things will be explained in this tutorial.
WINDOWS
Windows are rectangular areas which can be drawn into.  Windows have a position, specified by the x and y coordinates of their upper left corners, and also a size, specified by their width and height.  Windows are arranged in a tree structure, with the parent windows controlling the child windows. The top of the tree is known as the root window.  The root window is always present, and represents the total screen area.
Each child window is clipped by its parent window.  This means that a window can be very large, but the only part of the window that can ever be seen is the part which shows through its parent window.  This applies recursively, so that all of the parents of a window limit its visibility.  The position of a window is specified relative to its parent, and not absolutely.  This means that for example, when a window is moved, then all of its children will move with it.  The position of a window can be negative.
Windows which have the same parent can clip each other.  That is, there is a defined order among the children of a window as to which is more important. If two sibling windows overlap, then the more important window will be visible in preference to the less important window.  The precedence of visibility of siblings can be dynamically adjusted.  Clipping can also occur on a window by earlier siblings of any of the window's parents.
Windows can be mapped or unmapped.  Unmapped windows are not visible, and cause no events. They can be thought of as "in storage" or off screen. When a window is mapped, then it can become visible on the screen. Children of an unmapped window are implicitly also unmapped.  So a window is not visible until it and all of its parents are mapped.  A newly created window starts off unmapped. 
Windows have a background color. A newly mapped window is filled with its background color.  Clearing the window later, or having obscured portions of the window become visible again, will fill the region with the background. The client program can then draw into the window to make it look correct.
Windows may have a border.  A border is a set of rectangles adjacent to the four sides of the window which is drawn in a specified color, with a specified width.  This makes pretty lines around the window, for example. The border cannot be drawn in by the program.  Borders are optional, so that a window with a border width of zero has no border at all.  Borders are "around" the window, so that they do not affect the coordinates of the window.  Whether or not a window has borders, its position determines the location of the upper left corner which can be drawn into.
Windows can have a cursor associated with them.  The graphics server tracks the location of the mouse, and maintains the position of a graphics cursor on the screen.  This cursor can automatically change its shape and colors as it moves between different windows.  The use of different cursors for different windows can be used to provide a powerful clue to the user as to what will happen if a mouse button is pressed in a window.  Newly created windows inherit the same cursor as their parent.
There are two types of windows, input-output and input-only windows. Input-output windows are normal windows which are visible and can be drawn into.  Input-only windows are invisible, have no border, and cannot be drawn into.  Their purpose is to catch events, and to enable the cursor to be changed in different regions of a visible window.  The only children of input-only windows are also input-only windows. Windows are identified by integers called window ids.  The root window has a constant window id value of GR_ROOT_WINDOW_ID. 
The root window does not need creating, and cannot be unmapped, moved, resized, or destroyed. However, it can be drawn into and events can be delivered to it.  New windows can be created from existing windows. Their window ids are not constants, but once created the window id remains until the window is destroyed. Window ids are not reused as windows are created and destroyed.
GRAPHICS CONTEXTS
When drawing objects such as lines, there are many parameters that can be specified for the function call that affect the operation.  Besides the minimum information needed for the function such as the endpoint coordinates, there are extra parameters that are less important and less variable. Examples of these extra parameters are color, width (thin or thick), style (dashed, dotted), and drawing operation (setting, XOR'ing). Instead of requiring the specifying of each of these extra parameters for every function call, graphics contexts are used.  Graphics contexts are just a collection of specific combinations of these extra parameters.  The many possible extra parameters to each function are replaced by just one extra parameter, which is the graphics context.
For example, instead of a function call like:
        drawline(window, x1, y1, x2, y2, color, width, style, operation);
you have instead
        drawline(window, gc, x1, y1, x2, y2),
where the graphics context contains within itself the parameters color, width, style, and operation.
Graphics contexts are stored in the graphics server, and are identified by unique numbers in a way similar to window ids.  Your program must allocate graphic contexts, which then can be used in drawing functions.  A newly allocated graphics context is supplied with default parameters, such as a foreground color of white, drawing operation of setting, and width of 0. You can modify the parameters associated with the graphics context one by one, by for example, setting the foreground color to black.
A single graphics context could be used for every drawing operation by constantly setting the parameters associated with it to the values needed for each drawing call.  But this is inefficient.  The reason that multiple graphics contexts can be allocated is so that you can minimize the setting of their parameters.  By presetting the parameters of several graphics contexts to commonly used values in your program, you can avoid changing them later. For example, you can call one graphics context white_gc, and another graphics context black_gc, and then use the correct graphics context in the drawing functions to draw in either black or white.
The parameters contained within a graphics context are currently the following:
Drawing mode.
Specifies the operation performed when drawing each pixel.  One of:
        GR_MODE_SET     draw pixels as given (default)
        GR_MODE_XOR     draw pixels using XOR
        GR_MODE_OR      draw pixels using OR
        GR_MODE_AND     draw pixels using AND
Text font.
A small integer identifying the font for drawing text.  The first few are built-in to the device driver, others must be loaded by the graphics server. The default font is 0.
Foreground color.
The color that is used to draw almost all objects with, such as lines, points, ellipses, text, bitmaps, and filled areas.  Default is white.
Background color.
The color used for some functions in addition to the foreground color. For bitmaps and text, this is the color used for the zero bits.  The default background color is black.  The drawing of this color can be disabled by the next parameter.
UseBackground flag.
This is a boolean value which indicates whether or not the background color is actually to be drawn for bitmaps, text, and the GrArea8 function. The default is GR_TRUE.
EVENTS
Events are the way in which the graphics system notifies your program of asychronous changes in the state of the screen, mouse, or keyboard. Whenever the state changes, your program is notified of this change and can act on it.  The word "event" is used both for the actual change that took place, and also for the data that is returned to your program which describes the change.
Events are generated for various different types of changes that may be useful for your program to know.  Events directly related to the hardware are the keyboard and mouse events.  Keyboard events are generated for each key which is pressed (and released, if possible).  The event contains the character which caused the event.  Mouse events are generated when a button on the mouse is pressed or released, or when the mouse position moves.  The event contains the buttons which are pressed, and the current position of the mouse. Other events are more subtle, and are based on non-physical changes, such as having the mouse move into or out of specific windows.
Events are generally tied to individual windows.  Your program can enable or disable which kinds of events it wants for each window. Part of the data associated with an event is the window associated with the event.  For example, if a key is pressed on the keyboard, the event for that key will indicate which window that key is for.  You program can then act differently for different windows.  Events which you have not indicated an interest in
are simply discarded.
The keyboard and mouse events can propagate upwards through the window tree and be delivered to some parent window.  This occurs if the window does not select for the event, but one of the parent windows does. Part of the information returned about these events is the window that accepted the event, and also the original window which caused the event.  Therefore, your program can determine which child window an event was for without having to select for the event for each child.  Events other than keyboard and mouse events never propagate.
The window that keyboard events are delivered to depends on the current mouse position or on the "input focus".  The input focus is a way of specifying that keyboard events are to be delivered to a particular window, no matter where the mouse is currently pointing.  Your program can change the input focus as desired.  If the input focus is set to the root window, then the keyboard events will be delivered to the window which contains
the mouse pointer (or one of its parents).
Events are returned to your program as a structure containing the information about the event.  This information is the event type, the window id which the event is associated with, and other event-specific data.  Events are stored in a queue, and are delivered to your program one by one as requested. The order of the events is preserved.  Your program can either simply ask for the next available event (waiting for one if none are yet available), or it can check to see if an event is available without waiting.  The delivering of events only occurs when you request an event.  So even though events themselves are asychronous, the reading of them is synchronous. There are no "interrupts" for events, you must explicitly ask for them.
The important thing about programming with events is that your program should be written to run "upside-down".  That is, you do not have a main routine which checks that the mouse has been moved, or the keyboard has been typed on, or which window the mouse is in.  Instead, your main routine just waits for an event, and then dispatches on its type and which window it is for.  Generally, you must keep some state information to remember what is happening in your program.  For example, if the user wants to click the button in a window to indicate where some text should be inserted, then your program cannot simply detect the mouse click, and then wait for the text to be typed.  Instead, when the mouse is clicked, it should just remember the position of the mouse and set a flag to indicate that text typing is allowed,  When the keyboard event arrives, this saved information then enables you to draw the text at the correct location.  Your program basically becomes one large state machine.
One obscure event is the exposure event.  This is sent to your program when a window requires redrawing. Due to lack of memory space, the graphics server does not attempt to save the data from the parts of windows which are covered by other windows.  Therefore, when the obscured parts of the window are uncovered, your program must be told to redraw those parts.  The exposure event contains a rectangular area which requires drawing (which may in fact be larger than the area which was actually uncovered).  Your program can either just redraw that area, or if more convenient, redraw the whole window. The area to be redrawn has already been cleared to the window's background color.  When a window is mapped, an exposure event is sent for the window. Therefore, you should not explicitly draw into a window when it is first created and mapped, but should instead just wait for the exposure event, and then draw it.  In this way, the code to draw the window only resides in one place in your program, and you prevent redundant drawing of the window.
If you are drawing the complete window on all exposure events, then it might be useful to use GrPeekEvent to examine the next event too.  If it is also an exposure event for the same window, then you can read it by using GrGetNextEvent, and thereby prevent redundant redrawing.  Of course, to be able to redraw the window, you may need to save extra data in order to regenerate the drawing commands.  (Pixmaps are one way of doing this in the future, but they are not currently implemented.)
The following is a description of the various types of events which are available, and (in parenthesis) the typedef name for the structure that returns the event.  Each event has a type field, which can be used to distinguish between the various events.  For details on the other data within the structures, refer to graphics.h. The typedef GR_EVENT is a union which contains all of the possible event structures.
GR_EVENT_TYPE_NONE      (GR_EVENT)
        This indicates that no event has occurred.
GR_EVENT_TYPE_EXPOSURE  (GR_EVENT_EXPOSURE)
        This is generated when a window needs redrawing because it is either newly mapped, or has been uncovered by another window.  This returns the window id, and the x, y, width, and height of the area within the window which needs redrawing.
GR_EVENT_TYPE_BUTTON_DOWN       (GR_EVENT_BUTTON)
        This is generated when a button is pressed down on the mouse. This returns the window id which generated the event, the window id which actually contains the mouse, the current position of the mouse, the buttons which are currently down on the mouse, the buttons which were just pressed down, and the current modifier flags.
GR_EVENT_TYPE_BUTTON_UP         (GR_EVENT_BUTTON)
        This is generated when a button is released on the mouse.  This returns data similarly to button down.
GR_EVENT_TYPE_MOUSE_ENTER       (GR_EVENT_GENERAL)
        This is generated when the mouse enters a window.  This returns the window id which generated the event.
GR_EVENT_TYPE_MOUSE_EXIT        (GR_EVENT_GENERAL)
        This is generated when the mouse leaves a window.  This returns the window id which generated the event.
GR_EVENT_TYPE_MOUSE_MOTION      (GR_EVENT_MOUSE)
        Mouse motion is generated for every motion of the mouse, and is used to track the entire history of the mouse.  Mouse motion generates many events and causes lots of overhead.  This returns data similarly to mouse enter.
GR_EVENT_TYPE_MOUSE_POSITION    (GR_EVENT_MOUSE)
        Mouse position ignores the history of the motion, and only reports the latest position of the mouse by only queuing the latest such event for any single client (good for rubber-banding).  This returns data similarly to mouse enter.
GR_EVENT_TYPE_KEY_DOWN          (GR_EVENT_KEYSTROKE)
        This indicates that a key has been pressed on the keyboard. This returns the window id which generated the event, the window id which actually contains the pointer (if the pointer is outside of the event window, this will be the event window), the current position of the mouse, the current buttons on the mouse which are down, the current modifier flags, and the character which was typed.
GR_EVENT_TYPE_KEY_UP            (GR_EVENT_KEYSTROKE)
        This indicates that a key has been released on the keyboard.  This event is not necessarily available, and should not be depended on.This returns data similarly to key down.
GR_EVENT_TYPE_FOCUS_IN          (GR_EVENT_GENERAL)
        This indicates that the input focus has just changed to this window. This returns the window id which got focus.
GR_EVENT_TYPE_FOCUS_OUT         (GR_EVENT_GENERAL)
        This indicates that the input focus has just left this window. This returns the window id which lost focus.
To select for events, you use GrSelectEvents, and specify the window which wants to receive the events, and also specify a mask indicating the events you wish to receive.  The mask is the logical OR of individual bit values representing the event types.  The mask names are the same as the event names, except that the "_TYPE_" string is replaced by "_MASK_".  For example, the mask associated with the event GR_EVENT_TYPE_FOCUS_IN is
GR_EVENT_MASK_FOCUS_IN.
If you select for both button down and button up events, then the mouse will be implicitly "grabbed" when any button is pressed down in that window. This means that the mouse position and button down and up events will be delivered only to that window, and the cursor shape won't change, even if the mouse leaves that window.  The implicit grabbing ends after the last button is released.  While this grabbing occurs, the input focus is also
not changed as the mouse is moved.
MODIFIER AND MOUSE BUTTONS
Modifiers are the status of special keyboard shift-like keys.  The state of these keys can be read as up or down, and don't generate any characters by themselves.  These keys are for things like SHIFT, CTRL, and ALT.
They are returned as bit values OR'd together in various events.  Not all of these modifiers may be implemented.  The GrGetScreenInfo function returns the modifiers that are implemented.  The following modifiers are defined:
        GR_MODIFIER_SHIFT       shift key is down
        GR_MODIFIER_CTRL        ctrl key is down
        GR_MODIFIER_META        meta (or ALT) key is down
        GR_MODIFIER_ANY         any of the modifiers is down
The mouse button state are returned as bit values OR'd together in various events.  Not all of these buttons may be implemented.  The GrGetScreenInfo function returns the buttons that are implemented.  The following mouse buttons are defined:
        GR_BUTTON_1             button 1 is down (left)
        GR_BUTTON_2             button 2 is down (middle)
        GR_BUTTON_3             button 3 is down (right)
        GR_BUTTON_ANY           any of the buttons is down
BITMAPS
Bitmaps are defined as an array of GR_BITMAP values, which are unsigned shorts. Each word is 16 bits, which specify foreground and background values, with 1 being foreground and 0 being background.  Higher order bits in the word represent pixels to the left of the lower order bits.  Bitmaps have a width and a height, measured in pixels.  The width does not need to be a multiple of 16.  In this case, remaining bits in the last word of a row are unused, so that each row starts with a new bitmap word.  The GR_BITMAP_SIZE macro can be used to allocate the proper number of bitmap words for a bitmap, as in:
        GR_BITMAP_SIZE(width, height).
The symbol GR_MAX_BITMAP_SIZE is the number of bitmap words required for the maximum sized cursor.
ERROR CODES
Calls to the graphics libraries may produce errors.  Most errors that occur are due to specifying a window or graphics context which does not exist, or attempting an operation which is illegal.  Many things are allowed even if pointless, such as drawing outside of the window boundaries, or while a window is not mapped.  The things which return errors are those which definitely indicate a program bug, attempts to exceed the system limits, or a fatal device error.
In order to be as efficient as possible, error codes are not returned by individual function calls.  Instead, if a function fails, an error event is generated which will eventually be noticed by the program at a possibly much later time.  This allows many drawing requests to be sent at one time without having to worry about the status of each one.
Error events are detected when the program checks for events, such as by calling GrGetNextEvent.  At this point, if an error had occurred, a special error handler routine is called to notice the error.  If the program had not set up its own error handler, a default one is called which will disconnect from the server, print out an indication of the error, and exit the program.
The following is a list of the possible errors:
GR_ERROR_BAD_WINDOW_ID          the specified window id is unknown
GR_ERROR_BAD_GC_ID              the specified graphics context id is unknown
GR_ERROR_BAD_CURSOR_SIZE        the specified cursor is too large
GR_ERROR_MALLOC_FAILED          no more memory is available in the server
GR_ERROR_BAD_WINDOW_SIZE        the specified window size is illegal
GR_ERROR_KEYBOARD_ERROR         an error occurred reading from the keyboard
GR_ERROR_MOUSE_ERROR            an error occurred reading from the mouse
GR_ERROR_INPUT_ONLY_WINDOW      drawing was attempted in an input-only window
GR_ERROR_ILLEGAL_ON_ROOT_WINDOW an illegal operation was attempted on the root
GR_ERROR_TOO_MUCH_CLIPPING      complexity of windows exceeded clipping limits
GR_ERROR_SCREEN_ERROR           an error occurred talking to the screen driver
GR_ERROR_UNMAPPED_FOCUS_WINDOW  attempted to set focus to an unmapped window
GR_ERROR_BAD_DRAWING_MODE       illegal drawing mode specified for a GC
SCREEN PROPERTIES
You do not have to hard code the size of the screen or the number of colors available in your program.  Instead, you can find this information out dynamically after the connection is made to the graphics server, by using the GrGetScreenInfo call.  This returns the above information, and in addition returns the color values for black and white, the aspect ratio of pixels, the number of built-in fonts available, and the modifiers and buttons which are available.  The aspect ratio is useful for drawing objects which need to be scaled correctly, such as circles. The aspect ratio is the quotient of xdpcm and ydpcm, which are integer values.
typedef struct {
        GR_SIZE		rows;           /* number of rows on screen */
        GR_SIZE         	cols;           /* number of columns on screen */
        GR_SIZE         	xdpcm;          /* dots/centimeter in x direction */
        GR_SIZE         	ydpcm;          /* dots/centimeter in y direction */
        GR_COLOR        	maxcolor;       /* maximum legal color value */
        GR_COLOR        	black;          /* the color black */
        GR_COLOR        	white;          /* the color white */
        GR_COUNT        	fonts;          /* number of built-in fonts */
        GR_BUTTON       	buttons;        /* buttons which are implemented */
        GR_MODIFIER     	modifiers;      /* modifiers which are implemented */
} GR_SCREEN_INFO;
INCLUDE FILE AND GRAPHICS LIBRARY
To use the graphics server, your program must include "graphics.h". This should be put into /usr/include, so that your program simply has the following line at the top:
        #include <graphics.h>
Including this file gives you all of the definitions you need to use the graphics library.  These are the typedefs, function declarations, event structures, and various constants. When loading your program, you need to load the graphics server into the program by using the -lgraph option in the cc command.  For example, if your program is called myprog, then you could build it using the following:
        cc -o myprog myprog.c -lgraph
TYPEDEFS
The following is a list of the typedefs in the include file, and a short description of their purpose.  Refer to their definitions in graphics.h to find out what their actual C base type is.  Most are shorts, unsigned shorts, or longs.
GR_COORD        coordinate value (x, y locations, signed)
GR_SIZE         size value (widths, heights, signed)
GR_COUNT        number of items (signed)
GR_COLOR        full color value (32 bit value for full generality)
GR_COLOR8       eight bit color value (8 bit value for efficient storage)
GR_BITMAP       bitmap unit (single words of 16 bits for bitmaps)
GR_MODE         drawing mode (setting, xoring, anding, oring)
GR_CHAR         text character (normal chars)
GR_ID           resource ids (window, graphics context, pixmap)
GR_DRAW_ID      drawable id (window, pixmap)
GR_WINDOW_ID    window id (identifies individual window)
GR_PIXMAP_ID    pixmap id (identifies individual pixmaps, not yet used)
GR_GC_ID        graphics context id (identifies indiviual graphics contexts)
GR_FONT         font number (identifies individual fonts, first few built-in)
GR_BOOL         boolean value (GR_TRUE or GR_FALSE)
GR_FUNC         function codes (not for clients to use)
GR_ERROR        error value (reasons for graphics calls to fail)
GR_EVENT_TYPE   event types (identifies the type of event)
GR_BUTTON       button flags (which mouse buttons are depressed)
GR_MODIFIER     modifier flags (CTRL, SHIFT, etc)
GR_EVENT_MASK   event masks (mask values corresponding to event types)
GR_FUNC_NAME    function name (for error reporting)
GR_ERROR_FUNC   error function (for defining error handlers)
The following typedefs may be useful to your program.  None of the library functions (currently) accept any of these structures as arguments, except for the GrPoly and GrFillPoly routines, which use GR_POINT.
typedef struct {
        GR_COORD        x;              /* x coordinate */
        GR_COORD        y;              /* y coordinate */
} GR_POINT;
typedef struct {
        GR_COORD        x1;             /* x coordinate of first point */
        GR_COORD        y1;             /* y coordinate of first point */
        GR_COORD        x2;             /* x coordinate of second point */
        GR_COORD        y2;             /* y coordinate of second point */
} GR_LINE;
typedef struct {
        GR_COORD        x;              /* x coordinate of center */
        GR_COORD        y;              /* y coordinate of center */
        GR_SIZE         rx;             /* radius in x direction */
        GR_SIZE         ry;             /* radius in y direction */
} GR_ELLIPSE;
typedef struct {
        GR_COORD        x;              /* x coordinate of top left corner */
        GR_COORD        y;              /* y coordinate of top left corner */
        GR_SIZE         width;          /* width of rectangle */
        GR_SIZE         height;         /* height of rectangle */
} GR_RECT;
LIMITS
The coordinate system is limited to integers in the range GR_COORD_MIN to GR_COORD_MAX.  This is -32768 to 32767, and fits in a short. The maximum size of a cursor definition is GR_MAX_CURSOR_SIZE, which is 16 pixels by 16 pixels.
The complexity of overlapping windows is limited to GR_MAX_CLIPRECTS regions, which is 200.  Each window which overlaps another requires another 1 to 4 regions depending on its position and size.
GRAPHICS CALLS 
int GrOpen()
Open a connection to the graphics server.  This must be the first graphics function used by your program. Currently, this sets the screen into graphics mode.  Returns zero if successful, -1 on failure.
void GrClose()
Close the connection to the graphics server, first flushing any graphics calls that have been buffered.  Currently, this sets the screen back into text mode.  This (currently) should be called before your program exits, otherwise the screen will be left in graphics mode.  If this occurs, you can run the 'tm' program to reset the terminal to text mode.
GR_ERROR_FUNC GrSetErrorHandler(func)
        GR_ERROR_FUNC   func;           /* function to handle errors */
Set an error handling routine, which will be called on any errors from the server (when events are asked for by the client).  If zero is given, then a default routine will be used which will describe the error and exit. Returns the previous error handler (0 if none).  When an error occurs, the error handling function is called with the following parameters: GR_ERROR, GR_FUNC_NAME, and GR_ID.  These are the error code, the name of the function which failed, and a resource id (0 if not meaningful). The error routine can return if desired, but without corrective action new errors will probably occur soon.
void GrGetScreenInfo(sip)
        GR_SCREEN_INFO  *sip;           /* location to return info into */
Return useful information about the screen.  This information returned has been documented above.
void GrGetFontInfo(font, fip)
        GR_FONT         	font;           /* font number */
        GR_FONT_INFO    *fip;           /* address of font info */
Return useful information about the specified font number.  This information is the font number, the height of the font, the maximum width of any character in the font, the height of the baseline, a flag indicating whether or not the font is fixed-width, and a table of the individual widths of each character in the font.  If the font is unknown, the returned font number is set to zero and the remainder of the information is undefined.  Refer to graphics.h for a definition of the fields of GR_FONT_INFO.
void GrGetGCInfo(gc, gcip)
        GR_GC_ID        gc;             /* graphics context */
        GR_GC_INFO      *gcip;          /* address of graphics context info */
Return useful information about the specified graphics context.  This information is the graphics context id, the current font, the foreground and background colors, and so on.  If the graphics context is unknown, the returned id is 0, and the other information is undefined.  Refer to graphics.h for a definition of the fields of GR_GC_INFO.
voidGrGetGCTextSize(gc, cp, len, retwidth, retheight, retbase)
        GR_GC_ID        gc;             /* graphics context containing font */
        GR_CHAR         *cp;            /* address of text string */
        GR_SIZE         len;            /* length of text string */
        GR_SIZE         *retwidth;      /* returned width of string */
        GR_SIZE         *retheight;     /* returned height of string */
        GR_SIZE         *retbase;       /* returned height of baseline */
Return the size of a text string for the font in a graphics context. This is the width of the string, the height of the string, and the height above the bottom of the font of the baseline for the font.  The returned sizes are in pixels.
void GrGetNextEvent(ep)
        GR_EVENT        *ep;            /* address where event is returned */
Return the next event from the event queue, waiting for it if necessary. If a graphics error had occurred, the error handler will be called at this point.  This routine first flushes any buffered graphics commands.  The GR_EVENT is a union of all the possible events.  The type field of the union indicates which of the possible events took place, and then the correct element of the union can be used to access that particular event type's data.
void GrCheckNextEvent(ep)
        GR_EVENT        *ep;            /* address where event is returned */
Return the next event from the event queue if one is ready. If one is not ready, then the event type GR_EVENT_TYPE_NONE is returned. Therefore, this routine never blocks.  This routine first flushes any buffered graphics commands.
void GrPeekEvent(ep)
        GR_EVENT        *ep;            /* address where event is returned */
Return the next event from the event queue if one is ready, without removing it from the queue.  If one is not ready, then the type GR_EVENT_TYPE_NONE is returned.  This routine never blocks.  This routine first flushes any buffered graphics commands.
void GrSelectEvents(wid, eventmask)
        GR_WINDOW_ID    wid;            /* window id */
        GR_EVENT_MASK   eventmask;      /* mask of events wanted */
Select events for a window for this client.  The events are a bitmask specifying the events desired for this window.  This totally replaces any previously selected event mask for the window.
GR_WINDOW_ID GrNewWindow(parent, x, y, width, height, bordersize, background, bordercolor)
        GR_WINDOW_ID    parent;         /* parent id */
        GR_COORD        x;              /* x position relative to parent */
        GR_COORD        y;              /* y position relative to parent */
        GR_SIZE         width;          /* width */
        GR_SIZE         height;         /* height */
        GR_SIZE         bordersize;     /* size of border */
        GR_COLOR        background;     /* background color */
        GR_COLOR        bordercolor;    /* border color */
Allocate a new input-output window which is a child of the specified window. A new top-level window is made by specifying a parent of GR_ROOT_WINDOW_ID. The x and y position is the upper left corner of the window, relative to the parent's upper left corner.  These corners are only for the drawable area of the windows, so that the border does not affect the position.  An input-output window cannot be made as a child of an input-only window.  The new window starts off unmapped, and must be mapped before it can be seen. The new window inherits the cursor of the parent window, and initially is set to select no events.  This routine returns the window id of the window which can be used in other calls.
GR_WINDOW_ID GrNewInputWindow(parent, x, y, width, height)
        GR_WINDOW_ID    parent;         /* parent id */
        GR_COORD        x;              /* x position relative to parent */
        GR_COORD        y;              /* y position relative to parent */
        GR_SIZE         width;          /* width */
        GR_SIZE         height;         /* height */
Allocate a new input-only window which is a child of the specified window. An input-only window is invisible, and cannot be drawn into.  It's only purposes are that it can select events, and can have it's own cursor.  The new window starts off unmapped, and must be mapped before it is effective. The new window inherits the cursor of the parent window, and initially is set to select no events.  This routine returns the window id of the window which can be used in other calls.
void GrDestroyWindow(wid)
        GR_WINDOW_ID    wid;            /* window to destroy */
This unmaps and then destroys the specified window, and all of its children. The root window cannot be destroyed.  After destroying a window, you must be careful about handling events which refer to the dead window, but which have not been read yet.
void GrGetWindowInfo(wid, wip)
        GR_WINDOW_ID    wid;            /* window id to find out about */
        GR_WINDOW_INFO  *wip;           /* location to return info into */
Return useful information about the specified window.  Refer to the graphics.h include file for the definition of GR_WINDOW_INFO to see what data is returned.  If the window id is not valid, an error is NOT generated. Instead, the wid value in the returned structure is set to zero, and the other fields are not defined.
GR_GC_ID GrNewGC()
Allocate a new graphics context with default parameters.  These defaults are: background of black, foreground of white, font as font 0, and drawing mode as setting.  This routine returns the id for the graphics context which can be used in other calls.
GR_GC_ID GrCopyGC(gc)
        GR_GC_ID        gc;             /* graphics context to copy */
Allocate a new graphics context which is a copy of another one.  The new graphics context has the same parameter values as the old one, but is then independent.  This routine returns the id for the graphics context which can be used in other calls.
void GrDestroyGC(gc)
        GR_GC_ID        gc;             /* graphics context to destroy */
Destroy an existing graphics context.
void GrMapWindow(wid)
        GR_WINDOW_ID    wid;            /* window to be mapped */
Map the window to make it (and possibly its children) visible on the screen. This paints the border and background of the window, and creates an exposure event to tell the client to draw into it.
void GrUnmapWindow(wid)
        GR_WINDOW_ID    wid;            /* window to be unmapped */
Unmap the window to make it and its children invisible on the screen.
void GrRaiseWindow(wid)
        GR_WINDOW_ID    wid;            /* window to be raised */
Raise the window to the highest level among its siblings.  This means that this window will be visible in preference to those siblings.  Siblings are windows which have the same parent as this window.
void GrLowerWindow(wid)
        GR_WINDOW_ID    wid;            /* window to be lowered */
Lower the window to the lowest level among its siblings.  This means that this window will be covered by any siblings which overlap it. 
void GrMoveWindow(wid, x, y)
        GR_WINDOW_ID    wid;            /* window to be lowered */
        GR_COORD        x;              /* new relative x position */
        GR_COORD        y;              /* new relative y position */
Move the window to the specified position relative to its parent.
void GrResizeWindow(wid, width, height)
        GR_WINDOW_ID    wid;            /* window to be lowered */
        GR_SIZE         width;          /* new width of window */
        GR_SIZE         height;         /* new height of window */
Resize the window to be the specified size.  Resizing of a window can generate exposure events.
void GrClearWindow(wid, exposeflag)
        GR_WINDOW_ID    wid;            /* window id */
        GR_BOOL         exposeflag;     /* nonzero to cause an exposure */
Clear the specified window by setting it to its background color. If the exposeflag is nonzero, then this also creates an exposure event for the window.
void GrSetFocus(wid)
        GR_WINDOW_ID    wid;            /* window id */
Set the focus to a particular window.  This makes keyboard events only visible to that window or children of it, depending on the pointer location. Setting the focus window to the root window makes the input focus track the pointer (which is the default).
void GrSetBorderColor(wid, color)
        GR_WINDOW_ID    wid;            /* window id */
        GR_COLOR        color;          /* color for border */
Set the border of a window to the specified color.
void GrSetCursor(wid, width, height, hotx, hoty, foreground, background,
        fgbitmap, bgbitmap)
        GR_WINDOW_ID    wid;            /* window id to set cursor for */
        GR_SIZE         width;          /* width of cursor */
        GR_SIZE         height;         /* height of cursor */
        GR_COORD        hotx;           /* relative x position of hot spot */
        GR_COORD        hoty;           /* relative y position of hot spot */
        GR_COLOR        foreground;     /* foreground color of cursor */
        GR_COLOR        background;     /* background color of cursor */
        GR_BITMAP       *fgbitmap;      /* foreground bitmap */
        GR_BITMAP       *bgbitmap;      /* background bitmap */
Specify a new cursor for a window.  This cursor will only be used within that window, and by default for its new children.  The cursor is defined by giving its width and height, its foreground and background colors, its foreground and background bitmaps, and its "hot spot" position.  If a pixel is specified for both the foreground and background bitmaps, then the foreground has precedence.  The hot spot is an offset from the upper left corner of the bitmap, and is the location in the cursor which is important.
void GrMoveCursor(x, y)
        GR_COORD        x;              /* new x position of cursor */
        GR_COORD        y;              /* new y position of cursor */
Move the cursor to the specified absolute screen coordinates. The coordinates are that of the defined hot spot of the cursor. The cursor's appearance is changed to that defined for the window in which the cursor is moved to.
void GrFlush()
Flush the graphics buffer so that all previous requests will be executed. This is only needed if you do not check events quickly and want to see the results on the screen soon, since checking for events does an automatic flush.
void GrSetGCForeground(gc, foreground)
        GR_GC_ID        gc;             /* graphics context id */
        GR_COLOR        foreground;     /* foreground color */
Set the foreground color in a graphics context.  The default is white.
void GrSetGCBackground(gc, background)
        GR_GC_ID        gc;             /* graphics context id */
        GR_COLOR        background;     /* background color */
Set the background color in a graphics context.  The default is black.
void GrSetGCUseBackground(gc, flag)
        GR_GC_ID        gc;             /* graphics context id */
        GR_BOOL         flag;           /* TRUE if background is drawn */
Set whether or not the background color is drawn in bitmaps and text. This affects GrBitmap, GrArea8, and GrText.  The default is GR_TRUE.
void GrSetGCMode(gc, mode)
        GR_GC_ID        gc;             /* graphics context id */
        GR_MODE         mode;           /* drawing mode */
Set the drawing mode in a graphics context.  The drawing mode is one of GR_MODE_SET, GR_MODE_XOR, GR_MODE_AND, or GR_MODE_OR.  The default is GR_MODE_SET.
void GrSetGCFont(gc, font)
        GR_GC_ID        gc;             /* graphics context id */
        GR_FONT         font;           /* text font */
Set the font used for text drawing in a graphics context. The font is a number identifying one of several fonts.
Font number 0 is always available, and is the default font.
void GrLine(id, gc, x1, y1, x2, y2)
        GR_DRAW_ID      id;
        GR_GC_ID        gc;
        GR_COORD        x1;
        GR_COORD        y1;
        GR_COORD        x2;
        GR_COORD        y2;
Draw a line in the specified drawable using the specified graphics context.
void GrRect(id, gc, x, y, width, height)
        GR_DRAW_ID      id;
        GR_GC_ID        gc;
        GR_COORD        x;
        GR_COORD        y;
        GR_SIZE         width;
        GR_SIZE         height;
Draw the boundary of a rectangle in the specified drawable using the specified graphics context.
void GrFillRect(id, gc, x, y, width, height)
        GR_DRAW_ID      id;
        GR_GC_ID        gc;
        GR_COORD        x;
        GR_COORD        y;
        GR_SIZE         width;
        GR_SIZE         height;
Fill a rectangle in the specified drawable using the specified graphics context.  The boundary of this rectangle is identical to that drawn by the GrRect function.
void GrEllipse(id, gc, x, y, rx, ry)
        GR_DRAW_ID      id;
        GR_GC_ID        gc;
        GR_COORD        x;
        GR_COORD        y;
        GR_SIZE         rx;
        GR_SIZE         ry;
Draw the boundary of an ellipse in the specified drawable with the specified graphics context.
void GrFillEllipse(id, gc, x, y, rx, ry)
        GR_DRAW_ID      id;
        GR_GC_ID        gc;
        GR_COORD        x;
        GR_COORD        y;
        GR_SIZE         rx;
        GR_SIZE         ry;
Fill an ellipse in the specified drawable using the specified graphics context.
void GrBitmap(id, gc, x, y, width, height, bitmaptable)
        GR_DRAW_ID      id;
        GR_GC_ID        gc;
        GR_COORD        x;
        GR_COORD        y;
        GR_SIZE         width;
        GR_SIZE         height;
        GR_BITMAP       *bitmaptable;
Draw a rectangular area in the specified drawable using the specified graphics context, as determined by the specified bit map.  This differs from rectangle drawing in that the rectangle is drawn using the foreground
color and possibly the background color as determined by the bit map. Bits which are 1 are the foreground, and bits which are 0 are the background. Each row of bits is aligned to the next bitmap word boundary (so there can
be padding at the end of each row).  The background bit values are only written if the usebackground flag is set in the GC.
void GrArea8(id, gc, x, y, width, height, colortable)
        GR_DRAW_ID      id;
        GR_GC_ID        gc;
        GR_COORD        x;
        GR_COORD        y;
        GR_SIZE         width;
        GR_SIZE         height;
        GR_COLOR8       *colortable;
Draw a rectangular area in the specified drawable using the specified graphics context.  This differs from rectangle drawing in that the color values for each pixel in the rectangle are specified.  The color values are estricted to 8 bit values.  The color table is indexed row by row from left to right.  Table values whose color matches the background color are only written if the usebackground flag is set in the GC.
void GrReadArea8(id, x, y, width, height, colortable)
        GR_DRAW_ID      id;
        GR_COORD        x;
        GR_COORD        y;
        GR_SIZE         width;
        GR_SIZE         height;
        GR_COLOR8       *colortable;
Read the color values from the specified rectangular area of the specified drawable into a supplied buffer.  If the drawable is a window which is obscured by other windows, then the returned values will include the values
from the covering windows.  Regions outside of the screen boundaries, or from unmapped windows will return black.
void GrPoint(id, gc, x, y)
        GR_DRAW_ID      id;
        GR_GC_ID        gc;
        GR_COORD        x;
        GR_COORD        y;
Draw a point in the specified drawable using the specified graphics context.
void GrPoly(id, gc, count, pointtable)
        GR_DRAW_ID      id;
        GR_GC_ID        gc;
        GR_COUNT        count;
        GR_POINT        *pointtable;
Draw a polygon in the specified drawable using the specified graphics context.  The polygon is only complete if the first point is repeated at the end.  Note: currently if the polygon crosses itself, and the drawing mode is set to XOR, then the individual line segments will affect each other.  The endpoints of the lines are correct, however.
void GrFillPoly(id, gc, count, pointtable)
        GR_DRAW_ID      id;
        GR_GC_ID        gc;
        GR_COUNT        count;
        GR_POINT        *pointtable;
Draw a filled polygon in the specified drawable using the specified graphics context.  The last point may be a duplicate of the first point, but this is not required.  Note: currently only convex polygons are filled properly.
void GrText(id, gc, x, y, str, count)
        GR_DRAW_ID      id;
        GR_GC_ID        gc;
        GR_COORD        x;
        GR_COORD        y;
        GR_CHAR         *str;
        GR_COUNT        count;
Draw a text string at the specified location in the specified drawable using the specified graphics context.  The background of the characters are only drawn if the usebackground flag in the GC is set. 
EXAMPLE PROGRAM
The following simple program opens the graphics, creates a window, prints some text in it, waits for the mouse to be clicked in the window, then exits.
#include <stdio.h>
#include <graphics.h>
#define MARGIN  50                      /* margin around window */
main()
{
        GR_WINDOW_ID    wid;            /* window id */
        GR_GC_ID        gc;             /* graphics context id */
        GR_EVENT        event;          /* current event */
        GR_SCREEN_INFO  si;             /* screen information */
        if (GrOpen() < 0) {
                fprintf(stderr, "Cannot open graphics\n");
                exit(1);
        }
        GrGetScreenInfo(&si);
        wid = GrNewWindow(GR_ROOT_WINDOW_ID, MARGIN, MARGIN,
                si.cols - MARGIN * 2, si.rows - MARGIN * 2,
                1, si.black, si.white);
        GrSelectEvents(wid, GR_EVENT_MASK_BUTTON_DOWN | GR_EVENT_MASK_EXPOSURE);
        GrMapWindow(wid);
        gc = GrNewGC();
        while (1) {
                GrGetNextEvent(&event);
                switch (event.type) {
                        case GR_EVENT_TYPE_BUTTON_DOWN:
                                if (event.button.wid != wid)
                                        break;
                                GrClose();
                                exit(0);
                        case GR_EVENT_TYPE_EXPOSURE:
                                if (event.exposure.wid == wid)
                                        GrText(wid, gc, 50, 50, "EXIT", 4);
                                break;
                }
        }
}
For a more complete demonstration program, see the file "demo.c" in the
microwin/src/demos/nanox directory.
Mohanavadivelu (talk) 04:31, 22 July 2010 (UTC)
replies: text: How does this apply to the content of this page? MBisanz talk 04:36, 22 July 2010 (UTC)
thread_title:  Nano-x API