Splitting from the icons thread
Thanks, I see that path is displaying in the status bar now. Also the problem with minimum size of the window seems fixed. However the status bar still displays the “Local path: monitoring folder changes” message which does not really add much (if anything), and it takes up so much space that not much of the path is visible.
Version: (5.99.0-9102-g55db1aa5f5), release build
I agree about the status bar. Maybe we should start a new thread “Discussion about the new project view layout” because this is offtopic. But anyway there could be several details which could still be enhanced without making major changes. Like making the vertical tool list scrollable.
Definitely this topic asks for splitting.
My dream would be to use the project manager’s space to display preview of the selected file. This probably requires some huge internal reworking and might be the target for some future Kicad version.
But how about a function for the EESCHEMA/PCBNEW: “Use current view as project preview” that would just make a static screenshot and save it as certain filename that would be displayed in the Project manager window?
This way, after opening a project we could see the snaphshot (made by us) and quickly see current project’s scope/state in the way we see it important.
On Windows there’s even a way to have an image in a folder which is used as preview image in certain file explorer views.
There has been developer discussion about having some kind of tabbed interface or one window interface. If that’s implemented in some form, it must go hand in hand with the project view. There are enough examples of applications which use a concept of project to make some research and redesign the possible workflows of KiCad totally. There must of course still be the possibility for separate windows for parallel schematic/pcb viewing and multi monitor use.
Unfortunately, the point of this text is to inform users why or why not the file view is not being automatically refreshed. Due to bugs in samba, network folder monitoring is turned off. If we don’t indicate this intentional to the user, people will just end up reporting it as a issue. I wish I could detect it’s samba and make it a samba specific workaround instead of punishing Windows Server users.
The text isn’t the problem but that it always takes exactly half of the horizontal space from the window width. The file path is usually wider, so seeing it requires dragging the window considerably wider:
I would argue the statusbar altogether is a terrible spot for the filepath. It will have different max string lengths at different resolutions with no ability to word wrap or scroll.
That also reminds me since we msvc builds, I can enable modern windows long paths (>256 chars)
We could do the “modern” thing and figure out if the string is too long, then insert ellipses in the middle of it, preserving as much of the start and end of the path as possible. That might be more work than is worth it, though…
Readonly textbox that spans “both columns” at the top.
Could “Local path: monitoring folder changes” be replaced with an icon with these two states and an explanatory tooltip?
Or grey out the text for the folder path when it is not being updated?
While this may be good in some situations, ellipses isn’t needed here because the part replaced by ellipsis … is “5.99”, so
- it doesn’t make it much shorter
- there was no need to shorten it to begin with because there’s much space left
- I lost the most important part of the path which tells it apart from “5.1” or other folders.
Even though it’s possible to have different folder name and project name, most often the last folder of the path is the same than the project name. It would be better to replace that with ellipsis if it has to be guessed.
Also the .kicad_pro ending is mostly unnecessary. Actually even the file name may be unnecessary because it can be seen in the Project Files view above.
But the most important thing would be to show the whole path if there’s enough space. Ellipsis should be used only if the string doesn’t fit. I don’t know what takes the space because there’s nothing in the empty space. If I widen the window the path is shown completely.
We can’t win here
The empty space is used for all other status messages: the network path thing (Windows only), logs when you archive projects etc.
I fail to see why it is useful to put the project name in three different locations in the project window:
I also find the minimum width of the browser window and the other pane far to wide. My preference is to be able to make it as narrow as I want it to be. Even if the whole window is so narrow that only the column of icons is visible.
I do see some merit in the whole path name being visible (And selectable, copy-able, etc). It does have a tooltip with the full pathname, but it’s not selectable.
Another issue is the confirmation for if KiCad is already running:
I see some use for it, but most often it’s just unnecessary mouse movements and clicks.
Having this info in the status bar (Or in an “info bar”) would still give feedback, but without the extra clicks.
Now apparently the path is abbreviated because half the width of the screen is reserved for something else. I’d think making the status bar on the bottom two lines high is a better choice.
There is also one less icon on the left side (Top on KiCad V5.1). The “New Project from Template …” icon is missing. It is also an empty spot in the menu:
For those who do not know:
An “Info bar” is the yellow text (usually on top?)
Unfortunately this can’t be fixed until v7, it’s a todo item
We aren’t trying to give all menu items a icon. In fact it’s a mistake that KiCad has ever attempted to do so. No other software does this and its a giant amount of work to maintain
The explanatory text in italics to the right of the icons is really overdoing it, is repetitive and takes up too much space. If anything this text should go into a popup item, not clutter up the everyday view of the program. (It is text that is really not helpful to anyone but a first time user the very first time he/she encounters the program.)
I agree with @eelik that it is best to truncate the end of the path rather than the current ellipsis that takes out the very information that is important for me to see.
Also I like to repeat my suggestion to gray out the path if it is not updated and use the whole space for the path instead of using half for the the mostly useless ‘Local path: …’ message. It could be supplemented with a small gray network icon that is displayed in front of the the grayed out path whenever the path is on a networked drive and folder not updated. With this icon appearing and disappearing with the grayed out path it would make it clear why it is grayed out.
It’s possible that in future versions, this screen is mostly used as a getting-started screen rather than the “main” KiCad window
Besides, it used to be a big empty box. The explanatory text takes up space that would not go to anything else, so why not help out new users? You can always resize the window to hide it if you want.
I can’t find anything in the issue tracker or the roadmap about future plans for the logging window. I have always thought that it was a big patch of nothing very useful. I am sure it could be used more effectively as a sort of project dashboard - and could reflect the project status, revision dates, basic board parameters, ERC/DRC errors etc.
It would also be very useful to have the project level available for Python scripting. For instance, I have a board version control diff program - it would be great to be able to launch this sort of function from within the project manager.
Happy to register something on the tracker for discussion unless there is already a plan (and avoid more bikeshedding).
Sometimes ideas about the future are just tossed around in casual conversation long before they are put into GitLab issues. They are just ideas, after all.
There are reasons to consider just integrating the project management stuff into Eeschema and Pcbnew, versus expanding the capabilities of the project manager window. Nothing is decided here, more planning needs to be done.
The logging window was removed because today it is not doing anything useful. If new features are desired later, we can determine how to implement them (and where) without any kind of pre-conception that there is this big text box and thus it should be used.