Pandora PNDManager

[bzar]

porg: Keeping focus is non-trivial since the list view is actually rebuilt using the new list model. It can be done, but needs a bit of hackery. There are pros and cons in composing a UI from ready elements

Wouldn't the left/right work pretty much only in the installed view? Since all other list views have functionality tied to those buttons?

 

[porg]

Wouldn't the left/right work pretty much only in the installed view? Since all other list views have functionality tied to those buttons?

2) This suggestion has some value in its own, but of course mainly it's a compensation for the lack of keeping focus in lists (see nr.1 below).

But nevertheless for the use case of 50+ PNDs a solution for paging up/down would be appreciated.

Because all main directional buttons are already in use in some view, every new suggestion would be a button mapping chaos.

X/Y are available on all top level views, and up/down in the list view, but it's a bad idea to mix button mappings for different views or view levels.

The only yet unassigned input device in the category of scroll controll are the nubs.

Idea: Left nub up -> page up, left nub down -> page down. Nub and Dpad are physical neighbors, so a conceptual neighbor would be logical.

The right nub could be used for actions.

Btw: The right nub currently acts like a normal mouse button. Thus right nub to the left triggers go deeper (which is moving right). A contradiction. Would be better if go deeper would be mapped nub right or north-east (to ressemble the X-B-button axis orientation) and go up respectively right nub to the left or south-west.

Keeping focus is non-trivial since the list view is actually rebuilt using the new list model. It can be done, but needs a bit of hackery. There are pros and cons in composing a UI from ready elements

1) You can keep a variable prevItem and nextItem holding the UID of the PND, and after rebuilding the list select them.

3) Still begging you to enable "launch app" (ENTER) in the "Installed" list view, thereby using PNDmanager as a top level launcher. Conceptually there would need to be a button "Launch (ENTER UI hint icon)" above "Show ("B button UI hint icon)", with the disadvantage of less space for the description text. Currently that description text is anyhow cut at a certain length, so that there is enough space for a second button left. Even if you decide against the button, having the key mapping working silently without a UI resemblance, would still serve pro users.

 

[bzar]

2) This suggestion has some value in its own, but of course mainly it's a compensation for the lack of keeping focus in lists (see nr.1 below).


But nevertheless for the use case of 50+ PNDs a solution for paging up/down would be appreciated.

I see three main use cases for the installed list:

• Upgrade/install queue
• Open specific installed PND for examination/operations
• Browse through the installed PNDs without looking for anything specific

1 is trivial, as it's always on the top. 2 is provided through the keyboard filtering. 3 shouldn't require page up/down, but it might be convienient.


Not seeing a high priority issue there, but we'll see.

Because all main directional buttons are already in use in some view, every new suggestion would be a button mapping chaos.


X/Y are available on all top level views, and up/down in the list view, but it's a bad idea to mix button mappings for different views or view levels.


The only yet unassigned input device in the category of scroll controll are the nubs.


Idea: Left nub up -> page up, left nub down -> page down. Nub and Dpad are physical neighbors, so a conceptual neighbor would be logical.


The right nub could be used for actions.


Btw: The right nub currently acts like a normal mouse button. Thus right nub to the left triggers go deeper (which is moving right). A contradiction. Would be better if go deeper would be mapped nub right or north-east (to ressemble the X-B-button axis orientation) and go up respectively right nub to the left or south-west.

I'd rather not override the OS settings like that. The nub mouse functions are far more likely to be familiar to the user than such "intuitive" controls. I put "intuitive" in quotes since because the user already has prior expectations regarding the nubs' functions, it's actually counter-intuitive to go against that, no matter how intuitive the controls would be in the absence of previously learned controls. It's bad enough the sync button is also alt which some use to alt-tab out of pndmanager's window.

1) You can keep a variable prevItem and nextItem holding the UID of the PND, and after rebuilding the list select them.

Unless you know the code, don't make trivial suggestions . The actual case in any code is almost always more complicated than it seems at first thought. It is doable, but not as prettily as one could assume.

3) Still begging you to enable "launch app" (ENTER) in the "Installed" list view, thereby using PNDmanager as a top level launcher. Conceptually there would need to be a button "Launch (ENTER UI hint icon)" above "Show ("B button UI hint icon)", with the disadvantage of less space for the description text. Currently that description text is anyhow cut at a certain length, so that there is enough space for a second button left. Even if you decide against the button, having the key mapping working silently without a UI resemblance, would still serve pro users.

I'm reluctant to add this, since PNDManager would be, IMHO a horrible "top level launcher"

There's also some potential for counterintuitive and contradictory UX. In the search function, typing a search word and pressing enter shows the search results without initiating any operations on any of the results. In the installed view, the same would execute the first search result. The search operates like it does for performance reasons (full search is a lot slower than filtering by name).

 

[Neelix]

Because all main directional buttons are already in use in some view, every new suggestion would be a button mapping chaos.

X/Y are available on all top level views, and up/down in the list view, but it's a bad idea to mix button mappings for different views or view levels.

The only yet unassigned input device in the category of scroll controll are the nubs.

Idea: Left nub up -> page up, left nub down -> page down. Nub and Dpad are physical neighbors, so a conceptual neighbor would be logical.

The right nub could be used for actions.

Btw: The right nub currently acts like a normal mouse button. Thus right nub to the left triggers go deeper (which is moving right). A contradiction. Would be better if go deeper would be mapped nub right or north-east (to ressemble the X-B-button axis orientation) and go up respectively right nub to the left or south-west.

I'd rather not override the OS settings like that. The nub mouse functions are far more likely to be familiar to the user than such "intuitive" controls. I put "intuitive" in quotes since because the user already has prior expectations regarding the nubs' functions, it's actually counter-intuitive to go against that, no matter how intuitive the controls would be in the absence of previously learned controls. It's bad enough the sync button is also alt which some use to alt-tab out of pndmanager's window.

I very much agree with B-Zar on this one. As someone who always runs PNDManager windowed and makes the mouse cursor visible via the config file, remapping the nubs in this way would break things for me.

- Neelix

 

[danielm]

This is a quote that got f***ed up by the forum software that doesn't work well in browsers that deviate from the standard (cool to see this in a linux community) and are older than 1 month:

The .out files would be for the crashing. He's using the debug version with extra output that might be helpful.

