Skip to content
New issue

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

#

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

Already on GitHub? # to your account

Jump to bottom

Eliminate the empty space between the word "available" and the vertical scrollbar up arrow on the right side of the volume info header #493

Closed
c0mmander8 opened this issue Jul 2, 2021 · 7 comments
Closed

Eliminate the empty space between the word "available" and the vertical scrollbar up arrow on the right side of the volume info header #493

c0mmander8 opened this issue Jul 2, 2021 · 7 comments
Labels
bug DeskTop DeskTop bugs or feature requests
Milestone
1.3

Comments

@c0mmander8
Copy link
Contributor

Eliminate the empty space between the word "available" and the vertical scrollbar up arrow on the right side of the volume info header, just like the early Mac and the IIGS.
@c0mmander8 c0mmander8 added bug DeskTop DeskTop bugs or feature requests labels Jul 2, 2021
@inexorabletash
Copy link
Collaborator

Right-aligned strings are more complex than it would assume. Left aligned-strings can be drawn by moving the current position to a fixed start location, and drawing each substring (e.g. label, number), and drawing spaces to erase a previous shorter string. Drawing right-aligned strings requires composing all of the substrings into a buffer, shifting the string to have spaces as a prefix, computing the length, offsetting the current position, and drawing the string.

It's not worth my time or the code complexity for this, although I wouldn't object if someone submitted a good patch.

@inexorabletash inexorabletash added the Won't Fix Invalid, no repro, or infeasible label Jul 3, 2021
@c0mmander8
Copy link
Contributor Author

Can't you eliminate the empty space between the word "available" and the vertical scrollbar up arrow on the right side of the volume info header while still using left-aligned strings?

@c0mmander8
Copy link
Contributor Author

Describe the bug
Please reopen this issue. Even with the right side of the volume info header displaying the maximum number of digits possible for a ProDOS volume, there is still some empty space between the word "available" and the vertical scrollbar up arrow on the right side of the volume info header. I think this bug is from when you briefly changed changed the size displayed in the volume info header from "K" to "KB" and back again.

To Reproduce
Steps to reproduce the behavior:

  1. Start Apple II DeskTop with a fresh copy of "Live.Install" mounted, which is a fresh copy of the "Live.Install.po" disk image from ftp://ftp.apple.asimov.net/pub/apple_II/images/gs/os/gsos/Apple_IIGS_System_6.0.4/.
  2. Open "Live.Install".
  3. The right side of the volume info header says "27,422K available".
  4. Even with the right side of the volume info header displaying the maximum number of digits possible for a ProDOS volume, there is still some empty space between the word "available" and the vertical scrollbar up arrow on the right side of the volume info header.
  5. I think this bug is from when you briefly changed changed the size displayed in the volume info header from "K" to "KB" and back again.

Expected behavior
With the right side of the volume info header displaying the maximum number of digits possible for a ProDOS volume, there should be no empty space between the word "available" and the vertical scrollbar up arrow on the right side of the volume info header.

Screenshots
I am sorry. I have no screenshots to help explain my problem.

System Details (please complete the following information):

  • System [e.g. Apple IIe Enhanced, Apple IIc, Apple IIgs] Apple IIGS (ROM 01)
  • Emulator? [e.g. real hardware, or emulator name] GSplus 0.14 (the latest version of the program)
  • ProDOS version ProDOS 2.4.2 (the latest version)
  • DeskTop version (from About > Apple II DeskTop...) Apple II DeskTop 1.2 Alpha 33 (the latest version of the program)
  • Other [e.g. mouse, memory expansions, disk types, etc]

Additional context
I think this bug is from when you briefly changed changed the size displayed in the volume info header from "K" to "KB" and back again.

@c0mmander8
Copy link
Contributor Author

This is now a bug that can be fixed while still using left-aligned strings.

@c0mmander8
Copy link
Contributor Author

This bug is definitely from when you briefly changed changed the size displayed in the volume info header from "K" to "KB" and back again.

@c0mmander8
Copy link
Contributor Author

I have confirmed that this bug is definitely from when you briefly changed changed the size displayed in the volume info header from "K" to "KB" and back again.

@c0mmander8
Copy link
Contributor Author

I am sorry and I apologize for the repeated posts in this issue and in issue #523. Please do not suspend or ban me. Thank you for your trouble.

@inexorabletash inexorabletash removed the Won't Fix Invalid, no repro, or infeasible label Mar 8, 2023
@inexorabletash inexorabletash added this to the 1.3 milestone Mar 8, 2023
inexorabletash added a commit that referenced this issue Mar 8, 2023
@inexorabletash
DeskTop: Improve positioning of window header items.
0c99878 
Improve the logic of laying out the header items in directory windows.
Previously, the logic pre-calculated the maximum space each chunk
(item count, k in disk, k available) used. Centering was wonky because
it assumed each item was full width, and the k available was not filly
right aligned either. It also had a minimum threshold below which the
layout logic shifted shifted entirely.

Change to computing the actual width of each chunk dynamically as it's
not in a tight loop. Then properly center the middle chunk between the
left and right chunks by computing the gap needed on each side. And
impose a lower limit on the gap. This makes the layout "perfect" for
all window sizes - cut off when it gets too low, but without a
transition.

Note that the middle chunk is not visually centered below the window
title, but it is visually centered with respect to the adjacent text
items. Can't satisfy both constraints!

Resolves #493
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
bug DeskTop DeskTop bugs or feature requests
Projects
None yet
Milestone
1.3
Development

No branches or pull requests
2 participants
@inexorabletash @c0mmander8