kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Hey John,

I'm all for a read only hot key list based on the hot key list editor.
It would be more user friendly than the current flat hotkey list.  Since
both of these bug reports are wishlist items, they should be tagged for 5.1.

Cheers,

Wayne

On 09/28/2018 12:44 PM, John Beard wrote:
> Hi Wayne,
> 
> I understand - my question is what would be the better resolution for
> lp:1778374 for 5.1 (not 5.0.1)?
> 
> I have not done any work on the list dialog yet on any branch, as I
> don't want to waste time making a read-only widget if that's not the
> preferred method.
> 
> My feeling is that it would be better to kill off the list dialog and
> redirect the Ctrl+F1 action to the hotkey editor (which has the filter
> now). In future, when the legacy hotkey system is killed off and we
> port the hotkey dialog to the GAL-style tool actions (lp:1663896),
> then we could look at a slicker hotkey list widget if that has
> anything to add at that time.
> 
> In the meantime, lp:1792159 (listing hotkeys in tooltips, also a 5.1
> target) is probably the biggest positive impact we could have on
> hotkey deliverability.
> 
> Cheers,
> 
> John
> On Fri, Sep 28, 2018 at 4:16 PM Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>
>> Thanks for the clarification.  Wishlist bugs are always tagged for the
>> next release version so there is no need to make any hotkey list dialog
>> changes for 5.0.1.
>>
>> On 09/28/2018 10:42 AM, John Beard wrote:
>>> Hi Wayne,
>>>
>>> I was only planning to make changes to the list dialog (as opposed to
>>> the editor dialog) in the master branch. I'm not planning to backport
>>> any of the filter stuff to 5.0.1.
>>>
>>> The aim is to check off https://bugs.launchpad.net/kicad/+bug/1778374
>>> (Wishlist: add search box to Help --> List Hotkeys menu), which is
>>> milestoned for 5.1.
>>>
>>> The patches just merged would provide good groundwork for that (even
>>> if the list dialog used totally different widgets, the underlying
>>> HOTKEY_STORE would be re-usable), but don't actually complete that
>>> bug.
>>>
>>> Cheers,
>>>
>>> John
>>> On Fri, Sep 28, 2018 at 3:32 PM Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>>>
>>>> Hey John,
>>>>
>>>> Given that 5.1 is pretty far along and the delta between the 5.0 and
>>>> development branches, I would rather you didn't spent a lot of time
>>>> trying to back port the dialog fixes which are low priority.  I want to
>>>> get 5.0.1 tagged as soon as possible and merge the eeschema-gal stuff so
>>>> we can get some wider testing on that.  Having all hands on deck to fix
>>>> any issue we find in the eeschema-gal code will be more beneficial.
>>>>
>>>> Cheers,
>>>>
>>>> Wayne
>>>>
>>>> On 09/28/2018 10:23 AM, John Beard wrote:
>>>>> Hi Wayne,
>>>>>
>>>>> Do you have any preference on the hotkey list dialog? I'm happy to go
>>>>> either way, but I'd like to know the preferred direction before I
>>>>> spend too much time on it!
>>>>>
>>>>> Cheers,
>>>>>
>>>>> John
>>>>> On Fri, Sep 28, 2018 at 3:11 PM Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>>>>>> Hey John,
>>>>>>
>>>>>> Nice work!  I merged your patch into the development branch.  I do have
>>>>>> one favor to ask if you have the time.  Patch 6 does not apply to the
>>>>>> 5.0 branch which also suffers from the crash bug.  If you could merge it
>>>>>> into the 5.0 branch and send me a separate patch I would appreciate it.
>>>>>> If you don't have the time please let me know because this needs to be
>>>>>> fixed for the 5.0.1 release.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Wayne
>>>>>>
>>>>>> On 09/28/2018 07:53 AM, John Beard wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Here is a patch set for adding a filter control to the hotkey editor
>>>>>>> dialog. Preview video: https://sendvid.com/je0cyg87
>>>>>>>
>>>>>>> Most of the work in the first commit is separating out the hotkey data
>>>>>>> from the UI widget code.
>>>>>>>
>>>>>>> This also fixes a couple of other bugs (one crashing, and one able to
>>>>>>> get the HK configs into a mess with conflicts) in that dialog, and
>>>>>>> adds some mock objects to the common QA tests, which will make it
>>>>>>> easier to get more of libcommon under test.
>>>>>>>
>>>>>>> A 5.0 series fix for the crashing bug will follow.
>>>>>>>
>>>>>>> This is also useful as groundwork for
>>>>>>> https://bugs.launchpad.net/kicad/+bug/1778374 (a 5.1 milestone), but
>>>>>>> that will need a further decision to choose between:
>>>>>>>
>>>>>>> * Use a read-only variant of the hotkey editor TreeListView for the
>>>>>>> hotkey list dialog (needs more code: a new dialog and adding a
>>>>>>> read-only mode to the current widget), or
>>>>>>> * Remove the hotkey list dialog altogether and bind the "show hotkey
>>>>>>> list" command to simply opening the prefs dialog to the hotkey panel
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp