Acorn Arcade forums: Programming: On filetypes and thumbnails
| |
On filetypes and thumbnails |
| |
Loris (15:48 12/4/2005)
rich (06:44 13/4/2005)
Loris (09:02 13/4/2005)
rich (09:20 13/4/2005)
Loris (10:00 13/4/2005)
rich (10:46 13/4/2005)
Loris (11:32 13/4/2005)
rich (13:28 13/4/2005)
monkeyson2 (14:38 13/4/2005)
rich (14:49 13/4/2005)
monkeyson2 (15:02 13/4/2005)
rich (15:24 13/4/2005)
instantiator (14:15 14/4/2005)
monkeyson2 (15:10 14/4/2005)
Loris (16:39 14/4/2005)
monkeyson2 (17:03 14/4/2005)
Loris (09:17 15/4/2005)
Phlamethrower (10:13 15/4/2005)
adrianl (11:42 15/4/2005)
instantiator (11:45 15/4/2005)
xyzzy (22:12 15/4/2005)
|
| |
|
Tony Haines |
Message #64231, posted by Loris at 15:48, 12/4/2005 |
 Ha ha, me mine, mwahahahaha
Posts: 1025
|
In the latest issue of Qercus there is an article by Steve Turnbull. He outlines his suggestion for a way to permit both more filetypes and allowing individual files to have their own icon.
Basically it is to encapsulate files inside the drawfile format (with a new filetype), with new object types for the metadata, and the file data itself.
Personally I think it is a good idea, but completely coopting the drawfile has disadvantages. I think a new format (actually probably very similar to the drawfile) would be preferrable.
Also a couple of his suggestions strike me as plain wierd.
Well? |
| |
 [ Log in to reply ] |
| |
|
Richard Goodwin |
Message #64238, posted by rich at 06:44, 13/4/2005, in reply to message #64231 |
 Dictator for life
Posts: 6828
|
Having drawfile-like icons is useful, as has been shown on other OSs - you can scale them to whatever size, which means you can having 'kin huge icons if you so wish with no loss of quality (and no need for our current small and large alternatives). You'd probably have to render them antialiased, cache them for speed, and if you want to get really tarty, have animation capability (e.g. use SVG not Draw).
Having an icon for each file via Draw capsulation seems a bit OTT however: say you have a text file that's really important, and you encapsulate it in a Draw file. It's now fairly useless, as every program that supports text (including your own simple BASIC tools) have to be updated to include Draw encapsulation support. And then you want to transfer it to the PC, or have it on your website, etc. etc. - it's now gibberish to most other people.
A better way, if you really must have icons for individual files, is to have the icons stored elsewhere. Either an "invisible" file in the same directory (a Mac like resource fork? One uber resource for everything in the directory, a little bit like Windows desktop.ini and thumbnail caches?) or a collection of them somewhere tucked away (perhaps in the Boot sequence). After all, I already have individual icons for some directories by having a sprite file in the Boot sequence - but then, all directories of the same name have the same picture on them, not just the one in the root of my hard drive. This could be expanded so all files of a certain name have an icon, but that might not be "individual" enough for you 
</2p>
________
 Cheers,
