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@danplanet.com To: chirp_devel@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@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers

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@alumni.uvic.ca To: af5mi@yahoo.com; chirp_devel@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@yahoo.com To: chirp_devel@intrepid.danplanet.com; kosta@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@danplanet.com To: chirp_devel@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@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@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers

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.

Yeah, I think I'm against making the memory editor too much larger. Having to stack a potentially unlimited number of settings in a horizontally-scrolling row just kinda sucks. Also, it is a little more clear that things like extra settings aren't included in, say, CSV exports since they're not part of the table.

I think there *has* to be some way to embed a button in a row. If not, we could just do a link or image thing or something and trigger opening the dialog on click. I'd much prefer that I think.

--Dan

I'm going to be submitting a patch for the list which I think helps address this issue (as well as a few others); Please provide your feedback and if you like the patch by all means commit it.

The way I looked at solving this is by extending the memory editor toolbar, app edit menu, and memory editor context menu to provide additional access to the memory editor (property) dialog.

I extended the concept of "Edit" on the context menu by modifying it to 1) include a "Properties" button the toolbar, which when 'clicked' will bring up the memory editor; 2) including the "Properties" menu item to both the View menu and memory editor context menu and 3) added the 'r' accelerator to the context menu.

I believe this slight modification to the UI provides a clean interface to not only accessing the visible editable properties of a channel, but also the extended 'extra' properties.

It is very simple to now add an app wide accelerator which links to the property page; so please suggest one that is supported by gtk and we can add it.

A next step may be to retrofit the memory property dialog to be more explicit about which properties are 'standard' and which are 'extra'.

Opening up this UI element, may hopefully promote more radio to extend their interface through the 'extra' attribute of the memory class.

-kosta

From: kosta@alumni.uvic.ca To: chirp_devel@intrepid.danplanet.com Date: Wed, 28 Jan 2015 23:19:10 -0800 Subject: Re: [chirp_devel] accessing channel edit menu on mac

Yes, I also don't necessarily agree with the design implications this would have in creating a very large horizontally scrolling window.

I do believe however, that appending an "edit" button/text label to the list would also appear out of place. However, I do have some other ideas as to how we can provide access to this previously hidden information, I will explore this and post another patch when I can.

To the original point, until Jens brought up this issue, I had not yet realized that there existed 'extra' memory settings at all...

Any chance of committing the previous changed I posted to the mailing list?

Date: Wed, 28 Jan 2015 17:55:21 -0800 From: dsmith@danplanet.com To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] accessing channel edit menu on mac

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.

Yeah, I think I'm against making the memory editor too much larger. Having to stack a potentially unlimited number of settings in a horizontally-scrolling row just kinda sucks. Also, it is a little more clear that things like extra settings aren't included in, say, CSV exports since they're not part of the table.

I think there *has* to be some way to embed a button in a row. If not, we could just do a link or image thing or something and trigger opening the dialog on click. I'd much prefer that I think.

--Dan

_______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers

_______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers