Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Mon 22 Sep 2014, 00:34
All times are UTC - 4
 Forum index » House Training » Users ( For the regulars )
Can zero-sized (empty) documents display as a special icon?
Moderators: Flash, Ian, JohnMurga
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 1 of 2 Posts_count   Goto page: 1, 2 Next
Author Message
miriam


Joined: 06 Dec 2006
Posts: 279
Location: Queensland, Australia

PostPosted: Mon 03 Sep 2012, 19:40    Post_subject:  Can zero-sized (empty) documents display as a special icon?
Sub_title: Currently zero-byte files display erroneously as plain text even tho the zerosize mimetype exists
 

I'd love to be able to get Puppy to display empty documents, that is, zero-sized files as a special icon. Every now and then I have been caught out, thinking that I have a text document when it is just a filename and it has become a point of annoyance for me. Also it is useful sometimes to use a zero sized document as a kind of marker in a list. For example, when working my way through a series of mp3 or video or text or html files I put an appropriately named zero sized file in the folder so I know where I'm up to. If I could give zerosized files a special icon it would help in those and other cases.

If you look in /usr/share/mime/application you'll find an xml file that is supposed to handle empty documents. It is called x-zerosize.xml. I read online that the issue of assigning a distinct mimetype to zerosize files had been fixed some years back. However I haven't been able to find the key to getting Puppy to use it.