Rich.
|
| |
[ Log in to reply ] |
| |
|
Tony Haines |
Message #64241, posted by Loris at 09:02, 13/4/2005, in reply to message #64238 |
Ha ha, me mine, mwahahahaha
Posts: 1025
|
I agree that vector icons are good, although I'd like the option of providing a bitmap instead. (The article suggests using a sprite in the drawfile but I think it should just be pointed at directly). I'm not so sure about animation, it would make the desktop look a bit like the hamster dance.
The actual rendering would of course be up to the desktop to do at whatever quality was specified.
Incidentally, there already is a program which will display thumbnails in the filer, it is called Photofiler. It used to be freeware but now a (presumably updated version) is available commercially.
Having an icon for each file via Draw capsulation seems a bit OTT however: say you have a text file that's really important, and you encapsulate it in a Draw file. It's now fairly useless, as every program that supports text (including your own simple BASIC tools) have to be updated to include Draw encapsulation support. And then you want to transfer it to the PC, or have it on your website, etc. etc. - it's now gibberish to most other people. Yes, well. All preexisting formats could co-exist. And filetypes with no obvious preview or whatever wouldn't need one*. I'd imagine that plain text files would be left alone most of the time, since the absence of formatting is sort of the point.
So the use for it would be new native formats. Some generic formats already have thumbnail information (eg JPEG, in the form of EXIF files), and as time goes on probably more of these will arise. Files like this (and of course drawfiles) should probably remain unwrapped.
Space for these in plain filetypes would still be limited, although I suppose a plain wrapper could be used to add filetype information, this could be ripped off fairly simply, and applied fairly easily if the file type is known.
*actually he suggests that files without a 'preview' have a grey box with 'no preview' written in it but I think that is utter madness.
A better way, if you really must have icons for individual files, is to have the icons stored elsewhere. Either an "invisible" file in the same directory (a Mac like resource fork? One uber resource for everything in the directory, a little bit like Windows desktop.ini and thumbnail caches?) or a collection of them somewhere tucked away (perhaps in the Boot sequence). I think meta-data is OK in a separate file provided it can be regenerated from the file contents if necessary.
Anecdote about Mac stuff: Someone in my lab copied a lot of data, probably months of other peoples work to CD then deleted the original. He hadn't taken all that was required, so it was now unusable. Yes he was dumb not to check, but while this can happen the system is broken, in my opinion.
But this doesn't solve the problem of retrofitting this s#!t to RISC OS. The icons are a nice thing to have (and they aren't compulsory, or required for every file), but the important thing is really the other metadata.
One thing I've been thinking about is that perhaps filetype numbers are not the right way to go. A central allocation resourse is required. Wouldn't a filetype string be preferrable? There could be a defined format style for it. |
| |
[ Log in to reply ] |
| |
|
Richard Goodwin |
Message #64243, posted by rich at 09:20, 13/4/2005, in reply to message #64241 |
Dictator for life
Posts: 6828
|
I'm not so sure about animation, it would make the desktop look a bit like the hamster dance. It depends on your definition of animation - I was thinking of something more subtle, like the hands of a clock showing the correct time.
But it should be remembered that some people must have liked hamster dance, or why else would it have been so popular?
The actual rendering would of course be up to the desktop to do at whatever quality was specified. Yes, but you have to have an antialiased version for that to be an option 
Having an icon for each file via Draw capsulation seems a bit OTT however: say you have a text file that's really important, and you encapsulate it in a Draw file. It's now fairly useless, as every program that supports text (including your own simple BASIC tools) have to be updated to include Draw encapsulation support. And then you want to transfer it to the PC, or have it on your website, etc. etc. - it's now gibberish to most other people. Yes, well. All preexisting formats could co-exist.
They could, but then that's irrelevant to this discussion which is about the customisation. What I'm saying is, as soon as you add a custom icon, it's an encapsulated draw file, not the original file (if we go with Mr. Turnbull's suggestion). The file that's *being* encapsulated could remain upchanged nestling inside that Draw file, but that's by the by as you'd need to understand the encapulation to get it out again, and most programs/other OSs wouldn't.
And filetypes with no obvious preview or whatever wouldn't need one*. I'd imagine that plain text files would be left alone most of the time, since the absence of formatting is sort of the point. You're talking about preview, I was talking about custom icons. Two different things. The original post was about a "suggestion for a way to permit both more filetypes and allowing individual files to have their own icon".
You might want a really, really important Word doc to flash red or something, not preview the contents which would all look alike at a certain scale.
A better way, if you really must have icons for individual files, is to have the icons stored elsewhere. I think meta-data is OK in a separate file provided it can be regenerated from the file contents if necessary.
Then what's the point of having the meta data in the first place? If we're just talking custom icons, it doesn't really matter if it's there or not - if they become corrupted you just sigh and re-apply your pretty-pretty, but the original file is untouched. It's just window dressing. And if everything else can be generated from the file itself (date created, first paragraph of text etc.) it's probably best just left there. Although perhaps, as a compromise position, it could be cached - it's external, but can be regenerated from the original file.
________
Cheers,
Rich.
|
| |
[ Log in to reply ] |
| |
|
Tony Haines |
Message #64244, posted by Loris at 10:00, 13/4/2005, in reply to message #64243 |
Ha ha, me mine, mwahahahaha
Posts: 1025
|
But it should be remembered that some people must have liked hamster dance, or why else would it have been so popular? Hey, I liked the hamster dance. But I wouldn't want to live there.
The 'subtle' animation idea with the clock is interesting. Of course for that you'd need a programming language like Flash. Maybe that should be left 'till next time. We can burn another one of the 4096 later, once we are using 10Bip+ processors.
Yes, well. All preexisting formats could co-exist.
They could, but then that's irrelevant to this discussion which is about the customisation.
No it isn't. You built a straw man of everything needing to be encapsulated even when it would be counterproductive.
What I'm saying is, as soon as you add a custom icon, it's an encapsulated draw file, not the original file (if we go with Mr. Turnbull's suggestion). The file that's *being* encapsulated could remain upchanged nestling inside that Draw file, but that's by the by as you'd need to understand the encapulation to get it out again, and most programs/other OSs wouldn't. Actually it wouldn't be - quite. Because it would have its own filetype. But yes, this is a given. Which is why I said it would basically be limited to native formats (which PCs could recognise if they could be arsed, but probably won't), or would require a converter PC<->RISC OS. Steve T. recognised this. We actually have these programs already, they just work on filetypes and PC name-extensions.
You're talking about preview, I was talking about custom icons. Two different things. The original post was about a "suggestion for a way to permit both more filetypes and allowing individual files to have their own icon". Actually I'm still talking about that, just using different words for variety*. Oh, and it also allows other useful things. Did I mention that it would permit a helpful message instead of "filetype &xxx not recognised"?
*stupidity
You might want a really, really important Word doc to flash red or something, not preview the contents which would all look alike at a certain scale. Again that is beyond the scope of the original suggestion - I think this would be cool, but lets walk before trying run.
A better way, if you really must have icons for individual files, is to have the icons stored elsewhere. Actually, this would be a problem when things were moved around too. And it definitely isn't easy to retro-fit.
I think meta-data is OK in a separate file provided it can be regenerated from the file contents if necessary. Then what's the point of having the meta data in the first place? If we're just talking custom icons, it doesn't really matter if it's there or not - if they become corrupted you just sigh and re-apply your pretty-pretty, but the original file is untouched. It's just window dressing. And if everything else can be generated from the file itself (date created, first paragraph of text etc.) it's probably best just left there. Although perhaps, as a compromise position, it could be cached - it's external, but can be regenerated from the original file.
Quite. I think you've reached my position.
What no comment on my filetype strings suggestion? |
| |
[ Log in to reply ] |
| |
|
Richard Goodwin |
Message #64245, posted by rich at 10:46, 13/4/2005, in reply to message #64244 |
Dictator for life
Posts: 6828
|
The 'subtle' animation idea with the clock is interesting. Of course for that you'd need a programming language like Flash. Maybe that should be left 'till next time. We can burn another one of the 4096 later, once we are using 10Bip+ processors. SVG already has animation capability, using a simple Javascript-like language built in to the spec. The example image on the Adobe website is (or was, last I checked) a pocket watch with real-time hands.
Yes, well. All preexisting formats could co-exist.
They could, but then that's irrelevant to this discussion which is about the customisation.
No it isn't. You built a straw man of everything needing to be encapsulated even when it would be counterproductive.
No I didn't! I just said that the encapsulation idea as decribed in the first post is flawed! At no point did I say *every* file must be encapsulated!
To reiterate: encapsulate *one* *file* in accordance to the suggestion in the first posting, and that *one* *file* becomes useless to anything that doesn't support the encapsulation - all software would have to be updated to handle it, and other systems wouldn't uderstand it.
Hmm... unless the OS decodes it on the fly before it hits any software at all, which would have to happen before (e.g.) Samba and FTP transfers too. Not impossible given RISC OS's image file system, but then, why alter the Drawfile spec as Mr. Turnball suggests? Why not use (e.g.) an archive-style system that can contain the original file, a Draw/SVG file, a bitmap, and maybe some meta data like search terms and a title. So long as only the original file is seen when you try to access it, it might work.
However, currently the "archive" appears to be a directory, so you don't get the original file name. Example: using !ImageFS, you can get to a "sprite file" inside a JPEG image, but it's called something like ...image/jpg.sprite - not just image/jpg. So instead of encapsulation, just have directories to hold the cruft 
________
Cheers,
Rich.
|
| |
[ Log in to reply ] |
| |
|
Tony Haines |
Message #64246, posted by Loris at 11:32, 13/4/2005, in reply to message #64245 |
Ha ha, me mine, mwahahahaha
Posts: 1025
|
No it isn't. You built a straw man of everything needing to be encapsulated even when it would be counterproductive.
No I didn't! I just said that the encapsulation idea as decribed in the first post is flawed! At no point did I say *every* file must be encapsulated!
It looked to me like you were here (my emphasis):
Having an icon for each file via Draw capsulation seems a bit OTT however ... So nevermind.
You do realise that there could be 'standard' filetype icons too, don't you? Not every encapsulated file would need a unique icon. But for some formats (particularly graphical ones) it really makes a difference.
To reiterate: encapsulate *one* *file* in accordance to the suggestion in the first posting, and that *one* *file* becomes useless to anything that doesn't support the encapsulation - all software would have to be updated to handle it, and other systems wouldn't uderstand it. This is not an issue. If the format is 'new', having encapsulation makes no difference to its ability to be read elsewhere: nothing else can read it anyway.
If it is an 'old' format, or one standard on PCs, then, yes, encapsulation would affect the ability of PCs to use it. Which is why there would be a conversion program. encapsulated >> plain would be a standard process, so a single program would suffice for all formats. People (not me) already use such programs, which deal with filetyping issues, so it would possibly be *less* difficult for new users, if it were part of the OS. As you say, this could be made transparent on writing to a PC format. Of course there are considerations here. It would only be desirable for 'vanilla' wrappers of universal or non-native formats, and possibly not even then. Perhaps if when encapsulated files were on non-native media they were given a standard extension, and an option to decapsulate them?
... but then, why alter the Drawfile spec as Mr. Turnball suggests? Why not use (e.g.) an archive-style system that can contain the original file, a Draw/SVG file, a bitmap, and maybe some meta data like search terms and a title. So long as only the original file is seen when you try to access it, it might work. This would be a new file spec. The drawfile specification would persist unaltered.
I don't like your suggestion, as far as I understand it. |
| |
[ Log in to reply ] |
| |
|
Richard Goodwin |
Message #64250, posted by rich at 13:28, 13/4/2005, in reply to message #64246 |
Dictator for life
Posts: 6828
|
No I didn't! I just said that the encapsulation idea as decribed in the first post is flawed! At no point did I say *every* file must be encapsulated! It looked to me like you were here (my emphasis):
Having an icon for each file via Draw capsulation seems a bit OTT however ... So nevermind.
Sorry, I meant it in the context of the customisation system. If a file isn't being given a custom icon, then I'm assuming it just uses the existing filetype system (or something similar) and isn't in the scope of the discussion. I'm only going on a very limited amount in the first posting, as it's not possible for me to RTFA.
(Although, now you've started me thinking about it in this context and mentioning meta data... it's not a great stretch to imagine that many/all files might need to be updated to contain the meta data, to bring them in line with new, new stuff and old stuff that's had extras like icons added. Depends what you're doing with the new system I guess.)
You do realise that there could be 'standard' filetype icons too, don't you? Not every encapsulated file would need a unique icon. But for some formats (particularly graphical ones) it really makes a difference. Yes, I realise that there's standard filetypes, but if you're using the standard filetypes then I don't see the need for encapsulation, so I was leaving those out of it completely.
I'm assuming that the point of encapusalting things in Draw files is that you have the Draw "icons" in there, otherwise, I can't see the big win in using Draw files as opposed to, well, anything else. Is this not the case? Again, I don't have the full article to go on. I'm genuinely asking here, not just being argumentative - I just can't see the up side. I know there are a limited number of filetypes for new applications to use, but then, someone already wrote code that gets around that by diddling with the existing date/load/stuff (IIRC) to give an order of magnitude more filetypes, without breaking the existing stuff. Why is this not the best way to go? Why encapsulation? Why? Why?
To reiterate: encapsulate *one* *file* in accordance to the suggestion in the first posting, and that *one* *file* becomes useless to anything that doesn't support the encapsulation - all software would have to be updated to handle it, and other systems wouldn't uderstand it. This is not an issue. If the format is 'new', having encapsulation makes no difference to its ability to be read elsewhere: nothing else can read it anyway.
This is not how I'm reading the situation - what if you want to take an existing file of an existing filetype (e.g. a plain text file) and give it a custom icon? You still need it readable by things that understand plain text, but the file has been altered to contain a load of gibberish (as far as plain text readers would be concerned).
Obviously new stuff, e.g. a brand new word processor, could implement its own system - just as it would under the current system. But you've got to retain support the hundreds of file types out there now, many of which are industry standard (HTML, Word, JPEG etc.). Any customisation that breaks the ability to use these means you're locking RISC OS into its own little world.
... but then, why alter the Drawfile spec as Mr. Turnball suggests? Why not use (e.g.) an archive-style system that can contain the original file, a Draw/SVG file, a bitmap, and maybe some meta data like search terms and a title. So long as only the original file is seen when you try to access it, it might work. This would be a new file spec. The drawfile specification would persist unaltered.
I don't like your suggestion, as far as I understand it.
All I want explained is - why encapsulated draw files? What benifits do encapsulated Draw files have over any other system? Given that you wanted bitmap alternatives to icons (IIRC), why not have some kind of system that allows for storage of mutliple items of data?
It doesn't have to be they way I described it (IANAProgrammer), but I can't see the great benifits of the system being proposed other than some people can pretty up some files at the expense of compatibility.
________
Cheers,
Rich.
|
| |
[ Log in to reply ] |
| |
|
Phil Mellor |
Message #64254, posted by monkeyson2 at 14:38, 13/4/2005, in reply to message #64250 |
 Please don't let them make me be a monkey butler
Posts: 12380
|
I'm assuming that the point of encapusalting things in Draw files is that you have the Draw "icons" in there, otherwise, I can't see the big win in using Draw files as opposed to, well, anything else. Is this not the case? Again, I don't have the full article to go on. I'm genuinely asking here, not just being argumentative - I just can't see the up side. I know there are a limited number of filetypes for new applications to use, but then, someone already wrote code that gets around that by diddling with the existing date/load/stuff (IIRC) to give an order of magnitude more filetypes, without breaking the existing stuff. Why is this not the best way to go? Why encapsulation? Why? Why? It's a combo of two great things:
1. It's a Draw file, so you can import it into anything that can render Draw files.
2. It's the original file, so you can edit it in the application that created it.
If you've got a table editor, your Draw file would have the table rendered as paths and text, so you can drag it into any DTP app and it can display it instantly.
But because it's the original file you can still edit it in the creating application. The app-specific data is stored as a new draw object type which will get skipped over by the DTP's drawfile renderer.
Tablemate did this, so you could display its tables in Impression without Impression knowing anything about Tablemate, and use OLE to edit the table directly.
This I see as a good thing; the extra filetypes/metadata/icons I don't care for personally.
[Edited by monkeyson2 at 15:40, 13/4/2005] |
| |
[ Log in to reply ] |
| |
|
Richard Goodwin |
Message #64256, posted by rich at 14:49, 13/4/2005, in reply to message #64254 |
Dictator for life
Posts: 6828
|
It's a combo of two great things:
1. It's a Draw file, so you can import it into anything that can render Draw files.
2. It's the original file, so you can edit it in the application that created it. Still confused - what if the original file is something that isn't visual, like, um, a data file full of program choices? Random example plucked out of air: Impression dictionaries have their own filetype. You've stashed that inside a Draw file, which can be loaded as a Draw file and display... what? The icon? How is that different to dropping a WAV file into Impression and seeing an icon now?
This I see as a good thing; the extra filetypes/metadata/icons I don't care for personally. But we've already got what you've decribed, I don't understand how it helps in the whole filetype extension, custom icon debate. But yes, your example does look cool - so long as you don't edit the Draw part in a Draw file editor so it no longer resembles the table data
________
Cheers,
Rich.
|
| |
[ Log in to reply ] |
| |
|
Phil Mellor |
Message #64257, posted by monkeyson2 at 15:02, 13/4/2005, in reply to message #64256 |
Please don't let them make me be a monkey butler
Posts: 12380
|
Still confused - what if the original file is something that isn't visual Why would you be trying to add something non-visual to a DTP document? Duh!
like, um, a data file full of program choices? Program choices should be plain text/xml anyway.
Random example plucked out of air: Impression dictionaries have their own filetype. You've stashed that inside a Draw file, which can be loaded as a Draw file and display... what? The icon? How is that different to dropping a WAV file into Impression and seeing an icon now? Well a sound file could have the waveform as the draw version. That would be dead useful.
Impression dictionary - text area of the words?
[Edited by monkeyson2 at 16:05, 13/4/2005] |
| |
[ Log in to reply ] |
| |
|
Richard Goodwin |
Message #64258, posted by rich at 15:24, 13/4/2005, in reply to message #64257 |
Dictator for life
Posts: 6828
|
Still confused - what if the original file is something that isn't visual Why would you be trying to add something non-visual to a DTP document? Duh!
Because it's a Draw file
like, um, a data file full of program choices? Program choices should be plain text/xml anyway.
That's a very Microsoft-like redefinition of the problem
Well a sound file could have the waveform as the draw version. That would be dead useful.
Impression dictionary - text area of the words? It seems like we're off on a tangent now, but I can see some merit to having this as a kind of preview. But wouldn't this be best suited to a filer preview rather than as a Draw file?
________
Cheers,
Rich.
|
| |
[ Log in to reply ] |
| |
|
Lewis Westbury |
Message #64265, posted by instantiator at 14:15, 14/4/2005, in reply to message #64238 |
Member
Posts: 365
|
Having an icon for each file via Draw capsulation seems a bit OTT however: say you have a text file that's really important, and you encapsulate it in a Draw file. It's now fairly useless, as every program that supports text (including your own simple BASIC tools) have to be updated to include Draw encapsulation support. And then you want to transfer it to the PC, or have it on your website, etc. etc. - it's now gibberish to most other people. unless the filesystem ungibberishes the files invisibly for you... |
| |
[ Log in to reply ] |
| |
|
Phil Mellor |
Message #64266, posted by monkeyson2 at 15:10, 14/4/2005, in reply to message #64265 |
Please don't let them make me be a monkey butler
Posts: 12380
|
Having an icon for each file via Draw capsulation seems a bit OTT however: say you have a text file that's really important, and you encapsulate it in a Draw file. It's now fairly useless, as every program that supports text (including your own simple BASIC tools) have to be updated to include Draw encapsulation support. And then you want to transfer it to the PC, or have it on your website, etc. etc. - it's now gibberish to most other people. unless the filesystem ungibberishes the files invisibly for you...
Still no use on a network drive though, surely?
Also, if you're transparently ungibberishing files, applications can't make use of the 'hey, this is a drawfile' benefits. |
| |
[ Log in to reply ] |
| |
|
Tony Haines |
Message #64267, posted by Loris at 16:39, 14/4/2005, in reply to message #64266 |
Ha ha, me mine, mwahahahaha
Posts: 1025
|
unless the filesystem ungibberishes the files invisibly for you...
Still no use on a network drive though, surely?
Also, if you're transparently ungibberishing files, applications can't make use of the 'hey, this is a drawfile' benefits.
I've been thinking about this.
If an app can cope with new file formats it could use a new SYS call, or bit set in the old ones, or something. If its an old one, then the file can be supplied decapsulated. Careful design of the format could make this fairly painless I think.
Any modification of a file* without the updated bits should either decapsulate it or cause reversion to a vanilla capsule. Given this it would be useful for the OS to know whether the icon is a representation of the file, or a distinguishing icon.
*bytewise editing rather than just block overwriting - which must just decapsulate.
You do realise that there could be 'standard' filetype icons too, don't you? Not every encapsulated file would need a unique icon. But for some formats (particularly graphical ones) it really makes a difference. Yes, I realise that there's standard filetypes, but if you're using the standard filetypes then I don't see the need for encapsulation, so I was leaving those out of it completely.
Aaah, you misunderstand. There could be new filetypes for which some or all files don't have individual icons. These could have standard, filetype-wide icons.
I'm assuming that the point of encapusalting things in Draw files is that you have the Draw "icons" in there, otherwise, I can't see the big win in using Draw files as opposed to, well, anything else. OK, apart from the fact, which I've tried to emphasise, that these are NOT DRAWFILES.
Having them exactly the same format would be stupid. Although I don't think Steve doesn't say it explicitly, I think its quite clear implicitly.
The article explains the chain of reasoning by which the idea arose, and indeed the starting point was the drawfile format.
The important thing for our purposes is that there is a standard header, then tagged objects inside. Besides the icon, there are other advantages to encapsulating:
More filetypes
Help on unrecognised filetypes
Other metadata
A very important part of the proposal is that it can be introduced into RISC OS. It isn't a new system from scratch, it has to be able to 'work gracefully'*. That is, people must widely adopt the system for it to to work. The system must work at all intermediate stages. Given these, it must be possible to retrofit to older versions of RISC OS. It may not have all desirable properties (like your animation system), but we should be able to 'get there from here'.
*This is my invented term, so blame me if you don't like it, not Steve T.
I might post on the other points, but not today; I'm too tired now. Bear in mind, Rich, that Mr Monkeyson and myself are going off in slightly different directions. I'm advocating changing things slightly, he is talking about whatever part of the article is most appropriate. Sometimes I confuse even myself |
| |
[ Log in to reply ] |
| |
|
Phil Mellor |
Message #64269, posted by monkeyson2 at 17:03, 14/4/2005, in reply to message #64267 |
Please don't let them make me be a monkey butler
Posts: 12380
|
Any modification of a file* without the updated bits should either decapsulate it or cause reversion to a vanilla capsule. Given this it would be useful for the OS to know whether the icon is a representation of the file, or a distinguishing icon.
*bytewise editing rather than just block overwriting - which must just decapsulate. Sounds like fudging and bodging to me.
Are you advocating encapsulating standard/multiplatform formats like JPEG, HTML, GIF, etc? Because that would be a nightmare. If I copy/save/edit an encapsulated file on a pen drive or remote network share, and it remains encapsulated, it would be useless for any other platform.
If you only encapsulate on local/ADFS, what's the point?
If you only encapsulate on native format files, what's the point?
I guess you'd have to have an image filing system (like ImageFS) for that sort of thing. It gets more twisted and horrible the more I think about it
Edit: too many winks
[Edited by monkeyson2 at 18:03, 14/4/2005]
[Edited by monkeyson2 at 18:13, 14/4/2005] |
| |
[ Log in to reply ] |
| |
|
Tony Haines |
Message #64293, posted by Loris at 09:17, 15/4/2005, in reply to message #64269 |
Ha ha, me mine, mwahahahaha
Posts: 1025
|
Are you advocating encapsulating standard/multiplatform formats like JPEG, HTML, GIF, etc? Because that would be a nightmare. If I copy/save/edit an encapsulated file on a pen drive or remote network share, and it remains encapsulated, it would be useless for any other platform. I'm not sure whether I am or not. I suppose that it would be optional.
If you only encapsulate on local/ADFS, what's the point?
If you only encapsulate on native format files, what's the point? Thats a bit defeatist isn't it?
I think we have to accept the fact that we may lose the meta-data on transfer to other systems.
Macs create a second file, with a funny name. This could be done instead of discarding the data, on transfer.
But then, the obvious question is: why not have the data in a second, hidden file to start with? I guess the answer is that it would be easier to cope with within the OS. I believe it would be much easier, and would break less. A fringe benefit is that new file formats would at least be easily distinguishable.
Regarding your second question, I think the advantages would still be numerous. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #64295, posted by Phlamethrower at 10:13, 15/4/2005, in reply to message #64293 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Is this a good time to mention next-generation filing systems based around object oriented databases? |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #64297, posted by adrianl at 11:42, 15/4/2005, in reply to message #64295 |
Member
Posts: 1637
|
Is this a good time to mention next-generation filing systems based around object oriented databases?
Only if the next part of the sentence is ".... and here's one I made earlier." |
| |
[ Log in to reply ] |
| |
|
Lewis Westbury |
Message #64298, posted by instantiator at 11:45, 15/4/2005, in reply to message #64293 |
Member
Posts: 365
|
I think we have to accept the fact that we may lose the meta-data on transfer to other systems.
Macs create a second file, with a funny name. This could be done instead of discarding the data, on transfer.
But then, the obvious question is: why not have the data in a second, hidden file to start with?
Hidden files. Can we do that yet? When is ADFS2 coming out? (Is it coming out? I remember hearing talk about it and forgot if anyone predicted a release date...) Will it be stuffed full of goodies like wot we're talking about? |
| |
[ Log in to reply ] |
| |
|
Andy Wingate |
Message #64330, posted by xyzzy at 22:12, 15/4/2005, in reply to message #64298 |
Member
Posts: 25
|
When is ADFS2 coming out? (Is it coming out? I remember hearing talk about it and forgot if anyone predicted a release date...) Will it be stuffed full of goodies like wot we're talking about? Is this where someone does
*Help ADFS
==> Help on keyword ADFS
Module is: ADFS 3.35 (03 Apr 2003)
Or do we wait until next Pungeday? |
| |
[ Log in to reply ] |
| |
|
Acorn Arcade forums: Programming: On filetypes and thumbnails |
