OpenPandora Main OS

Quick Actions
Notice: Undefined index: tasklist_type in /srv/www/vhosts/ : eval()'d code on line 228 Notice: Undefined index: tasklist_type in /srv/www/vhosts/ : eval()'d code on line 233
  • Status Unconfirmed   Reopened
  • Percent Complete
  • Task Type Bug Report
  • Category Application
  • Operating System Release 1 (Zaxxon)
  • Severity Medium
  • Reported Version Hotfix 5
Attached to Project: OpenPandora Main OS
Opened by Stefan Nowak - 2011-10-11
Last edited by Stefan Nowak - 2012-01-31

FS#265 - MiniMenu: Flawed tab display of sub-categories if they have a common string beginning


I assigned personal subcategories to some of my games. Some of those subcategories share the same beginning string, i.e: Shooter, ShooterBallistic ShooterScoller. MiniMenu displays those subcategories with flaws! See the ASCII screenshots below. Note: The star symbols indicate the currently active selection. The main category tab "Game" being active: ---------------------------------------------------------- | All | Audio | AudioVideo | Education |*Game*| Graphics | ---------------------------------------------------------- ActionGame AdventureGame ArcadeGame BlocksGame ... Shooter ShooterBallistic ShooterScroller ... GameA GameB GameC ... ---------------------------------------------------------- Now if I navigate into the sub-category "Shooter", everything normal: ---------------------------------------------------------- |*Shooter*| ---------------------------------------------------------- .. ShooterA ShooterB ShooterC ... ---------------------------------------------------------- But if I navigate to the sub-category "ShooterBallistic", strangely MiniMenu shows 2 tabs, "Shooter" and "ShooterBallistic", and jumps right into "Shooter". ---------------------------------------------------------- |*Shooter*| ShooterBallistic | ---------------------------------------------------------- .. ShooterA ShooterB ShooterC ... ---------------------------------------------------------- In order to reach my intended tab "ShooterBallistic" I need to navigate to it again. Annoying. There the contents are as expected: ---------------------------------------------------------- | Shooter |*ShooterBallistic*| ---------------------------------------------------------- .. ShooterBallisticA ShooterBallisticB ShooterBallisticC ---------------------------------------------------------- The flaw is the same for all other sub-categories beginning with "Shooter...". All have the flaw as shown in the example "ShooterBallistic", only that it is themselves instead of "ShooterBallistic". One more example to be perfectly clear: ---------------------------------------------------------- | Shooter |*ShooterScroller*| ---------------------------------------------------------- .. ShooterScrollerA ShooterScrollerB ShooterScrollerC ----------------------------------------------------------
Stefan Nowak

Tuesday, 11 October 2011, 23:22 GMT
UPDATE: This bug only happens on Pandora OS 1.5.a4. On 1.5 it does not happen! Hopefully this helps tracing the bug.
Stefan Nowak

Tuesday, 11 October 2011, 23:31 GMT
UPDATE 2: Under 1.5 the bug is even more severe! Certain sub-categories (which share a common string beginning) do not even show up at all! Those marked with a star* don't appear at all on MiniMenu in OS 1.5 Platform, PlatformShooter* Shooter*, ShooterBallistic, ShooterFlight, ShooterScroller
Stefan Nowak

Friday, 21 October 2011, 21:02 GMT
On Pandora 1.6 (=Release 1, Hotfix 6) the bug still exists like on 1.5. (Only in Pandora OS 1.5.a4 had a different buggy outcome.)

