So I'm new to Chirp, did some looking around, and posted some questions around Android-based CHIRP to the user list, and they (Tom H) suggested the Developers list would be a better place to discuss.
Exec Summary: I want to lead an effort to develop an Android version of CHIRP.
My Goals of the Project:
1. Get permission from the existing owners to extend CHIRP 2. Invite the existing developers to participate - with the expectation that none has the time or interest 3. Create minimal (no) additional work for the existing CHIRP team. 4. I would like to leverage as much of the CHIRP structure as is practical 5. Build in such a way that changes from the main version can be copied directly to mobile
Questions for this list: (I have so many!) #1: Is this a good idea? #2: Are you willing to let me try? #3: What would be a good level of "linkage" between the "computer" and "mobile" teams? #4: Is this list the right place to continue discussions?
About me: Profession IT guy since pre-2000. "Systems" guy....scripting, admin work, application architecture, primary focus on security on Windows/Linux. Last 12 months I've been focused on device management in the mobile space. Not a developer, but I have done a fair amount of scripting (Batch, REXX/Regina, Perl, VBScript). New ham (KC1BHR) with a General ticket.
Thanks for reading this far, and thanks for all the work you have put in to making Chirp such a great tool!
--Rich
Background emails from the User list:
From me:
Based on the comments in the linked Feature #1369, Android is not in scope or on the roadmap for the existing development team. It sounds as if the existing code base could be forked for the new platform, based on the existing separation between the driver/radio/clone logic and UI. The fact that there is a commandline tool (even if very neglected) may provide an additional starting point.
Ideally, I'd like a new community of developers (I have some in mind) to support such an effort, so as to not add work to the existing devs. At the same time, there's a tremendous amount of knowledge the existing team has developed, and I'd like to leverage as much of that as is reasonable.
Disclaimer: I'm not a developer (I've done it, and I know what I'm not good at). Scripting and admin-type work, or project management, that I can do.
Milton Hywatt: In my early Android days I did a lot of data mining Using Google for any information I could get my hands on. I guess if you are lucky to find people that know and program both PyGTK and the Android GUI would be a good start. Like mentioned before the actual guts of the program that moves, collects and organizes the data portion would probably have no trouble in Android. It's just the GUI that would have to be redone. As far as steering you a little closer taking some of the research work out I'm not your man. However one of the Chirp coders named Jens seemed to be fairly familiar with some different tools out there that could help with a GUI conversion. Might keep watching this topic and see if he chimes in. It's been discussed in the past 3 months or so.
Tom Hayward: Don't expect a whole lot of involvement or expertise from the current Chirp devs. I don't think any of us have worked with Android much. We can help you understand the codebase enough to build another GUI for it.
I'd use one of the Python for Android projects, like Kivy, to load Chirp's Python radio clone code. If you keep everything in Chirp's "chirp" folder the same, you'll be able to use new radio drivers as they're released. Everything in the "chirpui" folder will need to be rewritten.
Tom KD7LXL