← Back to team overview

kicad-developers team mailing list archive

Re: Layers visibility


Brian Sidebotham wrote:
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 >>


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 like to
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.


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!

It has been some time since I coded it, but I recall making the DRC dialog modeless without using wxAui. A non-modal or modeless dialog is pretty easy to do. I am not a big fan of dockable windows, as this costs real-estate on semi-permanent basis. With a modeless dialog, you can keep it up if you want, and then dismiss it if you don't think you will need it in the near future.

Please play with the PCBNEW DRC dialog and see how that works for you. The toolbar button pulls it up even if it is simply open but "minimized". However I recall seeing different behavior of this modeless support on Windows vs. Linux, circa wxWidgets 2.8.4. This was one of the last times that I had booted Windows. It is no longer possible on this machine.

So one could reach different conclusions on different platforms, because you could see different behavior, at least back at 2.8.4.

If this is a simple change and worth pursuing, we might simply take some time and write in words how we want a modeless dialog window to behave, the various states it can be in. Open and minimized, open and visible, open and on top, etc, and what a toolbar icon would do to change these states. The modeless dialog could also use tabs.