Support and General Use > User Interface and Voice

A few User Interface quirks that seem strange to such a fine firmware OS

(1/2) > >>

Kratos:
Firstly, I personally live rockbox and all it has to offer.  I am not a real programmer, so when it comes to customizing rockbox, I am left at the mercy of various patches and builds people create.  (but i am looking into updating some of my favorite patches [i don't know tho... it seems daunting] and creating a WPS for the ipod 5G).

Now for the question.. err.. comment... err.. observation?
I don't really know what to call it...

okay a question: What does it take for patch or feature created out of a patch to be implemented into the CVS/current builds?  Why do i ask... Because there are several patches out there which add functionality or aesthetics to an otherwise spartan UI.   What to I mean?

http://forums.rockbox.org/index.php?topic=5881.0 This patch seems logical and doable, displaying settings within the menus so the user wont have to execute an additional button process.

http://forums.rockbox.org/index.php?topic=5881.45  later in the same topic is a more logical suggestion to the keys used to navigate the menus.

For iPod users, the scroll wheel settings are hardly adequate if not frustrating...  The scroll wheel acceleration patch described here: http://forums.rockbox.org/index.php?topic=4973.0 and here: http://www.rockbox.org/tracker/task/5594  also would seem to be useful additions to the iPod CVS builds.

I'm not addressing more cosmetic WPS patches (like Album Art, or custom margins) as they don't add to the functionality of rockbox (across a wide margin of devices and such)... But patches such as the "the" sorting patch were nixed quietly... http://www.rockbox.org/tracker/2885

Are all potential CVS additions discussed on the IRC, or should there be a board/thread to decide/discuss which patches/features should be implemented and which should be discarded..

And in the end, I am just wondering, please don't give an answer like "Patch your own builds" because i believe some interface quirks are relatively painless to "fix"... :-\

Llorean:
The patch for the menu settings within menus was discussed, but I think there was a lack of follow through from the person working on it, as often happens, and so it's somewhat faded away because there's no longer a force behind it trying to find what is necessary for it to reach acceptability.

The scroll wheel patch does not function with the new button action system, I believe, and until it's fixed to do so, can't really be included. Again, a case of needing someone to take it under their wing, and find out what the core developers ask of it.

The "The" sorting patch was not 'quietly', it was nixed as loudly as any patch that gets rejected. There's no reason why users can't simply name their files in a way that they're sorted effectively, and no reason to add the unnecessary addition to code size. Users have to remember that Rockbox is one piece of software capable of running on multiple targets and the limitations of other non-iPod platforms do have to be taken into account when it comes to basic functionality that will run on all players, such as track sorting. It was an option that was almost entirely a very mild convenience, and pretty much decided unnecessary.

What patches get accepted are discussed primarily in IRC, mainly because that's where the patch authors come to ask about them. Patches get accepted in the VAST majority of cases by the Author coming to the core developers, saying "What do I need to do to this patch for it to be accepted?". Now you may think that the core developers should be reading the patch tracker for patches, but really the core developers are working on their own stuff, and often only look at a patch when someone directly brings it to their attention, and will only commit a patch *after* it's cleaned up. The "apply, and then fix" methodology doesn't work for them. The developer's mailing list also works for discussing patches, but most authors seem to prefer discussion realtime.

So, basically what I'm saying is that for a patch to have a likelihood of inclusion, someone basically has to "sponsor" it by making sure the patch compiles cleanly against CVS, works, and meets the programming guidelines, as well as making sure to address the objections various people may have against it.

Kratos:
Hmm... okay I see.
So basically in order for a patch to be committed it needs to be:
-Compatible with the current CVS
-Have the interest of some developer
-Be an active discussion in the IRC
AND there are two levels of development:
-The creator/whoever wants to fix the patch to match the build
-The developer, who puts into the build


hmm...... okay, okay thanks

Llorean:
These aren't "rules" or anything, but seem to be the most common process of a patch getting into CVS.

Many times when you see a patch sit on the tracker for a while, there was one reason or other why it absolutely could not be included (such as the developers deciding that another feature had to be working first) and the patch author lost interest in Rockbox due to the time it took for their patch to come 'round to consideration.

JdGordon:

--- Quote from: Kratos on December 22, 2006, 02:31:12 PM ---Hmm... okay I see.
So basically in order for a patch to be committed it needs to be:
-Compatible with the current CVS
-Have the interest of some developer
-Be an active discussion in the IRC

--- End quote ---
- yes, but thats obvious...
- no, only needs one person with commit access to apply it, there are 60odd people apparently.
- it just needs to be brought up, irc happens to be the best place because its instant and lots of the main developers are there. (9am GMT is usually a good time for activity)

Navigation

[0] Message Index

[#] Next page