Release Hotfix 7 Alpha 3 released
- Thread starter EvilDragon
- Start date
Great (-:
And about that issue with icons on minimenu not working, cant you just rescan for apps automaticly when you turn it on?
That issue is already fixed and will be included in Hotfix 7 a4
skeezix
Internal Development
Theres a lot of under the hood changes to how minimenu detects apps for HF7, to speed up the boot process. More can be done, but baby steps
ie: Minimenu was 'designed' (if you can say that quickly; one of its goals was to work standalone, with X or without; so being we needed it quick (we thoguht we were shipping a week or two later... doh!), and wanted dual mode running, I went with SDL .. make it easy, and works with or without X, and makes testing easy (works on all popular OSes). Peachy! And another idea was to work without the rest of 'libpnd' -- maybe you just want to boot kernel + minimenu, have a bunch of shared libs, and ready to go -- most pnd apps would work like this, and run withotu X (since most use SDL as well!) -- its actually a very fast booting super mimnimal system, nice and lean. (But alas, I've no time to maintain a separate firmware brench, but I do suggest someone do it.. very fun. I got boot time down to like 11 seconds or something
Aaaaanyway, so minimenu can run without anything else.. which means it had to do 'app discovery' for pnd files all on its own, well and good, and that can take a few seconds as you see; note also that the rest of the system is _also_ doing that scan, since its spitting out .desktop files for DE like xfce and other appd benefit, so theres actually two scans at boot time, at nearly the same time .. but since dir info is cached and such, its not too big a performance hit, but theres definately a hit there.
So, it took awhile to get to, but I built in options so now minimenu can be configured to run either or both scans -- pnd scan, or .desdktop scan and trust someone else to maintain the .desktops. Given in pracice minimenu is usually run with the rest of the system (certainly in all our firmwares to date), this is a reasonable assumption. But the code for both is in there.. if someone wants to build another firmware and have minimenu do a pnd scan, no problem, flip a config value.
So now on boot, pndnotifyd does its app discovery early in boot and spits out .desktop files; minimenu watches for pndnotifyd to be done, and then picks up those .desktop files. That reduces boot load (one scan instead of two), and parsing the .desktop files is easier than parsing the pnd files .. so minimenu is general much sped up at its start time. The minus side of course is now mmenu has to wait for pndnotifyd (one of the background daemons) to finish up, but its pretty quick about its job, and its still faster than minimenu doing the second scan on its own at the same time.
Also, I experimented with some timing tricks; UIs are funny, since a lot of it is about 'perceived speed' versus 'real speeds', and 'speed during use' which may be not what you expect; so until recently minimenu was loading all icons into a cache at menu start up time, to try and keep 'usage speed high' with a hit to startup time; problem here is that minimenu wants to minimize its system impact, so it exits when you run a pnd -- so minimenu (unlike xfce) uses _almost zero_ system resources when a pnd is running; minimenu exits, runs the pnd, then comes back up. Nice! But as you can guess, this means minimenu is loading up all those icons every time you come back to the menu. It runs fast, paging and browsing is quick.. but you have to load up all those icons, many of which you'll never see (unless you're hitting All all the time, I suppose .. which I do
So, here I got to thinking, and ED is always thinking about user experience and pointed me in the right way.
If you dig into minimenus configs (which you don't want to , you can fiddle with a lot of stuff. Some stuff is exposed in the config UI, but the real nasty fiddly bits are not shown there.. they're just in textfiles for peopel to edit. Anyway, you can turn on background loading of preview pics (if you use the detail side panel at all), or background app scanning, or background icon loading. Turns out, since we're essentially singlre core, that doing things in background just chugs things up -- your main thread gets slower, and your behind thread isn't going fast, so cock wup the main thread for longer than it should Annoying (At least, doing threading in a simple brute force manner.. doing it very very carefully can works well, but thats work Anyway, most background stuff is turned off, it just didn't work out all that useful. So preview pics, if you want them, are on demand loaded when you idle the selection -- lets oy mvoe the selection around fast, but when you pause on an item (for a configurable amount of time..), it then decides to load the preview and makes you wait. (And loading previews is slow due to the whole 'mount', 'read pic', 'unmount' nature of fetching those until we revise the pnd file layout a bit, sometime down the road.) Anyway.
So for icons, its always had the ability to background load icons, but it wasn't really efficient about it since it didn't seem to work over well for user experience, so I didn't work over that code much; recently I thought I'd bang on it some more and introduced a bunch of configurable options .. when to do background icon loading, how fast to do it, which ones to do -- visible, go ahead so paging is fast if you're idling, or to scan all, or what.. all that stuff. Loading icoins is fast, but I always liked the look of, and the function of, background loading -- show you the generic icon template, then pop up the icons as it loads them, while you're working. To my brain, it seemed you'd want to 'get to business' fast, not wait -- maybe you just want to hit 'B' or 'Start' and run the app, who cares if the icon is loaded? So I banged around with a lot of options .. faster background icon loading slows down the main thread, so moving the selection feels clunkier; but it can load each image fast, just as long as it lets you move the selection around fast. But in the end, it just felt 'not right' to do background action, even if just background loading 'next page' and not too many icons, etc and so on.
Meanwhile, ED kept on with a suggestion that I misinterpreted, but when I 'got it' through my thick skull, I tried, and it is what we're going with now. Its all configurable of course, but right now its set to -- when it needs to show icons, make you 'wait' and load them, then show the screen. Don't background anything, but also do not preload anything; when icons are needed, go get them right bloodywell then.. not earlier, not later, right when you want them. The reason being.. loading icons, even a whole page full, takes no time at all. But doing them _all_ in advance, that takes a bit of time; doing them in background, that cocks up everything or takes awhile.
So now, you load up minimenu and it scans .desktop files instead (fast) and then jumps to the configured start page - be it All, or some tab/category, or whatever; then when it goes to render the page, it loads up the icosn it needs right then and there (from cache if its already seen them of course, for free.)
turns out this is bloody fast; at menu startup it picks up the app list fast, and then on demand loads icons fast; no extra work, nice and trim. Thats the minimenu philosophy.. and now instead of maybe 10 seconds of delay (say), you might get 2. Its not a big payoff for just afew apps, but some crazy peopel like to suck down the entire Repo onto their pandora, like ED does, and the payback is huge if you've got a large pile of applications.
--
Then for user experience speedup, theres stuff like .. when you go into a subcat folder abd backup, where does the selection land? and when you run a pnd app or shutdown and come back to the menu.. do we jump to your default startup tab, or go back to the app you had selected? "Simple" changes like these can make your geneal usage experience much mroe efficient, and 'feel better'. Sure, I didn't code swooshy fancy opengl graphcis in with sliding panels .. I didn't have time when I designed this menu, and I wanted trim and sleek and fast. But we do try to make the device fun and fast to use
Much more to come.. lots of improvements and tweaks, and behavioural changes in where the selection goes when, and search filtering the app listing based on keys entered, and more efficient file management, and so on.
If you guys still use it, we'll keep refining it
jeff
ie: Minimenu was 'designed' (if you can say that
quickly; one of its goals was to work standalone, with X or without; so being we needed it quick (we thoguht we were shipping a week or two later... doh!), and wanted dual mode running, I went with SDL .. make it easy, and works with or without X, and makes testing easy (works on all popular OSes). Peachy! And another idea was to work without the rest of 'libpnd' -- maybe you just want to boot kernel + minimenu, have a bunch of shared libs, and ready to go -- most pnd apps would work like this, and run withotu X (since most use SDL as well!) -- its actually a very fast booting super mimnimal system, nice and lean. (But alas, I've no time to maintain a separate firmware brench, but I do suggest someone do it.. very fun. I got boot time down to like 11 seconds or something Aaaaanyway, so minimenu can run without anything else.. which means it had to do 'app discovery' for pnd files all on its own, well and good, and that can take a few seconds as you see; note also that the rest of the system is _also_ doing that scan, since its spitting out .desktop files for DE like xfce and other appd benefit, so theres actually two scans at boot time, at nearly the same time .. but since dir info is cached and such, its not too big a performance hit, but theres definately a hit there.
So, it took awhile to get to, but I built in options so now minimenu can be configured to run either or both scans -- pnd scan, or .desdktop scan and trust someone else to maintain the .desktops. Given in pracice minimenu is usually run with the rest of the system (certainly in all our firmwares to date), this is a reasonable assumption. But the code for both is in there.. if someone wants to build another firmware and have minimenu do a pnd scan, no problem, flip a config value.
So now on boot, pndnotifyd does its app discovery early in boot and spits out .desktop files; minimenu watches for pndnotifyd to be done, and then picks up those .desktop files. That reduces boot load (one scan instead of two), and parsing the .desktop files is easier than parsing the pnd files .. so minimenu is general much sped up at its start time. The minus side of course is now mmenu has to wait for pndnotifyd (one of the background daemons) to finish up, but its pretty quick about its job, and its still faster than minimenu doing the second scan on its own at the same time.
Also, I experimented with some timing tricks; UIs are funny, since a lot of it is about 'perceived speed' versus 'real speeds', and 'speed during use' which may be not what you expect; so until recently minimenu was loading all icons into a cache at menu start up time, to try and keep 'usage speed high' with a hit to startup time; problem here is that minimenu wants to minimize its system impact, so it exits when you run a pnd -- so minimenu (unlike xfce) uses _almost zero_ system resources when a pnd is running; minimenu exits, runs the pnd, then comes back up. Nice! But as you can guess, this means minimenu is loading up all those icons every time you come back to the menu. It runs fast, paging and browsing is quick.. but you have to load up all those icons, many of which you'll never see (unless you're hitting All all the time, I suppose .. which I do
So, here I got to thinking, and ED is always thinking about user experience and pointed me in the right way.
If you dig into minimenus configs (which you don't want to
, you can fiddle with a lot of stuff. Some stuff is exposed in the config UI, but the real nasty fiddly bits are not shown there.. they're just in textfiles for peopel to edit. Anyway, you can turn on background loading of preview pics (if you use the detail side panel at all), or background app scanning, or background icon loading. Turns out, since we're essentially singlre core, that doing things in background just chugs things up -- your main thread gets slower, and your behind thread isn't going fast, so cock wup the main thread for longer than it should Annoying (At least, doing threading in a simple brute force manner.. doing it very very carefully can works well, but thats work Anyway, most background stuff is turned off, it just didn't work out all that useful. So preview pics, if you want them, are on demand loaded when you idle the selection -- lets oy mvoe the selection around fast, but when you pause on an item (for a configurable amount of time..), it then decides to load the preview and makes you wait. (And loading previews is slow due to the whole 'mount', 'read pic', 'unmount' nature of fetching those until we revise the pnd file layout a bit, sometime down the road.) Anyway.So for icons, its always had the ability to background load icons, but it wasn't really efficient about it since it didn't seem to work over well for user experience, so I didn't work over that code much; recently I thought I'd bang on it some more and introduced a bunch of configurable options .. when to do background icon loading, how fast to do it, which ones to do -- visible, go ahead so paging is fast if you're idling, or to scan all, or what.. all that stuff. Loading icoins is fast, but I always liked the look of, and the function of, background loading -- show you the generic icon template, then pop up the icons as it loads them, while you're working. To my brain, it seemed you'd want to 'get to business' fast, not wait -- maybe you just want to hit 'B' or 'Start' and run the app, who cares if the icon is loaded? So I banged around with a lot of options .. faster background icon loading slows down the main thread, so moving the selection feels clunkier; but it can load each image fast, just as long as it lets you move the selection around fast. But in the end, it just felt 'not right' to do background action, even if just background loading 'next page' and not too many icons, etc and so on.
Meanwhile, ED kept on with a suggestion that I misinterpreted, but when I 'got it' through my thick skull, I tried, and it is what we're going with now. Its all configurable of course, but right now its set to -- when it needs to show icons, make you 'wait' and load them, then show the screen. Don't background anything, but also do not preload anything; when icons are needed, go get them right bloodywell then.. not earlier, not later, right when you want them. The reason being.. loading icons, even a whole page full, takes no time at all. But doing them _all_ in advance, that takes a bit of time; doing them in background, that cocks up everything or takes awhile.
So now, you load up minimenu and it scans .desktop files instead (fast) and then jumps to the configured start page - be it All, or some tab/category, or whatever; then when it goes to render the page, it loads up the icosn it needs right then and there (from cache if its already seen them of course, for free.)
turns out this is bloody fast; at menu startup it picks up the app list fast, and then on demand loads icons fast; no extra work, nice and trim. Thats the minimenu philosophy.. and now instead of maybe 10 seconds of delay (say), you might get 2. Its not a big payoff for just afew apps, but some crazy peopel like to suck down the entire Repo onto their pandora, like ED does, and the payback is huge if you've got a large pile of applications.
--
Then for user experience speedup, theres stuff like .. when you go into a subcat folder abd backup, where does the selection land? and when you run a pnd app or shutdown and come back to the menu.. do we jump to your default startup tab, or go back to the app you had selected? "Simple" changes like these can make your geneal usage experience much mroe efficient, and 'feel better'. Sure, I didn't code swooshy fancy opengl graphcis in with sliding panels .. I didn't have time when I designed this menu, and I wanted trim and sleek and fast. But we do try to make the device fun and fast to use
Much more to come.. lots of improvements and tweaks, and behavioural changes in where the selection goes when, and search filtering the app listing based on keys entered, and more efficient file management, and so on.
If you guys still use it, we'll keep refining it
jeff
milkshake
Advanced Member
dont forget a built in wifi manager and repo connectivity? I remember you worked on that in the past how far did you get with that?
and repo connectivity? I remember you worked on that in the past how far did you get with that?
pmprog
DNF (Did Not Finish)
- Joined
- Apr 25, 2011
- Messages
- 4,150
Is the pndnotifyd better than the MiniMenu PND scan? Could you not set something so you could disable the deamon from the MiniMenu, and let the MM find the PNDs? This might give you some options for increasing load speed, as you can start displaying PNDs as they are found, rather than waiting for the deamon to finish.
Yeah, this is the main reason I don't use the MiniMenudont forget a built in wifi manager
That'd be pretty smart.
In order for me to move back over to MiniMenu, aside from the wireless, would be a "list view", and maybe a filter box. That said, I might even try and have a look at adding them myself when I get some time
skeezix
Internal Development
pndnotifyd has always done .desktop/icon emitting; same codebase as minimenu (ie: they both use libpnd for the heavy lifting.) If you never intend on using xfce or other DE's or apps that read .desktops or icons, you could jusr use minimenu and turn on its pnd-scan and kill pndnotifyd, but it wouldnt' save you much (a second or two). I think its better to leave pndnotifyd up, or if you want, go a full minimenu distro and prune the living heck out of things. (ie: the old kernel+minimenu+shared libs idea I keep mentioning
As to network, repo, and other to-dos .. all WIP, but still in the 'recently had babies, still chaotic' phase of life, so not moving as fast as I used to
jeff
As to network, repo, and other to-dos .. all WIP, but still in the 'recently had babies, still chaotic' phase of life, so not moving as fast as I used to
jeff
milkshake
Advanced Member
its good to hear you have any time at all thanks for your hard work.
thanks for your hard work.
pmprog
DNF (Did Not Finish)
- Joined
- Apr 25, 2011
- Messages
- 4,150
If the boot time is about 10 seconds, a second or two is quite significant. Just thinking
Didn't know you'd just had a baby. Congrats!As to network, repo, and other to-dos .. all WIP, but still in the 'recently had babies, still chaotic' phase of life, so not moving as fast as I used to
Last edited by a moderator:
skeezix
Internal Development
A "list view" is something I've been mulling; ie: a little icon in the top right of the window, to let you change from icon view to list detail view; a conf item in the UI too of course.
The reason I didn't do it yet..
- is that going 'too far' for a minimal menu? On the other hand, I'm not going to not do somethign because of a title.. but I don't want to take it a direction few people want, either. Other menus can fill in all those gaps, maybe? But I do think this is in the realm of minimenu
- Skinning; There are a bunch of skins out there, but not sure how many peopel actually use them; adding any GUI stuff in breaks the skins, so I like t be sure about it first
Still, a list view with a simple up/down navigation might be cool (with the same 'hit key to jump to it' that it normally does.)
I definately intend on adding a key or somethign that toggles into filter mode, where any typing that shows only matching apps with a substring of the typed stuff. So instead of 'jump to first', add som eway to enter 'jump to filter' or something.
Lots to do ..
jeff
A 4 year old, and now the twins! Pfffk, sleep is for the weak I say.
(A good thing I've often been an insomniac.. I'm pretty 'good' at living like a wreck
jeff
The reason I didn't do it yet..
- is that going 'too far' for a minimal menu? On the other hand, I'm not going to not do somethign because of a title.. but I don't want to take it a direction few people want, either. Other menus can fill in all those gaps, maybe? But I do think this is in the realm of minimenu
- Skinning; There are a bunch of skins out there, but not sure how many peopel actually use them; adding any GUI stuff in breaks the skins, so I like t be sure about it first
Still, a list view with a simple up/down navigation might be cool (with the same 'hit key to jump to it' that it normally does.)
I definately intend on adding a key or somethign that toggles into filter mode, where any typing that shows only matching apps with a substring of the typed stuff. So instead of 'jump to first', add som eway to enter 'jump to filter' or something.
Lots to do ..
jeff
A 4 year old, and now the twins! Pfffk, sleep is for the weak I say.
(A good thing I've often been an insomniac.. I'm pretty 'good' at living like a wreck
jeff
Emnasut
Member
- Joined
- Apr 26, 2010
- Messages
- 357
I got boot time down to like 11 seconds or something
Only for minimenu or from the moment you push the power switch? Either way that is damn fast, any chance of getting something like that in the future?
pmprog
DNF (Did Not Finish)
- Joined
- Apr 25, 2011
- Messages
- 4,150
Possibly. I might look at doing this as a seperate GUI option then. The main reason I thought of this was that applications/games with long names get cut off - I have two of Alex the Crocodile (is it?) in a single PND, same icon, but one's game 2 and the other is 4, but you can't tell from the mmenu (without opening the panel, which I prefer closed).
Following on from the last point - A couple of the themes prevented me from hiding the side panel, which is annoying. I (personally) don't need to see screenshots, so it's consuming real-estate that I can be using to show more apps. Is this a theme thing?
Maybe I should consider the tree/list menu as a seperate option, now to find some time :unsure:
lol, what a trooper!
TitanUranus
Active Member
All this chat about minimenu, isn't it time some noob asked why we can't get windows XP with service pack 3 and some additional bloatware installed as the Pandoras default OS/GUI?
pmprog
DNF (Did Not Finish)
- Joined
- Apr 25, 2011
- Messages
- 4,150
If I can get some time, I'll look at something like this
Quick one - I'm a little confused with pndnotifyd. On my SD cards, there's the following folder structure
Code:
|-pandora
|-appdata
|-apps
|-desktop
|-menu
|-mmenuFrom what the wiki, a folder like mmenu can be used to only show PNDs in the minimenu, and from what I can see, the pndnotifyd only searches two locations (desktop path, and menu path).
So, how will/does PNDs from the /pandora/apps and /pandora/mmenu folders get scanned? Am I missing something?
Cheers
skeezix
Internal Development
Consider the config:
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=blob;f=deployment/etc/pandora/conf/desktop;h=c3135ce2e9324c88efe291f12bca2896b03fe092;hb=5c3c97f377fd3be4ceecf16fba765852d1a9572b
9 [desktop]
10 searchpath /media/*/pandora/desktop:/media/*/pandora/apps # path to depth-search for PXMLs and pnd-files
11 dotdesktoppath ~/Desktop/ # path for pndnotifyd to spit .desktop files into (run as root)
12 iconpath /tmp/iconcache # path for pndnotifyd to drop icons into (can be same as dotdesktoppath if WM permits)
13
14 [menu]
15 searchpath /media/*/<1>:/media/*/pandora/menu:/media/*/pandora/apps:/usr/pandora/apps # path to depth-search for PXMLs and pnd-files
16 dotdesktoppath /usr/share/applications # path for pndnotifyd to spit .desktop files into
17 iconpath /tmp/iconcache # path for pndnotifyd to drop icons into (can be same as dotdesktoppath if WM permits)
See menu.searchopath and desktop.searchpath?
menu looks at menu and apps, and desktop looks at desktop and apps. Hence apps goes to both desktop and menu. All configurable.
'mmenu' is parsed by minimenu and not pndnotifyd, but thats a good point .. now that mmenu is scanning the pndnotifyd .desktops, its not going to see 'mmenu', so we should pronbably stop talking about that.. or maybe I shoudl turn pnd-scamnning back on just for that directory. Since most people dont' use that and never heard of it, woudlnt' really slow us down
libpnd is flexible, nothing is hardcoded. Where it looks for things is configured, so you have to check the config files; where those files can be is confgurable, and they can be overridden by copies on SD so that if you blow the configs up you can just eject and good to go And theres defaults built in for most options so if you remove the configs.. maybe it'd still work, I dunno
The system isn't perfect, with its evolutionairy design, but it works; but if you find a hole, let me know
jeff
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=blob;f=deployment/etc/pandora/conf/desktop;h=c3135ce2e9324c88efe291f12bca2896b03fe092;hb=5c3c97f377fd3be4ceecf16fba765852d1a9572b
9 [desktop]
10 searchpath /media/*/pandora/desktop:/media/*/pandora/apps # path to depth-search for PXMLs and pnd-files
11 dotdesktoppath ~/Desktop/ # path for pndnotifyd to spit .desktop files into (run as root)
12 iconpath /tmp/iconcache # path for pndnotifyd to drop icons into (can be same as dotdesktoppath if WM permits)
13
14 [menu]
15 searchpath /media/*/<1>:/media/*/pandora/menu:/media/*/pandora/apps:/usr/pandora/apps # path to depth-search for PXMLs and pnd-files
16 dotdesktoppath /usr/share/applications # path for pndnotifyd to spit .desktop files into
17 iconpath /tmp/iconcache # path for pndnotifyd to drop icons into (can be same as dotdesktoppath if WM permits)
See menu.searchopath and desktop.searchpath?
menu looks at menu and apps, and desktop looks at desktop and apps. Hence apps goes to both desktop and menu. All configurable.
'mmenu' is parsed by minimenu and not pndnotifyd, but thats a good point .. now that mmenu is scanning the pndnotifyd .desktops, its not going to see 'mmenu', so we should pronbably stop talking about that.. or maybe I shoudl turn pnd-scamnning back on just for that directory. Since most people dont' use that and never heard of it, woudlnt' really slow us down
libpnd is flexible, nothing is hardcoded. Where it looks for things is configured, so you have to check the config files; where those files can be is confgurable, and they can be overridden by copies on SD so that if you blow the configs up you can just eject and good to go
And theres defaults built in for most options so if you remove the configs.. maybe it'd still work, I dunno The system isn't perfect, with its evolutionairy design, but it works; but if you find a hole, let me know
jeff
Neelix
Insecticidal Maniac
'mmenu' is parsed by minimenu and not pndnotifyd, but thats a good point .. now that mmenu is scanning the pndnotifyd .desktops, its not going to see 'mmenu', so we should pronbably stop talking about that.. or maybe I shoudl turn pnd-scamnning back on just for that directory. Since most people dont' use that and never heard of it, woudlnt' really slow us down
Wouldn't it just be easier to configure pndnotifyd to spit out .desktops for the mmenu folder to a third folder that xfce doesn't use, and have minimenu scan that as well?
(keep in mind I've not looked at any of the code, but its just a thought)
- Neelix
