Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Histogram Shouldn't Have Max Height #17162

Open
johnlb opened this issue Jul 18, 2024 · 5 comments · May be fixed by #17045
Open

Histogram Shouldn't Have Max Height #17162

johnlb opened this issue Jul 18, 2024 · 5 comments · May be fixed by #17045
Labels
no-issue-activity scope: UI user interface and interactions

Comments

@johnlb
Copy link

johnlb commented Jul 18, 2024

Describe the bug

In 4.8.0, the height of the histogram was limited. This is a problem for large monitors as it makes it difficult to see the scope.

I submitted a pull request (#17045) a month ago that fixes this, but nothing has happened with it so maybe creating a ticket will at least start a conversation about it.

Steps to reproduce

Resize the histogram and it will stop at a certain point.

Expected behavior

The histogram should be able to be any size

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

downloaded from www.darktable.org

darktable version

4.8.0+

What OS are you using?

Linux

What is the version of your OS?

Ubuntu 24.04 on WSL2

Describe your system?

No response

Are you using OpenCL GPU in darktable?

None

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

@zisoft
Copy link
Collaborator

zisoft commented Jul 18, 2024

Summer time - vacation time.
So please be patient.

@zisoft zisoft linked a pull request Jul 18, 2024 that will close this issue
@zisoft zisoft added the scope: UI user interface and interactions label Jul 18, 2024
@wpferguson
Copy link
Member

The first month or so after a release is pretty much dedicated to fixing any bugs and getting the .1 release out. After that features and non-critical bug fixes start getting merged.

I usually hold off even submitting my PR's until after the .1 release so I don't "clutter" up the process.

The 4.8.1 release tarball was sent to packagers yesterday. The release should be out next week.

@johnlb
Copy link
Author

johnlb commented Jul 18, 2024

Gotcha! Thanks so much for the context that is good to know! I don't have a sense of what a normal turnaround time is for this project, so I figured a month was a reasonable amount of patience; sounds like it just happened to be at the wrong time in the design cycle :-)

I was hoping it would go out on the .1 release, since it was introduced in .0 and is kind of an accidentally regressive bug, but I can see how it would not seem that way if you mostly prioritize critical bugs for .1

@johnlb
Copy link
Author

johnlb commented Sep 15, 2024

Alright the PR went stale after 60 days. I just merged with the latest so I'm pinging this ticket to make sure someone sees it.

Copy link

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no-issue-activity scope: UI user interface and interactions
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants