[Beta/Alpha/Preview/Whatever] OpenMenuPSP

[NoEffex]

Made using the PSPSDK API, I figured "Hey, since all these menus take up SO MUCH damn RAM, and there's not very much of it, why not make the menuing in ONE well-written module and let the rest derive from it?". Well, that thought lingered for a few days and I started coding it, and it seems totally plausible.

Aiming for total code-correctness in terms of commenting and such(Hehe, OpenBSD) this project will hopefully be used. I intend to release several sample modules(ie music) that use the menu to give a base off of what it will be like.

What would it be done? Using imports/exports, all one would have to do is include the stubs and such, have a couple pre-made functions in the module, and use menus without using the pspdebug library or anything like it. Reason being is that all the data contained in it takes up a lot of ram and spread out between 3-4 modules it just doesn't work.

Also I will be coding a config file(I got good at parsing) so that won't be a problem.

Will be released under a bsd license(Probably will dual license it, source under GPL, headers under BSD or something) so anything using it won't be limited to open source. For now it's entirely under a BSD license though.

Basically, to sum it up, I got really annoyed coding menu after menu after menu, I figure "heh, I'll just code one and via exports I can have ONE menu with a bunch of entries from different modules". Uses the debug, though I wanted to use Wildc*rd, however from what I understand their source isn't for general use(education only) and I don't want to infringe on that.

So, it uses the debug library right now, to maintain a small impact on the ever-important heart - the kernel area.

How it works: A module included it's stubs, uses the headers, and calls to a function that links it with the rest of the entries(Does not add ANY extra memory at any point in time) using a nice pointer thing(root structure->next->next->next etc) that uses pointers for everything except the settings. If you want to actually look at how it works, source is in the tarball.

As of today it features a whole dealio of things, including scrolling(in case the amount of entries is more than the screen), callback(async, sync, paused, etc), descriptions, uses pointers to load text so you can change whatever at any given point in time in terms of whats stored on the module that's using it, highlight colors, and more.

If you want to look at it to get a better idea, download it. Ohloh says it's "Extremely well-commented", so I'd take that as a complement.

So rather than babbling on what is done, I'll tell you what isn't:
Config file
Exports(Easy)
Various callback options

Download(07-25-09):
http://openmenupsp.googlecode.com/files/openmenu_072509.tar.gz

Googlecode page:
http://openmenupsp.googlecode.com

 

[Dragoneon]

i donmn't really like reading gian't walls of text
but

whats it acctualy do?

 

[NoEffex]

i donmn't really like reading gian't walls of text
but

whats it acctualy do?

Read whats not in the quote, as that contains the explanation. Since any printing library pretty much takes up a good bit of ram, I decided to have ONE rather than a bunch, and with it include a menu system(That is working at the moment) and have a built-in kernel malloc library that allocates from user memory, possible stdio however that'd probably be pointless. It's like vlf but a billion times less complex and it's one type with little customization allowed.

 

[Cryox]

Is it usable (can you post screenshots if so)?

 

[NoEffex]

Is it usable (can you post screenshots if so)?

Yes and no, as I don't have the screenshot plugin on me. You can run the .prx on the download on the googlecode. It's a demonstration per se of a few of it's features(note the 30 "Durrrr" entries are for scrolling).

You're welcome to try out the plugin, it opens in the exact same way as nitePR, without the text saying "Press home twice".

 

[Davee]

I'mma give this a whirl.

 

[NoEffex]

This latest SVN build I switched from the (gay) home framebuffer to a malloc-based one(I love that malloc wrapper for kernel-based 'brew). You don't have to press home twice and it works in VSH.

http://openmenupsp.googlecode.com/files/openmenu_072509.tar.gz

I also did some things that are more visible via IDE(in other words, source changes that you don't really notice but I thought were cool). The callbacks don't use a global function that gets set, they're all set in the structure, so I just go optionEntry->entryhandler(topass, pad.Buttons);

Also, in doing this, I can also have it pass a specified value in case there is one module that has multiple entries but only one callback function, it can pass whatever you specify to that function so you can send it through a switch or a big if/else if to do it that way(pardon the non-tabbed, I'm typing all this improv'd)

What you'd do:

menuEntry entries[4];


void *functionCallback(int topass, int buttons)
{
switch(topass)
case 0:
//dosomething
break;
case 1:
//dosomething
break;
case 2:
//dosomething
break;
default:
case 3:
//dosomething
break;
}

int main(void)
{
entries[0].title = sometextpointer0;
entries[0].entryhandler = functionCallback;
entries[0].topass = 0;
entries[1].title = sometextpointer1;
entries[1].entryhandler = functionCallback;
entries[1].topass = 1;
entries[0].title = sometextpointer2;
entries[0].entryhandler = functionCallback;
entries[0].topass = 2;
entries[0].title = sometextpointer3;
entries[0].entryhandler = functionCallback;
entries[0].topass = 3;
//and so on
}

In other words, it's coming along.

 

[NoEffex]

Alright, I've pretty much finished the thing. It works, exports and all. I just need to probably compile it as a library(the stubs) and write some samples, but other than that it's done. I'll post up the final release when I write samples. I committed it just now, so it will be done.