← Back to team overview

kicad-developers team mailing list archive

Re: PCBNew auxiliary toolbar behavior proposal.

 

On 03/08/2011 10:17 AM, Wayne Stambaugh wrote:
> On 3/7/2011 5:53 PM, Dick Hollenbeck wrote:
>> On 03/07/2011 02:56 PM, Wayne Stambaugh wrote:
>>> I ran into some unexpected behavior of the PCBNew auxiliary toolbar while
>>> converting the control update handling over to wxUpdateUIEvent.  When selecting
>>> a trace or via, the net class edit box (which is read only), clearance edit box
>>> (also read only), trace width choice box, and via size choice box values where
>>> changed to the selected object's net class value.  This is a departure from
>>> normal object information display which is to display all of the object
>>> information in the message panel at the bottom of the screen.  Since I broke
>>> the old behavior, I want some input before I make any more changes.
>>>
>>> I propose removing the net class name and clearance read only edit boxes
>>
>> Intuitively, "read only edit boxes" gives a hint of an oxymoronic problem
>> doesn't it?
> I doubt I could have phrased it any better.
>
>>
>> One could wish that
>>
>> 1) toolbars offer choices, and
>> 2) a message panel shows things, including choices made.
>>
>>
>> One is a chooser, the other an indicator.
> Except for this one case, this is the behavior for the schematic, component
> library, pcb, and module editors.
>
>> But in the real world however, there are situations where you have to give
>> indication and control/manipulation, both, from the same metaphor.
>>
>> So I don't have a strong opinion, on this, until I get back into using the
>> software again, at which point my opinion might get stronger.
>>
>> It is unfortunate that "ease of programming" is having such a large role in
>> this decision, rather than ease of use.   Ideally ease of use rules, in any
>> case, and ease of programming happens because the code is designed to
>> facilitate ease of use.
> The "ease of programming" issue should be resolved by changing over to
> wxUpdateUIEvent for control state handling.  The complexity of the old set
> toolbar design was a large part of the problem.  The fact that I changed the
> auxiliary control state behavior brought this issue into the light.  Hopefully,
> the current design will make implementing ease of use features more manageable.
>
>>
>>>  and
>>> display all of the net class information when a trace or via has a net class in
>>> the message panel.  This behavior is consistent with selecting all other
>>> objects in PCBNew and prevents the current selected track and via size from
>>> being changed when the user (at least this user) doesn't expect them to be
>>> changed.  I have already discussed this with JP and if no one else objects, I
>>> will make it so.
>>>
>>> That being said, what I really would like to see happen is to make the net
>>> class control a choice box with a list of all the defined net classes so that
>>> drawing a net without a assigned net class will be assigned and drawn with the
>>> currently selected net class.  That seems like something that would be useful
>>> instead of having to open the DRC dialog whenever I need to set the net class
>>> for net.  I am not volunteering to do this.  But it's one of those improvements
>>> that I think would be a time saver.
>>
>> It should be easy to use, is what you are saying.    Do we ask the user to
>> specific the netclass for each net up front?  If so, then why is there any
>> choice to be made this late in the game?
> The only choice currently is the selecting the trace width and via size for
> routing nets that do not have an assigned net class.  These questions are the
> same questions I asked myself when making the changes and it is why I asked for
> clarification before I make any more changes.
>
>> If that decision was deferred, is it really enough to give a netclass name
>> drop down combobox, without also showing what it means?
> If the net classes are selectable on the fly, than it makes sense to update the
> track, via, and clearance controls to reflect the currently selected net class.
>
>>
>> Others have pointed out that eventually the netclass editor should be moved
>> into EESCHEMA, so that the layout person's job becomes more mindless.
>>
>> I am always arguing for features which will bring in a corporate user  (the
>> hobbyists are not my intended audience anymore, no offense). 
>>
>> Yes, we all get to chose where and how we would spend our time.  If
>> hobbyists benefit, that is only accidental from my point of view, and I am
>> serious about this.
> No argument here.  I am corporate user so I am going to spend my time
> contributing to Kicad accordingly.
>
>> In the corporate world, the engineer does the schematic, and probably
>> assigns the netclasses up front.  So less support for late binding of
>> netclasses is needed in my opinion to make this audience happy.
> Thanks for input.  I guess I'll have to get to work on the new schematic file
> format to support assigning net class information in the schematic editor.  In
> the interim (assuming no one protests too loudly), I will make my proposed
> changes to PCBNew until there is a better user paradigm for selecting net classes.
>
> Wayne

If you have an idea on how to solve this, and nobody else offers one, then
it looks like your idea is the best, isn't it?

Dick




References