Can zero-sized (empty) documents display as a special icon?

Using applications, configuring, problems
Post Reply
Message
Author
User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

Can zero-sized (empty) documents display as a special icon?

#1 Post by miriam »

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.
Last edited by miriam on Tue 04 Sep 2012, 06:11, edited 2 times in total.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

User avatar
`f00
Posts: 807
Joined: Thu 06 Nov 2008, 19:13
Location: the Western Reserve

#2 Post by `f00 »

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.

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#3 Post by miriam »

Thanks for the light-hearted humor :) 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.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#4 Post by npierce »

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: Select all

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.
Attachments
ROX-Filer.diff.gz
Changes made to add application/x-zerosize support
(940 Bytes) Downloaded 194 times
application-x-zerosize.png
/usr/local/apps/ROX-Filer/ROX/MIME/application-x-zerosize.png
(1.07 KiB) Downloaded 374 times
application_x-zerosize.gz
/root/Choices/MIME-types/application_x-zerosize
(82 Bytes) Downloaded 196 times

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#5 Post by miriam »

Wow! Amazing! I'm very grateful. I'll try this out later today and report back.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#6 Post by miriam »

I couldn't wait to try it out. :) 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!
[color=blue]A life! Cool! Where can I download one of those from?[/color]

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#7 Post by npierce »

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.

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#8 Post by miriam »

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 :) ).

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".)
[color=blue]A life! Cool! Where can I download one of those from?[/color]

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#9 Post by npierce »

(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.

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#10 Post by miriam »

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: Select all

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.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#11 Post by miriam »

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.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#12 Post by npierce »

miriam wrote:Just hand-edit the /usr/share/mime/globs file and add at the end:

Code: Select all

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/form ... 0105.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.

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#13 Post by miriam »

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. :)
[color=blue]A life! Cool! Where can I download one of those from?[/color]

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#14 Post by npierce »

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. :)
Assuming that the grindstone wasn't invented before the Pleistocene epoch, you can't keep your nose to it until you get there. :)

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.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#15 Post by greengeek »

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!

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#16 Post by miriam »

Previously I used an old-style RS232 serial com port Wacom, which I had working with Puppy after a lot of futzing around and helped by trailblazing done by others here on the Puppy forum. With recent changes to the Linux Kernel I have been unsuccessful in getting the Wacom tablet to work anymore so I'd been considering going out and buying a new USB Wacom tablet, but had been putting it off as I never seem to have enough money (starving artist syndrome).

Recently I was wandering around in a Jaycar electronics shop (geek, yes) and saw a surprisingly cheap (about $50 if my memory serves me correctly) Varexx graphics tablet. I bought it because I figured that if I couldn't get it working on Puppy I could donate it to my artistic niece who misguidedly uses Microsoft Windows. It comes with MSWindows and Macintosh installers (they're the only two operating systems on the planet aren't they? http://en.wikipedia.org/wiki/List_of_operating_systems -- a bit of a sore point with me).

The Varexx is one of a whole class of cheap tablets called "Wizardpen" tablets. I found that there is a healthy amount of ongoing development concerned with getting them to work under Linux. It was a little complicated getting it to work, but I finally did manage it. It works perfectly. It doesn't have the resolution of a Wacom tablet, but for $50 it is amazing.

One thing you have to be careful of is the setting in Gimp. In Gimp's Preferences >> Input Settings >> Configure Extended Input Devices, you need to disable all pointers except the tablet. (Can't remember off-hand what it's called -- Tablet WP5540U perhaps. If you get one that may be different.) Anyway disabling other input devices lets you use the tablet, otherwise Gimp gets confused.

Here is some of the stuff I found:

https://launchpad.net/wizardpen
https://help.ubuntu.com/community/TabletSetupWizardpen
http://www.serkey.com/ubuntu-wizardpen- ... ecf68.html
http://digitalbluewave.blogspot.com.au/ ... -ibex.html
http://ubuntuforums.org/archive/index.p ... 04537.html

google searches:
download wizardpen driver ubuntu
ubuntu graphics tablet drivers

Good luck with whatever you choose. If you want some more useful detail on getting it to work, please feel free to ask me. It would be nice to save someone else some of the frustration I went through.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

User avatar
Hotdog
Posts: 134
Joined: Fri 30 Sep 2011, 03:15
Location: Georgia USA

Wacom UD-II, Digitizer II serial tablet

#17 Post by Hotdog »

Miriam, what version of Puppy Linux did you have the serial graphics tablet working on? I'm using Puppy Lucid 5.2.8 and have a Wacom Digitizer II serial unit. Although I've read that 18-page forum topic started by Pizzasgood and the WacomLinux project material several times, I decided that the X Server (1.7.6) used in Puppy 5.2.8 made it impossible. I sure would like to be wrong on that.

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#18 Post by miriam »

Sounds like yours might be the same or similar to mine. I think I last had it working in Puppy 4.3.1
On my main desktop machine machine I have partitions for Puppy 2.1.4, Puppy 4.3.1, and Puppy Lupu 528.

I'm pretty sure I had it working in Puppy 2.1.4 and almost certain I had it working in Puppy 4.3.1, but was never able to get it working in Lupu 528. That doesn't mean it's not possible, of course. I may have been simply overlooking some tiny detail -- that's all it takes, unfortunately. I tried for quite a while to get the WizardTablet drivers to work with my cheap little Varexx tablet on Puppy 528 and almost gave up, but luckily I tried again another day and solved it. Normally I keep notes, but unfortunately I didn't that day, so I'm not quite sure what I did right. :(

One thing I would definitely advise. Try to note down everything you do, both the things that work and those that don't -- don't just trust your memory. The notes help you zero in on the solution, and it is incredibly useful later on when you want to install on another machine or version of Puppy.

I should really have another shot at trying to install my Wacom on Puppy 528, as it is a much better tablet. Now that I've had some success with the other tablet...

If I succeed I'll post here with details.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

User avatar
Hotdog
Posts: 134
Joined: Fri 30 Sep 2011, 03:15
Location: Georgia USA

Wacom Digitiazer II serial port

#19 Post by Hotdog »

Miriam,

Thanks for the reply. The old Walcom Digitizer II, also known as the UD-Series, has a drawing surface of 8.5 x 6.5 inches with a row of soft keys across the top. It is a real pleasure to use. Just cannot make myself discard it.

I'm not giving up, even partial success would be welcome. Obviously, the demise of the serial port minimizes the interest level.

User avatar
miriam
Posts: 373
Joined: Wed 06 Dec 2006, 23:46
Location: Queensland, Australia
Contact:

#20 Post by miriam »

Yep, same as my Wacom tablet. It is a pleasure to use, as you say. I have some visitors coming today and had to go out yesterday (this is no kind of lifestyle for a hermit!), but hopefully tomorrow I can reserve the day for the Wacom. Such efforts proceed best if uninterrupted.

If I can get it working I expect it will be pretty complete. One of the things I found very useful when using it on earlier Puppies was that I could reverse the stylus and use it as an eraser. So convenient when deeply involved in working on a picture! The driver was able to detect the angle of the stylus, but I don't think I ever made use of it when drawing and painting in Gimp. I never bothered looking into using the soft keys on the pad.
[color=blue]A life! Cool! Where can I download one of those from?[/color]

Post Reply