Minimenu And Tool Changes.. Rfc :)

[chris_c]

for my mind there are 2 or 3 types of users

the none tech dude(ette) that has the Pandora for emulation / games - Its about the games and not the box in their hands which is a means to an end, they want a menu that JustWorks(tm) as simple as possible, maybe just with the possibility to make custom pages and a default start up page, and custom wallpaper per page or global

These people just want something as simple as possible that just works. mini menu is probably it and shouldn't get too more complex.

The other is the geek - well they probably know how to handle compiling packages using opkg etc and can even follow instructions and install their own desktop, they use the machine for coding as well as games and might have only looked at mini menu once or twice - they'd rather have a micro desktop in their hand - they (generally) know what they are doing and don't need a "menu"

The intermediate user is not catered for and probably shouldnt be by the mini menu there probably should be three modes of using the Pandora


Mini Menu - very very simple - works and is very fault tolerant of faulty pnds etc should only include very basic customisations should be very stable and not change very often if at all other than the end users limited customisations


Intermediate Menu - this should be about being a flexible as possible, driven by well structured xml files that allows almost any customisation to be done this is where all the customisation and new ideas should be tried may be unstable from time to time with certain pnd's, but its the power users menu


The Desktop - Its Linux so its not as difficult as Windows and those who can google can make it work like they want...

 

[skeezix]

chris -- I'm with you on a lot of that (and I think most people are too) -- when you run mmenu and do nothing, it should 'just work'; anything I've described above is really options that could be enabled to tweak a few behaviours, but that will still not break the default behaviour. It might be we move subcats to be folders inside the maincats instead of tabs or something, we'll have to see, but mostly I'm trying to avoid rocking the boat, but do provide some tweaks to make day to day better for those who've stepped up from beginniner, but don't want to roll their own desktop experience. (Or people like pleng who prefer the mm type UI, but tweak their environment, etc.)

But fully agreed -- we don't want mm to lok or feel complicated, and to just work; I don't mind if, once they've used it, they feel like fiddling a bit.

Stuff like 'plugins' is just way too much for mm, probably, but I could see a use for it in skinning or some options .. like weather-panels, or doing things like special animations when switching categories or something; but given mm is open source, it might be better to just code such things as options into the main code But plugin interface might be fun to write, and I've fiddled with it, so could just fold it in for fun (Default off and invisible!)

OR maybe I should write a intermediate environment .... naah, that'd be spreading me too thin I bet.

Why am I replying, I'm exhausted and incoherent

jeff

 

[chris_c]

Why am I replying, I'm exhausted and incoherent

Coz its what us geek do!

I've implemented a plugin system using glibs gmodule api which looks a lot more confusing than it is!!!
http://library.gnome.org/devel/glib/2.26/glib-Dynamic-Loading-of-Modules.html it works well and it worth a look

There are a lot of advantages to a plugin system and its very rewarding and "safe" (you can always rename the plugins folder
if one plugin if going rogue and access the menu if you need to...)

I'd suggest an event system for the plugins with each plugin registering its interest in particular events
tab changed, menu tick, pre app run, post app run, menu initialised etc...

Have fun!

 

[skeezix]

Yep, read up, thats more or less what I was proposing.

I've been looking at options for non-dynlink plugins, to avoid the case were plugin crash takes down the whole app; ie: consider -- a plugin could just be a standard app (C, python, whatever) and mmenu would run it, and set up stdin/stdout via pipes. mmenu pushing events to the plugin to arrive in plugins stdin, and mmenu listening for responses from plugin stdout. JSON for wrapping up the data types just to be safe. If a plugin crashes, mmenu would just detect the error on the pipe and close the tab (for example of a tab opening plugin.) If you use dynlinking shared libs, then it makes life so much easier to code, but you have that big gorilla on your back .. thign could crash at any time for any reason (It also makes it harder to do non-C plugins, ie: in python or whatever.)

jeff

 

[chris_c]

Yep, read up, thats more or less what I was proposing.

I've been looking at options for non-dynlink plugins, to avoid the case were plugin crash takes down the whole app; ie: consider -- a plugin could just be a standard app (C, python, whatever) and mmenu would run it, and set up stdin/stdout via pipes. mmenu pushing events to the plugin to arrive in plugins stdin, and mmenu listening for responses from plugin stdout. JSON for wrapping up the data types just to be safe. If a plugin crashes, mmenu would just detect the error on the pipe and close the tab (for example of a tab opening plugin.) If you use dynlinking shared libs, then it makes life so much easier to code, but you have that big gorilla on your back .. thign could crash at any time for any reason (It also makes it harder to do non-C plugins, ie: in python or whatever.)

jeff

tbh there is a case for doing the whole menu in python, a lot of Ubuntu's config management is done with python if only just because its just so damn quick to develop with! and its not like a menu needs to be implemented in C for the sake of speed.

Your point about dynlink plugins is a very valid one, and running as a separate application while it might be tricky to implement and could be less flexible, is maybe the way to go, not sure for the need for JSON, what improvements would it give over just simple xml fragments?

One problem how would a plugin draw to the screen ? would you provide an api where the plugin would send text "commands" back to the menu and the menu would do the actual drawing?

I do think that an event system with plugins registering their interest in particular events would be the most flexible way to go.

that way at a later date the menu could emit a new event type (at a later version) without effecting existing plugins.

if plugins are script based then they could potentially just be a list of events to listen for and a function for each event.
if a portion of a plugin does need the speed of C - (3d particle effects for example) the python can always include a module that has a custom C library called via ctypes...

still a lot of ways it could be done, but at least you have some food for thought!

 

[EvilDragon]

EDs idea sounds awful. I am not sure why you seem to want to do that one the most. Why do that? Too "buttony" and awkward, plus you have to hit a button to even see them. Then you have indicators or whatever to know? What if you have like 10 or so subcats?

I guess my idea wasn't properly described here.

It was like that:

On the tabs, only the MAIN Categories are shown. Select it, and it shows the files of that main cat (ignoring the subcat).
No difference than what we have right now, just without the subcats.

If you want to only see a certain subcat, press a button which pops up a quick menu showing all subcats from the selected maincategory (of course only those where there are files for) and then only those files will be shown.

Basically, it's a filter.

If you know what you want to run, you don't need the subcat.

But if you want to take a look at all Arcade games you have, simply select the GAME category, open the subcat popup and select Arcade.

So it's basically the same idea you had, just not with showing folders in the grid for the subcats, but showing them as popup when you press a button.

Why would I want subcat folders in the grid anyways? It takes away space for the icons, and it might be confusing for users if within the Racing folder, for example, are the same games as in the main category folder.

Select the GAMES category, see all games.
Press a button, select Racing and only see the RACING games.
Wanna see games from a different subcat? Press the button again and select the other subcat.

It's as easy as that.

 

[skeezix]

XML is 'pretty heavy' for parsing (especialyl considering unicode etc etc); most languages have a few XML parser libs, but they're usually pretty heavy; all told, XML is ugly and huge. JSON is much more lightweight (and has the benefit of being the native syntax of python and javascript among others.) .. so parsing JSON in python is pretyt much an eval() away, you know? More to point, I would envision messgaes and respones to be pretty terse -- a string event/function name, and a few numeric params, so lightweight (or just fprintf() would do) but to keep it halfway standards oriented, I figured JSON is trivial for everythign to parse, and much smaller and faster than XML.

ie:

You dpont' want to send down stuff like ..
<mmenuPluginEvent>
<event name="fubar" param1="1" param2="2"/>
</mmenuPlugEvent>

When you can just say

event: { param1: "1", param2: "2" }

Or whatever

The real quesiton is rendering, of course; right off the top, an issue is resource sharing -- ir'd be nice if mmenu had already loaded an object for itself or one p-lugin and could hand a handle/pointer to it to another to use and save the time/memory of reloading it, but thats impractical in a lot of ways; for rendering the background (which would be needed) or tabs, I figure a plugin woulfd always have mmenu do it. The real quesiton is then what subsequent render operations would do --

