Feature #1369: Android app - CHIRP

Custom queries

All CHIRP-next Bugs
All CHIRP-next Feature Requests
All closed issues
All open issues
New Model Requests
Open bugs by Developer
Open bugs by Target Version
Potentially Stalled Bugs

Feature #1369

closed

Android app

Added by Aldo Cugnini almost 11 years ago. Updated over 1 year ago.

Status:

Rejected

Priority:

Low

Assignee:

Category:

Target version:

Start date:

01/12/2014

Due date:

% Done:

Estimated time:

Chirp Version:

0.3.0

Model affected:

(All models)

I read the instructions above:

Description

It would be very useful to getvan Android app in the works. Users could then connect their radio directly to a USB host por on a tabletbor cell phone.

Any thoughts?

Related issues 4 (0 open — 4 closed)

Has duplicate Feature #1411: android

Rejected

01/28/2014

Actions

Has duplicate Feature #2743: Android based version

Rejected

07/20/2015

Actions

Has duplicate Feature #2789: Android App?

Rejected

08/11/2015

Actions

Has duplicate Bug #2951: Request to create Chirp for Android.

Rejected

10/27/2015

Actions

Issue # Delay: days Cancel

History
Notes
Property changes

Actions

Copy link

Updated by Tom Hayward almost 11 years ago

Status changed from New to Blocked
Assignee deleted (~~Dan Smith~~)

Note that the scope of this bug tracker is for enhancements and fixes to the current codebase. Chirp is heavily reliant on the PyGTK GUI framework. This issue is blocked until PyGTK works on Android.

Chirp's core logic and radio drivers could be utilized to jump start development of a third-party Android application using Android's native GUI library. If someone chooses to take on this project, it will be an independent project and have its own bug tracker.

Actions

Copy link

Updated by Mike Storke almost 11 years ago

Not sure if I should write this here or the mailing list, but here goes. Two possibly stupid questions:

How hard would it be to port to something newer (PyQt, PyGObject, Kiva, wxWindows, etc)?
Perhaps better question, and in relation to the blind guy's post, how about separating the GUI from the low level parts (as a shared library) so a non-GUI front end could be written--this could, in theory, run on anything and be displayed on anything.

I haven't looked at Chirp's internals yet, and am not a Python expert, so sorry in advance if these are boneheaded-stupid.

Actions

Copy link

Updated by Dan Smith almost 11 years ago

First off, chirp is 100% cleanly split between driver/radio/clone logic and UI. There is a very neglected command-line tool for driving chirp in that way that could be resurrected (I've offered) for the blind folks if there is someone interested in working on it. The graphical UI can easily be replaced, although it is a non-trivial amount of code and not something I'm looking to do or maintain.

Second, such a split would not magically enable an android app as there are many other hurdles to overcome so further discussion about that sort of thing doesn't belong here (it didn't really in the first place).

Actions

Copy link