I can easily edit the /usr/share/mime/globs file and add any mimetype I want. (Yes, I know we're not supposed to hand-edit it, but until I find a better way...) For instance I added
text/x-readme:README*
text/x-readme:*.README

entries to the globs file and then added an icon of a text page but colored gold called text_x-readme.png into the /root/.config/rox.sourceforge.net/MIME-icons/ folder. Now when I'm compiling programs my eye jumps quickly to any readme files in a directory.

However, no matter what I do I can't seem to get Puppy to see zero sized files as special.

I tried making an entry in /usr/share/mime/globs:
application/x-zerosize:*
but refreshing a folder containing an empty file continues to display it incorrectly as plain text document or text/plain.

Does anybody have any idea how to fix this?

EDIT: I should have mentioned that I'm using jwm as window manager and rox as file manager.

_________________
A life! Cool! Where can I download one of those from?

Edited_times_total
Back to top
View user's profile Send_private_message Visit_website 
`f00


Joined: 06 Nov 2008
Posts: 809
Location: the Western Reserve

PostPosted: Mon 03 Sep 2012, 23:06    Post_subject:
Sub_title: mime-ish
 

Hi miriam (and let me say I've enjoyed your input here quite a bit)

Any idea would be like the any key? okay, spacebar away

I try to stay away from mimes (no wait, seriously now). My usual file manager (xfe) works with filetypes as the organizational pref and that's pretty straightforward (absolutely README is a filetype with its own icon and everything, now and then I get a bounce from a texteditor about encoding).

Possibly try the ~/Choices/.. route - think I did some miming in there and it worked fairly well. Then again, I've done some bonehead things (like try to simplify the duplicity of the dual globs in root and so on but that's another story).

The system mime stuff is for people who know what they're doing (or should) - strictly as an aside, one dotpet I tried some while back almost trashed a formerly useful pup (and not just cosmetically .. it threw rox in the toilet, slammed the lid and sat on top so to speak).

Seems there definitely should be a way to do your will, more competent help should arrive soon.
Back to top
View user's profile Send_private_message 
miriam


Joined: 06 Dec 2006
Posts: 279
Location: Queensland, Australia

PostPosted: Tue 04 Sep 2012, 02:08    Post_subject:  

Thanks for the light-hearted humor Smile and for the suggestion about ~/Choices. I've tried muddling around in there, but they seem to need the mime for "zerosize" to be already defined.

When you mentioned your file manager I realised I hadn't stated my file manager or window manager (rox and jwm), so I'll edit my post above to include that info.

_________________
A life! Cool! Where can I download one of those from?
Back to top
View user's profile Send_private_message Visit_website 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Wed 12 Sep 2012, 14:05    Post_subject:  

ROX-Filer determines the MIME type with code borrowed from the xdgmime project at freedesktop.org.

There are a number of issues that prevent ROX-Filer from being able to properly recognize a file with an application/x-zerosize MIME type. Each of these issues alone is enough to break things.

1. Before ROX-Filer even calls the xdgmime code it looks at the size of the file and sets the MIME type to text/plain if the size is zero.

2. The xdgmime code used by ROX-Filer was forked from the xdgmime code base in 2005, and updated from the xdgmime code base in 2007. But support for the application/x-zerosize MIME type was not added to the xdgmime code base until 2011. So the code that supports application/x-zerosize hasn't yet been merged into ROX-Filer. Therefore, even if ROX-Filer did call the xdgmime code instead of deciding prematurely that the file is text/plain, it would not work.

3. The new code that supports application/x-zerosize in the xdgmime code base seems to have a bug. It only works if there is support for loading the mime.cache file into shared memory. Apparently ROX-Filer is not normally built with that support. So even if the new code was in ROX-Filer, ROX-Filer still wouldn't recognize application/x-zerosize files.

I am attaching a version of ROX-Filer which has been modified to eliminate the above issues.

This works for me running Racy 5.2.2. You didn't mention which Puppy you are running, but this may also work in other recent Puppies. (But, if you are using Slacko, be aware that 01micko has reported that ROX-Filer doesn't work with user fido in Slacko unless it is compiled in Slacko.)

This version of ROX-Filer is based on the code in rox-filer-20111022-patched3.tar.gz (which Barry keeps at
http://bkhome.org/sources/alphabetical/r/), so it has the latest Puppy patches.

The changes made to the code are mostly just a subset of the changes in a patch submitted to the xdgmime code base by David Faure. (See xdg/xdgmime: Implement text vs binary fallback; support for application/x-zerosize.) My only contributions were to make a small change in the diritem_restat() function to eliminate issue #1 above, and to make a change to the xdg_mime_get_mime_type_for_file() function identical to a change he made to the _xdg_mime_cache_get_mime_type_for_file() function; this fixes issue #3 above so that it will still work even if there is no support for the mime.cache file.

Note that David Faure's patch also adds support for guessing whether a file is binary or text if no other method has been able to identify the MIME type. ROX-Filer has had support for that since 2005 (with a short vacation from 2007-08-18 to 2008-01-21 when the code had been mistakenly removed). I have retained the ROX-Filer code for that support and not implemented David Faure's related changes.

I've attached a *.diff file showing the changes. There is no need to download it unless you are curious. I'm just attaching it for documentation.

(And speaking of documentation, some discussion of Faure's patch is available here: Re: Questions regarding the shared mime spec)


Trying it out - - -

I'd be happy to hear from anyone who is willing to take the time to test this. (As always, although I have no reason to expect any problems, it never hurts to backup your save file before testing stuff.)

Make a back-up of /usr/local/apps/ROX-Filer/ROX-Filer, download the attached version, gunzip it (or unzip it with pupzip), set the executable permission bits, and copy it over your old /usr/local/apps/ROX-Filer/ROX-Filer. (You may get a "file busy" error when trying to overwrite this file. If so, you probably should kill ROX-Filer before copying, but I usually just remove the original file first, then copy, and haven't yet had a problem with doing that.)

Also attached is a .png file for the icon. It is simply a copy of the text.png file, from which I erased the "text". You can make a better one. Anyway, it should be copied to: /usr/local/apps/ROX-Filer/ROX/MIME/application-x-zerosize.png

And, lastly, I have attached a script for the run action. This just executes defaulttexteditor. In fact, it is just a copy of the text_plain script. Some folks like to use ROX-Filer to create a new empty file, then click on it to edit it, rather than starting a text editor and clicking New, so I thought it best to retain the same behavior that it had when empty files were text/plain. You know how to change that if you want another run action, or no run action. After unzipping, and making executable, that file should live at: /root/Choices/MIME-types/application_x-zerosize

Once the three files are in place, open a terminal window and issue these commands (if your pinboard file has a different name, substitute accordingly):
Code:
killall ROX-Filer
rox -p /root/Choices/ROX-Filer/PuppyPin

At first, your wallpaper will turn black, but if the wind is blowing favorably, it will be restored by the second command, and ROX-Filer should now recognize application/x-zerosize files.
ROX-Filer.diff.gz
Description  Changes made to add application/x-zerosize support
gz

 Download 
Filename  ROX-Filer.diff.gz 
Filesize  940 Bytes 
Downloaded  78 Time(s) 
ROX-Filer.gz
Description  /usr/local/apps/ROX-Filer/ROX-Filer
gz

 Download 
Filename  ROX-Filer.gz 
Filesize  223.44 KB 
Downloaded  70 Time(s) 
application-x-zerosize.png
 Description   /usr/local/apps/ROX-Filer/ROX/MIME/application-x-zerosize.png
 Filesize   1.07 KB
 Viewed   340 Time(s)

application-x-zerosize.png

application_x-zerosize.gz
Description  /root/Choices/MIME-types/application_x-zerosize
gz

 Download 
Filename  application_x-zerosize.gz 
Filesize  82 Bytes 
Downloaded  86 Time(s) 
Back to top
View user's profile Send_private_message 
miriam


Joined: 06 Dec 2006
Posts: 279
Location: Queensland, Australia

PostPosted: Wed 12 Sep 2012, 19:32    Post_subject:  

Wow! Amazing! I'm very grateful. I'll try this out later today and report back.
_________________
A life! Cool! Where can I download one of those from?
Back to top
View user's profile Send_private_message Visit_website 
miriam


Joined: 06 Dec 2006
Posts: 279
Location: Queensland, Australia

PostPosted: Wed 12 Sep 2012, 20:49    Post_subject:  

I couldn't wait to try it out. Smile So I saved all my current work (just in case) and followed your instructions. It works beautifully!!!

I tried making my own icon -- just a black dot, but found that a simple transparent icon with nothing visible suits me best. It makes sense too -- zero-sized... nothing...

Looks great as a marker in lists of files in a directory. And I'll never again mistake an empty file for something with content.

Brilliant! Many thanks!

_________________
A life! Cool! Where can I download one of those from?
Back to top
View user's profile Send_private_message Visit_website 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Thu 13 Sep 2012, 17:56    Post_subject:  

You're welcome.

I'm always glad to hear that things I've built on my Puppy work on someone else's Puppy as well. I am curious as to which Puppy you are running it on.

Yes, a transparent icon seems most appropriate.

miriam wrote:
I'll never again mistake an empty file for something with content.

Just be aware that the Shared MIME-info Database "standard" recommends that the filename glob (e.g., *.pdf) has precedence over the file content (or, in this case, the lack thereof). The xdgmime code follows that recommendation. So you may still see an occasional empty file without the application/x-zerosize MIME type. This would happen if, for instance, someone created an empty file named SumOfAllHumanKnowledge.pdf.
Back to top
View user's profile Send_private_message 
miriam


Joined: 06 Dec 2006
Posts: 279
Location: Queensland, Australia

PostPosted: Thu 13 Sep 2012, 19:02    Post_subject:  

I'm running a variety of Puppies. Mostly standard line... 2.14, 4.13, 5.28 lupu, a very recent Puppy Quirky (can't remember which one as it's on a different machine), and the experimental Raspberry Pi Puppy that Barry has been working on (haven't had time to play with that lately as I'm doing a series of paintings with a graphics tablet using Puppy - YAY!). My main desktop computer is a moderately powerful 3GHz base-model AMD machine, but I always have lots of computers, many of them low-power ones, like the Raspberry Pi, the Norhtec Microclient and Edubook, Android HTC handheld (not Puppy, though I wish it was), an old Palm Vx (not Puppy, of course), and I have some tiny Arduino computers on order that are about half the size of a thumbdrive and plug into a USB connector (won't be able to use Puppy on their 8KB memory though Smile ).

At the moment most of my work gets done on the Puppy lupu 528, though it is starting to bloat beyond what I like and it may soon be time to move on to Wary or Slacko, both of which I want to get my teeth into. (Though I'm not looking forward to getting the graphics tablet working in the new environment again -- tablets are such a pain.)

Good to know that the filetype can be overridden in some cases. I'll keep an eye out for that. (Strange saying: "keep an eye out".)

_________________
A life! Cool! Where can I download one of those from?
Back to top
View user's profile Send_private_message Visit_website 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Fri 14 Sep 2012, 10:51    Post_subject:  

(Given a choice between "keeping an eye out" and "keeping my eyes peeled", it would be tough to decide which sounds like less fun.)

Thanks for the info on your Puppy menagerie. 'Tis nice to know that this build of ROX-Filer also works on Lupu 528. Good luck with getting your graphics tablet to talk with whatever you try next.
Back to top
View user's profile Send_private_message 
miriam


Joined: 06 Dec 2006
Posts: 279
Location: Queensland, Australia

PostPosted: Fri 14 Sep 2012, 21:43    Post_subject:  

I seem to have found a solution to zero-sized html or pdf or other documents being presented as the wrong mime-type and icon.

Just hand-edit the /usr/share/mime/globs file and add at the end:
Code:
application/x-zerosize:*


I know we're not supposed to hand-edit it, and that it is supposed to be auto-rebuilt by the update-mime-database command, but in practice the online list is never all I'd like it to be so I've added lots more definitions to my globs file. I keep a backup so that if it gets overwritten I can re-add all my extras.

_________________
A life! Cool! Where can I download one of those from?
Back to top
View user's profile Send_private_message Visit_website 
miriam


Joined: 06 Dec 2006
Posts: 279
Location: Queensland, Australia

PostPosted: Sat 15 Sep 2012, 03:31    Post_subject:  

uh-oh... small problem.

My computer no longer recognises some of my file mime-types. It appears to have totally lost the ability to recognise mp3 files and DVD subtitle 'sub' files appear as just mpeg files, instead of video/mpeg-dvd-subtitle. In that particular case it is true that the sub files really are mpeg files, but I was able to override that with the globs file and attach a distinctive subtitles icon. A lot of other mimetypes have been broken too -- csv, xls, some txt files.... I'll try to find out what all these have in common.

Interesting...

Weird... If I delete my application/x-zerosize:* line from the globs file then all my mimetypes go back to normal.

Weirder still: if instead of deleting it I change it to application/x-zerosize:*.* then everything goes back to normal and I lose my flexible zerosize mimetype, just as if I'd deleted the line. Darn.

_________________
A life! Cool! Where can I download one of those from?
Back to top
View user's profile Send_private_message Visit_website 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Sat 15 Sep 2012, 16:53    Post_subject:  

miriam wrote:
Just hand-edit the /usr/share/mime/globs file and add at the end:
Code:
application/x-zerosize:*

The xdgmime code used by ROX-Filer considers a glob that begins with *, and doesn't have other special characters ( \ [ ? * ) following it, to be a simple glob (XDG_GLOB_SIMPLE). For instance, *.txt is a simple glob.

Your * glob is also recognised as a simple glob.

But your glob, placed in the final line of the globs file, is saying, "Any file that doesn't match the above globs has a MIME type of application/x-zerosize." In effect, you have defined a default MIME type for any file that doesn't match any of the other globs. The authors of the xdgmime code didn't expect anyone to do that, since doing that prevents their code from going on to the next step, which, for any file that didn't match a glob, guesses the MIME type by looking at the content of the file.

You may have noticed, though, that your glob isn't actually doing what one would expect it to do, that is: define a default MIME type (as stated above). For instance, my globs file has no *.conf glob. Yet adding your glob to the end of the globs file doesn't make all the .conf files show as application/x-zerosize.

That is because your glob confuses the xdgmime code, resulting in no files finding any match in the globs file. So the process of finding the MIME type advances to the next step, examining the content, for all files. So the .conf files in my /etc/ directory, which are all full of text, are identified as text/plain. And an empty .pdf file is identified as application/x-zerosize -- because when the content of the file was examined, it was found to be empty.

(Note that it doesn't matter what MIME type you associate with your single asterisk glob. If you were to change it to, for instance, application/x-pkg:*, any empty files would still be identified as application/x-zerosize because they are being identified by content.)

The reason that your glob confuses the code is this: When building a hash table for the globs, the xdgmime code uses the characters in the glob to the right of the initial asterisk. In this case there are none, so all that it sees is the string's terminating null character. This results in a bad hash table. (As I said above, the authors of the xdgmime code weren't expecting you to be thinking outside of their box.)

(By the way, the function involved in this has had a major rewrite since the version used by ROX-Filer. Your single asterisk glob won't break the new code. Instead it is apparently (and correctly) ignored, and the glob hash table continues to work.)


miriam wrote:
My computer no longer recognises some of my file mime-types. It appears to have totally lost the ability to recognise mp3 files . . .

An .mp3 file with no redundancy in the stream and not pre-pended with ID3 metadata has FF FB for the first two bytes. If ID3 metadata has been pre-pended, it has 49 44 33 for the first three bytes (the string "ID3"). (ref: http://www.digitalpreservation.gov/formats/fdd/fdd000105.shtml)

The /usr/share/mime/magic file that came with Racy 5.2.2 properly associates a file beginning with 49 44 33 ("ID3") with an audio/mpeg MIME type, but says nothing about a file beginning with FF FB. Instead it also associates a file beginning with 00 00 FF FB with an audio/mpeg MIME type. I suspect that those zeros are a mistake.

You probably have the same magic file, so if you have any .mp3 files beginning with the "ID3" string, ROX-Filer will properly associate them with the audio/mpeg MIME type when examining the content, but those beginning with FF FB will not be recognised.


miriam wrote:
. . . and DVD subtitle 'sub' files appear as just mpeg files, instead of video/mpeg-dvd-subtitle. In that particular case it is true that the sub files really are mpeg files, but I was able to override that with the globs file and attach a distinctive subtitles icon.

You've probably already figured this one out. Since your single asterisk glob caused the glob hash table to go bad, and no globs are recognised, the globs you added are no longer recognised. When the file content is examined, it is correctly identified as mpeg.


miriam wrote:
Weird... If I delete my application/x-zerosize:* line from the globs file then all my mimetypes go back to normal.

Yup.


miriam wrote:
Weirder still: if instead of deleting it I change it to application/x-zerosize:*.* then everything goes back to normal and I lose my flexible zerosize mimetype, just as if I'd deleted the line.

Well, not quite. Look again.

Because this blob is more than a single asterisk, it doesn't cause the problem that the single asterisk blob did. So now all globs are working again.

So, yes, your .mp3, .sub, and any other files with a matching glob in the globs file will be correctly identified again. But any other file containing a dot in the filename will be identified as application/x-zerosize, whether it is or not.

Look at the blob. Two wildcards surrounding a dot basically says, "Any file that has a dot in the name and doesn't match the above globs has this MIME type."

Look in your /etc/ directory. When using this blob you will probably see .conf files misidentified as application/x-zerosize (unless your globs file has an entry for *.conf files).

So in this case, your blob didn't break anything, but did just what it is supposed to do. Unfortunately, this wasn't what you had hoped it would do.


Anyway, you probably now know more than you or anyone else (including me) would really want to know about the weird behavior you described. Since that behavior was not what you expected, or what I would expect, I decided to dig into it a bit. Often times I am reluctant to leave such mysteries unsolved.
Back to top
View user's profile Send_private_message 
miriam


Joined: 06 Dec 2006
Posts: 279
Location: Queensland, Australia

PostPosted: Sat 15 Sep 2012, 18:04    Post_subject:  

Very interesting. Thank you for thinking this through and sharing such a nicely laid out explanation. I guess the secret to solving misidentified zero-sized mimetypes would be found if I dig into the ROX-Filer code. With the help of your diffs and the actual source (which I have downloaded) I guess I could do that, however it may have to wait some weeks until I have this set of paintings out of the way -- I'm trying to force myself to keep my nose to the grindstone (another painful metaphor) to produce a series of pictures of the major epochs in Earth's history and I'm notoriously easily distracted. Smile
_________________
A life! Cool! Where can I download one of those from?
Back to top
View user's profile Send_private_message Visit_website 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Wed 26 Sep 2012, 17:13    Post_subject:  

You're welcome. Glad you liked it.

I've since sent my patch upstream to the rox-devel mailing list.

[rox-devel] Patch to provide support for application/x-zerosize


npierce wrote:
3. The new code that supports application/x-zerosize in the xdgmime code base seems to have a bug. It only works if there is support for loading the mime.cache file into shared memory.

I've also reported that bug to freedesktop.org's Bugzilla.

Bug 55120 - application/x-zerosize isn't supported when not using cache.


npierce wrote:
The /usr/share/mime/magic file that came with Racy 5.2.2 properly associates a file beginning with 49 44 33 ("ID3") with an audio/mpeg MIME type, but says nothing about a file beginning with FF FB. Instead it also associates a file beginning with 00 00 FF FB with an audio/mpeg MIME type. I suspect that those zeros are a mistake.

I would have reported this bug as well, but I found that it had already been fixed on 2011-Nov-04, so should be in shared-mime-info database 1-0 (released 2012-Jan-17).

Fix magic for MP3 files without ID3

(Latest release in Puppy no-arch repository is 0-70 (released 2009-Oct-06).)


miriam wrote:
I'm trying to force myself to keep my nose to the grindstone (another painful metaphor) to produce a series of pictures of the major epochs in Earth's history and I'm notoriously easily distracted. Smile

Assuming that the grindstone wasn't invented before the Pleistocene epoch, you can't keep your nose to it until you get there. Smile

Anyway, good luck with your painting. It sounds like a fun project -- although finding models must be difficult unless you happen to have a tardis.


miriam wrote:
I guess the secret to solving misidentified zero-sized mimetypes would be found if I dig into the ROX-Filer code.

Yes, you would probably only need to move the order of the tests in the relevant functions, so that the test for an empty file is called before the test for a matching glob. If and when you go there, have a look at xdg_mime_get_mime_type_for_file() and _xdg_mime_cache_get_mime_type_for_file() in xdgmime.c and xdgmimecache.c.

Before you go to the trouble, though, are you sure that you really want to change that behavior? Some folks might not classify them as "misidentified".

One person might argue that if someone created a file and named it test.pdf, they obviously intended it to have an application/pdf MIME type, otherwise they would have given it a different name. Another person might counter with, "Maybe, but look at the file: it's empty. Its not an application/pdf; it's not anything! It's just an empty file, so it must have MIME type application/x-zerosize."

Who is correct? Both are. There is no official definition of MIME types with an "x-" prefix.

RFC 4288: Media Type Specifications and Registration Procedures, § 3.4. Special x. Tree wrote:
These types are unregistered, experimental, and for use only with the active agreement of the parties exchanging them.
(Source: RFC 4288 Section 3.4)

"the active agreement of the parties exchanging"?!

Remember that the second 'M' in "MIME" is for "Mail". So originally this meant that, when sending e-mail attachments, you and your Aunt Agatha could decide what you wanted "x-zerosize" to mean, as long as you both agreed on it. You might even have a different definition of "x-zerosize" that you and your cousin Zeb agreed on when exchanging e-mail. (What?! Did I hear some people say that they never discussed or debated with their correspondents about what definitions they would use for various experimental MIME types? Oh, for shame!)

The RFC goes on to say,
RFC 4288: Media Type Specifications and Registration Procedures § 3.4. Special x. Tree wrote:
However, with the simplified registration procedures described above for vendor and personal trees, it should rarely, if ever, be necessary to use unregistered experimental types. Therefore, use of both "x-" and "x." forms is discouraged.

Ah, such optimism!

The glob and glob2 files created with the latest release of the shared-mime-info database (Release 1-0, 2012-Jan-17) contain 371 unregistered experimental types (up from 296 in Release 0-21, 2007-Apr-18 ). Maybe not all of those types are frequently used, but the fact that they made it into the database indicates that they are certainly used more than "rarely, if ever." (Oh, for comparison, how many registered types are in the database? 197 (up from 120 in Release 0-21).)

This problem of officially non-standard things becoming commonly used as if they were standard has been around for ages. One of the most notorious instances of this sort of thing is the legacy of ISO standard 646 allowing the code for LINE FEED to be used alternatively for NEW LINE. The language which allows this is similar to the "for use only with the active agreement of the parties exchanging them" in the MIME specification:

Third Draft Proposal on ISO 6 Bit and 7 Bit Codes (1964) wrote:
The use of New Line requires agreement between the sender and the recipient of the data.
(Source:H. McG. Ross, "The I.S.O. character code", The Computer Journal, vol 7, no. 3, October, 1964, pp. 197-202)

Over the decades there must have been millions of people-hours wasted by this confusion, and the need to translate text documents created in one O.S. for use on another O.S..

While it is too late to avoid the LINE FEED / NEW LINE confusion, there is hope that at least some of the x- MIME types may eventually get standardized. Since experience has shown that experimental types often end up being in common use, there is a plan in the works to modify RFC 4288 to allow people to create unregistered MIME types with a meaningful, currently unused name, without the need for an "x-" prefix (in fact, the "x-" prefix would be discouraged). Later, when it looked like the experimental type was a success, it could be registered with no need to change the name. And existing x- types would no longer be unregisterable, so their creators or maintainers could decide to register them "as is" with the "x-", or could choose to migrate them to a name without the "x-".

Media Type Specifications and Registration Procedures draft-ietf-appsawg-media-type-regs-14, § 3.4. Unregistered x. Tree wrote:
Note that types with names beginning with "x-" are no longer considered to be members of this tree (see [I-D.ietf-appsawg-xdash]). Also note that if a generally useful and widely deployed type incorrectly ends up with an "x-" name prefix, it MAY be registered using its current name in an alternate tree by following the procedure defined in Appendix A.
(Source: Media Type Specifications and Registration Procedures draft-ietf-appsawg-media-type-regs-14, Section 3.4)

As far as I know, this is still just a draft document, and hasn't yet been approved to replace RFC 4288. So x- MIME types are currently still unregisterable. Time will tell if it gets approved.

Of course, a personal computer is personal. And no one needs the approval of any standards organisation to set it up to work best as fits her needs. So the possibility that some x- MIME types might one day get registered shouldn't dissuade you from modifying ROX-Filer to suit your needs.

A larger consideration would be the Shared MIME-info Database "standard". Since that recommends that the filename glob has precedence over the file content, most software will probably follow the same convention. If you choose to follow a different drummer, be prepared to repeatedly patch new versions of ROX-Filer, or other file managers that you use, over the years.

Other than saving yourself some coding time, what other reasons might there be to leaving things as they are?

What point would there be in giving an empty file a MIME type other than application/x-zerosize?

Consider this, for instance:

Some folks, like me, are of the old school. We start an application, then click the Open button to get the file we want to work on. Not surprisingly, to create a new file we also start the application and click the New button.

Other folks are of the new school. They use their file manager to find the file that they want to work on, then click on its icon to run the appropriate application. They need not remember where the application lives. So they may find it easier to create a new file my creating and naming it with their file manager, then clicking on the new icon to run the application.

This is why I suggested in an earlier post that since an application/x-zerosize file was previously identified as a text/plain file, it might be a good idea to maintain the old behavior by setting the default run action for application/x-zerosize to be a text editor. But what if a user wants to create a word processing document or a spreadsheet? If all empty files are considered to be application/x-zerosize, then clicking the icon of a newly created file named test.abw or test.xls won't open the appropriate application.

Obviously, if you never use that method of creating files, you need not take that into consideration (unless you were to remaster your Puppy for others to use).

Anyway, thanks for taking the time to read through this rather long-winded post. I was looking into the various standards and fear that, as a result, I have burdened this post with more detail than was necessary.

Good luck with your painting and coding.
Back to top
View user's profile Send_private_message 
greengeek

Joined: 20 Jul 2010
Posts: 2551
Location: New Zealand

PostPosted: Wed 26 Sep 2012, 17:29    Post_subject:  

miriam wrote:
haven't had time to play with that lately as I'm doing a series of paintings with a graphics tablet using Puppy - YAY!

I would be very keen to hear exactly which tablet and Puppy setup you are using to achieve this. My daughter is a keen painter but has to spend quite a bit of time in hospital so this sounds like a neat idea. Did you mean an actual tablet like a touchscreen tablet, or did you mean something like a wacom attached to a PC? Any tips? thx!
Back to top
View user's profile Send_private_message 
Display_posts:   Sort by:   
Page 1 of 2 Posts_count   Goto page: 1, 2 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » House Training » Users ( For the regulars )
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1622s ][ Queries: 13 (0.0052s) ][ GZIP on ]