New package management code testing

BuZz

I have already given you an answer on this.

It's not too difficult to follow currently - others have managed. Please don't quote our styleguide at me - I am aware what is in there, since I helped adjust it to our project.

I have already said I will document the API more in the future. I am likely going to use a bash supporting extension to doxygen or similar. As I wrote the functions I would like to document it myself - but in my own time.

meleu

WOW! I didn't expect this reaction!

I'm sure I can manage it. I just suggested it because I think my job gives some time to read the code, but I have no access to a linux box to actually write a code. I'm an industry operator, I have to control several variables (level, pressure, temperature, start pumps, etc.) and sometimes these variables are behaving very well. This is when I can read and comment the code. (Please, don't think I operate like a Homer Simpson! :D We have several trends to monitor these variables.)

I thought "If I have to read it to understand what it does, why not comment to help future contributors?". But it's OK, I see you are very attached to your code :-) I won't touch it!

Please, sorry, I won't bore you on this anymore.

BuZz

Please don't overreact :)

I don't think it make much sense for someone else to document the code that they have said they don't fully understand because it is not documented ? I also have my own plans for this and want to make further changes to the API, but I appreciate the offer.

Please understand that I am not working on this in my free time simply to make it easier for you to implement something - as with the other thread when you said "please rewrite this in python for me". I don't work for you. Sorry.

I listen to user suggestions, and try and improve RetroPie as I can, but it is not my job.

meleu

@BuZz said in New package management code testing:

(...) as with the other thread when you said "please rewrite this in python for me". I don't work for you. Sorry.

Oh, I didn't want to sound like a boss. Sorry again :-)

The jslist.c is so small. And actually I learned the minimum python knowledge needed to translate jslist.c to jslist.py, and I did it. But I did it with python3 and then I realized this "python2 vs. python3" issue. It's a little tricky to install pygame for python3. I did it, but I don't want to force the users to install a new package for such a small task (list the available joysticks). I'll keep it in C until the will to rewrite in python2 comes to my mind. :-)

BuZz

It should be possible to get a list of the system joysticks without an external tool from shell script directly btw, which would remove the need of an additional tool to compile. I plan to implement better support for multi player and joystick assigning (it is needed to fix up player 2 configuration on keyboard also), but may do it as part of the configuration editor, or even via some changes to ES as with recalbox.

meleu

@BuZz the use of SDL2 lib is usefull for detect joysticks regardless of the connection method (usb, bluetooth, etc.).

BuZz

I assume all joysticks create a /dev/jsX device though - so should be possible (if it can be worked out how to match the order etc if it's not the same as the /dev/jsX order)

meleu

@BuZz [I'm not sure if we should be using this thread for this, but it's going interesting! :D ]

Yeah. Indeed they are all /dev/input/jsX. But, for example, when I use udevadm info -q all -n /dev/input/js0 for my 8bitdo zero bluetooth controller, it doesn't show me the joystick name, neither in ID_MODELnor anywhere. This is why I went to SDL2.

BuZz

I will take a look - I wanted to use the names in the configuration editor, so I will need this (or a tool like yours)

meleu

@BuZz
Oh... I've just remember that I created a thread to discuss this about a month ago:
https://retropie.org.uk/forum/topic/991/solved-how-can-i-get-the-connected-joypad-names/

@Zigurana pointed me to the SDL2 approach.

BuZz

I will continue there if I have an update.