🚀 go-pugleaf

eBerndR@aol.com (Bernd Rutzmoser) writes:

> 
> 
> Diverse Leute schrieben:
> 
> > > Zweifelsohne. Aber was gibt es Komfortableres, als diese beiden Attribute, 
> > > die mich beide interessieren, auf einen Blick sehen (und aendern) zu 
> 
> > Man sollte wohl einen Modus der Workspace zusaetzlich zu Unix Expert
> > und Normal einfuehren, bei dem die Extension nicht sichtbar ist. Dann
> > kann man das Verhalten von MacOS simulieren, man sieht keine Extension
> > (aus aesthetischen Gruenden), die Information steht im Dateinamen, ist
> > problemlos zu aendern, wenn denn Bedarf besteht, und alle sind
> > zufrieden. Ich meine damit nur, dass die UNIX-Auffassung (alles ist
> > eine datei) ihre staerken hat, und auf der Oberflaeche nicht sichtbar
> > sein muss (mag ich persoenlich nicht, aber ist ab und an nuetzlich).
> > 
> > Wer will, kann so Dateinamen und Typ als unterschiedliche Attribute
> > betrachten, und ich habe die Information zugaenglich und aenderbar.
> > Das ist bei Mac eine ziemliche Seuche (IMHO), dass es zwar fuer den
> > Standarduser gut laeuft, aber es immer mal wieder vorkommt, dass die
> > Attribute falsch sind... und dann ist der "StandardUser" eben leider
> > ueberfordert. Sicher gibt es die Apps, aber erklaer das mal der
> > Schreibkraft im Buero...
> 
> Scheinbar haben einige Leute vergessen, da� das MacOS letztendlich durch
> BenutzerFREUNDLICHKEIT ber�hmt wurde. Type und Creator dem
> Allerwelts-Normal-User vorzusetzen w�rde genau dem zuwiederlaufen. Soll
> sich der Anwender wie bei WinDOOF dar�ber �rgern, wenn er mal die falsche
> angibt und dann statt Word (*w�rg*) sein Write aufgeht? Ich denke nein.

niemand hat gesagt, dass man die extension im mac-modus angeben darf
oder gar soll.  kaum eine next app erlaubt es dem user, seine
extension selbst auszusuchen (im normalgebrauch nur edit, aber das
wars auch fast, edit muss es koennen als default app fuer alle
extensions.).  wer versucht, ein rtf-file statt mit bla.rtf mit bla.doc zu
speichern, bekommt eine datei namens bla.doc.rtf, das ist und bleibt
aber eine rtf datei.  im "mac-modus" wuerde der user bla eintippen und
bla kriegen, oder bla.doc angeben und eben das kriegen; die datei
hiesse nur auf der platte bla.rtf bzw. bla.doc.rtf. ich bin nicht
dafuer, diese information aenderbar (in diesem modus) zu halten,
sondern nur, es _intern_ bei der formel "dateiname+inhalt == alle
wesentlichen inhalte" zu belassen, damit man keine extra-utils
braucht, um sie zu aendern.

der einzige unterschied, der mir einfaellt, ist, dass man natuerlich
mehrere dateien namens bla haben kann, say bla als (tex, aux, log,
lst)... finde ich aber nicht so schlimm.

es ist in beiden faellen moeglich, die identische oberflaeche
aufrechtzuerhalten. kein user wuerde den unterschied bemerken. nur,
dass z.b. die netzprotokolle keine weiteren dateiattribute kennen (ein
"ftp-get" einer mac datei ist zum scheitern verurteilt, es sei denn,
sie ist verpackt, oder man hat angepasste ftp server und clients auf
beiden seiten, wo bleibt da die offene welt?)

ich will benutzerfreundlichkeit _und_ administratorfreundlichkeit.

> Die unter uns, die Type und Creator �ndern wollen, wissen auch, wie
> (ResEdit, FileBuddy). 

alle unter _uns_? alle, die es mal brauchen? und sie wissen auch, wo
sie es her kriegen? meine erfahrung sieht leider anders aus. 

im allgemeinen wird man irgendwann von irgendjemanden in sein buero
gerufen, der gerade ziemlich flucht, und natuerlich die utils _nicht_
auf der platte hat, ja sie wahrscheinlich fast nie brauchte und deshalb...  

na gut, dann geh ich eben wieder zurueck in mein buero, und hole die
diskette und sage dem user dann, "das sollst du aber bitte nicht so
machen, weil es sonst nicht mehr benutzerfreundlich ist".  bei einer
extension brauche ich definitiv keine utilities. auch nicht uebers
netz, auch nicht ueber modem von zuhause, auch nicht vom letzten vt100
oder pc...

> Sicherlich w�re es nett, wenn man im Sichern-Dialog auch noch
> wahlweise die Applikation ausw�hlen k�nnte, mit der sie das n�chste
> Mal ge�ffnet werden soll oder wenn man best. Types und/oder Creators
> andere Defaultprogramme zuordnen k�nnte (sprich TeachText Dateien
> immer mit BBEdit �ffnen). Uber solche Erweiterungen la� ich mit mir
> diskutieren.  :-)

und wen freut nicht die meldung: die app zum oeffnen der datei bla
wurde nicht gefunden, moechten sie teachtext benutzen? ;-( ich sehe
nicht ein, warum man die metapher "datei" verlassen muss, ohne einen
gewinn davon zu haben.

> Niemand wird davon abgehalten, irgendwelche - ihm/ihr vielsagende -
> Endungen an die Dateinamen anzuh�ngen. Man kann das machen MUSS aber
> nicht.

es ist fuer die oberflaeche _identisch_, ob man dateien, mal extrem
gedacht, hallo.adobeillustrator.eps intern benennt, oder ob man die
datei hallo nennt mit creator=adobeillustrator und type=eps.

mir geht es nur um die interne darstellung einer datei, und die ist
fuers look & feel irrelevant. natuerlich koennte man auch diese datei
attribute zusaetzlich einfuehren, und eine moeglichkeit anbieten, auf
diese dateien per file-utils zuzugreifen. einfacher finde ich, die
erste moeglichkeit. wenn man die vorteile aus beiden lagern haben
kann, soll man nicht eine haelfte wegwerfen. 

> Wer's mag...

ich will die _moeglichkeit_ haben, dateien mit file-utils zu
bearbeiten, und die wesentlichen attibute aenderbar zu behalten.  ich
will, dass ftp funktioniert, und ... das bitte unter beachtung von
standards, wie unix und posix.

> ...aber da� Du bei Unix keinen "/" verwenden darfst, nicht?  ;-) Es
> gibt halt mal ein Zeichen, da� Betriebssystemintern als
> Hierarchietrenner dienen mu�, bei Unix ist das der / beim Mac der :
> und bei DOS der \.

naja, auch das ist kosmetik. man koennte das bei der "anzeige"
beliebig erzeugen. unix kann sicher kein / im namen, aber warum das
die oberflaeche nicht koennen soll, ist mir unklar. man koennte
z.b. \/ und \\ im namen entsprechend darstellen, oder dateinamen in
unicode erlauben, oder...

Ciao, Stephan

p.s. ich denke, dass man alles, was den Mac ausmacht, auf einem Unix
Unterbau implementieren kann, das duerfte bei Regierungsauftraegen in
den USA auch wichtig sein...  
-- 
Task:  System Administration Unix (HP-UX, Linux, FreeBSD) 
Email: Stephan Trebels <strebel2@cage.mpibpc.gwdg.de>  
Mail:  Abt. 081, MPI bpC, Am Fassberg, 37077 Goettingen, Germany
Tel:   +49 551 201 1 454