Rockbox Technical Forums
Rockbox Development => Feature Ideas => Topic started by: NarcoticV on September 04, 2013, 02:42:20 PM
-
Hey everybody,
I'm new here - bought a Fuze+, heard about Rockbox and decided to try and help out a little bit.
The controls for the Fuze+ are pretty good already, but I'd love to make some changes. I did some work already.
The idea: why not have the touchpad on the Fuze+ behave like a scroll wheel a la IPod/Fuze player? Move your finger in a circular motion and scroll through menu items that way. I think it could be more intuitive than just tapping up and down (personally, I tend to miss the correct tapping area sometimes).
I'd like to hear what you think.
It also raises a question about the code reviewing system: I haven't committed any code to Git yet, and I'm not sure how I can best show you the idea. I have a working proof-of-concept for it (a demonstration screen, not actual usage but representative), which works on the Fuze+ and also in the UISimulator. However, some of the changes have been hacked on in various parts of non-target-specific code, and it breaks any builds that are not for Fuze+ or Fuze+-simulator.
Should I submit this for review, just so people can try it out? Obviously, it's not meant to go into the master branch, but I would like to publish it somehow to show you what it's like... How do people usually handle these kind of situations?
In any case, thanks!
-- edit: just read in the posting guidelines that I should post the patch to the "patch tracker"... Not sure what that means exactly. Could anyone elaborate? --
-
I would put something like that on gerrit, with a note explaining the status (I've done similar things with proof of concept code). http://www.rockbox.org/wiki/UsingGit should explain all you need to know, but feel free to point out unclear bits :)
-
Thanks for the tip. I added it in Gerrit: Change I64836451.
-
Now I'm wondering how I will try to integrate this properly into the control scheme for the Fuze+.
Regardless of how well it will work, I'm sure not everybody would want this functionality, so there should be a choice by the user to go for this alternative control method or choose the original one.
This could be:
- through a settings menu option
- through an extra define that the user can add in the makefile when building rockbox
- some other way
A settings menu option seems like a good way, because users would be able to revert to the normal scheme whenever they wanted (for example, if they want to play a plugin game or something).
Any thoughts? What are the chances of a feature like this getting accepted into the master branch if it works well, if I did it through an extra configuration setting for the user? Or if I did it through a code define in the makefile, or some other way?
Or do you think something specific like this would be forever doomed to go to the unsupported builds section, no matter how it's integrated? ;)
-
While I don't have a Fuze+ I do like the idea.
I'm not sure the setting is a good idea, we generally don't like configurable buttons. But if it's done well and works better than whatever method is in place right now I don't see anything against this change.
-
I think the Setting menu option is the good way! This is absolutely NOT something that is tied to a specific target(s) IMHO. Of course, targets with scroolwheel are going to avoid this option (^^) as well as targets which don't have a touchpad nor a touchscreen.
After thinking about my previous message, developing this for touchscreen isn't actually a priority so I would go ahead without this into mind (of course a certain support - design - has to be taken into consideration anyways).
Let's start thinking targets:
- touchpad
That's it. And we don't have any particular define for those platforms afaik. I encountered this issue while developing on Z5: sharing code with a touchscreen controller, I had to include the touchpad define - still on gerrit, currently.
Once defined these "touchpad" targets we can start thinking about a virtual scrollwheel driver.
Opinions?
-
I've putted a lot of work and thought in the fuze+ keymaps. So here are some general thought about implementing gesture on touchpad's target:
- I thing the way the actual button system works cannot be easily made compatible with some gestures implementations. Especially the short/long button system will make it very difficult to implement gesture not messing/making more difficult to use the actual system. I think a good way would be to keep the standard system for consistency and have a setting switch to go on some touch experimental input system. That way we could start with a blank sheet on a new input system more adapted to touchpad interface.
- then we have to find a way to solve some pure interfacing problem like how do we make difference between long/short press/gesture begin. A solution would be for instance to move all long press to double click press, that way a long press would be safely understandable as gesture begin. or generally any other idea to replace long all press call.
- Once the two above questions are solved we can start implementing additional gesture. I would probably make sense that ones is able two activate with a setting the gesture he want, as some various gesture could get incompatible to each other.
On the principle of a virtual scrollwheel, I have nothing against it, but I think that this is already a quite sophisticate gesture. One could probably start with some basic scrolling function first. That being said once the two first question are solved, anyone can start to implement any gesture he wants
Anyway, I also think that if we can have guidelines on the way to implement it cleanly, there is no way we could find out the detail theoritically. My experience is that the interface require experimenting and comparing different solution before we can actually find which ones are worthy.
-
It seems to make sense that in general, configurable control schemes are being avoided. But about something like gestures (and definitely about a virtual scrollwheel), I think that there will be very strong opinions about which way is "better", no matter how well-implemented it may be - so maybe a general setting that chooses between a "button control scheme" and a "control scheme with gestures" would be necessary.
I won't give any opinions on the best way to fit this into Rockbox, because I've hardly looked at any code except for the Fuze+ - I'd like to learn a bit more about the existing general control structure (also touch-screen etc) before I join in. But I'm really curious to see where this will go.
Also, I'd love to contribute in making it happen. That having been said, I will leave for a long time of travelling in three weeks, and don't have much spare time until then, meaning that after I leave I won't be able to work on it until January/February. I guess this feature isn't in a big hurry though... And you can always beat me to it! ;)
Before I leave, I'd like to at least have "felt it in action": to implement this in a way that's a bit less "quick'n dirty" than the proof-of-concept from before. Also out of self-interest: that way I'll be able to use Rockbox the way I'd like while travelling. It would allow the user to actually use it, instead of just a demo screen.
I think I'll spend my free time in the coming weeks getting that done, doing it in the target-specific button code for Fuze+, and trying to do it in a way that major parts of the code will at least be well-documented and re-usable for when the time comes to do it right. It'll stick to taps, flick gestures and the virtual scrollwheel gesture.
By the way, how many targets are actually out there with touchpads?
And another thing to think about: would we want support for these gestures in the UISimulator? If so, there will have to be code that imitates the behaviour of the touchpad hardware in each target... Or a more general solution would have to do, such as clicking on a button to send the "gesture command" to the UISimulator.
-
This discussion is a bit too general for the title of this topic. We can move to this thread:
http://forums.rockbox.org/index.php/topic,43447.0.html (http://forums.rockbox.org/index.php/topic,43447.0.html)