Pandora Usability of package management (PND) --> Coordinating related development efforts

[porg]

As you realized yourself in your second reaction: It is really odd. Because the custom sub-categories all work fine EXCEPT if they share a common string beginning.

 

[skeezix]

I like what you've doen.. ie: really, we've had most or all of these goals on the various project to-dos for some time, but pulling them together into a single goal list, rather than spread across the apps, puts things in a better light. Easier to make a plan when its viewed as a whole, not per-project. I think wiki for discussion is terrible, but good place to put summary.


I'm getting back into the swing of things after 2-3 weeks being hard 'out' (back to work, a breather from the crying babies so I'm no where near caught up .. a lot of this stuff is things we've all had on the cooker for some time. (The feature requests for mmenu in the bugtracker have been on my todo list since day one really.. ie: jump to key, versus search panel modes, etc The trick as always is we've always had very few people actually working on firmware, and stuff like pndstore and milky are very new and been done in peoples spare time to scratch their itch; fortunately we have good folks who generally do work well together .. we draft specs and revise to meet newer spec changes, etc. But the problem remains -- we have few hands, and a vast supply of 'needs'. (Consider our goal to move the firmware forward to .next whicvh takes hundreds of developer hours to accomplish, and we have really only djwillis doing it in the time he can make available...)


Problem is .. we still have only a few hands


Solution -- getting more hands seems to be (to this sleep deprived mind) a function of number of units in the field; this problem will get better over time in theory..


So in the absence of new hands, all we can do is prioritize. Maybe pick off low hanging fruit. ie: Some fixes are just 'easy' (at least for the maintainer) .. righrt now with RL kicking my tail its easy for me to slouch off, but really, some of these mmenu thigns I can knock off in a few mins or an hour. So once I get my soul back a little, maybe I can do that.


So perhaps you want tyo pull together the 'detail level' todos, and see if you can gauge community interest in some of them, and try to figure out the level of ease, and the interest level, and put new feature requests into the tracker.


ie: the tracker is the item-level database of actions; it has ease and interest level slots, and can sort by them. Its not the best tool out there, but it works, and is what we have. So why not try to convert some of your action iteem requests into feature requests. Mayube some of them peopel do or donmt' want, so maybe want to troll the forum and get a perspective, then attach forum references to the tracker items.


ie: So that when devs get time, they can poach there and say 'filter by the apps I can work on, and show me easy ones' and get to it?


Or maybe thats just wasting your time, I dunno -- but hopefulyl you see what I'm eluding too - given few hands (like, literally, a couple of hands), what can and shoudl they do?


jeff

 

[porg]

Dear Jeff and others!


I guess I'm yet quite unknown in the OP community! What many of you don't know: I already contributed a lot, but until this thread here now, it seems that my actions were not noticed at all.


Summed together, I already spent many workdays only filing bug reports and feature suggestions to the issue tracker. I spent a lot of effort into being as clear and illustrative as possible to ease a proper handling with as little callbacks as necessary. So far almost ZERO reaction!!!


Now I publish something to the forum, and here the reaction is far better! It feels good to finally get some feedback! So please: Have a look at the issue tracker, subscribe to its issues! Otherwise it leads a sad existence.


Now back on topic. Before filing new issues, I suggest to carefully look into the issue tracker for existing bugs and feature suggestions. Many of them are small fixes (for the competent persons).


I started this co-ordination effort to aid as a central framework of the large topic Usability concerning package management (discovery, management, overview, launching), from/to which the single efforts are acted from.

 

[skeezix]

I wouldnt' say not noticed 'at all', dont' discredit your work But as I say, theres few hands, and they're mostly 'well defined' .. djw looking at .next, notaz tracking kernel plus his many other projects and hacks (the emus, tv-out recent fixes, you name it); I'm rather out of commission for a little while longer. The others such as ivanovic, sebt3 etc are on their various projects.


