When having the Edit Symbol Fields window open, why can’t I click around on my schematic!? I think this window should float without limiting me from using Eschema while it’s open. 
1 Like
There are quite many modal windows in KiCad. I don’t like them either. I hate especially the fact that if I leave a dialog open in one part of KiCad it locks all other parts without even telling what’s going on - I have to remember and find the dialog manually. That’s outright evil design.
Sometimes it may be only because nobody has cared enough to make it otherwise. However, there may be good practical reasons for it even though it limits usability.
Many windows contain data which can be changed in many ways and could affect other things. It might just get too complicated if using multiple windows simultaenously would be allowed. In this case the contents of the Edit Symbol Fields window and the schematic should be synchronized in both ways, and there are several dialogs which can change e.g. footprint associations. They all should be synchronized, and what then? It would probably get complicated very soon and become a can of worms. What if you would open dialogs in eeschema and in pcbnew which would both affect each other? Who is the developer who could take care of all possible dialogs and combinations and situations which can happen?
A good compromise could be to allow read-only viewing of schematic and layout even when a dialog is open. But even that wouldn’t necessarily be easy to implement.
1 Like
Having multiple ways of changing properties open simultaneously can easily become a nightmare to ptoram, and can also easily lead to confusion for users.
On the other hand. It would seem to be simple to add a lock on edits as long as one editing method is active.
Just being able to pan and zoom through the schematic while the “Symbols Fields” spreadsheet is open would be nice to have. If you click on a component in the Symbol Fields window, the schematic pans and highlights it, which I like. And also having it work the other way around: Click on a schematic symbol, and have it highlight in the Symbol Fields window.
Another simple issue with a lot of these popup windows is that they do not have maximise buttons. Just maximising such windows is faster and more convenient then first moving the window to the bottom left, and then grabbing a corner to stretch it to see more. Especially on multi-monitor setups. (Which every serious CAD user should have).
I assume that for a lot of situations this is simply overlooked. While implementing (for example) the Fields edit window, it is very simple to start with “just lock Eeschema for now”, and then in a later stage focus moves to elsewhere.
It also looks like (my own thoughts, I’m just a user) the “Edit Symbol Fields” window in itself is in an incomplete and transitional state. I envision that in a future KiCad version the “Edit Symbol Fields” may get combined with CvPcb, or at least that the search and filter functions of CvPcb get integrated into the Footprint library browser.
IMHO…
The GUI framework does that job usually… but with the drawing area probably not being tied into that system it would require some effort to implement a link between the GUI framework and the drawing area framework that KiCAD uses…
No, it doesn’t. Or we are talking about two different things. GUI doesn’t take care of data flow unless it’s carefully coded by the application developer. It might be possible to use some kind of model/view framework which would trigger updates automatically but that would be muuuuch more work anyways and in the end achieve little in most situations.
I’m not talking about one specific dialog but the whole UI/workflow paradigm. It would be beneficial to identify places where simultaneous editing and synchronizing would be really wanted and consider implementing it there. It’s still not clear what the OP wants to do - actually edit things in many places at the same time, or just view the shcematic to see what needs to be edited in a dialog. And the stupid lock-all-windows-without-giving-chance-to-know-what’s-going-on bug should really be fixed, but that’s another issue.
1 Like
In an older version of Kicad I had one open and accidentally minimized it. It didn’t show on the lower tool bar separately. Now everything is locked and I can’t do anything. I think I had to kill the process and then reopen.
I didn’t do much GUI programming yet, but the way I understood it that the more advanced ones will update any appearance of stuff if the underlying data changes.
This is not hard to track if the frameowork is properly designed and built.
Problems start if you want to change the Value of a Resistor in the Window GUI (Editor, framework 1) and the value shall change in the drawing area (Schematic, Layout, framework 2) as well, because they are not really linked anywhere in a way that would make this possible, unless a ton of time has been invested.
A framework which is able to do that, doesn’t need modal windows anymore.
Modal windows are a sign, that the change of data is a sort of snapshot. Then things are being changed and applied and stuff is handed back to the other framework.
Doing this on the fly requires much more grunt work on the lower levels, to not require snapshots.
My I propose one other possible solution? Maybe don’t allow any other popups. Just one popup allowed, but still allow the user to click and move around the schematic. Just a thought. I do know this is open source and nobody is responsible to code my feature requests. 
KiCad’s UI framework does not do automatic data binding. We must manually write code to transfer data between dialogs and the main window. People in this thread are correct in guessing that the code gets much more complicated if more than one window can change the underlying data at the same time.
I suggest making a feature request on the Launchpad issue tracker with any specific requests along these lines. A “read only” schematic view is not currently possible but is one potential way to address this.
2 Likes
As described above by others… sometimes those modal windows get lost and one one doesn’t know where they are to be able to close them.
Can you think of a sort of tracker of those modal windows that at least would give one the ability to bring them upfront if they hinder progress otherwise?
I have been there as well and also had to kill KiCAD as the dialog was buried and not ‘focusable’.
Yes that should be fixable as a separate issue. I’m not sure if it’s already in the bug tracker.
If no-one has done it already, I can do some search in the bug database and report the lost dialog issue.
5 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.