kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@...>]

2009/6/2 Wayne Stambaugh <stambaughw@...>:
> Brian Sidebotham wrote:
>> 2009/6/2 Wayne Stambaugh <stambaughw@...>:
>>> Dick Hollenbeck wrote:
>>>> Ing. Gabriele Oberhammer wrote:
>>>>> Thanks for all the replays :-)
>>> << snipped >>
>>>
>>>> I'm glad to see you and others are still in brain storm mode.
>>> << snipped >>
>>>
>>>> Dick
>>> While we are still in the brain storm mode, I had a few rumblings in my
>>> head so I thought I would weight in on this discussion.  I would liketo
>>> see a two pronged approach.  A full featured implementation such as
>>> Dick's suggestion of a modeless dialog is great for those users that
>>> have more than one monitor.  For those of us poor souls that have to
>>> work on single monitor systems, a solution that doesn't use any more
>>> screen real estate than necessary is preferable.  Some CAD programs use
>>> a combobox in the main tool bar to allow changing the current working
>>> layer, turning layers on and off, and other minor layer settings.  To
>>> access the full layer editing dialog, you double-click on the layer you
>>> wish to edit and have the full layer editing dialog open.  The only real
>>>  issue I see with this solution besides the extra coding is that using a
>>> modeless dialog would require keeping both the combobox and dialog
>>> settings synchronized.
>>>
>>> Wayne
>>
>> Looking away from PCB CAD for a moment, some CAD systems have a
>> collapsible (saving screen real estate if necessary) and dockable
>> (Useful for multiple monitor setups) panels. I see this as not just a
>> way forward for the layer visibility selection, but also expanding to
>> other object properties if the panel has multiple dockable elements or
>> is paged.
>
> I like dockable panels as long as you can quickly hide and unhide them.
>  However, dockable panels seem to quickly become excessive.  Many of
> the modern IDEs have taken this paradigm to the extreme.  Visual Studio
> and Eclipse come quickly to mind.  Pretty soon there is no room left on
> your screen for the object you are actually editing.

Hi Wayne,

Yes I totally agree that implementations can go bad. Qt Designer is a
case in point for me. The dockable properties dialogs are almost
useless at displaying the information I need could do with access to.
Visual Studio is of a similar design. Even on a 1920x1200 monitor that
I am on right now QT Designer dockables do not work well. But there
are not so many properties with PCB objects and there are
implementations that make good use of this. The collapsible ones are
best, one click of a button hides or displays the dialog.

>> CorelDraw! springs to mind as a piece of CAD where objects are
>> selected and can be quickly edited. In this vein, multiple objects can
>> be selected and common properties can be edited at the same time. It's
>> something that KiCad is missing support for, and also a dream in terms
>> of UI but this simple patch offered by Gabriele could open the door to
>> this sort of functionality if it is implemented with the foresight to
>> extend beyond the layer visibility.
>
> Multiple object common property editing would be very handy.  The last
> version of Orcad I used (9.1) had this capability but I didn't care much
> for the way it was implemented.  Although, I'm not sure I could come up
> with a better implementation myself.  I haven't used CorelDraw so their
> implementation may be better.

The CorelDraw! implementation (at least at V12) is well done. You can
quickly display the tool palette, go to the object properties page and
edit anything you want. It is very quick, certainly much quicker than
having a complex main menu or context menu containing links to all
possible editables.

>> I think the only downside to this is that you may have one extra click
>> to get to the layer visibility page of a dockable panel as opposed to
>> a specific combo box in the tool bar. Not unreasonable for extra
>> future functionality.
>
> The other downside is dockable panel support requires wxAUI as far as I
> can tell.  I've looked a the wxAUI sample and it appears that it would
> take a great deal of effort to convert the Kicad UI over to it.  I don't
> know how well wxAUI is supported on all platforms so that may be an
> issue as well.

This is the major part of the implementation, and the work involved
might rule this way forward out later on. There are several cross
platform implementations of wxAui GUI's. Codeblocks is a coding GUI I
use quite a lot and is distributed on Windows, Linux, and Mac. It
makes use of the wxAui framework. wxAui was included at the start of
wxWidgets 2.8.x so is now pretty well established although I don't
believe it is actually marked as V1.0 yet!

> Wayne
>
>>
>> Best Regards,
>>
>> Brian.