amantia at freemail.hu
Tue May 13 00:54:57 EEST 2003
-----BEGIN PGP SIGNED MESSAGE-----
The X-KDE-Text property was introduced because there was no reliable way to
find out if a file is text or binary. Some applications needs to know it, as
it doesn't make sense to open a binary file inside a text editor (or inside
KMail and view as text). Furthermore it can even be dangerous, and you may
not even call it a bug when the application designed to work with text files
fails when a binary files is opened as text. Of course, it can be discussed
what is marked as text, but script files, plain text and such surely belongs
there. Even postscript is text, but of course not so easy to understand. ;-)
BTW, looking if the files belongs to text/* is not enough as many (mainly for
script files) mimetypes are under application/ . I cannot count how many
mail/bugreports I've got from users when Quanta relied only on the mimetype
check (for text/*) to find out if a file is text (and therefor editable) or
On Monday 2003 May 12 16:21, David Faure wrote:
> On Monday 12 May 2003 15:10, Thomas Leonard wrote:
> > On Mon, May 12, 2003 at 02:33:02PM +0200, David Faure wrote:
> > > We have a X-KDE-Text boolean property now in mimetypes, to tell which
> > > one have a plain text representation - so that kmail can show the
> > > contents if asked for. application/x-perl, x-ruby and x-python have it
> > > set to true, for instance, as well as all the text/* mimetypes.
> > >
> > > I think email programs should have the option to view the plain text
> > > source for everything, builtin, but indeed firing text editors in the
> > > general case (e.g. from a filemanager) isn't useful (to a
> > > non-developer).
> > Wouldn't it be better to just check the start of the file for control
> > characters? Or even just show it anyway? In ROX-Filer, clicking on any
> > file with Shift held down loads it as if it was a text/plain file, for
> > example.
> Nice for binaries :)
> I don't think it makes sense to always offer to view something as plain
> text though.
> > We already have 'text/*' to indicate that text is a reasonable want to
> > view the file (as a default option). Having another layer ("This file
> > shouldn't normally be viewed as text, but advanced users could still get
> > some sense out of it") doesn't seem necessary, given that an advanced
> > user should be able to view *anything* as text, if they want (eg, an
> > MS-Word document).
> But viewing binary data as text is much less useful than viewing e.g.
> python/ruby/perl scripts or postscript files, as text.
> I think the point of X-KDE-text is to offer a sensible "advanced users can
> view AND edit this as text" option in some apps (which is the case for
> perl/ruby/python, but editing as text is definitely not a good idea with
> binary formats). Andras, can you confirm?
> > > (The other special property we have is X-KDE-NativeExtension, so that
> > > the file dialog can offer to automatically append a given extension).
> > Something like this?
> > <preferred-extension>png</preferred-extension>
> > What happens for files without a preferred extension given in the
> > database?
> The file dialog doesn't offer to append an extension automatically, the
> user has to provide it.
Quanta Plus developer - http://quanta.sourceforge.net
K Desktop Environment - http://www.kde.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the xdg