Coding Guide for Homebrew Apps

Hi there,

I'm thinking about a coding guide för homebrew apps. Is there something existing?

The reason I'm asking is as follows.
I had an idea about communicating between HB apps. For implementing this, the way to do has to be specified.

If you have e.g. the WiiXplorer running and from this you'll start the MPlayer-ce with a media file.
In this case you need a way to tell MPlayer the file you'll play.
And after playing, the MPlayer has to know, what app has called it, to go back to the WiiXplorer.

Regards, Joe

I like this idea. It would work kind of like Windows Explorer, then, where it would create file associations?

I honestly can't comprehend what either of the posts in this topic are trying to say.
Sorry for the sarcasm - I figured it out. The name of the topic was what confused me. Slow and careful reading ftw.



Edited 3 time(s). Last edit at 10/17/2009 10:24PM by Arikado.

Does he mean running more than one app at once? Lol, I don't get it. :P

JoeBar, could you maybe try to explain with more detail?

I'm not sure if this would be possible.

It would probably be a lot easier to incorporate the necessary parts of (for example purposes) MPlayerCE into WiiXplorer instead.

If you can cheat with Gecko OS then you can run more than one app at the same time. There's not much memory to play with though :P

Sorry for late feedback ;-)

The idea with the coding guide is to handle global problems. The "WiiXplorer <-> MPlayer-ce" sample is only one of global stuff.

OK, let's look at the sample.
It's as Hman360 says. If you can handle command line arguments, it's a little bit like Windows Explorer.

For file manager and app like this: they need the possibility to call an app with parameters.
For apps like editors, player and so on: they need the possibility to read the parameters.

And if you'll do it perfect, they have to call back the file manager.

Sample: WiiXplorer --> MPlayer [video.avi]
... (MPlayer reads the parameter [video.avi] and plays it)
... (after playing, MPlayer calls WiiXplorer)

For this you doesn't need a multitasking (only one app running)

@WaxyPumpkin72: If there is something I forgot to explain, please ask a bit specific.

As I understand it you're asking for some standardization to be able to set some protocols of communication between applications, am I right?

Talking between apps is obviously possible in "dumb ways" (such as through files) but I'm not sure if with current libogc loading methods parameters can be passed while loading an app from another one nor if this can be implemented at all.

Whatever, the hardest problem would be to make developers stick to the "standards" (or set up their little app-talking-way) and if I got it right that's why you want developers to learn those "coding guides" so their applications come out ready-to-intercommunicate with others.

I think it's a good idea but also a big movement. It would need massive developers' acceptation and I don't know who could start this revolution! (lol)

If that wasn't the idea then laugh at me, hard.
Aruskano

Well it's already possible through argv style arguments, homebrew channel supports them...

One thing you can't accomplish though, programs to be able to return to programs that invoked them require the launching program to be a loader... one that leaves a stub behind to reinitialize itself... Homebrew channel for example reloads itself from nand once a program returns to it... as scanff noted, there isn't enough memory to use for more than one application...

actually it's not the memory size but more the lack of an operating system... each program manages their own memory so you can't rely on having two programs on the memory and let them behave...

Idea is good for certain applications and is already suggested... but I guess people want to show their gui instead of getting invoked to do something from another program. (like emulators)



Edited 1 time(s). Last edit at 10/20/2009 12:41PM by I.R.on.

@Aruskano: To establish a coding guide, you don't need a revolution.
Think positive ;-)

A guide should tell a (new) developer the easiest way to do something.
It's NOT to tell you: "There's no other way!"
It should tell you: "If you do it this way, there are less problems then other ways."

(BTW: Thanks for the good talk and your feedback @ll.)

Definitely. I think if WiiXplorer could work like that and set some form of file associations, it would make life easier. Maybe if it worked specially with the in-development web browser (like Windows Explorer and Windows Internet Explorer). It would work with Mplayer CE like Windows Media Player and maybe other things like that. Sorry for all the Windows references, I'm a PC ;-)

ive even cheated and used the wii memory below the entrypoint of an app to leave instructions for it. for (almost) all homebrew, it must start after the space that is allotted for the HBC stub. this means that if you know what is in the memory there, you can overwrite it with 1 app with some instructions and then boot another app. then the second app can read the instructions and then replace back the original bytes from the hbc stub. obviously this can be done with other places in the memory so the stub is untouched, but you cannot guarentee that an app will not overwrite that instructions. the hbc stub location (or directly after it) seem to be a nice safe place to leave stuff.

this doesn't really solve the issue of how to get mplayer_ce to be able to exit back to wiiload because it cannot load dols like wiixplorer can. i think the best solution for this is either have a dol-loading stub like the HBC return to stub, or to be able to use the bootchannelWithArgs() function on HBC and tell it what to boot. then any app will be able to exit to any app, assuming that the app is still somewhere that HBC can get to it.