“The OpenBeOS Translation Kit BETA 1 is now available. It contains the Translation Kit library, BMP translator, StyledEdit files translator, TGA translator and the source and project files for all of the above. Also, the BMP and TGA translators should have more capabilities than the BMP and TGA translators that came with BeOS R5.” You can download the beta at the OpenBeOS website.
*sigh* isn’t posting it once good enough? Besides, on that, I really have to wonder why would any company pick JLG was their CEO. Makes no sense. Maybe even if Microsoft really killed Be, Gassee isn’t even close to a good businessman…
1) jlg rules. I’d love to see us do any better under the same conditions he faced trying to cmpete fairly in a tough market
2) lighten up
Closer every day…. let’s take those last few steps and get this R1 baby rocking this place =)
Hey, the translation kit is in Beta, that is definitely something!
Congrats to the team.
Its wonderfull to see the new translation kit become a reality,
The Translation kit is one of those things that makes BeOS somthing special
Nice done guys!
Thanks!
/Konrad
Nice to see obos going ahead!
I tried out the kit and it works just fine (and it seemed to be a bit faster too!)
Congrats to obos team!
Now if only OBOS could keep the OBOS name, and not be lost in the myriad of other obscure hobbyist OS names, people might actually know what it is and remember what it stands for and show some interest!
Hey,
I’m a new bie to BeOS, but a firm supporter…just what is the translation kit? and what can one do with it?
Rgds.
Just when I start getting a little disheartened by the seeming LACK of progress… the MIDI kit (FINALLY!) start making moves and then the Device APIs are beining worked on and now the Translation kit is beta!
Guess you guys are really getting motivated by Zeta’s looming presence, eh? 🙂
Keep up the good work!
BTW, what’s the status of the OBFS? Last I read it was 99.999% complete and then some annoying bugs were found and now… ???
Luposian
“I’m a new bie to BeOS, but a firm supporter…just what is the translation kit? and what can one do with it? ”
This is an OS service that offer to every application a way to “understand” any kind of file format, in a centralized way. For each format (bitmaps, text documents, etc), one can develop a file format “driver” that can be used by all application.
For exemple, I create a bitmap translation driver for GIF format. I register it in the OS, then EVERY graphics applications that use the translation kit can load and save GIF files.
I can download a driver for Microsoft WORD file format. Once registered, all of my word processors (using translation kit) can load an save using the MS-Word file format.
And so on. It’s just that : a drivers architecture for file format.
My mind is just playing with the idea of porting the Translation Kit to other operating systems – wouldn’t it be cool to have this available on OS X, Windows and the free Unix crowd as well?
Sigh .. i agree but the problem is that because it hasn’t been there from the start 100% of current apps won’t use it and I doubt most (if any) would rewrite their app *just* for this functionality – mores the pity.
Great work OBOS! All you people are doing a great job, and more importantly, you seem to be doing it in a professional manner. Keep it up…
Great to hear of the progress of OpenBeOS. Between this and Oleg Madox Weekly updates on Il2 FB, I’m thinking, 2003, great year for me (-:
Hope to hear more from the OpenBeOS team on a regular basis. Nothing like keeping the community in the loop if you know what I mean.
Take care and all the best.
Sigh .. i agree but the problem is that because it hasn’t been there from the start 100% of current apps won’t use it and I doubt most (if any) would rewrite their app *just* for this functionality – mores the pity.
Retail BeOS has a Translator kit, almost all BeOS native apps use the built in one. This one is a replacement, so yes, all existing BeOS native apps benefit from the new translator – thats the beauty of translators, apps dont care how the conversion is done, its up to the OS to provide the translation service.
Translators are really a great idea, even the Amiga had something similar (Datatypes). In 15 years or so, even the major OS’s will finally implement this ‘innovative’ idea.
SmallStepForMan,
The comment was talking about the unfortunate reality of our beloved translation kit being ported to other OSes. On any OS other than BeOS or its distant cousins, it would have little impact because it wasn’t there from the beginning. That is what the poster was trying to say.
Keep up the great work everyone.
Regards,
Maverick
Thanks Jason. Your correction makes perfect sense. I need to cut down on the scotch and marujuana…
While I’ll offer congratulations on the OpenBeOS group’s achievement, I think a few people here are far overstating the usefulness of translators.
Why is that? Because the entire point of a translator architecture is to expose similarities between various file formats, but in reality, file formats tend to have less in common than you might think.
For example, what about animated GIFs? Any bitmap translator architecture probably won’t be able to view GIF images. And what about layered images? Sure, there was a BeOS translator to read Photoshop images, but it could merely flatten the layers; that’s fine for an image viewer, but an image editor obviously couldn’t use the translation kit for reading in Photoshop files because of that.
The most famous example was in MPEGs in R5 for the BeOS (whether this has since been worked around I don’t know). Opening a large MPEG file, say a few hundred megs, could take a looooong time (up to ten minutes, sometimes). Why? Because some movie formats contain detailed information about the various frames and whatnot, and some take a more streaming approach. Essentially, the BeOS’ media player had to read through the entire MPEG movie to analyze its layout. For further examples, open up a bunch of various file types in Windows media player and try to jump around within the files; some jump immediately, and some have to buffer, based on the decisions of the file format. A translation kit that pretends these differences don’t exist leads to many problems (as the BeOS’ slowness is opening MPEGs wonderfully demonstrates).
This gets worse with things like word processing documents, where there isn’t even close to a standard feature set among word processors and their file formats. Overall, I’d say translators tend to work fairly well for image formats–the problems I mentioned notwithstanding, of course–and sound formats. After that, although they sound like an elegant idea, the reality isn’t as impressive.
As a final issue, never forget that translators only help users indirectly, not directly. The idea is that they help users by allowing for better applications (because they can support more formats, etc.). However, making things easier for the programmers doesn’t necessarily make things any better for the users. Most people are accustomed to complete applications that support all of the important file formats, anyway, so having a tranlation system doesn’t necessarily offer users any new features. Techies have a habit of equating good features for programmers to a better experience for users, when this isn’t always the case. It’s important to distinguish between direct and indirect user benefits.
Untill now there was no way for the community to improve the translator kit itself, We can iron out Translator problems as we go
The Translation kits primary goal is to provide a system wide way
of understanding files, When you convert a file its preferable you
save it in the Native file format that the app was designed for.
Looking at all my translation modules and the translators avalible for Download I don’t even see a translator for Mpeg, Ive personally
never had much waiting opening large Mpegs in Media Player
Oops…….I meant “…probably won’t be able to view animated GIF images.” Probably clear from what I was writing, but just in case…
As for Travis’ comment, it’s not that the BeOS’ TranslationKit implementation was poor or anything like that; it’s simply that a translation kit in concept is only useful for exploiting “identicalities” across file formats. Any differences will cause problems (such as the ones I mentioned in my previous post, as well as other things such as when certain formats are lossy, and so on).
As a final, unimportant response, have you ever tried opening a large (say, hundreds of megs) MPEG-1 file in the BeOS–stock R5, at least? It was even an acknowledged bug in Be’s bug database.
Actually I have, Ive viewed Lord of the Rings MPG and Star Wars Episode 2, both very very very large, I had minimal load times
bkakes, While at first glance with a brilliant mind what you said seems perectly intelligent and unflawed, it is not.
File formats naturally are not simple matters, if you wish your program to take advantage of the layers individually for editing, you call the layers from the array given by a supporting translator.
Movies don’t take long to load because of BeOS, but instead of the bundled Media Player. I suggest you download Video Lan Client and watch as your 600MB video loads in less than 1/1000th of a second!
Also, having a translation kit is useful for users. They can save a file in one program and not worry if the other program they have to do something else can use it. No compatibility issues.
If they can’t open a file, all they have to do is download a measly 15kb translator (compressed of course), install it, and then open the file with ease forever. This also allows the ability for developers to work on replacement translators, so if a user has been having troubles saving PNGs, they can look for a new version of the translator (or run the Updater in Zeta, which is a bit silent about what it does (though you can view the updates and install manually via Net+)).
This is of great value to everyone. Especially kids trying to do homework! When I was still in school, I did indeed use BeOS to do my reports, and naturally they always looked great until the teacher wrote all over it with red ink ;-(
Back to the file format standards..
text documents all have one similarity.. Text. Now, it is up to the programmer how the program will use the Translators, not the user. So this is NO big deal!
If the Text Editor is meant to be a full featured text editor, then you can open Word or GP docs with it if the translators are installed and get the results you desired more or less.
If the editor is meant to be simple, then you get at least the text from it, and most likely some garbled mess that is usually sent to the advanced editors. But what is bad about that? It is more likely to happen in a non-centralized stytem than a kit-based system, with less tweakable results.
Now, as far as animations, that is a different thing. All the coder does is run the frames at a certain pulse rate in accordance with what the translator says, I’d imagine. I have not done animations from files, though I have coded and worked on coded animations.
The user will benefit still in the same manners.
–The loon
PS: If you wish to use your system, use it wisely and you will be surprised at how much can be done. This is an OS-independent statement. BeOS users become burnt out on awesomeness and are no longer awe-able in short order.
Actually I have, Ive viewed Lord of the Rings MPG and Star Wars Episode 2, both very very very large, I had minimal load times
I sincerely doubt that you had MPEG-1 encoded versions of those movies. Each would be many gigabytes in size.
Movies don’t take long to load because of BeOS, but instead of the bundled Media Player. I suggest you download Video Lan Client and watch as your 600MB video loads in less than 1/1000th of a second!
VideoLAN doesn’t use the TranslationKit! My point wasn’t that the BeOS can’t load movies correctly–it was an example of the kinds of problems that can happen when you attempt to abstract two fundamentally different things to the same base object (in this case, movies). The point was that the TranslationKit made certain assumptions about movies, and that in order to make MPEGs conform to them, doing an analysis of the entire file was required. I don’t think you understood my post–I don’t see how you could even mention VideoLAN had you understood it. I don’t mean to be rude, but it’s just so obviously irrelevant.
If they can’t open a file, all they have to do is download a measly 15kb translator (compressed of course), install it, and then open the file with ease forever.
My point is that it’s not always that easy. For example, an image viewer like ACDSee that was written with the considerations of the various file formats in mind will support animated GIFs, while no BeOS image viewer that uses the TranslationKit to get BBitmaps ever will. Again, you’re arguing in a world of theoretical perfection (and, again, restricted to images, where translators were the most successful, along with sound files) rather than responding to the points that I made.
This is of great value to everyone.
You haven’t shown why. Whereas I showed why it isn’t always (and that’s why ACDSee will always be a better image viewer than a program relying on a generic bitmap translation layer, and Windows Media Player will always be a better program than a program relying on a generic movie translation layer).
If the editor is meant to be simple, then you get at least the text from it, and most likely some garbled mess that is usually sent to the advanced editors.
That makes no sense. The whole point of an abstraction layer is that the program gets the object without worrying about how it’s saved.
BeOS users become burnt out on awesomeness and are no longer awe-able in short order.
BeOS users also have a tendency to pretend that all features benefit the user. I have demonstrated one area in which that really isn’t the case.
I don’t get it–you say that I’m wrong but then post nothing which contradicts what I say, and more or less evade my point entirely. I’m really not saying this in a rude manner–flaming is not my goal–but I don’t understand what you intended for people to get out of your post.
bkakes – if you loved BeOS before and now hate it, this is no reason for confusing others or lie.
Open /boot/beos/system/add-ons/Translators or /boot/home/config/add-ons/Translators.
DO YOU SEE THERE something about audio-video there????
No. You don’t
Translators concept in BeOS don’t touch AV.
AV is done by other tools, mainly undocumented – extractors, encoders/decoders etc.
So, if there are flaws in mpeg EXCTRACTORS, you cannot blame translation kit concept. This is different area
Yeah, there is similarity in AV handling and translators – centralized repository. That’s all. But “centralisation” isn’t anything very different form other OS-es. Under Windows apps use common decoders/encoders for AV.
Media Kit is “special” for other reasons
Time is money so I’ll be short and straight.
bkakes has shown a good example of where BTranslators does not make sense. For that he gets a point, thank you.
On the other hand, bkakes may have been thinking BTranslators are the cure for all translation requirements. For that, he is a bit wrong, or should I say waaaaayy wrong.
All in all, BTranslators have their use, though. It’s just the part where the designer has to figure out what it is best for.
Ok. Let’s get this straight:
1 – Translators are not related in any way with videos under BeOS, as pointed out by s_d.
2 – The reason MPEG files act the way they do under BeOS is because the BeOS media kit (which was a good idea badly implemented, IMHO) expects video files to have indices so it can skip around inside the file. MPEG video files (not MPEG-4) does not have the required indices so it must be generated on-the-fly by the MPEG extractor. In the standard R5 media kit it was done by reading the entire file and creating an index table and, then, playing the movie. In the Media Kit Beta 1 (the new media kit that was never released), they changed it to generate the indices in a secondary thread so the videos started to play right away.
-Bruno
s_d:
bkakes – if you loved BeOS before and now hate it, this is no reason for confusing others or lie.
Ok, let’s get a few things straight. 1) I wasn’t lying. I happened to be mistaken about one thing (which, incidentally, made no significant difference to the point of my posting, which, I might add, you never addressed). 2) I don’t hate the BeOS. Never in this post did I ever insult the BeOS, other than use an aspect of it to demonstrate why generalized abstractions are not always good things. I simply dislike when people spout off about how great a feature is without fully considering it (as did the people here who talked about how we could have translators for everything), and without even considering whether that feature has any benefit to the user. 3) The fact that I was calm and careful in stating my case while you were fairly rude about correcting a tangential point without even touching the main point might suggest something.
nymia:
On the other hand, bkakes may have been thinking BTranslators are the cure for all translation requirements.
I never said that. But a lot of other people here sure have. The precise intention of my post was to explain why they are not the cure for all translation requirements!
Bruno:
1 – Translators are not related in any way with videos under BeOS, as pointed out by s_d.
My mistake. However, the point of my post wasn’t to detail how the BeOS handled it, but to demonstrate the problems with abstracting two different filetypes to the same base level. In that regard, I do not consider my posting to be flawed; the video files example is still relevant.
2 – The reason MPEG files act the way they do under BeOS…
You provided more specific information about the problem, but note that we said the exact same thing. To repeat for the second time, the intention of my post was not to bitch about BeOS movie playing, but to demonstrate problems with poor abstractions.
I appreciate your corrections, Bruno, although they are tangential to the point of my post.