MiniMenu / Simplified UI
- Thread starter pmprog
- Start date
skeezix
Internal Development
Minimenu is probably not a good 'base'; it does the job, and is straight forward, but its 'dumb' in a lot of ways, and makes a lot of assumptions (ie: its code is decent at what its for, but not generalized to be pluggable for other sorts of things.)
Reason: cpasjuste was working on a simplified launcher, but had some RL time constraints or whatever and didn't see mable to deliver in time for the 'official Pandora launch date, part 2'; ie :we'd all gotten our dev units with only a couple of weeks to deliver a userland, so we were going full speed to make .. everything
Craig came along to ask me 'I dont' think cpasjuste will be done, can you make a simple menu and have it ready in 2 weeks?' (or maybe a week, I forget now.) The core of mmenu was written in 4 nights. That doesn't leave a lot of time for elegance, I assure you
At the same time, mmenu was written to run pretty fast, be portable and easy to work with (its SDL, so that it coudl run on X, on /dev/fb, or whatever), and builds on a desktop as well as Pandora no problem. It can do pnd's itself, or do .desktop type work. It does okay, and runs with almost no memory footprint (since it usually exits when running an app.)
So .. it has some good ideas, but I'd rather rewrite it if we wanted to use at all; it should just present a framework (theres that word..) for launching apps; a protocol for communicating with them, and hooks for any future needs .. actions, screen savers, overlay panels, etc. The look and feal and so on, shoudl be plugins, that leverage the core to do work. A consistent interface approach.
Right now, mmenu was 'a different desktop'; the new device shoudl not have 'use desktop A, or desktop B' sort of thing for mmenu; there shoudl be your desktop choice, and mmenu (or whatever) should plug into _that_; we've got the processing power, so why isn't mmenu/etc just a plugin to the DE, or to the window manager? Really just a consistrent API to device specific features. A social media manager, etc.
So, I would suggest a different concept entirely, and a different way of going about it.
--> but if that ends up being 'too heavy' and slow, then I'd also suggest a mini menu that doesn't do any of that, andjust presents a menu to run stuff. But I woudlnt' write it liek mmenu is.. I'd do it as a thin layer on top of a very basic tiled window manager.
I'm certainly open to working on userland firmware for the pyra, but I have less time than I used to.. each year, less and less, with kids and all; fortuantely we have many peopel taking the charge, so we can have a team
jeff
Reason: cpasjuste was working on a simplified launcher, but had some RL time constraints or whatever and didn't see mable to deliver in time for the 'official Pandora launch date, part 2'; ie :we'd all gotten our dev units with only a couple of weeks to deliver a userland, so we were going full speed to make .. everything
Craig came along to ask me 'I dont' think cpasjuste will be done, can you make a simple menu and have it ready in 2 weeks?' (or maybe a week, I forget now.) The core of mmenu was written in 4 nights. That doesn't leave a lot of time for elegance, I assure you At the same time, mmenu was written to run pretty fast, be portable and easy to work with (its SDL, so that it coudl run on X, on /dev/fb, or whatever), and builds on a desktop as well as Pandora no problem. It can do pnd's itself, or do .desktop type work. It does okay, and runs with almost no memory footprint (since it usually exits when running an app.)
So .. it has some good ideas, but I'd rather rewrite it if we wanted to use at all; it should just present a framework (theres that word..) for launching apps; a protocol for communicating with them, and hooks for any future needs .. actions, screen savers, overlay panels, etc. The look and feal and so on, shoudl be plugins, that leverage the core to do work. A consistent interface approach.
Right now, mmenu was 'a different desktop'; the new device shoudl not have 'use desktop A, or desktop B' sort of thing for mmenu; there shoudl be your desktop choice, and mmenu (or whatever) should plug into _that_; we've got the processing power, so why isn't mmenu/etc just a plugin to the DE, or to the window manager? Really just a consistrent API to device specific features. A social media manager, etc.
So, I would suggest a different concept entirely, and a different way of going about it.
--> but if that ends up being 'too heavy' and slow, then I'd also suggest a mini menu that doesn't do any of that, andjust presents a menu to run stuff. But I woudlnt' write it liek mmenu is.. I'd do it as a thin layer on top of a very basic tiled window manager.
I'm certainly open to working on userland firmware for the pyra, but I have less time than I used to.. each year, less and less, with kids and all; fortuantely we have many peopel taking the charge, so we can have a team
jeff
fusion_power
Advanced Member
MiniMenu still has alot of bugs and missing "failsave" options. YOu can hang it up pretty easily if you do something wrong and it will never start again. Besides that, the concept itself is good and improves the usability of the Pandora alot. It blends very well with the PND system so it would make sense to have some kind of MiniMenu for the Pyra too.
skeezix
Internal Development
Did they not get applied?There are some minimenu patches in some other thread. If you can crash that version tell me how you did it and I fix that (sometime
I remember you sent me some .. If I forgot in my sleepdep then I have no honor! Got them handy? I can go looking.
jeff
I did hide them in the attachment to http://boards.openpandora.org/topic/14449-proposal-recovery-menu-for-minimenu-aka-breaking-the-crash-loop
They are separate from the controversial mmwrapper patch and documented, so could in theory be applied, but the number of downloads was 0 last time I checked, so not much testing obviously
And I was too lazy to start on your proposal. Sorry.
They are separate from the controversial mmwrapper patch and documented, so could in theory be applied, but the number of downloads was 0 last time I checked, so not much testing obviously
And I was too lazy to start on your proposal. Sorry.
Last edited by a moderator:
fusion_power
Advanced Member
Easy, use a not compatible graphic theme for Minimenu (old version for example) or delete (remove app from being displayed in the menu should already trigger this) the app that was last selected in MiniMenu when you enabled this option. MiniMenu will then hang up at loading in an endless loop without any chance to get out again. At least I was able to find the right line in the config to get it working again but this was luck. The Menu needs a failsafe mechanic to prevent this stuff, like 15s timer to test new themes if working at all (like testing new graphic settings on the PC) or auto-reset the last-selected app function if the selected app is not found anymore. I mentioned this stuff already years ago by the way.There are some minimenu patches in some other thread. If you can crash that version tell me how you did it and I fix that (sometime
Last edited by a moderator:
skeezix
Internal Development
hey if anyone can verify, thats groovy; otherwise since we've just had a firmware release, we can roll these patches in and get some test cycles going.
The mmwrapper needs a patch where it removes conf-files if it sees crashes; I built that years ago and frankly did nothing with it (blasted having babies, wiped my mind , but its not to hard. I'm sorr,y I've gotten lazy in some respects
I've made a reminded to roll patches in mon/tuesday.
jeff
The mmwrapper needs a patch where it removes conf-files if it sees crashes; I built that years ago and frankly did nothing with it (blasted having babies, wiped my mind
, but its not to hard. I'm sorr,y I've gotten lazy in some respects I've made a reminded to roll patches in mon/tuesday.
jeff
fusion_power
Advanced Member
No, which thread do you mean? Do I have to manual patch MiniMenu? I hoped this is included into the usual firmware updates?
Last edited by a moderator:
When i renember right exist another more simple Gui.
This Gui was in the Rebirth Competition.
But i dont renember the Name.Maybe a little Forum Search can help
This Gui was in the Rebirth Competition.
But i dont renember the Name.Maybe a little Forum Search can help
Null
Snug
^ Pandafe perhaps? http://repo.openpandora.org/?page=detail&app=package.pandafe
The one I linked above: http://boards.openpandora.org/topic/14449-proposal-recovery-menu-for-minimenu-aka-breaking-the-crash-loop
A prebuilt mmenu ready to run is included (if you trust me enough
I'd be grateful, if you could test it and confirm that some of the crashes are fixed. It might make skeezix's work easier, too.
Last edited by a moderator:
fusion_power
Advanced Member
Ah, this one, yes I even posted the issues there a while ago. Not time to test this (and not in the mood to hang up Minimenu and fix it after then) but as long as it will be included in an upcoming update or already is, then it's fine. So or so I boot only in Desktop mode, I use MiniMenu only when I need more free ressourcers on my Pandora. It is a little bit more memory friendly than the full Desktop.
Not time to test this (and not in the mood to hang up Minimenu and fix it after then) but as long as it will be included in an upcoming update or already is, then it's fine. So or so I boot only in Desktop mode, I use MiniMenu only when I need more free ressourcers on my Pandora. It is a little bit more memory friendly than the full Desktop.
skeezix
Internal Development
So no tests eh?
Aight, been a nutty week as usual, but I'll apply these tomorrow
jeff
Aight, been a nutty week as usual, but I'll apply these tomorrow
jeff
pepone
Pouet! Pouet! Do want!
I'm not a fan of windows8, but I think something like it could make sense on the pyra. A "modern ui" desktop (Actually I'm thinking about something like a simple android launcher) which would act like mini menu, perfect for fullscreen application like games and emulators, and a traditional desktop like xfce. The switch between the tow should be easy and fast.
bzar
A Commando
Heh, I actually have a working simple metro/modern-style UI from ages ago for Panorama .
Supports widgets with tile and full modes. It's a simple prototype for giggles though, never fleshed it out.
.Supports widgets with tile and full modes. It's a simple prototype for giggles though, never fleshed it out.
Last edited by a moderator:
