Cura 2.6 & 2.7 Machine settings window extends below usable desktop on Mac

[hillct]

The printer Management -> Machine Settings window is taller than the mac desktop can accommodate (at least on my MBP 2012 Retina) and is not scrollable, so the height of the start and end GCode entry textareas pushes the row of buttons below those textareas (whih I presume are cancel and OK/Apply) below the viewable/accessible desktop area. I was able to operate the buttons by TAB'ing through the UI, in order to apply some settings changes, but this is certainly an unacceptable workaround, and presumably easily correctable. It should be noted this was not an issue in Cura 2.5

[Ghostkeeper]

Possibly due to the addition of multi-extrusion settings, but personally I like to blame the recent issues and "fixes" we've had with high DPI stuff.

[hillct]

@Ghostkeeper As you say, it's just a layout issue related to addition of input fields near the top of the window, without reducing the spacing below those fields, and above the OK/Save and Cancel buttons, which results in the buttons being shoved down below the accessible area of the window.

The more important thing worth conveying at this point is the issue still exists in version 2.7, which is arguably predictable but still I think worth noting here.

[Ghostkeeper]

Our project manager just removed this from our planning for being older than 12 weeks.

[hillct]

What process or theory of project management has you removing bug fixes from a project timeline for the simple reason that you haven't delivered a fix in 12 weeks? In most organizations, that would INCREASE the priority for delivering a fix, and if needed, prompt allocation of more resources to the resolution.

It's important for us as a customer to understand, your process here. We've been quite patient in awaiting a resolution to this issue, but is it in fact your decision to disregard this issue and intentionally not provide a resolution? Is this same project management strategy utilized in the ultimaker hardware lifecycle?
Looking over this reply, it sounds trite, but I'm absolutely serious about seeking an answer here. Thanks.

[Appesteijn]

I believe this issue has been fixed in master and will be in the next release (17 oct).

By resources I assume you mean people, but as a developer you should know that just adding twice as much people to a project/team doesn't produce twice as much output. I hope we will get into a state were can fix all incoming issues, but at the moment this is not the case.

I close old issues in our system because they are not on my (and the teams) radar. Nobody is actively looking in to them and because of new priorities, such as other bugs or new features, these items sink deeper and deeper in Jira (our ticket system).
I could just leave them open, but I think the person who created this ticket deserves to know that we are not (now and possibly ever) working on it. This gives that person the possibility to create other options to solve his/her ticket or rant a little that we closed his/her ticket.
By closing tickets it also generate focus for the tickets that are open, so it is more clear for everyone what we are working on.

I know closing these tickets might be blunt and look as if we don't care, but there just isn't enough time to dive into each ticket in detail. Keeping them up to date gives too much administrative overhead which prevents us from fixing bugs.

Closing also doesn't mean we are never going to fix this, it means we don't think we're going to fix this in the next 3-6 months because we think we have more important&urgent items to spend our time on.

This is why I move issues that haven't been touched in the past 12 weeks to a bucket we internally call 'We are not going to do this' and urge everyone that 'listens' to this ticket to respond with new information on priority/urgency. If nobody replies, I close the ticket when it has been a month in the 'We are not going to do this' bucket.

[hillct]

I see. You started your comment by stating that you believe this issue to be resolved. As indicated last week, this issue was not resolved as of the 2.7 release, and if it hasn't been touched in 12 weeks is seems highly unlikely that it'll have been addressed in the October 17 release, as I don't see any references to code checkins addressing this issue.
Still, I'm perfectly happy to evaluate a nightly build so we can test your theory, to the extent you can make one available. I did some looking, for a link to your CI system and didn't see one, but perhaps I've simply overlooked it. Please advise. Thanks.

[nallath]

Well, it's not quite uncommon to have issues fixed without anyone explicitly addressing them.
In this case you found a symptom of a much larger issue (high DPI screens and mac not playing well). The larger issue was fixed as far as I know, but that would explain why there is no reference to this issue.

[fieldOfView]

it seems highly unlikely that it'll have been addressed in the October 17 release, as I don't see any references to code checkins addressing this issue.

Actually, quite a bit has been done to fix dialog scaling issues. See https://github.com/Ultimaker/Cura/pull/2484, (specifically https://github.com/Ultimaker/Cura/pull/2484/files#diff-568d1cd152217578c1f7eae53753fd97R113, which made the width/height of that dialog fall back to https://github.com/Ultimaker/Cura/pull/2484/files#diff-75d339a33a6a0cd1de017f3273182342R16)
I do have good hopes your specific issue is fixed now, but I don't have a MBP 2012 Retina to test with.

[fieldOfView]

Still, I'm perfectly happy to evaluate a nightly build

Unfortunately there are no nightly builds available for public use/testing. This has been brought up before. A community project could be created to set up a system for nightlies, but I don't think Ultimaker is going to put resources towards it any time soon (correct me if I am wrong @Appesteijn or @nallath)

[hillct]

The code you've referenced does seem as though it may address the issue. With regard to nightly builds, as you know, there are plenty of enterprise-grade CI infrastructures available freely to OSS projects, so it's surprising nobody has taken advantage of those offerings to this point. I did come across the recent forum post you alluded to on the subject https://ultimaker.com/en/community/51175-cura-2-nightly-builds and I'm aware doing CI builds for mac are particularly painful as regards cross-compiling or having access to Apple based CI infastrucure.
With all this in mind, I look forward to the October 17 release.

[Appesteijn]

I'm definitively positive about having daily builds available, but I need to prime this in the correct way to have other parts of our company align on this. At the moment we are focussing on Cura 3.0 to be released (17 oct) but after the next sprint we have some time to spend on this.

[hillct]

Having downloaded and tested the rendering of the machine settings window in Cura 3.0, it appears this issue has now been resolved.