Notice: Trying to access array offset on value of type bool in /srv/www/vhosts/openpandora.org/domains/bugs.openpandora.org/httpdocs/scripts/details.php on line 649 FS#265 : MiniMenu: Flawed tab display of sub-categories if they have a common string beginning

OpenPandora Main OS

  • Status Unconfirmed   Reopened
  • Percent Complete
    0%
  • 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 - 11.10.2011
Last edited by Stefan Nowak - 31.01.2012

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 ----------------------------------------------------------
Admin
Stefan Nowak commented on 11.10.2011 23:22
UPDATE: This bug only happens on Pandora OS 1.5.a4. On 1.5 it does not happen! Hopefully this helps tracing the bug.
Admin
Stefan Nowak commented on 11.10.2011 23:31
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
Admin
Stefan Nowak commented on 21.10.2011 21:02
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.)
Jeff commented on 31.01.2012 20:32
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. http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=commit;h=4b971492a7042a6771f7b441db54b22bb400e235
Admin
Stefan Nowak commented on 31.01.2012 23:58
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.
Jeff commented on 01.02.2012 01:38
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
Admin
Stefan Nowak commented on 01.02.2012 19:03
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: http://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits -> 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).

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing