(flatpak 3.1.0)
Expected: Bottom bar has fixed height.
Actual: Bottom bar height is dynamic, dependent on file names. (e.g. CJK characters could raise the height of bottom bar)
If I may ask, what is the problem with the bottom bar becoming larger to accommodate larger font symbols? If the bar was fixed height, the font height would need to decrease instead, leading to decreased readability.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is anti-conventional.
Which widely used applications use dynamically sized top or bottom bar?
It looks horrible when navigating through directories or image files, and prevents users from using mcomix to comparing images visually (as viewport size become inconsistent).
Bottom bar file name looks ugly in case of CJK characters: same font size + extra vertical margin means broken vertical layout.
Apparently the text widgets of file names screws up vertical margin for CJK characters. Then the bottom bar applies a padding or margin to the broken text widgets and gets incorrect height.
In case of CJK characters, the text widgets should enforce fixed line height or avoid top padding or margin (e.g. set to same size as latin-only text widgets - page no, file size).
Last edit: aasa 2024-10-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Huh. I was expecting this to be about wrapping. If the height of the statusbar is changing based on the character set used in its text contents, I'm not sure how much control MComix has over that. The statusbar is just a Gtk.EventBox with a Gtk.Statusbar embedded in it. Contents are removed by calling Gtk.Statusbar.pop() and added by passing strings to Gtk.Statusbar.push(). MComix never sets, adjusts, or computes the height of the widget.
If there's a sizing bug related to the text content, it's probably a Gtk3 Gtk.Statusbar bug. (But there's no point in reporting it to them, GNOME aren't fixing Gtk3 bugs anymore.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Weeeell... one qualifier on that. It could be that the Gtk.EventBox creates some default padding/margins around the Gtk.Statusbar that allow it to have a more dynamic height than it otherwise normally would. AFAICT EventBox is a Gtk.Bin subclass with full layout support, including spacing adjustments. It's probably worth looking for weirdness along those lines.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using the GTK3 inspector, I can determine that mcomix+status+statusbar (the Gtk.EventBox subclass) has no margin or padding values, but the Gtk.Statusbar contained within it is created with default margins of 6 10 6 10 (using CSS top-right-botttom-left ordering). So if the contents of the statusbar widget become taller, those margins could push out the height of the surrounding container to make room.
Ideally we'd want the Statusbar to expand into its surrounding container, if necessary, but without affecting the container height. That should be possible (there's room), I just have to figure out how to explain that to Gtk3.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you provide an example filename that causes the bottom bar to expand? I don't typically work with non-ASCII filenames, and I'd rather have a "real example" than one I just made up, since I can't be sure that mine will reproduce the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I may ask, what is the problem with the bottom bar becoming larger to accommodate larger font symbols? If the bar was fixed height, the font height would need to decrease instead, leading to decreased readability.
Which widely used applications use dynamically sized top or bottom bar?
Apparently the text widgets of file names screws up vertical margin for CJK characters. Then the bottom bar applies a padding or margin to the broken text widgets and gets incorrect height.
In case of CJK characters, the text widgets should enforce fixed line height or avoid top padding or margin (e.g. set to same size as latin-only text widgets - page no, file size).
Last edit: aasa 2024-10-20
Huh. I was expecting this to be about wrapping. If the height of the statusbar is changing based on the character set used in its text contents, I'm not sure how much control MComix has over that. The statusbar is just a
Gtk.EventBoxwith aGtk.Statusbarembedded in it. Contents are removed by callingGtk.Statusbar.pop()and added by passing strings toGtk.Statusbar.push(). MComix never sets, adjusts, or computes the height of the widget.If there's a sizing bug related to the text content, it's probably a Gtk3
Gtk.Statusbarbug. (But there's no point in reporting it to them, GNOME aren't fixing Gtk3 bugs anymore.)Weeeell... one qualifier on that. It could be that the
Gtk.EventBoxcreates some default padding/margins around theGtk.Statusbarthat allow it to have a more dynamic height than it otherwise normally would. AFAICTEventBoxis aGtk.Binsubclass with full layout support, including spacing adjustments. It's probably worth looking for weirdness along those lines.Using the GTK3 inspector, I can determine that
mcomix+status+statusbar(theGtk.EventBoxsubclass) has no margin or padding values, but theGtk.Statusbarcontained within it is created with default margins of6 10 6 10(using CSS top-right-botttom-left ordering). So if the contents of the statusbar widget become taller, those margins could push out the height of the surrounding container to make room.Ideally we'd want the Statusbar to expand into its surrounding container, if necessary, but without affecting the container height. That should be possible (there's room), I just have to figure out how to explain that to Gtk3.
@aasa
Can you provide an example filename that causes the bottom bar to expand? I don't typically work with non-ASCII filenames, and I'd rather have a "real example" than one I just made up, since I can't be sure that mine will reproduce the problem.