Crappiest Launcher You'll Ever See, But Here You Go

[DaveC]

the line under the selected tab is just piece of the tab art, pretty easy to cut off; but notice I also made the selected tab have a different alphamask (colour in essence), so taking off the line.. you'd still see the highlight box. So woudl have to make the hilight do some gradiant effect anyway, but that in effect is just a fuzzier line. So in effect, having a line there is not so different perhaps, until I make or get all new artwork for that anyway Hence, not motivated to do it.

Get yesterdays build running, and then you can futz with the 'skin' as much as you like

Everything in the PXML.xml is overridable, but theres no tool for it for now; I think for mmenu just for you I'm going to make an override mechanism thats easy (and maybe directly support it in libpnd, so it works for all apps.)

ie:

/pandora/desktop/foo.pnd
If /pandora/desktop/foo.desktop (like a .desktop file), then inhale and try to overide

The .desktop file could have replacement title, cpu speed, category, whatever. PRobably not support the full .desktop spec as its reasonably comprhensive, but something like this..

.desktop
-----------
[Application]
name=Giana
X-CpuClock=200
Category=Fooby

Then those 3 values could override their counterparts in PXML.xml, while all the other PXML bits would stay.

Then also /pandora/desktop/foo.png would override for the icon, if present.


But looks like minimenu and pmenu will be running on top of X (with no window manager or desktop environment) for now anyway, so thats moot. (They know how to kill X temporarily when they need to.) Still, booting up kernel, then X, then pmenu/minimenu should be pretty quick.


jeff

Ok for the tabs I will probably work on the art tonight. I will probably do it without testing the actual app as with my bad linux "skills" it will probably take hours to set up with all of the terminal CLI typing stuff, I am terrible at that and don't even know much of the syntax.

For the .desktop override could one more option be added: appdataDir=same (or whatever it would be called) which would then allow the appdata dir to be in the same subdir as the app? (or make the PND look in both spots on load and use what it finds first) I am still not liking the whole scatter the app and it's data files into separate places thingy. That is still sloppy for me. I like to manage one not two subdirs per app.

So this will still need the overhead of X? There goes the fast boot up. It seems silly to have to waste all of that time loading all of that crap if you just want to play a game for a few minutes. Hopefully authors of at least games and emus will not require X, there would be no point in that. Booting up kernel, then X, then pmenu/minimenu seems like a lot of time. It would be nice to get rid of the booting of X unless you select it from the minimenu.

 

[may88]

may88 -- if by 'finger friendly' you mean 'push an icon to run it', then yes -- I'll be adding basic touchscreen; tap an icon to run it, tap a tab to switch to that category.

Its not going to be 'kinetic' like an iphone .. its not that sort of thing. Its not a smooth scrolling vertical move.. its a grid of icons, with invisible page-flipping, old school.

Sounds just perfect. Keep it simple. Keep it fast. Except the bit with the binary clock.

 

[MDave]

the line under the selected tab is just piece of the tab art, pretty easy to cut off; but notice I also made the selected tab have a different alphamask (colour in essence), so taking off the line.. you'd still see the highlight box. So woudl have to make the hilight do some gradiant effect anyway, but that in effect is just a fuzzier line. So in effect, having a line there is not so different perhaps, until I make or get all new artwork for that anyway Hence, not motivated to do it.

Get yesterdays build running, and then you can futz with the 'skin' as much as you like

Everything in the PXML.xml is overridable, but theres no tool for it for now; I think for mmenu just for you I'm going to make an override mechanism thats easy (and maybe directly support it in libpnd, so it works for all apps.)

ie:

/pandora/desktop/foo.pnd
If /pandora/desktop/foo.desktop (like a .desktop file), then inhale and try to overide

The .desktop file could have replacement title, cpu speed, category, whatever. PRobably not support the full .desktop spec as its reasonably comprhensive, but something like this..

.desktop
-----------
[Application]
name=Giana
X-CpuClock=200
Category=Fooby

Then those 3 values could override their counterparts in PXML.xml, while all the other PXML bits would stay.

Then also /pandora/desktop/foo.png would override for the icon, if present.


But looks like minimenu and pmenu will be running on top of X (with no window manager or desktop environment) for now anyway, so thats moot. (They know how to kill X temporarily when they need to.) Still, booting up kernel, then X, then pmenu/minimenu should be pretty quick.


jeff

Ok for the tabs I will probably work on the art tonight. I will probably do it without testing the actual app as with my bad linux "skills" it will probably take hours to set up with all of the terminal CLI typing stuff, I am terrible at that and don't even know much of the syntax.

For the .desktop override could one more option be added: appdataDir=same (or whatever it would be called) which would then allow the appdata dir to be in the same subdir as the app? (or make the PND look in both spots on load and use what it finds first) I am still not liking the whole scatter the app and it's data files into separate places thingy. That is still sloppy for me. I like to manage one not two subdirs per app.

So this will still need the overhead of X? There goes the fast boot up. It seems silly to have to waste all of that time loading all of that crap if you just want to play a game for a few minutes. Hopefully authors of at least games and emus will not require X, there would be no point in that. Booting up kernel, then X, then pmenu/minimenu seems like a lot of time. It would be nice to get rid of the booting of X unless you select it from the minimenu.

I don't think X has the overhead you're worrying about, at least while playing something like Quake: http://www.gp32x.de/board/index.php?/topic/52297-pandora-sgx-driver-benchmarks/

No idea memory wise, but does it really add noticeable loading time to minimenu?

 

[skeezix]

Rickis idea is growin on me, for expert use. Ie maybe dpad up while holding shoulder will page up and leave selection in same relative position. Nice

davec .. Don't confuse booting x with booting up everything. X by itself isjust a biggraphics driver .. A window manager on top, and a desktop environment on top of that, that's where it fattens up. So looks like first cut ED will configure all the menus to run on top of X, but this is not on top of xfce or a window manager at least.

minimenu can run entirely without x, just a matter of sorting out the boot process. It's good to let a process like Slim do 'log in' and then go to minimenu, but currently slim is set up for x. Anyway we'll take care of it, but both mmenu and pmenu I think will be ready for no x

anyway can't say much .. On my phone again

jeffphone

 

[DaveC]

Rickis idea is growin on me, for expert use. Ie maybe dpad up while holding shoulder will page up and leave selection in same relative position. Nice

davec .. Don't confuse booting x with booting up everything. X by itself isjust a biggraphics driver .. A window manager on top, and a desktop environment on top of that, that's where it fattens up. So looks like first cut ED will configure all the menus to run on top of X, but this is not on top of xfce or a window manager at least.

minimenu can run entirely without x, just a matter of sorting out the boot process. It's good to let a process like Slim do 'log in' and then go to minimenu, but currently slim is set up for x. Anyway we'll take care of it, but both mmenu and pmenu I think will be ready for no x

anyway can't say much .. On my phone again

jeffphone

Ok sounds good.

What about adding the appdata dir over ride to the .desktop thing, or just have the PNG check two spots the one like now, and in an appdata dir in the same subdir as app. Would that be hard to do?


Also instead of "dpad up while holding shoulder" to flip pages you could always use one of the nubs for that. Press left nub up/down for page change.

 

[skeezix]

Moving the appdata dir is a bit of work. Ask vimacs nicely

jeff

 

[Tom`]

Would it be possible for the menu to start X only for those applications that need it (as defined by PXML.xml)? I don't think it takes more than a few seconds just to load X, provided the user is logged in - I guess maybe this could be done by generating an .xinitrc/.Xsession file or something, I don't know...

 

[skeezix]

Tom, yeah, its in the future. "xinit someAwesomerApp" is enough to kick up that app, and some magic to kill X when the app dies. But we probably need to fire up a WM (Window manager) as well, so that the app doesn't freak out, and it may depend on Gnome or KDE or various frameworks suddenly, so we're talking about a per-app framework requirement..... yeah, need some more research

Theres a lot of permutations, and we've covered a bunch; ie: no X, running no X apps; in X, running X apps; in X, running an app that needs to shut down X (we ask user to confirm, then kill X, run the app, then bring X back up. But no-X, needing X and who knows what to run, we've not done yet.

jeff

 

[DaveC]

Moving the appdata dir is a bit of work. Ask vimacs nicely

jeff

Couldn't the pnd just check two spots the current appdata dir in the separate spot and also have it check the current apps dir for an appdata dir too? This way if we want to put it in the same dir as the pnd we would just create the appdata dir there. If the pnd doesn't find it in the other desktop folder it looks for appdata in the apps's current folder for it. This way you can do it either way and it will work. Don't you have some say in how the pnd works too?

 

[skeezix]

Theres several different components to modify (not hard mods, but amid everythign else we want to wrap up before launch. Really, vimacs wants to rewrite the critical bit there to make it work more quickly for a case, that would massively speed up pulling preview pics from a pnd for instance. So its one of those bits thats not hard, but takes a bit of time in a few bits, and those bits have higher priority things to change first, time permitting. Priority because your change for appdata would be much easier after he does the other one first (Specifically, vimacs is doing some magic .. right now we do the full mount with appdata magic, but when you just want to mount read-only to pull preview pics (or whatever) quickly then unmount the pnd again, theres no reason to do the appdata magic stage. So we could do a quick-mount, read, unmount instead. But theres magic there, since what if the user is running 10 pnds at once, a few of which are the same pnd-file .. we have to be careful about mounts and unmounts and partial-quick-mounts when you take multi-user and multi-tasking into consideration...) -- see, its always more work than you think at the surface All this stuff already works just fine, but we can probably double the speed of preview pic pulling if vimacs gets time to rewrite the one job.. and its that same job that he has to change to move the appdata around, so hes prioritizing the speed-up first. Once its rewritten, it'll be more maintainable and he can add an appdata change in easier.

But I'd not make it app-by-app I think.. I imagine a user woudl have a personal preference .. all appdata in one place, or all appdata with their apps, one way or the other.. not app by app as you suggest. So we'd have to add a config item to the master onfigs, and the user coudl just alter that item to flip it, but we just have to carry that config item through the various components.

So its not too bad to do, but its a bit of work.

jeff

And yes, before someone asks .. yes, we thought about and made it work to run the same pnd multiple times, and multiple different pnds at once, etc. (Remember, not all apps demand 100% cpu like an emualtor or many games might; think about somethign like Kronos which opens up a full windowed GUI for text adventures.. it spends most of its time waiting for user input, and thus is often at 0% cpu utilization. I set the PXML to clock that sucker down to 200mhz and could probabyl do 50mhz So theres no reason not to open up Kronos and other pnds if you want, or even multiple KRonos should you want to play multiple games at once. (I'm not currently suporting multi games in one Kronos process, but it could do that with some work.) Consider FreeCiv, a turn based game. OR Wesnoth, etc. Quake with OpenGL-ES needs the cpu and monopolizes the screen, but a lot of apps do not.. so we support all those crazy cases already

 

[DaveC]

I imagine a user woudl have a personal preference .. all appdata in one place, or all appdata with their apps, one way or the other.. not app by app as you suggest. So we'd have to add a config item to the master onfigs, and the user coudl just alter that item to flip it, but we just have to carry that config item through the various components.

So its not too bad to do, but its a bit of work.

jeff

Sounds complicated. I guess for me I don't really care about multi-user at all, and I won't be runing two ST or GBA emulators at once either. But I guess you need to make it work for productivity apps and other ones who use multiuser things. Hopefully you guys can suss it out someday.

 

[x68000]

This is certainly the launcher i'll be booting up every time - Have zero interest in anything non-gaming related on Pandora

Btw, Happy 7th GP32X Birthday Jeff! Not many older active members than you

 

[Wolenber]

Its not going to be 'kinetic' like an iphone .. its not that sort of thing. Its not a smooth scrolling vertical move.. its a grid of icons, with invisible page-flipping, old school.

As much of a fan I am of older applications, I think that the user interface (at least the scrolling, I hate that you can't have multiple windows open) is one of the things the iTouch did perfectly.

Any chance we can get the scrolling smooth, or will I have to use PMenu?

 

[Vorporeal]

That's really just eye candy - all it does is make you wait for the animation to finish as well as use CPU time. While it might make it look nice, this is the MINIMAL interface. It's not going to have any of that. If you want that stuff, use pmenu.

 

[skeezix]

This is certainly the launcher i'll be booting up every time - Have zero interest in anything non-gaming related on Pandora

Btw, Happy 7th GP32X Birthday Jeff! Not many older active members than you

haha, cool, never noticed that And like 3500 posts.. *jeezus*

At the time I signed up, I'd been putting it off a few months too, just lurking Then one day I sai d'hell with it, I need a gp32' and .. well, damn, I could'v ehad so much more free time over the years

jeff