[chirp_devel] accessing channel edit menu on mac

Mon Jan 26 22:06:05 PST 2015

I have put together a quick prototype which allows the Radio class, via the features interface, to expose user defined memory attributes.  In a way it extends the memory object allowing the user to generically specify editable columns in the edit view.

As this is only a prototype, I have only upgraded two radio classes (UV5R and FT60) to utilize this feature and not all portions of the mem edit view support it.  You can try it by applying the supplied patch, I would appreciate the feedback.

Under the current prototype users can define user extensions to the memory class by specifying a tuple in the radio features structure.  This tuple defines the caption, type, and choices for each "user" defined memory which is then stored in the memory's "user" dictionary.

For example,

    def get_features(self):
       ...
        rf.valid_user_mem = [ ("BCL", TYPE_BOOLEAN, "bcl", False, None), \
            ("PTT ID", TYPE_STRING, "pttid", PTTID_LIST[0], PTTID_LIST)

    def get_memory(self, number):
        ....
        mem.user["bcl"] = _mem.bcl
        mem.user["pttid"] = PTTID_LIST[_mem.pttid]

As a result "BCL" and "PTT ID" will appear in the memory editor as either Text or ComboBox ui elements, depending on whether or not choices are provided.  Two values will be added to the dictionary under the keys "blc" and "pttid" each of the respective type defined by the tuple.

This API is simply a proof of concept, no mention is made to committing the code as is. 

 This may allow us to ask the question, does it make sense to allow each radio define its own memory class, rather than a single common class that all radios must adhere too...?  While many radios share many similar attributes, it is not uncommon for a particular make/model to deviate from this slightly.  This is even more true when it comes to settings.

We may wish to take this a bit further and help define a method of serializing raw memory into a class object which may then be reflected to appear in the memory editor, settings editor, etc.. thus resulting in a completely radio driven interface...   

-kosta

From: kosta at alumni.uvic.ca
To: af5mi at yahoo.com; chirp_devel at intrepid.danplanet.com
Date: Sat, 24 Jan 2015 13:37:28 -0800
Subject: Re: [chirp_devel] accessing channel edit menu on mac

Hi Jens,

I also find it counter intuitive; the mem.extra concept is hidden too deep in the ui so that some users may not necessarily realize it exists. Unfortunately, the TreeView does not support CellRendered buttons that would allow us to directly show to the Edit dialog.

Maybe there is another method for exposing custom channel settings.

-kosta

Date: Sat, 24 Jan 2015 20:46:09 +0000
From: af5mi at yahoo.com
To: chirp_devel at intrepid.danplanet.com; kosta at alumni.uvic.ca
Subject: Re: [chirp_devel] accessing channel edit menu on mac

Dan,
I sent a separate query - I'm not sure how/when you determine if the radio has extra settings. Seems mem.extra is only populated sometimes for set_memory.Should this be a radio features flag, e.g., rf.has_extra_channel_settings?
Hi Kosta,I noticed you seem to be very comfortable with GTK and UI portions of the code.Do you know what it would take to enable a column in edit table view with an "edit" button when the radio has extended channel settings?
I suspect alot of users aren't even aware that there are extra channel settings for some radios (even in windows world, unless they are handy with right-click, i.e., power-users)
-Jens
        From: Dan Smith <dsmith at danplanet.com>
 To: chirp_devel at intrepid.danplanet.com 
 Sent: Thursday, January 22, 2015 9:45 AM
 Subject: Re: [chirp_devel] accessing channel edit menu on mac

> Besides right-clicking fpr context menu on a channel, is there a way to> access the channel edit menu, i.e., by keyboard shortcut or other> combination if user doesnt have right-click mouse setup (I think most> mac users dont).Well, control-click gets you that without any extra settings, but I canimagine that dyed in the wool mac folks probably wouldn't think of that.> I'm wondering how users would even know to look at the extended edit> menu for channels.Well, I right-click on everything looking for more stuff, but... :)

> Maybe one of the columns (last one?) should contain an edit button which> has the same functionality (open edit window for that channel).Yeah, that seems reasonable, as long as we only display that button forradios that have extra settings in the memories.--Dan
_______________________________________________chirp_devel mailing listchirp_devel at intrepid.danplanet.comhttp://intrepid.danplanet.com/mailman/listinfo/chirp_develDeveloper docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers

_______________________________________________
chirp_devel mailing list
chirp_devel at intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20150126/9f9fd518/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2015-01-26_22-02-14_r2342+.diff
Type: application/octet-stream
Size: 10002 bytes
Desc: not available
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20150126/9f9fd518/attachment-0001.obj 