The .out is attached to this posting. You can ignore the errors about some PND parsing failures (can't paste text into this post in this forum), I deleted the PNDs and re-placed them. As I said before, this crash might be something that was fixed before and it has probably nothing to do with the failed MD5 sums. Unfortunately I stopped using the debug version of PNDManager because it collides with the ordinary PNDManager and it will replace itself when updating all PNDs.

Today, I had several broken downloads again (time was 13:57 in Oslo) and I had to re-start PNDManager three times to complete the update process of five PNDs.

Would it be possible to implement a workaround for the problem, while trying to find out what causes it? When PNDManager encounters an MD5 error, it could just re-download the PND in question and also continue downloading other PNDs (remember, when an MD5 error is encountered, the download queue will not be processed any more, even though there would be one download slot free next to the failed download).

Hope this helps somehow

pndrun_pndmanager_crashed.out.txt

 

[porg]

B-Zar: Browsing shouldn't require page up/down.

Neelix paraphrased: Nub for scrolling up/down breaking control concept for windowed mode.

Agreeing to B-Zar, but at certain list length, some way of quick scrolling would be convenient.

The most UX compliant way (introducing nothing new, just modifying something existing): When using a swipe gesture for scrolling up/down use a higher scrolling speed. Basically the same physics simulation as on the other main touch OSes (iOS, Android). For precise scrolling the user has fingerDown-move-stop-fingerRelease or the Dpad-up/down, for faster scrolling fingerDown-move-immediateFingerRelease, the scrolling then continuing until the scrolling momentum is over or when the user prematurely touches again to stop the momentum. The scroll speed can even vary depending on the finger swipe->release speed. 

'B-ZaR', on 08 Jan 2014 - 9:18 PM, said:

I'm reluctant to add this ["ENTER for launching PND in list"], since PNDManager would be, IMHO a horrible "top level launcher"  There's also some potential for counterintuitive and contradictory UX. In the search function, typing a search word and pressing enter shows the search results without initiating any operations on any of the results. In the installed view, the same would execute the first search result. The search operates like it does for performance reasons (full search is a lot slower than filtering by name).

The "Search" screen refreshes "on ENTER": from a pure UX perspective (in a world with super computing power) this would not be necessary, but for performance reasons it must be as response time is critical to UX, in doubt trumps other UX factors. So as it anyhow operates differently than searching in the "Installed" screen (instant filtering, no need for ENTER), thus already no consistency anyhow, I don't see the problem.

In the "Installed" screen the user starts typing and immediately gets visual feedback (the list elements change, with a high probability already after typing the first character). Thus the user very unlikely triggers enter for submitting a search ("I already got a result, so why would I ask for it again?").

In the "Search screen" the user types a query, and nothing happens. Already after the first or second character type it's clear that this alone is not enough. According to universal key binding convention, the user presses ENTER. Now what could happen to a user being used to the behavior "ENTER launches app" from the "Installed" screen, is that the user browses within the results (with the Dpad) and wants to launch it with ENTER. Currently nothing (seemingly) happens (query is unchanged, package-list unchanged,  thus no retriggering), as there are actually two focuses in this screen. The typing focus is still in the search field ("remains hot", no need to TAB between search field and search result area, or moving with the dpad from the topmost result into the search field, as often found on Desktop apps) With an unchanged query, ENTER could simply launch. With a changed query line of course, ENTER must trigger the query.

 

[dimag0g]

It should. The metacategories in PNDManager are defined as regexp filters, as seen here. If it doesn't, libpndman does not, for one reason or another, report its category as "Utility". Have you validated your PXML to make sure it's not malformed? Any PNDs I've tested seem to work fine, so no idea without further investigation.

It seems that PNDManager just doesn't display apps which are already installed when browsing categories (that would explain why I fail to see my own apps in there). Could you confirm?

 

[bzar]

Agreeing to B-Zar, but at certain list length, some way of quick scrolling would be convenient.

The most UX compliant way (introducing nothing new, just modifying something existing): When using a swipe gesture for scrolling up/down use a higher scrolling speed. Basically the same physics simulation as on the other main touch OSes (iOS, Android). For precise scrolling the user has fingerDown-move-stop-fingerRelease or the Dpad-up/down, for faster scrolling fingerDown-move-immediateFingerRelease, the scrolling then continuing until the scrolling momentum is over or when the user prematurely touches again to stop the momentum. The scroll speed can even vary depending on the finger swipe->release speed.

This is already (IIRC) implemented (at least the QML Flickable element supports it). Try flicking the views. Maybe the friction could be tuned though.

The "Search" screen refreshes "on ENTER": from a pure UX perspective (in a world with super computing power) this would not be necessary, but for performance reasons it must be as response time is critical to UX, in doubt trumps other UX factors. So as it anyhow operates differently than searching in the "Installed" screen (instant filtering, no need for ENTER), thus already no consistency anyhow, I don't see the problem.

In the "Installed" screen the user starts typing and immediately gets visual feedback (the list elements change, with a high probability already after typing the first character). Thus the user very unlikely triggers enter for submitting a search ("I already got a result, so why would I ask for it again?").

In the "Search screen" the user types a query, and nothing happens. Already after the first or second character type it's clear that this alone is not enough. According to universal key binding convention, the user presses ENTER. Now what could happen to a user being used to the behavior "ENTER launches app" from the "Installed" screen, is that the user browses within the results (with the Dpad) and wants to launch it with ENTER. Currently nothing (seemingly) happens (query is unchanged, package-list unchanged,  thus no retriggering), as there are actually two focuses in this screen. The typing focus is still in the search field ("remains hot", no need to TAB between search field and search result area, or moving with the dpad from the topmost result into the search field, as often found on Desktop apps) With an unchanged query, ENTER could simply launch. With a changed query line of course, ENTER must trigger the query.

One design principle I've tried to keep through the entire GUI is not having UI element focus. All the buttons always do the same thing within a view. For lists of items (in the broad sense also text input fields) don't actually break this as the interaction is manipulating the list UI element. This also makes it quite straightforward to map game controls without awkward navigation from one UI element to another, guessing which way the desired element should be from the one the focus is now in.
Basically you're right about the intuition between the immediate filtering and executed search query. Because of the feedback the user expects different things.

I'll... consider the enter key the next time I happen to do stuff for PNDManager. I still think it's a bad idea to use it as a launcher for several reasons.

It seems that PNDManager just doesn't display apps which are already installed when browsing categories (that would explain why I fail to see my own apps in there). Could you confirm?

Yes

 

[danielm]

Is there a difference between automatic downloads from the update queue and manual downloads from within a PNDs details page?

Last time I synced, there where quite some updates available. I ran into the broken download problem quickly. Then I set the updater to only download one PND at a time, which also didn't work for me. Out of desperation, I viewed a PND (highlight the PND and press the "B" button to get to the detailed view) and started the download manually. This time, everything went well. After that, I continued to download about 10 PNDs manually, without a single error. Maybe it was coincidence, maybe something else?

 

[bzar]

Nope. Compare upgrade all with upgrade from package view

EDIT: Though it is always possible the queuing is broken somehow

 

[Neelix]

I have noticed that it doesn't seem to start any queued downloads until all current downloads have finished. (instead of starting one from the queue when a slot opens up) If a download "breaks" (download finished but with errors, so it just sits there in a 'downloading' state doing nothing) then it never triggers the remainder of the queue.

- Neelix

 

[bzar]

Well noticed. It seems I've connected "done" and "cancelled" events but not errors that QPndman::Handle also emits. A bona fide clear as day bug

 

[bzar]

PNDManager 1.3.8.0 prerelease

If some of you could test this out before I upload it to repo it'd be swell.

Stuff to test:

• Abovementioned queue bug should be fixed
• A bug regarding symlinked PNDs fixed (symlinking a PND to scanned directory used to make stuff not work)
• UI polishing based on feedback from Ekianjo (package list spacing, fonts and stuff)
• Added custom devices option to config, which can be used to regard specific directories like SD cards. The config takes a comma-separated list of paths. I've found adding /tmp very useful for testing out stuff. Suggested by Linux-SWAT (launch pndmanager once first to get an empty option to the config, then edit)
• Installed-view should try to retain cursor position after PND deletion as suggested by Porg
• Left/right work as page up/down in installed-view as suggested by Porg
• Enter executes PNDs from installed-view as suggested by Porg
• Queued items now don't appear in multiple sections at installed-view

EDIT: Levi found a new bug in queuing (entries showing up in multiple sections when queued),  I'll fix it and upload a new version

EDIT2: Uploaded

 

[levi]

Okay, new version fixes the queuing. It's a little odd that queued items report their size as 1 byte completely downloaded if you highlight them, but it's fairly understandable they're still queued, so their stats haven't been downloaded yet.


More of an issue is despite it not showing anything as upgradable any more, hitting Y caused one item from the 'Downloading' list to move to 'Queued', but it was still actually downloading. I guess that's technically only cosmetic though, as everything still did download okay.


Left/right do work now as pageup/down, although on my machine when I scrolled to the top of the list then paged down twice (right, right) the page ended up scrolled not on a whole line, and the selection was between lines as well. Going up or down fixed that glitch though, and if you don't start the page down from the very top, it doesn't happen. Again, entirely cosmetic, but a little odd.


The good news is, enter does launch games directly from the install list, and when you remove a PND and go back to the installed list, the highlight is on the next item in the list.


I can't say I have noticed much difference in the UI. The server view (second tab) doesn't look as cramped as it used to, and I don't recall the titles being bold. It all looks okay to me is all I can say.


I tried adding one of the subfolders of my browsers's download folder as the right hand argument to the customDevices left argument, but it doesn't seem to have picked up anything from it. I'll have to double check my testing tomorrow, and likewise test symlinks then.


And one new feature request that's come out of testing - I think it'd be nice if, if you've started searching for items by typing from the installed screen, pressing the X button cancelled the search, like it cancels and takes you back in most other contexts.

 

[bzar]

Levi: Thanks for the comments! I'll try to fix those before release. The filter cancel would be a bit of an inconsistency, because filtering is also available in views where it's possible to go back. Making it first clear, then go back is bad also as it breaks the direct button mapping the UI is built upon. Maybe something like pressing delete (fn+backspace) would be ok?

 

[fusion_power]

I hope this kind of great tool and software system will also be used onto the Pyra, it makes it so easy and comfortable to maintain your software.  

 

[bzar]

PNDManager 1.3.9.1 prerelease

Fixed Levi's findings (all but the custom device issue which is still under debugging) and one comments-induced crash reported by Ziz.

EDIT: Added new libpndman with Cloudef's static analysis fixes (so maybe less bugs)

 

[porg]

Left/right do work now as pageup/down

The good news is, enter does launch games directly from the install list

when you remove a PND and go back to the installed list, the highlight is on the next item in the list

Wow! All my feature suggestions were implemented plus one feature "launch via enter form list view" being explicitly welcome ("good news") by another user ;-)

it'd be nice if, if you've started searching for items by typing from the installed screen, pressing the X button cancelled the search

+1. Seems consistent, reasoning:

1) No conflict: AFAIR searches are anyhow only possible on top levels, "X" cannot bring one up higher, thus being assigned to "clear" is no conflict.

2) Conceptional similarity: "clearing a field" (=returning to previous state) to "returning to previous hierarchy".

Overall quite consistent.

 

[bzar]

IIRC category views have filtering as well, so they're not all on top level.

 

[danielm]

The queuing system is working fine in the new release. I will download old versions of some PNDs and try updating them in the evening (when my internet connection is worst/slowest) and see if I can provoke downloads getting stuck (after I assured myself that the old version of PNDManager from the repo _does_ give me broken downloads).

Thanks for all your work on this great software!