Re: [Kicad-developers] GitLab migration
Agreed. Another equivalent common term in the industry is WAI or "works as intended". Andrew On Sat, Oct 12, 2019 at 6:10 PM Strontium wrote: > My 2c > > "As Designed" should be the only answer. Bug is subjective. If the > user thinks the designed behaviour is > broken then they will always think of it as a bug. Invalid is worse, > because yes it tells the user they are an idiot. > > Even if the program is working "As Designed" it does not mean its > fantastic, or couldn't be improved, also saying "as designed" does not > make any comment about the person logging the report (The other two > do). If someone spends a reasonable amount of time filling out a bug > report, then there may be work needed to an area even if it is working > "As Designed". Marking it "As Designed" would allow the conversation to > continue about what specifically regarding the "As Designed" behaviour > is problematic. "Invalid" and "Not a Bug" cut off continued dialogue > and look dogmatic/arrogant. > > Steven > > On 12/10/19 9:36 pm, Jeff Young wrote: > > The main thing I didn’t like in the Launchpad workflow was the “Invalid” > tag. After one of our users spends a lot of time (or even a little) > logging a bug, it often gets their back up if you mark it “invalid”. > > > > (In the past I’ve used systems that labelled this either “Not a Bug” or > “As Designed”. The later is probably the least triggering.) > > > > Cheers, > > Jeff. > > > > > >> On 12 Oct 2019, at 10:57, Nick Østergaard wrote: > >> > >> The document is still open for comments on > >> > https://docs.google.com/document/d/1pRcqXIXSn1_Ep2mYtSnoJWFahi9fMx4UJ8UEwFFwLkQ/edit?usp=sharing > >> > >> On Thu, 10 Oct 2019 at 11:30, Ian McInerney > wrote: > >>> On a similar note, the issue workflow will need to be modified if the > GitLab tracker is used. Unfortunately, GitLab doesn't seem to have the same > functionality as the Launchpad tracker with respect to issue status and > severity. This might be a good time to finalize the earlier work that Nick > had started to formalize the issue process and the bug tracker workflow > before we transition to the GitLab tracker. That way we can define how we > want to do this from the outset. This will probably require some trial and > error and discussions to fully work it out. > >>> > >>> -Ian > >>> > >>> On Thu, Oct 10, 2019 at 8:51 AM Maciej Suminski < > maciej.sumin...@cern.ch> wrote: > On 10/10/19 2:30 AM, Andrew Lutsenko wrote: > > > In terms of issues migration I think moving open issues via script > and > > locking down launchpad tracker is the best option. Even if migrated > > issues and comments on them will be owned by some service > account/bot. > > It should be doable to include enough information there so that it's > > clear who originally posted it and the context is not lost. > I agree, I am not sure if there is any added value in having correct > authors assigned to issues/comments, compared to displaying the > information in the contents field. Since I have spent some time > scripting both Launchpad and Gitlab, let me see how it can be done. > > Cheers, > Orson > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > >>> ___ > >>> Mailing list: https://launchpad.net/~kicad-developers > >>> Post to : kicad-developers@lists.launchpad.net > >>> Unsubscribe : https://launchpad.net/~kicad-developers > >>> More help : https://help.launchpad.net/ListHelp > >> ___ > >> Mailing list: https://launchpad.net/~kicad-developers > >> Post to : kicad-developers@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~kicad-developers > >> More help : https://help.launchpad.net/ListHelp > > > > ___ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : kicad-developers@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GitLab migration
My 2c "As Designed" should be the only answer. Bug is subjective. If the user thinks the designed behaviour is broken then they will always think of it as a bug. Invalid is worse, because yes it tells the user they are an idiot. Even if the program is working "As Designed" it does not mean its fantastic, or couldn't be improved, also saying "as designed" does not make any comment about the person logging the report (The other two do). If someone spends a reasonable amount of time filling out a bug report, then there may be work needed to an area even if it is working "As Designed". Marking it "As Designed" would allow the conversation to continue about what specifically regarding the "As Designed" behaviour is problematic. "Invalid" and "Not a Bug" cut off continued dialogue and look dogmatic/arrogant. Steven On 12/10/19 9:36 pm, Jeff Young wrote: The main thing I didn’t like in the Launchpad workflow was the “Invalid” tag. After one of our users spends a lot of time (or even a little) logging a bug, it often gets their back up if you mark it “invalid”. (In the past I’ve used systems that labelled this either “Not a Bug” or “As Designed”. The later is probably the least triggering.) Cheers, Jeff. On 12 Oct 2019, at 10:57, Nick Østergaard wrote: The document is still open for comments on https://docs.google.com/document/d/1pRcqXIXSn1_Ep2mYtSnoJWFahi9fMx4UJ8UEwFFwLkQ/edit?usp=sharing On Thu, 10 Oct 2019 at 11:30, Ian McInerney wrote: On a similar note, the issue workflow will need to be modified if the GitLab tracker is used. Unfortunately, GitLab doesn't seem to have the same functionality as the Launchpad tracker with respect to issue status and severity. This might be a good time to finalize the earlier work that Nick had started to formalize the issue process and the bug tracker workflow before we transition to the GitLab tracker. That way we can define how we want to do this from the outset. This will probably require some trial and error and discussions to fully work it out. -Ian On Thu, Oct 10, 2019 at 8:51 AM Maciej Suminski wrote: On 10/10/19 2:30 AM, Andrew Lutsenko wrote: In terms of issues migration I think moving open issues via script and locking down launchpad tracker is the best option. Even if migrated issues and comments on them will be owned by some service account/bot. It should be doable to include enough information there so that it's clear who originally posted it and the context is not lost. I agree, I am not sure if there is any added value in having correct authors assigned to issues/comments, compared to displaying the information in the contents field. Since I have spent some time scripting both Launchpad and Gitlab, let me see how it can be done. Cheers, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] wxUpdateUIEvent abuse
Hi Sylwester, Please keep in mind that wxUpdateUIEvents are generated in response to wxCommandEvents which are typically generated by menu, toolbars, and buttons. Other control events will not fire a wxUpdateUIEvent so using them will have no affect for things like checking a wxCheckBox control or selecting an item in a list control. Of course you could manually send a wxCommandEvent to trigger an wxUpdateUIEvent but this is overkill. If you have a control in a dialog that needs to be disabled, do that in the event handler for the control that determines the state of the other control. In your case, you should just call the function that sets the dialog control states from TransferDataToWindow() directly. I cannot stress enough that you understand how event handling works in wxWidgets. If you have to, dig around in the wxWidgets code. This is what I do when the wxWidgets documentation is lacking. Cheers, Wayne On 10/12/19 5:08 AM, Sylwester Kocjan wrote: > Hi Wayne, > > In the light of below finding, is this review comment still valid? > It belonged to my changes for initial conditions[1]. > > Dnia 27 czerwca 2019 21:04 Wayne Stambaugh > napisał(a): >> Get rid of DIALOG_SIM_SETTINGS::disableCtrlOnCheckboxEvent() and use the >> appropriate wxUpdateUIEvent[1] handler to enable and/or disable any >> controls. Manually doing this will almost certainly lead to broken >> control states. We have done this poorly so many times in the past that >> I am not allowing it in new code. > > As I understand wxUpdateUIEvent is useful for scenarios like this or > similar: >> 1. Application wants to connect to target hardware. >> 2. State of hardware changes - application updates status on GUI. >> 3. Connectivity is lost - some functions on GUI become grayed. > Thanks to wxUpdateUIEvent GUI update can be processed separate from > application logic. > > When we want to change state of controls depending on other controls > we can use simply event handlers. The same logic can be applied to the > multiple events or multiple controls, like in dialog_spice_model_base.fbp, > field m_modelName, events OnCombobox and OnText. > > Best regards, > Sylwester > > [1]: > https://github.com/skocjan/kicad_initialconditions/tree/Sim_InitialConditions_SK > > > On 18/09/2019 22:01, Wayne Stambaugh wrote: >> Given the recent rash of odd dialog UI behavior, I did some digging and >> it appears that we might be abusing wxUpdateUIEvent[1]. This event >> handler was specifically designed for updating controls that respond to >> command events such as menus, toolbars, buttons, etc. Using them for >> anything else is risky. I would avoid using UI control object calls >> inside a wxUpdaetUIEvent handler other than those provided by the >> wxUpdateUIEvent object itself. I'm pretty sure making changes to a >> control inside a wxUpdateUIEvent handler can spawn an event loop where >> the changes made to the control generate a new wxUpdateUIEvent. A >> better solution might be to use wxIdleEvent to do any dialog control >> post processing as a one shot. >> >> Cheers, >> >> Wayne >> >> [1]: >> https://docs.wxwidgets.org/3.0/classwx_update_u_i_event.html#aa25df58e7047f819f5dd0520eb2cc8ea >> >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GitLab migration
The main thing I didn’t like in the Launchpad workflow was the “Invalid” tag. After one of our users spends a lot of time (or even a little) logging a bug, it often gets their back up if you mark it “invalid”. (In the past I’ve used systems that labelled this either “Not a Bug” or “As Designed”. The later is probably the least triggering.) Cheers, Jeff. > On 12 Oct 2019, at 10:57, Nick Østergaard wrote: > > The document is still open for comments on > https://docs.google.com/document/d/1pRcqXIXSn1_Ep2mYtSnoJWFahi9fMx4UJ8UEwFFwLkQ/edit?usp=sharing > > On Thu, 10 Oct 2019 at 11:30, Ian McInerney wrote: >> >> On a similar note, the issue workflow will need to be modified if the GitLab >> tracker is used. Unfortunately, GitLab doesn't seem to have the same >> functionality as the Launchpad tracker with respect to issue status and >> severity. This might be a good time to finalize the earlier work that Nick >> had started to formalize the issue process and the bug tracker workflow >> before we transition to the GitLab tracker. That way we can define how we >> want to do this from the outset. This will probably require some trial and >> error and discussions to fully work it out. >> >> -Ian >> >> On Thu, Oct 10, 2019 at 8:51 AM Maciej Suminski >> wrote: >>> >>> On 10/10/19 2:30 AM, Andrew Lutsenko wrote: >>> In terms of issues migration I think moving open issues via script and locking down launchpad tracker is the best option. Even if migrated issues and comments on them will be owned by some service account/bot. It should be doable to include enough information there so that it's clear who originally posted it and the context is not lost. >>> >>> I agree, I am not sure if there is any added value in having correct >>> authors assigned to issues/comments, compared to displaying the >>> information in the contents field. Since I have spent some time >>> scripting both Launchpad and Gitlab, let me see how it can be done. >>> >>> Cheers, >>> Orson >>> >>> ___ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GitLab migration
The document is still open for comments on https://docs.google.com/document/d/1pRcqXIXSn1_Ep2mYtSnoJWFahi9fMx4UJ8UEwFFwLkQ/edit?usp=sharing On Thu, 10 Oct 2019 at 11:30, Ian McInerney wrote: > > On a similar note, the issue workflow will need to be modified if the GitLab > tracker is used. Unfortunately, GitLab doesn't seem to have the same > functionality as the Launchpad tracker with respect to issue status and > severity. This might be a good time to finalize the earlier work that Nick > had started to formalize the issue process and the bug tracker workflow > before we transition to the GitLab tracker. That way we can define how we > want to do this from the outset. This will probably require some trial and > error and discussions to fully work it out. > > -Ian > > On Thu, Oct 10, 2019 at 8:51 AM Maciej Suminski > wrote: >> >> On 10/10/19 2:30 AM, Andrew Lutsenko wrote: >> >> > In terms of issues migration I think moving open issues via script and >> > locking down launchpad tracker is the best option. Even if migrated >> > issues and comments on them will be owned by some service account/bot. >> > It should be doable to include enough information there so that it's >> > clear who originally posted it and the context is not lost. >> >> I agree, I am not sure if there is any added value in having correct >> authors assigned to issues/comments, compared to displaying the >> information in the contents field. Since I have spent some time >> scripting both Launchpad and Gitlab, let me see how it can be done. >> >> Cheers, >> Orson >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] wxUpdateUIEvent abuse
Hi Wayne, In the light of below finding, is this review comment still valid? It belonged to my changes for initial conditions[1]. Dnia 27 czerwca 2019 21:04 Wayne Stambaugh napisał(a): > Get rid of DIALOG_SIM_SETTINGS::disableCtrlOnCheckboxEvent() and use the > appropriate wxUpdateUIEvent[1] handler to enable and/or disable any > controls. Manually doing this will almost certainly lead to broken > control states. We have done this poorly so many times in the past that > I am not allowing it in new code. As I understand wxUpdateUIEvent is useful for scenarios like this or similar: > 1. Application wants to connect to target hardware. > 2. State of hardware changes - application updates status on GUI. > 3. Connectivity is lost - some functions on GUI become grayed. Thanks to wxUpdateUIEvent GUI update can be processed separate from application logic. When we want to change state of controls depending on other controls we can use simply event handlers. The same logic can be applied to the multiple events or multiple controls, like in dialog_spice_model_base.fbp, field m_modelName, events OnCombobox and OnText. Best regards, Sylwester [1]: https://github.com/skocjan/kicad_initialconditions/tree/Sim_InitialConditions_SK On 18/09/2019 22:01, Wayne Stambaugh wrote: Given the recent rash of odd dialog UI behavior, I did some digging and it appears that we might be abusing wxUpdateUIEvent[1]. This event handler was specifically designed for updating controls that respond to command events such as menus, toolbars, buttons, etc. Using them for anything else is risky. I would avoid using UI control object calls inside a wxUpdaetUIEvent handler other than those provided by the wxUpdateUIEvent object itself. I'm pretty sure making changes to a control inside a wxUpdateUIEvent handler can spawn an event loop where the changes made to the control generate a new wxUpdateUIEvent. A better solution might be to use wxIdleEvent to do any dialog control post processing as a one shot. Cheers, Wayne [1]: https://docs.wxwidgets.org/3.0/classwx_update_u_i_event.html#aa25df58e7047f819f5dd0520eb2cc8ea ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
