[chirp_devel] accessing channel edit menu on mac

Wed Jan 28 16:15:54 PST 2015

Wow that sounds cool.  When I get a chance I would love to add the memory name.frequency display button for tyt h9800.  I’ll have to give it a try when I have some time.

James

> On Jan 27, 2015, at 1:06 AM, Kosta Arvanitis <kosta at alumni.uvic.ca> wrote:
> 
> 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 <mailto:kosta at alumni.uvic.ca>
> To: af5mi at yahoo.com <mailto:af5mi at yahoo.com>; chirp_devel at intrepid.danplanet.com <mailto: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 <mailto:af5mi at yahoo.com>
> To: chirp_devel at intrepid.danplanet.com <mailto:chirp_devel at intrepid.danplanet.com>; kosta at alumni.uvic.ca <mailto: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 <mailto:dsmith at danplanet.com>>
> To: chirp_devel at intrepid.danplanet.com <mailto: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 can
> imagine 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 for
> radios that have extra settings in the memories.
> 
> --Dan
> 
> 
> _______________________________________________
> chirp_devel mailing list
> chirp_devel at intrepid.danplanet.com <mailto:chirp_devel at intrepid.danplanet.com>
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel <http://intrepid.danplanet.com/mailman/listinfo/chirp_devel>
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers <http://chirp.danplanet.com/projects/chirp/wiki/Developers>
> 
> 
> _______________________________________________ chirp_devel mailing listchirp_devel at intrepid.danplanet.com <mailto:chirp_devel at intrepid.danplanet.com>http://intrepid.danplanet.com/mailman/listinfo/chirp_devel <http://intrepid.danplanet.com/mailman/listinfo/chirp_devel> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers <http://chirp.danplanet.com/projects/chirp/wiki/Developers><2015-01-26_22-02-14_r2342+.diff>_______________________________________________
> chirp_devel mailing list
> chirp_devel at intrepid.danplanet.com <mailto:chirp_devel at intrepid.danplanet.com>
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel <http://intrepid.danplanet.com/mailman/listinfo/chirp_devel>
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers <http://chirp.danplanet.com/projects/chirp/wiki/Developers>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20150128/cb20a9e3/attachment-0001.html 