Replicants are classes unarchived from an add-on. They live in the address space of the application which is hosting the replicant, and would therefore only have the translation strings available to the host application by default. Read the article here. Update: OpenBeOS also published their newsletter with another article about replicants.
Zeta Developer Articles: Localizing Replicants
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
They might at least learn a bit of HTML before they post code with angle brackets 😉
Luke McCarthy wrote:
They might at least learn a bit of HTML before they post code with angle brackets 😉
the only angle brackets I see are not html tags …
#include <app/Roster.h>
#include <storage/Path.h>
#include <locale/Locale.h>
From the OpenBeos newsletter, it seems that OpenBeos is very close to an alpha release according to Michael Phipps:
“What I would like to ask every developer to do is this: put everything else aside for one month. Put one month into OpenBeOS. We have lots of areas that can be finished in one month of concentrated development. I would love to be able to demo a bootable, functional alpha of R1 at WalterCon.”
I wish it were that close. What I expressed was a wish. A dream. What I would like. What would it take to get there? I don’t know for sure. Maybe 50 more developers for the next month. That is a wild guess. We have lots of pieces that are complete. Others not so much.
@Luke McCarthy
When you have some constructive critism, let me know, otherwise – sheesh pull your head in.
I think your newsletter was one of the better ones. I agree that including some main apps are advisable _especially_ the IM Kit that you mentioned as well as a browser ofcourse.
It would be exciting if the community responded to your call, but I think you might have underestimated the value of the new name and the new website and all. I think that the community will actually grow as a part of that very reason when it happens. Ofcourse it’s great that you do it in a professional manour with a presentation and so forth, but still, it’s just taken far to long to present it.
Also, it’s not very clear what areas need to be worked on. The statuspage is not up2date and for newcomers it’ll take a month just to figure out where you are, quite unefficient if you ask me.
Don’t want to bring you down or anything, I’m still waiting _eagerly_ to start using XXXX R1 (whatever XXXX will be).
Oh, and note that this first GUI boot is also something that would be of high value as some australian pointed out a year ago…
good luck =)
I have always liked BeOS replicants and I think it is a shame that they didn’t become more popular. I would have liked to have seen some of the windowmaker dockapps ported over as replicants or even a standard library for easily adding and removing replicants to the deskbar or desktop.
I am sure though that quite a few BeOS programmers have unfinished replicants lying around, I know I certainly do!
Replicants pose interesting possibilities and limitations. Speaking from the viewpoint of a developer, the advantages of a replicant are its obvious attributes: creating a bit of code that can be embedded in a completely different application is amazing. I once created a replicant quit button; not very useful, but it was interesting to be able to drag the button to the desktop (Tracker), click the button and watch Tracker shut itself down. 🙂
The down side of replicants, besides the occasional headache trying to get it to work and keep it working, is that for them to truly be able to interact with a host application, the replicant developer needs to know something about the host application(s). In general, (s)he would need to know what BMessages (s)he can send to the host and which ones (s)he mustn’t. For instance, that quit button I mentioned might sent B_QUIT_REQUESTED to the parent window; that might close just a single window in a host application or the whole thing. Without knowing anything about the host app, the behavior is pretty much unknown. Likewise, if I had sent an arbitrary what value to the host, say 0x1000, who knows what would happen?
From my perspective as a former Be QA/QC Pit Slave, I think it should be noted that removing replicant technology and abilities was discussed several times. The reasons were mainly that replicants were a bit tricky to develop and were not being used. Some questioned their usefulness because of the reason I illustrated above: some knowledge of the host application is generally required for useful replicants. Or vice versa: for a host application to properly take advantage of a replicant, it needs to know something about the replicant’s API. With open source software and open API’s this isn’t a big deal, but back in those days everyone was generally trying to have their own proprietary apps… Ah well… maybe in the new era of BeOS, this information will be more available and replicants will flourish.