Tuesday, 31 January 2012, 20:32 GMT
Investigating the code .. okay, so I very deliberately did this, as a side effect of how I did it internally (a quick hack ;) -- ie: it appends subfolder name to parent folder name, with a * separator (which is normally not allowed in this sort of thing) -- this explains why * buggers up -- this explains the weird behaviour of filtering bring up multiple similar names subfolders, due to how its calculating which part of the name to look at I should probably block '*' from allowable characters .. or at least strip it out, to avoid _this_ problem (by creating another, since you might want *.. but you shouldnt' use that, so thats probably more acceptible.) I could use another character but that just displaces the problem. I could use a control or otherwise unprintable character, but need to do a code review about that, and I'm al ittle tight for time so can worry about that later. For now I am mapping * to _ when entered into 'register custom subcategory' and 'register cvustom category'. The multiple tabs showing up in a subfolder view is now fixed.;a=commit;h=4b971492a7042a6771f7b441db54b22bb400e235
Stefan Nowak

Tuesday, 31 January 2012, 23:58 GMT
Just to be certain, that you did not misunderstand me: The bug occurred with no asterisk character being involved at all !!! I just used the asterisk as a denotation in the report! If you understood it that way, and were indeed writing in the sense that you actually have an "asterisk flaw" in your code, then I would say forbidding asterisks in sub/category strings is an understandable standard, if you cannot figure out a solution with a control character, which undeniably would be the best solution. Users will live with the limitation of not using an asterisk character much better than having to abstain from using strings which share the same beginning, which is the current limitation due to the bug.

Wednesday, 01 February 2012, 01:38 GMT
The issue had two parts.. - subcats of the same parent cat, where both subcats had the same starting set of characters (probably of certain lengths, too) - also, a second issue, is using * in custom category names. Both separate issues, in the same piece of code. The first one is now fixed (so you can have Game -> Emulator and Game -> EmulatorFoo just fine.) The asterisk one is still in there, and it now maps * to _ when you create a subcat/cat custom category, as a stop-gap. Now, there is no standard since the Standard only defines specific standard categories and subcats; you're not supposed to have custom ones at all ;) The definition on custom category naming probabyl needs to be clarified; ie: spaces are not allowed I imagine, they would probably break things; I forget if I trim them out .. probably not. ie: Spaces are bad, in the same way they do not exist in the real standard; remember that mmenu is geared towards honouring the real Standard, so we have to stay close to it, though allowing for made up names. So it seems reasonable to me to have.. - no spaces - no asterisks <- though if this really truly bugs you, I could look into it; probabyl not too hard a change, but lots of things need working on that are more pressing too :) - limited length <- actual length TBD So, the first issue is fixed; the second (asterisk) issue is at least 'worked around' for now, but suboptimal. You coudl keep this report open for that, if you like, or close; or open another for that one. *shrug*
Stefan Nowak

Wednesday, 01 February 2012, 19:03 GMT
1) From your response and the given example, I am now assured, that you understood my bug description correctly, and fixed it accordingly. Fine! 2) The asterisk character was used in my bug description merely as a symbol character, and just coincidentally an actual bug with an asterisk existed, of which I had no awareness whatsoever. I just coincidentally hinted you towards it :-) ALLOWED CHARACTERS: So far I had never used any character besides [A-Za-z0-1] in sub/cat strings, and also do not intend it for the future. I think your proposed standard for allowed sub/cat characters (no whitespace and special characters) seems reasonable for the common OP user. My only wish inquiry is to possibly allow printable non-English letter characters, so that non-English speakers could insert there characters as well! If not possible [A-Za-z0-1] is also sufficient. Support for extended Latin characters would be fine (still a bit Western World biased), support for entire Unicode (Greek, Cyrillic, Arabic, Chinese,… not necessarily symbols/dingbats) would of course be the best for the internationally orientated OpenPandora platform! LENGTH LIMITATION My suggestion: a) To be somehow related to the common technical boundaries as in: -> Maximum filename length 255 or 30, or their respective halves if the available length must be shared for subcat and cat. b) Or something related to the maximum available sub/cat UI-space (=in the layout). But this is not such a clever limitation, as sub/cat presentation UIs may vary (in the future revisions of MiniMenu, or various other sub/cat/OVR interfacing clients), text content could be presented in scroll mode, etc. I would prefer to only give in to a technical limit. TODO: For Skeezix: - Define this standard on your own responsibility, or include other people, if the must be included in this standard definition process. - The finished standard definition should be made available in the PXML/OVR/.desktop and MiniMenu documentations / wikis. - MiniMenu's UI should inform the user with an understandable error message, if s/he offends the limitations. For porg: - He will take the communication part. He will refer developers of existing OVR utilities to this definition, as soon as it is defined, and in addition make a general announcement on the boards (for potential future OVR related developers).


Notice: Undefined variable: effort in /srv/www/vhosts/ : eval()'d code on line 18 Notice: Trying to get property of non-object in /srv/www/vhosts/ : eval()'d code on line 18 Warning: Invalid argument supplied for foreach() in /srv/www/vhosts/ : eval()'d code on line 18
Date User Effort (H:M)