Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Re: flogged!

Originally posted by avkills
install/uninstall is pointless in OS X since all the information about the app is stored in one file except user preferences. Preferences are stored under the "/Users/username/library/preferences". OS X apps do not spread DLLs

Well, besides ~/Library/Preferences it seems like it has been a long time since you looked at folders such as

/Library/StartupItems/
~/Library/StartupItems/
/Library/Application Support/
~/Library/Application Support/
~/Library/Preferences/loginwindow.plist

Excluding applications that create their preferences/user data in none of the folders above, such as

/Library/Mail/
~/Library/Mail/
/Library/Mozilla/
~/Library/Folding@home/

And excluding, of course, the applications that after granting them root access install items inside the /System/ folder, such as Norton or whatever other, or, better, in hidden Unix folders such as /usr/local/bin/, in which case prepare to unwrap your fingers for Terminal use or reach some third party app.

Admittedly, applications' traces are much more localizable than in whatever flavor of Windows, but still OS X made a headache of what in OS 9 was a breeze.

I appreciate apps such as PGP which include an "Uninstall" option in their application's menu. If that option in that particluar app is efficient or not, I do not know, since I have not feel the need to use it so far. But in any case it is a good idea.
 
Re: Re: Re: Actually. . .

Originally posted by Wry Cooter
I have trouble considering this a legitimate complaint. There is no individual column resizing, but after all, one is merely saving a document. The columns do resize as a group... you can grab the corner of the save dialog 'sheet' to widen the finder view. The columns seemed to be based on the width of the file names. All visible columns widen until another column the same width as the original can pop in... 3 column view... 4... 5 column view, and so on.

Actually, no, the column width is not based on the width of the longest folder name (I have some long folder names which come from the same code base being used cross-platform, and no matter how wide I make the dialog box the columns "pop" back down to size before I can see the full folder names!)

The complaint is simple: the column view in the save boxes has some pre-determined "width" which it keeps each column at. That width is too narrow to view a really long folder name.

Experiment: Create a folder called "This is a really really really long folder name". Open TextEdit. Try to save the new document (File/Save). Can you get any more of "This is a really really really long folder name" to display than just "This is a really really really"? And that's only if you shrink the dialog box down so that only two columns can fit, then grow it until just before it changes to three columns.

IMHO, a very bad UI design on the save dialog, in countless ways. But let me count the most obvious:

1) To see longer folder names you have to make the dialog box smaller. And even then you are constrained by a predefined maximum (2x the min column size).

2) You can not overwrite an existing file without retyping its file name in full.

3) You can not make a derivative of an existng file name without retyping the name in full.

4) Resizing the panel resizes it in two directions at once, which runs counter to the convention of resizing only one direction in the rest of the OS (a panel issue, but Save inherits it)

5) The panel obscures the document beneath it. Us forgetful users often need details about the underlying document to remind us what file name we should choose for the document. :)

6) It is possible (esp with the default window size in TextEdit) for the panel to completely obscure the document beneath, and since you can not see the underlying doc's bottom-right corner you can't resize it.

7) "Hide Extension" has no noticable effect and gives no clue as to what it really should be doing.

8) Not so much specifically the "Save As" panel, but more the general mechanics of Column View: if I'm ten directories deep and change to "Home" (three levels deep) I am presented with a blank screen (multiple empty columns) and a bottom scroll bar scrolled all the way to the right. It appears that I am still looking "ten levels deep" in the directory structure, even though my "focus" is at three levels deep (ie, seven columns to the left of what's visible on screen). This is silly and inconsistent (I "jumped" right to "Home" ... and if I had navigated there normally I would not ever be able to scroll seven columns to the right and have my focus off-screen!)

Need more? We can move on to the "Open File" dialog if you'd like!
 
Re: Re: flogged!

Originally posted by elmimmo
in hidden Unix folders such as /usr/local/bin/, in which case prepare to unwrap your fingers for Terminal use or reach some third party app.

Ahhh, the hidden folders. You do know that you can see them in Finder, right? Seems there used to be a global option to show them (but I can't find it today in Jaguar 10.2.6), but you can always use the "Go to folder ..." command to see /usr and /bin etc. You can even, once you have such a folder on-screen, drag that folder up to the toolbar to make a shortcut to it so that in the future all you have to do is click the button.


I appreciate apps such as PGP which include an "Uninstall" option in their application's menu. If that option in that particluar app is efficient or not, I do not know, since I have not feel the need to use it so far. But in any case it is a good idea.

Quite true. Unfortunately, the same is the case in Windows (the "Uninstall Programs" control panel just runs the app's uninstall script, which is never guaranteed to work 100% and often does not).
 
Re: Re: Re: flogged!

Originally posted by elmimmo
in hidden Unix folders such as /usr/local/bin/, in which case prepare to unwrap your fingers for Terminal use or reach some third party app.
Originally posted by jettredmont
Ahhh, the hidden folders. You do know that you can see them in Finder, right?

I was refereing that if any app puts some files in the /System/ folder or any of the hidden Unix folders, you will need most probably root access to delete those files. And hence either you use the Terminal to sudo or launch another Finder as root, or use some sort of Super Delete such as that found in FileXaminer.
 
Re: Re: Re: Re: Actually. . .

Originally posted by jettredmont

Need more? We can move on to the "Open File" dialog if you'd like!

just incase you dont know (im not saying you dont) if you hold the option key while you drag the lower right hand corner of the dialog, the columns will increase in size.

didnt read all the posts so it might not even be relevant. gotta work, bye.
 
Re: Re: Re: Re: Re: Actually. . .

Originally posted by beatle888
just incase you dont know (im not saying you dont) if you hold the option key while you drag the lower right hand corner of the dialog, the columns will increase in size.

This only works in cocoa programs by the way, fwiw.

There are enough advantages to using as short a name as possible, having trained on many OS of the past where you did not have the luxury of long file names, I tend to keep things short and sweet anyway. If you are complaining about them being too long, don't give them 80 character names, or whatever it is that is irking you so.

Sometimes the flexibility in an OS is most easily improved by simply adjusting the nut behind the keyboard.
 
Re: Re: Re: Re: Re: Actually. . .

Originally posted by beatle888
just incase you dont know (im not saying you dont) if you hold the option key while you drag the lower right hand corner of the dialog, the columns will increase in size.

didnt read all the posts so it might not even be relevant. gotta work, bye.

Oooh! Thanks, that helps alot!

Doesn't help the UI (hidden features used to be anathema at Apple!), but at least there's code in there to work with ...
 
Re: Re: Re: Re: Re: Re: Actually. . .

Originally posted by Wry Cooter
This only works in cocoa programs by the way, fwiw.

For me, personally, that's fine. The only programs (Developer tools) where this is a problem for me are Cocoa.


There are enough advantages to using as short a name as possible, having trained on many OS of the past where you did not have the luxury of long file names, I tend to keep things short and sweet anyway.

Yes, and the most important advantage to short names IMHO is being able to write scripts and just use the command line without difficulty (a tab-completing shell is pretty much mandatory for our system right now!)


If you are complaining about them being too long, don't give them 80 character names, or whatever it is that is irking you so.

Sometimes the flexibility in an OS is most easily improved by simply adjusting the nut behind the keyboard.

Quite true, and if OS X were my only development platform and/or if I were the only developer working on this project and/or if changing directory structure now was anywhere near as simple as just changing the folder name ... well, then that would be an option. I'm working on an originally-Windows-only code base, which is why the file names are so darned long.

That said, mine is a fairly unique case, so the advice would usually apply :)

Now, as for the other UI missteps in the "Save As..." dialog ...
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.