So ED tracks the tracker, and I dip in when I have time (which hasn't been for a little while , and random people do check in therer quite a bit.. but of coure devs, theres sztill only a few, so you cannot expect much to change week by week


But do your work, it is just not glory work; we call it 'plumbing', right?


jeff


Your more recent update, that going 'up' from folder should select the folder you werre just in, does make a hell of a lot of sense tho

 

[porg]

I have small coding abilities (those of a media artist: Processing, Arduino, some JS, PHP, BASH), so expect little from this.


But what I do is, test a lot, analyse, write memos, give productive feedback.


And now I realize, that this is appreciated!

 

[sebt3]

And now I realize, that this is appreciated!

Dont worry about that, it is indeed

 

[EvilDragon]

Well, I don't have much time right now, but I'll also chime in a few things.


First: I check the tracker and fix stuff I can fix. But that's mostly for scripts, as I can't code.


All reported issues are appreciated and I fix whatever I can do, but I don't report back on these issues but just include fixes in the new Hotfixes


About usability:


Panorama and MilkyHelper are a very good start. They are working pretty good already, so I think we should work on including these into the official OS.


The biggest issue are currently the more recent QT-Libraries needed - as a workaround, we could include Panorama as PND including these libraries until DJWillis has a working .next for us


About categories:


We follow the Freedesktop-Standards, and they also allow us to create new categories.


So we're fine here. However, MiniMenu has a big flaw in the interpreation of the categories.


I already suggested to skeezix a fix for that a few months ago, but nothing happened here (no idea whether he didn't like the idea or just didn't have time, but I guess he can speak for himself here )


Here's the issue I'm talking about:


Freedesktop categories don't always have nice names (there are names like AudioVideo, AdventureGame, etc.) - that's because they are NOT meant to be shown with these names.


For XFCE, for example, there's a config file where I can define what category shows up in what menu.


For example, I set up that the categories "Audio", "Video" and "AudioVideo" show up in a menu named "Multimedia".


This works great and unclutters the menu a lot, as you will probably never have more than 10 - 15 Multimedia-Apps on your SD Card.


MiniMenu shows these categories.


On my system, I've got a tab named "Audio", a tab named "Video" and a tab named "AudioVideo".


Each tab only has a few apps in there, which is pretty annoying.


There are 12 main categories defined in the FreeDesktop standards - so that means we'd have a maximum of 12 tabs for our stuff, which is very cluttered.


I think we should need a config file for MiniMenu as well. It could be something simple like

[AudioVideo]


Multimedia

[Audio]
Multimedia

[Video]
Multimedia

Or maybe some XML-Standard file.


But I think we really need a config file to tell MiniMenu where to sort what. I could then easily update that with firmware updates and every user could define his category-sorting himself by just changing that config file.


That's the one thing I'm missing about MiniMenu.


Now, there's another thing that annoys me with MiniMenu:


We've got libpnd that exists to create the .desktop files. That works freaking fast. If I put my SD Cards in the slot, it takes about 7 seconds and all apps are sorted in the menu.


And as libpnd works in the background, all apps are instantly in the menu, as soon as XFCE is fully loaded after a boot.


With MiniMenu, it takes about 10 - 15 seconds when I started it. And what's worse: It does that EVERYTIME I quit playing a game - which is pretty annoying when trying out new stuff.


For me, starting MiniMenu takes longer than starting a full desktop, and that defeats the purpose of MiniMenu.


As libpnd works on that stuff in the background, shouldn't it also create some Cachefile for MiniMenu, so MiniMenu wouldn't need to check for apps itself everytime?


Why is MiniMenu even checking for apps when that should be the task of libpnd?

[/CODE]

 

[fusion_power]

The biggest Minus of Mini Menu for me is, that it doesn't return to the last cathegory or section or anything. Whatever you change or do, you always get throwed back to the first cathegory, that's the "all apps" section in my case. I havn't found an option that forces Mini Menu to STAY wherever it was. Until this is not solved, I just can't use the Mini Menu often, it's just to frustrating.

 

[Caine]

I think it just shuts down and restarts all the time to save resources (but I'm not sure). If this is true it certainly ought to do some caching of the content and remember its location.


For the caching part, it probably is sufficient to write the relevant content of the .desktop files in ~/Desktop and /usr/share/applications to a single cache file and monitor them for changes (or check their last modification date) to determine when to update the cache.


@ED. If such a mapping file already exists for XFCE, why not reuse that for MiniMenu. Do you have reasons to believe they would significantly deviate in content?

 

[EvilDragon]

@ED. If such a mapping file already exists for XFCE, why not reuse that for MiniMenu. Do you have reasons to believe they would significantly deviate in content?

Sure, that would make sense.


So include the XML-Mapping setup from XFCE into MiniMenu, add some caching so that it doesn't always reload and MiniMenu gets A LOT better already.


As skeezix is pretty much busy right now, anyone else who want to submit patches for that?


I'm sure skeezix wouldn't mind


Ah, one thing I'd also love to have:


Two lines for the game name!


It's just too short. There are PNDs where you don't know whether you'll run the game or the editor, as the name is too long for one line.

 

[Mr Rob]

The biggest Minus of Mini Menu for me is, that it doesn't return to the last cathegory or section or anything. Whatever you change or do, you always get throwed back to the first cathegory, that's the "all apps" section in my case. I havn't found an option that forces Mini Menu to STAY wherever it was. Until this is not solved, I just can't use the Mini Menu often, it's just to frustrating.

Though I don't want to derail the current discussion...


@Fusion_Power, you can his 'select' on the MiniMenu and go to 'Configure Minimenu' and under 'general options' choose the default tab to show. Not quite as perfect as showing your last viewed tab, but it may help if you only use the Game category anyway.


I usually create my own 'Favorite' category, and that works well for me.

 

[skeezix]

Well, I don't have much time right now, but I'll also chime in a few things.


First: I check the tracker and fix stuff I can fix. But that's mostly for scripts, as I can't code.


All reported issues are appreciated and I fix whatever I can do, but I don't report back on these issues but just include fixes in the new Hotfixes


About usability:


Panorama and MilkyHelper are a very good start. They are working pretty good already, so I think we should work on including these into the official OS.


The biggest issue are currently the more recent QT-Libraries needed - as a workaround, we could include Panorama as PND including these libraries until DJWillis has a working .next for us


About categories:


We follow the Freedesktop-Standards, and they also allow us to create new categories.


So we're fine here. However, MiniMenu has a big flaw in the interpreation of the categories.


I already suggested to skeezix a fix for that a few months ago, but nothing happened here (no idea whether he didn't like the idea or just didn't have time, but I guess he can speak for himself here )


Here's the issue I'm talking about:


Freedesktop categories don't always have nice names (there are names like AudioVideo, AdventureGame, etc.) - that's because they are NOT meant to be shown with these names.


For XFCE, for example, there's a config file where I can define what category shows up in what menu.


For example, I set up that the categories "Audio", "Video" and "AudioVideo" show up in a menu named "Multimedia".


This works great and unclutters the menu a lot, as you will probably never have more than 10 - 15 Multimedia-Apps on your SD Card.


MiniMenu shows these categories.


On my system, I've got a tab named "Audio", a tab named "Video" and a tab named "AudioVideo".


Each tab only has a few apps in there, which is pretty annoying.


There are 12 main categories defined in the FreeDesktop standards - so that means we'd have a maximum of 12 tabs for our stuff, which is very cluttered.


I think we should need a config file for MiniMenu as well. It could be something simple like

[AudioVideo]



Multimedia


[Audio]

Multimedia


[Video]

Multimedia

Or maybe some XML-Standard file.


But I think we really need a config file to tell MiniMenu where to sort what. I could then easily update that with firmware updates and every user could define his category-sorting himself by just changing that config file.


That's the one thing I'm missing about MiniMenu.


Now, there's another thing that annoys me with MiniMenu:


We've got libpnd that exists to create the .desktop files. That works freaking fast. If I put my SD Cards in the slot, it takes about 7 seconds and all apps are sorted in the menu.


And as libpnd works in the background, all apps are instantly in the menu, as soon as XFCE is fully loaded after a boot.


With MiniMenu, it takes about 10 - 15 seconds when I started it. And what's worse: It does that EVERYTIME I quit playing a game - which is pretty annoying when trying out new stuff.


For me, starting MiniMenu takes longer than starting a full desktop, and that defeats the purpose of MiniMenu.


As libpnd works on that stuff in the background, shouldn't it also create some Cachefile for MiniMenu, so MiniMenu wouldn't need to check for apps itself everytime?


Why is MiniMenu even checking for apps when that should be the task of libpnd?

Old things, and things I've often wanted to attack; great, good to be in allignment. But as you say, I got derailed


Category


-----------


- config file to do category mapping, sure, no problem; I didnt' get to it before because I'd already done that in the past, but then went and built the config editor menu and tossed out a bunch of the textfile config hacking options, so its sort of ugly under the hood, and I need to clean it up. (Well, a lot of mmenu code is goofy, since the original goal was.. Craig wanting a new menu in 4 days so we coudl ship, but of course our ship date sliipped and slipped.. but mmenu's fondation was really all done in 4 nights


---> so yeah, I can do this for you, not too hard.


- we did a lot of changes to mmenu for the later few hotfixes (total overhaul of a few things .. like the whole category/tab system), so I wanted to let the dust settle, and see if it was riddled with bugs or not; fortunately.. not!


- is everyone more or less happy with the look and feal? Its pretty 'rigid' (it is 'mini'menu after all, not 'bells and whistles'menu), but I think it does its job pretty well; ie: its not fancy opengl or svg-scaling or animations, but looks good for static raster artwork; renders quick! I consider the goal to be fast and efficient to use/operate, with most options available, but not everything; not infinitely flexible, but a little flexibile.


Networking:


-.. is this a prioriry, ot does anyone really care? ie: We started this road, but I got derailed. ie: given the command line tools in firmware now, I can work more on the idea of having mmenu scan for wifi networks, try to connect to them using your xfce wallet, and stuff like that; could even use tempel's pndstore API to show an icon over old apps on the display.


----> but I worry this might all be for naught, that people really ultimately donm't care? or is this out of scope for _mini_menu being mini? or is this the line .. it'd be nice to have some basic network operations in mmenu .. ie: so you could bring up network, and then run firefox pnd, without having to jump to xfce?


----> we need a vision decision here. I've sort of been going with the sassumption we want to build this stuff, and I'm starting to get free time again so I could start investigating


Caching:


- I built a preliminary cache in the past; worked good, but had some issues I forget now; I originally built it in such a way where mmenu would do its own caching, and then you could ask mmenu to refresh its cache (or it'd automatically do it once in awhile.. say once a day, or after a SD change was detected.) The problem here being.. the SD coudl be updated while the unit is off, so no way for mmenu to really know there was a change needing a refresh. So I never built this in since it was .. humm, haww, not sure


---> another option I pursued and never fleshed out (someone else di some work here, but vanished.) .. doing app caching at the libpnd level, entirely; ie: when a filename is found, check (say) its file size and if same as recorded, then skip parsing the PXML and use cached PXML and icon. Some possible error potential,since what if just the PXML version changed, but the size didn't .... I think the other fellow had some clever ideas (outside of running md5 hashes, which is slow on 10,000 apps too..) .. so maybe doing it at the mmenu level and having occasional/manual re-cache hits is fine?


libpnd:


- some fixes .. many have noticed a biug that crept in back around hf4 I think, where after running a pnd, some series of dbus entires or inotify entries is triggering libpnd to do a rescan, which means on app exit, the unit slows doen for a couple seconds while everything is checked. Sort of annoying, so I'd like to fix that


mmenu UI


- some minor changes might be nice .. improve the app-seek-on-typing behaviour, or add options; right now it jumps to letter, but could make an option so if you type 3 letters in a row, to search them as a word, not as the third letter; or perhaps do _filter_ instead of _jump_ .. if you hit 'a', have it show all that start with a, and then if you type 'b', have it show all that match ab, rather than jump at all?


--> or search mode.. s 'search tab' that could be default always on, so if you go to that tab, it has a text entry field at the top; any typing there causes an app filter to go on (ie: it acts as All tab, but with filtering.) Then leave the 'jump to letter' behavior for other tabs?


-> peca or pperu or something there (above no doubt) noted into the tracker a few scenarios needing repair


... on return to mmenu, jump to selected app (good?)


... on return up a level from within a folder, should hilight the folder (makes sense to me)


... someone started a thread on some UI decisions as a whole that shoudl be invbestigated; right now, I'm depending on folks to work thigns out and make good solid requests, that peopel geneerally agree on, as I've not the time to run info gathering sessions myself


--> edit: long filenames/advertised names.. this is a tough one; the detail panel is togglable so may not be present; could show a info-line option on the UI but woudl break all skins, and might just be ugly. Could show the full time as a floating bubble that pops up for a second when item is walked over or selected, but that soujnds liek bad UI. Theres the music app style of showing the full name in the small box provided, slowly sliding back and forth so if you stare long enough you see the whole name, or can otherwise control it with a num. Seems goofy to me, too (who wants to wait?) ... so I pondered this problem (like all of these issues but never came up with a good idea. Problems are easy.. solutions are harder


-----> pressing a key to toggle the detail panel (already in) may be fine, but fleshign out the info in the detail panel more? Or do we really need to make the info fit.. ie: could scale the font as needed, with a minimum 'floor threshhold', so if the name is too big, scale it down to fix? (and if the name is a whole paragraph long, just truncate it, devs fault.)? That might be the way to go .. I mean, good enough for Apple etc, right?


I'm no UI expert, so not sure if these qare good or bad ideas.


There, thats my list of things I'd like to do in mmenu.


Please let us know if you think these (an an item by item basis) are good or bad. I've not the time right now to monitor all threads or run polls, so someone tell me and I can get to coding.


(keep my time useful, not farting around


jeff


edit: I always wonder what the interface divide is . ie: I rather assume its 80% peopel using xfce, since they get full options there (browser, etc), and hence more OS focus goes there? Or if mmenu is really 50% or 80% of uders, we shoudl put more attention to it (and other non-xfce UIs.)


edit: I'd put _my_ priority right now (in terms of easyness to build ... category merge/rename stuff, caching (nice and fun speedup!), simple UI stuff, then networking if wanted, then fancier UI stuff (filtering, etc.)


edit: currently libpnd has:


pnd_box_handle pnd_disco_search ( char *searchpath, char *overridespath ) {


(and also a single-file scanner variation.)


Options are to add another _caching() variation but thats goofy (new function for every scan option combination is silly); adding a global 'toggle caching' option is a little goofy, but workable; adding another search function that takes a bitmask of options could work too, something like:


pnd_box_handle pnd_disco_find ( char *searchpath, char *overridespath, unsigned int options ) // replacing deprecated _search() function


(or instead of unsigned int, a struct, or whatever.)


But maybe just easier to add a function like..


pnd_disco_set_option ( pnd_disco_enum option, void *value );


--> pnd_disco_set_option ( pds_caching, PND_DISCO_CACHE_ON )


Then pndnotifyd and mmenu could both enable that (based on config settings, so could be disabled?) and good to go..

 

[porg]

@Jeff! Thanks for answering in such detail! As you openly asked for a task list, and I carefully thought the Pandora OS 's UI / UX related issues through, I now feel free and qualified to give you a prioritized todo list, already factored in the relation of coding effort to gained benefit:

1. Improvements concerning remembering state (#241) and navigation (#239) as pointed out by many users (i.e. @Fusion_Power, me @porg, etc)
   
2. Enormous speedup (=time gain) through caching rather than scanning each time. A time saver for the masses! Clearly this is more work, but for the beginning follow the maxim: Users prefer speedup over top reliable content accuracy! Why? You launch/quit your apps daily/hourly, whereas you only add/remove apps every here and then. Therefore the focus should clearly be on keeping the time for returning to MiniMenu (and your recent state/position) and the effort to navigate/browse as minimal as possible! And if a user clearly misses something (occurring rather rarely!), s/he will be surely be willing to trigger that "manual re-scan". And in later versions for MiniMenu you will probably find a system which is very accurate but still fast, and only needs manual re-scanning in exceptional situations.
   
3. Category related severe bug (#265 disappearing categories!)
   
4. Category related improvements (config files for mapping of FreeDesktopCategories to user desired category names as suggested by @EvilDragon).
   
5. Improve jump-to-app from "string input as a word" as you call it (#243) or at least fix the bug of the existing "cycling through" functionality (#258).
   
6. Function "Delete app", "Delete app settings only" (associated AppData on same SD) "Delete app and its settings". The "discover, install and update" process for now is out of the scope of MiniMenu, definitely better done in other apps such as PNDstore and PanoramaMilky. But a "Delete app" function is probably only very minimal coding effort for you, and it would practically help a lot. Because if you as a user are browsing your apps, and see all the alternatives around, you are likely to make that "delete" decision right within this context, hence it would be great if that decision could be acted out right from here, in the app's context menu (launched via the SPACE key).
   

Tasks for a later realization:

1. Better overview through Filter options and Favorite system. The favorite system is at best system-wide (residing in the .OVR files) and not on an launcher-application specific basis. Therefore this needs an agreed standard. I would appreciate further discussion on this, but it is clear, that this is a more long term feature realization. For starters, consider the described actions "overview" and "launch" in http://www.pandorawiki.org/PND_management_workflow
   
2. Network ability improvements are low on the priority list, as there is a cheap workaround to get WiFi working properly within MiniMenu (though yet only with the cost of minimizing security) Hint: Make sure to set your initial keychain password to an empty string. From then on: Launch "Toggle WiFi" to ON, the whole WiFi connection procedure now works without any further user interaction, use Network app as long as you like, quit it, "Toggle WiFi" to OFF to conserve battery power.)
   

Some things in detail:


@Jeff regarding jump-to & filtering:


You had the idea of using direct character key input to narrow down the list of displayed apps. I advocate for using those "instant key input" simply for the jump-to method. Why?


Goal of this task is to launch an application, whose name is already clear to you!


Therefore it does not make a difference, whether you get a reduced list, or wether the app jumps to your intended app.


Whereas FILTERING makes sense, where a rather large (and rather unknown) quantity of items, shall be reduced to match certain intended criteria.


And related items are unlikely sharing their relatedness in their app title, but rather in their meta data like category, usage-frequency, favorite, rating, etc.


@EvilDragon regarding custom category mappings:


1) To reduce the effort for managing custom categories, I suggest the opposite format:


I suggest to map "User desired category 1" -> "ExistingCat1", "ExistingCat2", "ExistingCat3".


Rather than the more redundant and error-prone "ExistingCat1" -> "User desired category 1"; "ExistingCat2" -> "User desired category 1"; "ExistingCat3" -> "User desired category 1".


2) I think "ExistingCat" shall have the right to be listed in as many different "Custom Cat" egories as you like, to give users flexibility, thus allowing an app to appear at multiple places (tabs, folders,etc), if one desires it.


3) I am thinking of a combined config files solution (similar principle of cascading style sheets) so that the system maintainer defines the default category mappings, which suit most users, and those who want more details, add/override only portions of the ruleset in a separate file, with the advantage, that after the next hotfix, the user does not need to work in all his/her changes again, and on he other side can benefit from updates to the default mappings.

## Delivered default category mapping files (managed in versioning system)

## One for all, possible deviations for specific launchers if it makes sense for them

cat-sys-all

cat-sys-xfce    

cat-sys-minimenu

cat-sys-launcherXYZ 


## User override/additions for all launchers, and specific launcher

cat-usr-all

cat-minimenu-usr