Re: commit -- [manifesto] no more mangling


Subject: Re: commit -- [manifesto] no more mangling
From: Aaron Lehmann (aaronl@vitelus.com)
Date: Sat Jun 10 2000 - 17:59:07 CDT


Juan,

Thanks for your feedback. It would be very simple to make a checkbox for
"append extension" in the UNIX file selection dialog. If you would like, I
will do this. However, I think it would be awkward to put in the file
selection dialog - it would be easier to type .abw than to reach for a
checkbox, at least in my opinion. Maybe this would be best implemented as
a preference item. Someone who knows more about the preferences system
would have to do that.

Aaron Lehmann

On Sat, 10 Jun 2000, Juan Carlos Castro y Castro wrote:

> I hope your plan includes leaving "append extension" as an option -- I see no
> problem in "no extensions" being the default, but after all you can turn on file
> extension visibility in Windows too (I always do). As much as you hate them,
> remember we PC types have never heard of anything even remotely resembling
> resource forks (OS/2 notwithstanding), which makes this contrivance a necessity.
>
> As you can probably tell, I have a friendly relation with file extensions. Please
> don't send Hezbollah after me. ;)
>
> Juan
>
> Aaron Lehmann wrote:
>
> > On UNIX, an OS that allows you to name files what you want to name them,
> > don't mangle the filenames that The User inputs to include yucky, useless
> > suffixes or anything else. I could rant on for hours on why this is the Correct
> > Behavior, but I will not to avoid sparking a flamewar. Anyway, files seem
> > to work fine now without a .abw extension, so why forcefully append one?
> > If the answer is to be like windows, well, why don't we stick a taskbar at
> > the bottom of the screen to make abiword on unix look more like abiword on
> > windows. My point is that different platforms work differently, and it is
> > a bad idea to write programs that work in exactly the same way on
> > different platforms, disregarding the traditions and standards of each
> > platform. Make it be like the other applications that the user is using.
> >
> > Furthermore, this change brings the UNIX and Win32 versions of Abi even
> > closer together. On Win32, a filename suffix is meant as internal data for
> > the OS to determine which filetype it is (this is because Win32 is dumb).
> > This is why Win32 does not show filename extensions by default. So, if a
> > user on Windows saves a file as MyFile, then when looking at the directory
> > with the OS (explorer) they will see a file named MyFile. On UNIX before
> > this change, if you were to type ls after saving a file MyFile, you would
> > see MyFile.abw. This is not the same behavior as on windows! Filename
> > extensions are a type of metadata that win32 uses, and it is incorrect to
> > write this metadata on platforms that do not understand it and ignore it.
> >
> > I hope I've made my point well, and that this change does not meet up with
> > a lot of resistance. As you can probably tell, I have a very strong hate
> > for filename extensions, originally being a mac user and programmer (heh,
> > I was the one that coded support for determining the file type with
> > file(1) in GNOME's file manager). If there is someone who opposes this
> > change, I would like to discuss it with you, and I will try to listen to
> > what you have to say.
> >
> > Well, at least I didn't rant on for hours as I promissed not to :).
> > CVS:
> > ----------------------------------------------------------------------
> > CVS: Enter Log. Lines beginning with `CVS:' are removed automatically
> > CVS:
> > CVS: Committing in .
> > CVS:
> > CVS: Modified Files:
> > CVS: src/af/xap/unix/xap_UnixDlg_FileOpenSaveAs.cpp
> > CVS:
> > ----------------------------------------------------------------------
>
> --
> Juan Carlos Castro y Castro | "Standing up to an evil system is
> jcastro@appi.com.br | exhilarating." -Richard Stallman
> APPI Informatica Ltda. |
> Rio de Janeiro - Brazil | http://www.pcshop.com.br/~jcastro/decss
>
>
>
>
>



This archive was generated by hypermail 2b25 : Sat Jun 10 2000 - 17:59:23 CDT