Example; if you're doing a weather app that requests one tab for itself and wants to show a picture of a sun for a sunny day, then you'd conceptually want mmenu to render the tab (using theme) and tab background, and then hand render to plkugin to draw the sun on top (with transparency all around); presumably the plugin initialization and shutdown code would handle the sun, but nothing else. (Redundant font load I suppose, unless somehow the font coudl be passed over, but opening up a shared mem and passing around SDL_TTF structs sounds really really messy.)

I'll have to look into feasibility of shared memory or mmap'd memory or something, to see if its possible to pass complex SDL info around (such as SDL_Surface.) ie: since the pointers are normalized to the app, theres facilities to passing around the pointers and making them useful to other apps, or using common shared memory .. just sounds painful and messy and a lot of massaging.

So, and understand i've put nearly zero thoguht into it, at the time I was figuring that a plugin would render to an SDL Surface of its own, with alpha; then when complete it'd just (instead of calling SDL's unlock routine that normally hands to render) it'd just call a plugin release function and hand it a shared mem pointer to th surface pixel data.

ie: During plugin setup, plugin requests a tab from mmenu; mmenu responds with a tab handle and some sizing and depth information and a shared memory object (say)

To render, plugin renders a surface, then calls mmenu with the pixel data in the shared memory and mmenu just renders it on top of the tab.

For a app resize (future, mmenu doesn't resize now) we could just send down an event to the plugin.

But again, I've not thought about it at all.

I just didn't want to get into the case of using a socket/pipe and transmitting a large tab area 60fps (ie: say a tab is 700*400 * 2b/per/pixel thats what, 500k per frame? Thats a lot of data

The model I was thinking of was akin to MITSHM, but letting mmenu be man in the middle, so that it could apply any extra effects and such if it wanted, or refuse to render if it wanted .. consider if the weather tab is on top, but user brings up the Select menu, you want mmenu to render the plugin, then render the menu on top.)

jeff

 

[chris_c]

I'd favour *not* resource sharing! basically the menu would provide an api something like

int loadResorce(filename) - if a resource is already loaded by menu or other plugin no loading takes place, its id is returned
string getResourceType(id) - "WAV" "MP3" "ICON" "IMAGE" "FONT"
void blitResource(x,y,id) - only valid for images!
void printText(x,y,id,text)
void playResource(id)
int createTab()
int findTab(???) - ??
void showTab(tabId)
int createTabArea(tabId,x,y,w,h)
void makeTabAreaCurrent(tabAreaId) - all rendering is now done to this area


A resource could be an image, bitmap font, or sound

Obviously this is not a complete api just to give an example what I mean - the menu controls and handles all the resources and their rendering and the plugins just request things are done with the *menus* resources - a plugin itself would have no resources other than say a connection to a weather website and a copy of the numerical value of the temperature ie plugin specific data not relating to the rendering of the menu itself

I take your point about JSON

I'd highly recommend that the complete v1 api should be fully designed by multiple people *before* any coding is done!

 

[skeezix]

*g* Yeah, thats the question; theres a numbe of ways to do go about it .. purely abstracted plugins, versus plugin doing rendering and handing things over. I've been hummning and hawwing over it for 'awhile' (back of the brain while driving home) but not really weighed it out for pros/cons. I don't want to get 'out of control' .. ie: to start with, v1.0 would be plugins to open tabs (such as file browser), but not take over the entire rendering frontend. Also stuff that would want to watch events and render, but without opening tabs (so something could make a swooshing noise when you tab switch, or whatever.) Also need to write a bunch of stubs up .. being JSON or whatever pipe between the host and plugin mewans things are essentially untyped etc, but I'd rather for each language that a wrapper gets made, so that folks could call a native abstraction that does offer type checking etc, which in turn just formats to/from host.

ie:

python plugin <-> pyMiniMenuPlugin <-> pipe <-> MiniMenu plugin host code <-> MiniMenu proper.

On the other hand, I shoudl better spend time reworking parts of minimenu and libpnd that were rushed, but a plugin interface keeps coming to mind since its such a fun little project

I have a rough specification in mind (list of functions for v1, and all that) that I've been meaning to get around to write up; once I get it documented, I'll post in a couple places for comment. I'm not aiming for 'comprehensive' as that is the enemy of 'getting things done', but growable is important. (Again, using a text interface between modules is handy here .. sure you lose the 'just call it' of shared libs, but its nice to be able to add or change arguments without breaking the whole call layer Add a new argument with a default value.. boom, no change to the plugins

I'll let you and everyone know whenever I get the first draft spec down.

jeff

 

[milkshake]

ooooh I just love development ideas

 

[DaveC]

Why would I want subcat folders in the grid anyways? It takes away space for the icons, and it might be confusing for users if within the Racing folder, for example, are the same games as in the main category folder.

Select the GAMES category, see all games.
Press a button, select Racing and only see the RACING games.
Wanna see games from a different subcat? Press the button again and select the other subcat.

It's as easy as that.

Too many "press button" steps. It should be quick and show your apps in a logical way. With what you are saying you have two different interfaces in one, the standard grid and a pop-up list of filters when you do subcats. It is just disjointed and incoherent and could be confusing to newbs that hit the wrong button. "What happened? why do only racing games show up?! Did this damn thing delete some of my games!?" Everyone who hasn't been in a cave the last 20 years knows what a folder is and how it works.

If you have subcat folders in the grid you will have less there anyway as allot of stuff is in folders. Plus it all has the same look and operation. You wouldn't have the same game in the main catagory AND the folder, that would be dumb and defeats the whole purpose of a folder. It would only show up in the place you put it in. Ever use a PC before? it is like that. Plus it would be less to code and less re-arranging/redesigning of the whole thing.

 

[EvilDragon]

Too many "press button" steps. It should be quick and show your apps in a logical way. With what you are saying you have two different interfaces in one, the standard grid and a pop-up list of filters when you do subcats. It is just disjointed and incoherent and could be confusing to newbs that hit the wrong button. "What happened? why do only racing games show up?! Did this damn thing delete some of my games!?" Everyone who hasn't been in a cave the last 20 years knows what a folder is and how it works.

Well, I'm sure the users that have a Pandora are smart enough to use filters
It's the same concept femame used, and me (and a lot others) loved it.
Wanna play an Arcade game? Set the filter

If you have subcat folders in the grid you will have less there anyway as allot of stuff is in folders. Plus it all has the same look and operation. You wouldn't have the same game in the main catagory AND the folder, that would be dumb and defeats the whole purpose of a folder. It would only show up in the place you put it in. Ever use a PC before? it is like that. Plus it would be less to code and less re-arranging/redesigning of the whole thing.

But is it also possible that I can see ALL my games at once then, if they only show up in a subcategory?
Sometimes I can't decide what to play and want to see everything I got, without having to crawl through all the subcats. Sometimes I want to play a racing game and don't want to see the rest.
Coding wise, it's no big difference. For a quick popup menu, no redesign is necessary. It pops up in front of the grid and disappears after you made your selection.
You could also let it appear in the right area, where the other menu appears when you press select

 

[skeezix]

Chris -- I did a bit of editing on a vague spec I was working on and off for awhile; its reasomably complete for a discussion spec, but not super complete (on purpose):

Switch to this thread for plugin API discussion:

http://www.gp32x.de...25&#entry934625

jeff

 

[DaveC]

But is it also possible that I can see ALL my games at once then, if they only show up in a subcategory?
Sometimes I can't decide what to play and want to see everything I got, without having to crawl through all the subcats. Sometimes I want to play a racing game and don't want to see the rest.
Coding wise, it's no big difference. For a quick popup menu, no redesign is necessary. It pops up in front of the grid and disappears after you made your selection.
You could also let it appear in the right area, where the other menu appears when you press select

By the time you go to the games tab then hit a button to pop up a menu, then scroll through the menu to pick a subcat, then select it then go to the grid and pick the filtered game, you could have just moved the d-pad down a few times to get the same result. It just doesn't sound very useful and there are better more intuitive ways to do it.

It would just be nice to see everything in a grid under the tab, unsubcat games and subcatagories without the need for more menus.

Also what happens when you are on the Game tab and you don't select the "racing" subcat? Does this mean none of those in that subcat show up until you go to a pop up menu? That would be a bad idea. How do you see "racing" in the grid without having to first go to *another* menu?

Besides you are talking about a filter that really isn't a subcatagory or an organizing feature like a folder structure would be. You still see all icons in one big pile under the tab unless you fiddle with filters. What I am talking about is a way to group apps by type without having to do anything. It would clean up cluttered tabs by further grouping by folder. It is almost a different thing altogether.

 

[EvilDragon]

But is it also possible that I can see ALL my games at once then, if they only show up in a subcategory?
Sometimes I can't decide what to play and want to see everything I got, without having to crawl through all the subcats. Sometimes I want to play a racing game and don't want to see the rest.
Coding wise, it's no big difference. For a quick popup menu, no redesign is necessary. It pops up in front of the grid and disappears after you made your selection.
You could also let it appear in the right area, where the other menu appears when you press select

By the time you go to the games tab then hit a button to pop up a menu, then scroll through the menu to pick a subcat, then select it then go to the grid and pick the filtered game, you could have just moved the d-pad down a few times to get the same result. It just doesn't sound very useful and there are better more intuitive ways to do it.
It would just be nice to see everything in a grid under the tab, unsubcat games and subcatagories without the need for more menus.

Ehh? I asked above, but you said it shouldn't show all games (without subcat) at once...?

Also what happens when you are on the Game tab and you don't select the "racing" subcat? Does this mean none of those in that subcat show up until you go to a pop up menu? That would be a bad idea. How do you see "racing" in the grid without having to first go to *another* menu?

Nope, it shows all, unless you select a "Show only subcat xx".

Besides you are talking about a filter that really isn't a subcatagory or an organizing feature like a folder structure would be. You still see all icons in one big pile under the tab unless you fiddle with filters. What I am talking about is a way to group apps by type without having to do anything. It would clean up cluttered tabs by further grouping by folder. It is almost a different thing altogether.

But that's what I'd love.
Select the category in a tab. It shows ALL stuff in that category, i.e. ALL games (nothing else).
Then you select a filter if you don't want to see all games at once.

Sometimes I want to browse through all games I have and select one from those.
And sometimes I don't know what to play, but it should be an arcade game, so I want an easy way to only show arcade games.

How would this work if you don't want a tab that shows all things from one main category?

 

[Esn]

Hi, I just started using the Pandora yesterday... so far I only have one request for Minimenu:

The tabs at the top: it's impossible to tell how many there actually are. Please make it so that there's a "+" symbol at the top whenever there are more tabs in that direction, and a little number beside them.

For example, you start out with 0 unseen tabs to the left and 10 unseen tabs to the right. As you press "R" and move right, the number of unseen tabs decreases one by one on the right, and increases one by one on the left.

 

[Esn]

After another day with the Pandora, it seems to me that Minimenu is very impractical to use unless you only have a small number of programs on your SD card.

This is because of its lack of support for nested directories. Or perhaps because there's no option to "override all defaults for where PNDs should go, just let me create whatever tabs I want and choose where each PND will go".

 

[Pleng]

You can use mmenu.conf to adjust the grouping of icons in tabs, or .ovr files to move apps from one tab to another but, yes, it's a pain. As suggested in this thread, this is being implemented within MiniMenu itself over time

 

[DaveC]

But that's what I'd love.
Select the category in a tab. It shows ALL stuff in that category, i.e. ALL games (nothing else).
Then you select a filter if you don't want to see all games at once.

Sometimes I want to browse through all games I have and select one from those.
And sometimes I don't know what to play, but it should be an arcade game, so I want an easy way to only show arcade games.

How would this work if you don't want a tab that shows all things from one main category?

But is it also possible that I can see ALL my games at once then, if they only show up in a subcategory?
Sometimes I can't decide what to play and want to see everything I got, without having to crawl through all the subcats. Sometimes I want to play a racing game and don't want to see the rest.

If that is the case a folder in the grid named "Arcade" under the Games tab does the same thing. Only now you don't need to go through another menu and sequentially pick from a list of filters, you just pick a folder called "arcade" after selecting the games tab and now the grid shows all of your arcade stuff only. You want to go back up a level just press "X" button to go back. The other advantage is when on the Games tab you can see all of your subcat folders in the grid without the need to go into another menu. They are just there to see. Maybe after seeing the "Racing" folder you will go in there instead. The whole idea here is to have one consistant intuitive interface and not making it a mish-mash of different styles lumped together. Those filters work ok for things like MAME where you are managing lists of thousands of entries but is inconsistant with the MM theme.

You can't see ALL games at once if you have allot as many would be off of the screen anyway. If you did want to see everything and not the subcatagories then toggle off the subcat thing then everything would show without folders. I am sure a toggle button or icon somewhere can be made to quickly show subcats as folders or flatten everything (all games would show under games tab, or toggle to show subcats as folders).

After another day with the Pandora, it seems to me that Minimenu is very impractical to use unless you only have a small number of programs on your SD card.

This is because of its lack of support for nested directories. Or perhaps because there's no option to "override all defaults for where PNDs should go, just let me create whatever tabs I want and choose where each PND will go".

Well actually the whole idea of MM was the opposite, to allow those with allot of stuff to get to it quickly, kind of like a Gmenu2X for Pandora.

But yes I agree the implementation needs work. I have been lobbying Skeezix since it's first version to be able to easily "override all defaults for where PNDs should go, just let me create whatever tabs I want and choose where each PND will go". There is an override system to do this but you need to hack text files to do it. I have done it but somehow created an error in my .ovr files that crashed MM.

It is a hassle and there needs to be a simple context menu to do this. Hit a certain button while over the desired icon and the commands pop up: Rename, Move to tab, Move to folder, etc. There should be a way to rename tabs too I think. I think the whole PND idea was to do things "automagically" without user intervention. It does that but as we see that just results in tab spam and is at the whims of those making the PND and not always what the user really wants. There needs to be a simple GUI method to do overrides.

As far as the lack of support for nested directories that is another thing I was trying to get implemented. If you have subfolders in the grid to go into you can further catagorize your stuff to get rid of clutter (like all PCs do these days).

 

[Esn]

After another day with the Pandora, it seems to me that Minimenu is very impractical to use unless you only have a small number of programs on your SD card.

This is because of its lack of support for nested directories. Or perhaps because there's no option to "override all defaults for where PNDs should go, just let me create whatever tabs I want and choose where each PND will go".

Well actually the whole idea of MM was the opposite, to allow those with allot of stuff to get to it quickly, kind of like a Gmenu2X for Pandora.

On my first day, I readied my SD card by downloading tons of software, games and emulators from the wiki. Then I tried browsing them in minimenu. What I saw were dozens and dozens of tabs, some with only one app in them, many of them with duplicated apps from another tab.

In short, completely masochistic.

So I'm forced to use XFCE simply because it's easier and faster to find the app I'm looking for.

Yes, a lot of this is the fault of devs who specify custom tabs for their programs. So there are lots of tabs which have just one program in them. This will always be a problem, and the simplest way to solve it is...

I have been lobbying Skeezix since it's first version to be able to easily "override all defaults for where PNDs should go, just let me create whatever tabs I want and choose where each PND will go". There is an override system to do this but you need to hack text files to do it. I have done it but somehow created an error in my .ovr files that crashed MM.

It is a hassle and there needs to be a simple context menu to do this. Hit a certain button while over the desired icon and the commands pop up: Rename, Move to tab, Move to folder, etc. There should be a way to rename tabs too I think.

Yes. Yes! Just make something that acts like YAFL on the GP32 and I'll be happy.

Thank you for "lobbying". I add my voice in calling for this very fundamental feature, and I hope others will too.

think the whole PND idea was to do things "automagically" without user intervention.

Things like this will always fail unless you're Apple. You either give the user control, OR you don't give the user control but give devs lots of incentives (read: good pay) to make sure they keep to the same standards. The first option is much cheaper and more appropriate for a project like this.