Trying to get into using the software and bumping against a few things.
the behavior of the gui when clicking on the maximize button shouldn’t cause the window to go full screen, it should just maximize. I see that cmd-F doesn’t do anything, and that is what should be causing the window to go full screen, and actually toggle between full screen and not.
in the board editor, is it possible (yet) to choose the color theme so a white background is used instead of a black one?
also in the board editor, I think it would be good to be able to have the option to turn on rulers, top and side, so we can see at a glance the size of the board outline against those rulers. And eventually echo the cursor’s position on those rulers (when they’re turned on).
Also I bumped against a little snag that took me a while to figure out what’s going on:
In the board editor, after having placed a couple of components in the schematic editor, I can see those in the “place devices” side bar, but can’t place them, and I assume this may be because those library components may not be complete and missing the footprint part, because no pull down menu is showing to choose a device and there is no footprint to choose.
It took me a while because I was intuitively attempting to drag the listed components directly to the board, which doesn’t happen, and it also took some time browsing through the skimpy documentation to find the relevant info on how to place parts on a board.
Perhaps something visible could help identify such situation so we would know at a glance what’s going on. Some visual clue, maybe in red or whatever, explaining why there is no menu to pick something from…
The menu at the top should still be there, the window just maximized to take up all the screen space, except perhaps for the area used up by the dock, before it goes away.
And a full screened window would truly take up the whole screen, leaving no space around it at all, not even for the dock, and the menu at the top goes away:
(have to post the next image separately, I was refused that upload because of being a new user)
Quite a difference. And the top menu drops down when pointing the mouse there. It goes away other wise.
On mac, many apps use cmd-F for full screen. The green gumball is only meant to maximize, not do full screen.
Just to clarify the proper behavior for the yellow/minimize and green/maximize gumballs in mac windows, here’s a quick breakdown:
with a window not maximized, taking only a portion of the screen, hitting the yellow/minimize should minimize to dock. clicking on its icon in the dock would bring it right back to the same size/location.
with that same window, open on the screen, hitting the green/maximize should maximize, not go full screen.
full screen is usually obtained with cmd-F, toggled
when a window is maximized, hitting the yellow/minimize should resize the window down to its previous smaller size/position
hitting yellow again would send it to dock
eventually, if a window is already maximized, hitting green once more could send it to full screen, but only if already maximized
Thanks for the explanation. Unfortunately I don’t understand why the window goes to fullscreen, I suspect this is handled by Qt in some way. I searched a bit about this in the Internet but didn’t find useful information.
Do you know if other Qt applications have the same issue?
Not sure about Qt exactly, but although it’s been quite a while, I have seen this wrong behavior before, but can’t recall which app at the moment.
I’m not familiar with mac software devel, so I can’t say much about that unfortunately, I can only relay what’s wrong, or not, about how it works.
Okay so unfortunately I can’t do anything without knowing where the issue is exactly coming from. And on Linux/Windows I can’t reproduce it, there it’s working as expected…
@spkdd I cannot confirm your statement about the proper behavior.
I cannot confirm that. Safari (which I would consider a reference application for Apple UI guidelines) goes to fullscreen when clicking the green button, even if it’s not maximized. Same thing happens for Firefox and Xcode.
In Firefox and Safari, I can vertically maximize by double-clicking the title bar. In Xcode, the window fully maximizes by double-clicking the title bar.
Safari does not go to full screen with cmd-F, neither do Firefox or Xcode. All three of them invoke the search function instead.
When Xcode is maximized, clicking the yellow button minimizes it to the dock.
You’re right, they didn’t make the full screen command with just cmd-F for safari and firefox, they add the crtl key with it. Which is inconsistent.
There are indeed too many inconsistencies among most apps, not all using the exact same conventions.
And that’s a cause for confusion from one app to the next, not using the exact same keys to do the same things.
What’s important is to make it intuitive, consistent and straightforward.
Personally I never could memorize that ctrl-cmd-F sequence as being the toggle for full screen, and a 3 key sequence to hold isn’t as convenient as it “should” be, especially since cmd-F does nothing in those apps, so why add the ctrl key to cmd-F??? Beats me!
The yellow button should minimize to dock, but logically it should only do so if that window is not maximized. So to keep it consistent, a maximized window “should” not go straight to the dock when minimized by the yellow button, it should minimize to a prior minimized state, and then if that yellow button is hit again, then it should be minimized to dock.
That is a logical and “expectable” behavior.
Same with maximize. Whenever I hit that green button when a window isn’t maximized, what I’m looking for is to maximize it, not to go full screen. A separate and specific key sequence is there to handle the full screen action. I get bothered by apps that go full screen from a non-maximized window when hitting the green button every time. I always curse at it and revert back out of full screen, but then I have to manually resize the window to maximize it, because that is what I am actually seeking to do, which the intended button didn’t do.
Some apps do behave properly, but it’s hard to keep track and it’s always a mess to remember all those different behaviors. It has to be standardized and kept simple. The 3 key toggle for full screen isn’t simple, especially if cmd-F isn’t doing anything and should be used instead.
One other thing to note, is that when gone full screen, it can become a pain to switch to an other window within the same program, because no quick and easy navigation button was implemented to do that, so to switch to an other window, one must first exit full screen, then go to that other window, whichever way it’s done, and then use that. Really not what mac users expect from a well behaved app.
The standards were not always respected and varied too much, so it’s become too inconsistent. Why contribute to perpetuate that inconsistency?
Logical behavior is always subective. If Apple programs (Safari, Xcode) don’t conform to those expectations, then they seem to disagree with you. (I also find macOS UI behavior confusing, but I’m not a regular macOS user.)
Do you have a link to some authoritative Apple UI guidelines? Otherwise, I’d consider the LibrePCB behavior “working as intended”.
I found something on the apple developer’s site.
They have revised things over time and although they do try to standardize, when they change things, it causes more confusion.
I see now they call the green button “zoom” instead of “maximize”, and although it’s not 100% clear, they’re mentioning to “expand” OR “go full screen”, for that button. It could be more specific.
I find it cumbersome to have the green button go full screen, where pretty much all menus go away and there is no longer an easy and quick way to navigate to an other window, and switch back and forth as we would need to do so when designing a pcb for example. I would expect to have a quick and easy way to switch back and forth between the schematic, the pcb layout, and the footprint design, etc…
Efficiency and simplicity is a must, keeping it as intuitive as possible.
Try to think of yourself actually using it, doing real work, and how you would want to do things quickly without giving too much thought about the UI itself. It “should” behave transparently and not get in the way as much as possible.
So, 3 keys sequences should be avoided, unless there is no way around them.
And a logical and not cumbersome function is what we need.
Just tried the adobe indesign and photoshop behaviors, and the green button does maximize as I expect it. So that’s one that behaves differently and I personally prefer that way.
I suppose their whole suite behaves the same. They should be consistent.
OK so for me that sounds like the “real” issue is not related to LibrePCB at all, but mainly to Apple/macOS in general. Actually I expected that, since this behavior is not implemented by ourselves, but either by Apple or by Qt developers, I don’t know. If Qt apps behave different than other apps, you should discuss that with Qt developers. Most probably we (LibrePCB developers) can’t do much anyway since we have very limited control over the window behavior.
