<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Another approach to recursive permissions</title>
	<link>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/</link>
	<description>Just another GNOME Blogs weblog</description>
	<pubDate>Sat, 30 Aug 2008 13:09:58 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
		<item>
		<title>By: Ken</title>
		<link>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-59</link>
		<dc:creator>Ken</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-59</guid>
		<description>First, I agree that getting rid of the grid-o-checkboxes is a good thing.  And that dealing with permissions for files and folders at the same time is probably icky.  But I think (and I'm going to get lumped in with "usability experts" here) the simple/advanced thing is a bad idea, because the advanced version still offers things that don't even make sense to me.&lt;p/&gt;Now, in the same vein as &lt;a href="http://log.ometer.com/2005-08.html#10"&gt;Havoc's lightbulb joke&lt;/a&gt;, I question the need to solve "Joe Doe downloads a binary and wants to make it executable".&lt;p/&gt;If Joe Doe downloaded a program, and has used Windows or a Mac at all (or even Linux with a decent distribution), he won't know why the program won't run, or that he has to "make it executable".  Why isn't the correct answer to this "Let's create first-class applications, so Joe doesn't *need* to do something as silly as 'make it executable'"?  (I know to do this, but that doesn't mean I like doing it.)&lt;p/&gt;Showing "Execute" as a type of "Access" is just dumb.  I've used Unix for most of my life, I know why it's there, but that doesn't make it any less dumb.&lt;p/&gt;I don't want to sound disapproving.  There's good ideas here and overall this design is *much* better than what Gnome has today.  Keep it up!</description>
		<content:encoded><![CDATA[<p>First, I agree that getting rid of the grid-o-checkboxes is a good thing.  And that dealing with permissions for files and folders at the same time is probably icky.  But I think (and I&#8217;m going to get lumped in with &#8220;usability experts&#8221; here) the simple/advanced thing is a bad idea, because the advanced version still offers things that don&#8217;t even make sense to me.
<p />Now, in the same vein as <a href="http://log.ometer.com/2005-08.html#10">Havoc&#8217;s lightbulb joke</a>, I question the need to solve &#8220;Joe Doe downloads a binary and wants to make it executable&#8221;.
<p />If Joe Doe downloaded a program, and has used Windows or a Mac at all (or even Linux with a decent distribution), he won&#8217;t know why the program won&#8217;t run, or that he has to &#8220;make it executable&#8221;.  Why isn&#8217;t the correct answer to this &#8220;Let&#8217;s create first-class applications, so Joe doesn&#8217;t *need* to do something as silly as &#8216;make it executable&#8217;&#8221;?  (I know to do this, but that doesn&#8217;t mean I like doing it.)
<p />Showing &#8220;Execute&#8221; as a type of &#8220;Access&#8221; is just dumb.  I&#8217;ve used Unix for most of my life, I know why it&#8217;s there, but that doesn&#8217;t make it any less dumb.
<p />I don&#8217;t want to sound disapproving.  There&#8217;s good ideas here and overall this design is *much* better than what Gnome has today.  Keep it up!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ryan</title>
		<link>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-60</link>
		<dc:creator>ryan</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-60</guid>
		<description>I like the basic screen, it handles 90% of use cases. I also agree that a details dialogue is needed (if only to accomodate later things like extended attibutes), but splitting between "cvs and subdirs" and "files in cvs and subdirs" makes the dialogue very busy and rather ugly (sry).&lt;p/&gt;The whole purpose of having a commandline interface is that some operations (usually the complex ones) are easiest to express in words. Trying to get a gui dialogue to cover the last 0.1% of use cases is not worth the effort.&lt;p/&gt;However if you have your heart set on it, can I recommend you replace the two grids with one, and add a combo that says "Apply to: (1) cvs and subdirs (2) files in cvs and subdirs" which makes the dialogue represent an action of the files/dirs instead of the current state of the files/dirs.</description>
		<content:encoded><![CDATA[<p>I like the basic screen, it handles 90% of use cases. I also agree that a details dialogue is needed (if only to accomodate later things like extended attibutes), but splitting between &#8220;cvs and subdirs&#8221; and &#8220;files in cvs and subdirs&#8221; makes the dialogue very busy and rather ugly (sry).
<p />The whole purpose of having a commandline interface is that some operations (usually the complex ones) are easiest to express in words. Trying to get a gui dialogue to cover the last 0.1% of use cases is not worth the effort.
<p />However if you have your heart set on it, can I recommend you replace the two grids with one, and add a combo that says &#8220;Apply to: (1) cvs and subdirs (2) files in cvs and subdirs&#8221; which makes the dialogue represent an action of the files/dirs instead of the current state of the files/dirs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: cendrizzi</title>
		<link>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-61</link>
		<dc:creator>cendrizzi</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-61</guid>
		<description>Great work, this really is a huge improvement over what currently exists.  I can't wait to see this in gnome.&lt;p/&gt;As for the example on joe doe downloading a binary, I totally agree with Ken, joe doe should never have to go in to set the permissions for something like this.  However this isn't your issue, as this needs to be resolved seperatley (I think).  It's just too bad you have to include execute since it won't make a lot of sense to anyone except those who understand *nix file permissions.</description>
		<content:encoded><![CDATA[<p>Great work, this really is a huge improvement over what currently exists.  I can&#8217;t wait to see this in gnome.
<p />As for the example on joe doe downloading a binary, I totally agree with Ken, joe doe should never have to go in to set the permissions for something like this.  However this isn&#8217;t your issue, as this needs to be resolved seperatley (I think).  It&#8217;s just too bad you have to include execute since it won&#8217;t make a lot of sense to anyone except those who understand *nix file permissions.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peteris Krisjanis</title>
		<link>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-62</link>
		<dc:creator>Peteris Krisjanis</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-62</guid>
		<description>First, I really love that someone took its time and rethought permissions dialog, because well, it needs serious upgrade. &lt;p/&gt;But I like to point out that current mockups looks some how frustrating and confusing to me and I would like to see less drop down boxes. My pick is that simple user will NEVER need to mess with permissions. So if basic is such confusing, I better suggest in default regime to just to SHOW permissions. Because well, give a thought to situation when casual user just messes with preferences dialog and changes accidentaly some permissions to file. Any error messages, warnings would be confusing to him, so I suggest to get rid of possibility to change owners and permissions and put a button "change owner &#038; settings" or something like that. &lt;p/&gt;I am not good in mockups, in fact, I never have done them for GNOME apps, but I will try to create some and get them attached to bug.</description>
		<content:encoded><![CDATA[<p>First, I really love that someone took its time and rethought permissions dialog, because well, it needs serious upgrade.
<p />But I like to point out that current mockups looks some how frustrating and confusing to me and I would like to see less drop down boxes. My pick is that simple user will NEVER need to mess with permissions. So if basic is such confusing, I better suggest in default regime to just to SHOW permissions. Because well, give a thought to situation when casual user just messes with preferences dialog and changes accidentaly some permissions to file. Any error messages, warnings would be confusing to him, so I suggest to get rid of possibility to change owners and permissions and put a button &#8220;change owner &#038; settings&#8221; or something like that.
<p />I am not good in mockups, in fact, I never have done them for GNOME apps, but I will try to create some and get them attached to bug.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marius Gedminas</title>
		<link>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-63</link>
		<dc:creator>Marius Gedminas</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-63</guid>
		<description>Looks nice.  Well, the details dialog is a bit biggish, and I don't see how I could express "please remove write permissions recursively, but leave read/execute permissions untouched".&lt;br/&gt;</description>
		<content:encoded><![CDATA[<p>Looks nice.  Well, the details dialog is a bit biggish, and I don&#8217;t see how I could express &#8220;please remove write permissions recursively, but leave read/execute permissions untouched&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Christian Neumair</title>
		<link>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-64</link>
		<dc:creator>Christian Neumair</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-64</guid>
		<description>Marius: You toggle the "Write" checkboxes of both sections in "Details" so that they're off and press "Apply".&lt;p/&gt;Another weakness of my proposed dialog is that it does not yet offer a non-recursive permission change, but this should be easily doable with an additional checkbutton.&lt;p/&gt;Maybe I should drop the whole "Details" approach and replace it by a *real* chmod GUI, i.e. an entry with some helpful suggestions and tooltips, parsing the user's input?&lt;p/&gt;&lt;a href="http://www.advogato.org/person/Manny"&gt;http://www.advogato.org/person/Manny&lt;/a&gt;</description>
		<content:encoded><![CDATA[<p>Marius: You toggle the &#8220;Write&#8221; checkboxes of both sections in &#8220;Details&#8221; so that they&#8217;re off and press &#8220;Apply&#8221;.
<p />Another weakness of my proposed dialog is that it does not yet offer a non-recursive permission change, but this should be easily doable with an additional checkbutton.
<p />Maybe I should drop the whole &#8220;Details&#8221; approach and replace it by a *real* chmod GUI, i.e. an entry with some helpful suggestions and tooltips, parsing the user&#8217;s input?
<p /><a href="http://www.advogato.org/person/Manny">http://www.advogato.org/person/Manny</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thiago Sayão</title>
		<link>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-65</link>
		<dc:creator>Thiago Sayão</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-65</guid>
		<description>I don't like it. It's a little confusing, you have to stop and think about what are you doing. You have to actually stop, look at the screen and try to understand the combinations. The difference between the top and the bottom of the details screen is not very visually clear. I would not use it, because it's easier to just fire gnome-terminal and type it. A user would not use it too because it's too confusing. I don't like the selection boxes, i think it would be better if you change it with checkboxes. I think the current approach is nice, it just have to have a way to recursively apply the permissions or to only apply for the selected contents. One idea is to verify the user selection, folowing the cases:&lt;br/&gt;1 - The user selected just a folder, a dialog would pop up and ask if he wants to recursively apply to it's children.&lt;br/&gt;2 - The user selected just a file, no popup is shown.&lt;br/&gt;3 - The user selected file and folders, just do like 1.&lt;p/&gt;The label "Number view" should just say "Octal".. an stupid user would not know how to read the number anyway.. and a advanced user, like Linus for example would think this label is just stupid.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t like it. It&#8217;s a little confusing, you have to stop and think about what are you doing. You have to actually stop, look at the screen and try to understand the combinations. The difference between the top and the bottom of the details screen is not very visually clear. I would not use it, because it&#8217;s easier to just fire gnome-terminal and type it. A user would not use it too because it&#8217;s too confusing. I don&#8217;t like the selection boxes, i think it would be better if you change it with checkboxes. I think the current approach is nice, it just have to have a way to recursively apply the permissions or to only apply for the selected contents. One idea is to verify the user selection, folowing the cases:<br />1 - The user selected just a folder, a dialog would pop up and ask if he wants to recursively apply to it&#8217;s children.<br />2 - The user selected just a file, no popup is shown.<br />3 - The user selected file and folders, just do like 1.
<p />The label &#8220;Number view&#8221; should just say &#8220;Octal&#8221;.. an stupid user would not know how to read the number anyway.. and a advanced user, like Linus for example would think this label is just stupid.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thiago Sayão</title>
		<link>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-66</link>
		<dc:creator>Thiago Sayão</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-66</guid>
		<description>Complementing, the recursive function is not suitable for the Details screen (read Advanced screen) because a normal user would want to do it but would not understand the Details screen. An advanced user would think the details screen is just stupid and would use the terminal. So, this approach is not good for any type of user. The first screen should suit the "stupid" user, and the details should suit the "kernel hacker" :)</description>
		<content:encoded><![CDATA[<p>Complementing, the recursive function is not suitable for the Details screen (read Advanced screen) because a normal user would want to do it but would not understand the Details screen. An advanced user would think the details screen is just stupid and would use the terminal. So, this approach is not good for any type of user. The first screen should suit the &#8220;stupid&#8221; user, and the details should suit the &#8220;kernel hacker&#8221; <img src='http://blogs.gnome.org/cneumair/wp-content/mu-plugins/tango-smilies/face-smile.png' alt=':)' class='wp-smiley' width='16' height='16' /></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-67</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-67</guid>
		<description>To me this seems pretty usable, much better then the previous version.</description>
		<content:encoded><![CDATA[<p>To me this seems pretty usable, much better then the previous version.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: stefan</title>
		<link>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-68</link>
		<dc:creator>stefan</dc:creator>
		<pubDate>Tue, 30 Nov 1999 00:00:00 +0000</pubDate>
		<guid>http://blogs.gnome.org/cneumair/2005/12/28/another-approach-to-recursive-permissions/#comment-68</guid>
		<description>I don't think "none" makes sense as an option for the owner's rights. As a regular user you'd at least want to be able to read your own files :-)&lt;p/&gt;What about making the labels more verbose? "read only" (instead of "read"), "readable and writable" (read, write) or even "opening and saving".&lt;br/&gt;What about "Everyone else" instead of "others"? (okay, that's nitpicking :-) I like the basic dialog very much)&lt;p/&gt;Also, AFAIK OSX doesn't have the executable bit in the file properties. Why's that? Can someone shed some light on it?&lt;br/&gt;</description>
		<content:encoded><![CDATA[<p>I don&#8217;t think &#8220;none&#8221; makes sense as an option for the owner&#8217;s rights. As a regular user you&#8217;d at least want to be able to read your own files <img src='http://blogs.gnome.org/cneumair/wp-content/mu-plugins/tango-smilies/face-smile.png' alt=':-)' class='wp-smiley' width='16' height='16' />
<p />What about making the labels more verbose? &#8220;read only&#8221; (instead of &#8220;read&#8221;), &#8220;readable and writable&#8221; (read, write) or even &#8220;opening and saving&#8221;.<br />What about &#8220;Everyone else&#8221; instead of &#8220;others&#8221;? (okay, that&#8217;s nitpicking <img src='http://blogs.gnome.org/cneumair/wp-content/mu-plugins/tango-smilies/face-smile.png' alt=':-)' class='wp-smiley' width='16' height='16' /> I like the basic dialog very much)
<p />Also, AFAIK OSX doesn&#8217;t have the executable bit in the file properties. Why&#8217;s that? Can someone shed some light on it?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
