Hello Peter!
Thanks!
By the way, I have started reading in detail. I spotted one typo in new file format. Bellow should be replaced by below.
R
Hello Peter!
Thanks!
By the way, I have started reading in detail. I spotted one typo in new file format. Bellow should be replaced by below.
R
This is something that I find difficult to find information about.
Is there any information you can provide to help me fill in this stub in the article?
heh, I still have to write the documentation for it.
Until then, this youtube video is probably a good overview: https://www.youtube.com/watch?v=z6x0xiKgDIc
I think it’s still mostly accurate
Also, wow, it’s been 3 years since I made that video… time flies
Finally, in KiCad 5 Eeschema context menu, the last function is “Close”. I never understood the purpose of this function, since to close the context menu you simply click outside the menu. In KiCad 6, the “Close” function is removed.
This interesting detail actually shows the big difference in the editing model or paradigm between v5 and 6, and was one of the major points in v6 development. I think many people have learned to use v5 eeschema editor, have noticed it’s somehow “weird” or different from other apps but couldn’t tell exactly why. Some people have expressed strong disliking.
It’s because in v5 you can’t actually select anything in the normal meaning of the word “select” in software world. You always act instantly on an item or a group of items.
I hope the next video demonstrates it:
Clicking on an item shows some information about it in the message bar below which may fool you to think that you have selected it. So does the Clarify Selection menu. But what happens after you have clarified the left mouse button click? You can’t open the right button menu for that item which you just “selected”. Why?
Because you didn’t select it. You just acted upon it. You told KiCad to show information about it in the message bar. It’s not kept selected, and when you want to do something else with it you have to clarify again because all clicks do some action immediately.
Doing a drag “selection” works similarly: once dragging is done, the items are acted upon immediately. If you move the mouse they move along. Now it’s possible to use the context menu on those selected items. This is the only situation where they can be said to stay in selected state, and even then they are in the midst of a “move” operation.
Now you can also see why there are two ways to dismiss the context menu. The other discards the selection. The other one keeps it for further actions (moving etc.) or rather goes back to the move operation which was interrupted by the context menu.
This was good in 90’s, but since then every other program evolved and “select first, then choose the action” became the normal paradigm. Even pcbnew has used that normal editing system, so KiCad has been internally inconsistent.
In eeschema v6 the editing paradigm has been changed from the old one to the universally used normal one.
Now it’s easy to understand why this is the most important change in eeschema besides the file format change. Many small new features depend on this fundamental change.
In your context menu screenshots you don’t have icons. Even if that’s on purpose in your GTK setup (or in desktop environment setup) they look cooler with icons for demonstration purposes.
I did not know about that. Cool!
Same here.
I have turned icons in menu’s of for years and never regarded them as very useful. After I re-installed Linux on a new (to me) PC I decided to leave the icons in the menu’s because I post lot’s of screenshots here and those screenshots look a bit fancier.
It is also one less thing to tweak every time you re-install the OS.
For me (Linux Mint with Mate I think) I can set it in:
[ Main Menu] / Desktop Settings / Interface
Wow, that helps a lot, thank you!
Interesting. I’m using Ubuntu 20.04 LTS. I have not noticed a configuration to turn on the context menu items. I’ll give it another try.
It can set the icons off if they are set on in the desktop setup. But it can’t set them on if they are off in the desktop setup.
EDIT: I use Kubuntu and assumed that Ubuntu could do the same in the desktop settings.
Ubuntu (actually Gnome 3 in general) forces icons in menus off even if the KiCad option is on.
You can override this but they are trying to discourage this feature: https://unix.stackexchange.com/questions/150236/enabling-menu-icons-in-gnome3
I hate what the Gnome project is doing to user interfaces. Essentially they’ve decided they know best what everyone should have, and are removing all options they don’t see as valuable.
For example, I’ve been using Focus follows Mouse for nearly 30 years. Gnome 3 has removed the configuration interfaces for this, and are trying to eliminate support for it entirely.
It’s like Apple’s “We Know Best” attitude. There’s a reason I use the KDE desktop instead.
I agree in general, but I hate menu icons personally so I don’t know how to feel about it
I have an overwhelming impression that time is galloping. The older you get, the faster.
Perhaps the fact that the universe is expanding faster and faster is because we don’t know something about the fourth dimension
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.