cal: add landscape layout for yearly views (#117)
A message that is not in the archive (sent off-list or not yet received): karelzak/util-linux/pull/[email protected]
A message that is not in the archive (sent off-list or not yet received): karelzak/util-linux/pull/117/[email protected]
A message that is not in the archive (sent off-list or not yet received): CAP0zEAb8y+P-McdLc23dJyqG3_=mFQw9PEmkaLLbzGzmWL7p-A@mail.gmail.com
This is a follow-up to:
https://github.com/karelzak/util-linux/pull/117#issuecomment-55868722
Quoted 8 lines
With the high availability of wide screens and high-resolution emulated terminals and terminal window managers it's sometimes useful to change the output of cal(1) yearly views to more stretched out ones horizontally.
This patch adds a new -l/--landscape flag that stretches out the yearly view to 3x4 and 4x3 months in Julian mode and 4x3 and 6x2 in regular mode. The flag can be used up to two times.
Thank you for your response, Karel :)
"It would be better to make it completely dynamical and fill-in all terminal horizontally if possible. It means to determine the number of the months dynamically according to terminal width rather than hardcode number of months (or require more -l options (ctl.landscape++))."
I don't think the filling in the terminal completely is a logical approach. I feel that calendar year output has to be rectangular. T here are always 12 months and the only way to arrange them into a nice rectangular shape is 1x12, 2x6, 3x4, 4x3, 6x2, 12x1, other shapes don't make much sense UI-wise, do they? All the printed mini calendars I get are always laid out in 3x4, 4x3 or 6x2 (rare).
This is what actually inspired me to hack cal in the first place. Someone asked me to put together a simple mini calendar from print, it had to be in landscape mode (4x3 months). cal would only output 3x4 so I couldn't just copy and paste into GIMP. I couldn't even find a tool online that would output nice text to paste in. Ended up downloading the source and hacking a quick 4x3 mode for a once-off purpose, writing down "cal landscape mode" in my todo list.
I did pick the most useful extensions of 4x3 and 6x2 for regular, and 3x4 and 4x3 for the Julian one. I have a 1080p monitor and 6x2 is the largest it goes without wrapping on a 12pt mono font for a regular calendar (Julian is a bit wider even so 6x2 barely fits).
If 12x1 is really useful (i.e. full length with month wrapping) adding another -l to extend would work. But not having the flexibility of wrapping to predefined sizes seems like a missing feature. I mean we could resize the terminal window and wrap along the edges, but that's not good UI. Forcing the user to resize the terminal window to get perfect rectangular layouts seems like a hack.
I did pick the repetition of the flag to stretch out the layout akin to the way verbose flags work in many programs, by repeating -vvvv one gets more verbosity out of the program. And by repeating -lll one gets more lanscape out of cal.
Hope this makes sense. I appreciate your feedback and hope to sort this feature out with more input and brainstorming.
Regards,
Gennady Kovshenin
Quoted 16 lines · Karel Zak
Hi Gennady,
don't care about po/ stuff, it's automatically updated before release.The request to make cal(1) more friendly to large screens makes sense, but your -l implementation does not seem to be user-friendly.
It would be better to make it completely dynamical and fill-in all terminal horizontally if possible. It means to determine the number of the months dynamically according to terminal width rather than hardcode number of months (or require more -l options (ctl.landscape++)).
See
lib/ttyutils.candget_terminal_width().Note the best way to discuss new features is [email protected] mailing list. You don't have to subscribe to send to the list.
—
Reply to this email directly or view it on GitHub.
Karel Zak
maintainerQuoted 6 lines · Gennady Kovshenin
I don't think the filling in the terminal completely is a logical approach. I feel that calendar year output has to be rectangular. T here are always 12 months and the only way to arrange them into a nice rectangular shape is 1x12, 2x6, 3x4, 4x3, 6x2, 12x1, other shapes don't make much sense UI-wise, do they? All the printed mini calendars I get are always laid out in 3x4, 4x3 or 6x2 (rare).
Well, "fill-in all terminal horizontally" does not mean that I want to generate any unreadable mess :-)
I'd like to see "cal --landscape" *just works* and it automatically selects the best output format (3x4, 4x3, 6x2, ...) which fits into the current terminal width. That's all the story. As user I don't want to think about number of -l options.
Additionally we can add a new option --format={3x4, 4x3, auto, ...} to provide full control on the output for scripts that generate something from cal(1) output.
IMHO, it's mistake that for example -y or -3 ignores terminal width so on small terminals it's unreadable.
Karel
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
I like the format=auto idea. But we can keep it to just the number of columns instead of a full CxR format.
i.e. format=2 (2x6), format=3 (3x4), format=4 (4x3), and so on. perhaps the parameter should be called --columns/-c instead of format. We can either have an additional auto value to the format, or have it be on by default.
Having auto on by default means breaking compatibility. Some users might be parsing output expecting the default 3x4 view in place and if we abruptly change this to be stretched automatically their scripts might break.
Any thoughts on the above? --format vs. --columns? And the default value thereof.
Regards,
Gennady Kovshenin
Regards,
Gennady Kovshenin
Quoted 28 lines · Karel Zak
Quoted 6 lines · Gennady Kovshenin
I don't think the filling in the terminal completely is a logical approach. I feel that calendar year output has to be rectangular. T here are always 12 months and the only way to arrange them into a nice rectangular shape is 1x12, 2x6, 3x4, 4x3, 6x2, 12x1, other shapes don't make much sense UI-wise, do they? All the printed mini calendars I get are always laid out in 3x4, 4x3 or 6x2 (rare).
Well, "fill-in all terminal horizontally" does not mean that I want to generate any unreadable mess :-)
I'd like to see "cal --landscape" *just works* and it automatically selects the best output format (3x4, 4x3, 6x2, ...) which fits into the current terminal width. That's all the story. As user I don't want to think about number of -l options.
Additionally we can add a new option --format={3x4, 4x3, auto, ...} to provide full control on the output for scripts that generate something from cal(1) output.
IMHO, it's mistake that for example -y or -3 ignores terminal width so on small terminals it's unreadable.
Karel
--
Karel Zak <[email protected]>
http://karelzak.blogspot.com
Karel Zak
maintainerQuoted 2 lines · Gennady Kovshenin
I like the format=auto idea. But we can keep it to just the number of columns instead of a full CxR format.
It would be the best to talk about number of months ;-)
Quoted 11 lines
i.e. format=2 (2x6), format=3 (3x4), format=4 (4x3), and so on. perhaps the parameter should be called --columns/-c instead of format. We can either have an additional auto value to the format, or have it be on by default.
Having auto on by default means breaking compatibility. Some users might be parsing output expecting the default 3x4 view in place and if we abruptly change this to be stretched automatically their scripts might break.Any thoughts on the above? --format vs. --columns? And the default value thereof.
Or something else --horizontal-months[=<num>|auto]
and think we can support arbitrary <num> in range 1-12.
Karel
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
Agreed. And the default would still be 3, right? For back compatibility.
What's the short version of the flag -z?
And would the auto mode try to still limit itself to a rectangle? Or stretch indefinitely?
I appreciate your time brainstorming about this, Karel. Thank you. Regards,
Gennady Kovshenin
Quoted 27 lines · Karel Zak
Quoted 2 lines · Gennady Kovshenin
I like the format=auto idea. But we can keep it to just the number of columns instead of a full CxR format.
It would be the best to talk about number of months ;-)
Quoted 11 lines
i.e. format=2 (2x6), format=3 (3x4), format=4 (4x3), and so on. perhaps the parameter should be called --columns/-c instead of format. We can either have an additional auto value to the format, or have it be on by default.
Having auto on by default means breaking compatibility. Some users might be parsing output expecting the default 3x4 view in place and if we abruptly change this to be stretched automatically their scripts might break.Any thoughts on the above? --format vs. --columns? And the default value thereof.
Or something else --horizontal-months[=<num>|auto]
and think we can support arbitrary <num> in range 1-12.
Karel
--
Karel Zak <[email protected]>
http://karelzak.blogspot.com
Quoted 24 lines · Karel Zak
Quoted 23 lines · Gennady Kovshenin
Quoted 2 lines
I like the format=auto idea. But we can keep it to just the number of columns instead of a full CxR format.
It would be the best to talk about number of months ;-)
Quoted 11 lines
i.e. format=2 (2x6), format=3 (3x4), format=4 (4x3), and so on. perhaps the parameter should be called --columns/-c instead of format. We can either have an additional auto value to the format, or have it be on by default.
Having auto on by default means breaking compatibility. Some users might be parsing output expecting the default 3x4 view in place and if we abruptly change this to be stretched automatically their scripts might break.Any thoughts on the above? --format vs. --columns? And the default value thereof.
Or something else --horizontal-months[=<num>|auto]
and think we can support arbitrary <num> in range 1-12.
Karel
Quoted 3 lines · Gennady Kovshenin
Agreed. And the default would still be 3, right? For back compatibility.
What's the short version of the flag -z?
Mind the fact the cal is part of posix, so adding short options may cause (theoretically) necessity to be either backwards incompatible or break the standard.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cal.html
Quoted 2 lines
And would the auto mode try to still limit itself to a rectangle? Or stretch indefinitely?
IMHO rectangles are fine if the they are requested with an option something like
--geometry=x:y
But if the number of months is wanted to be
--begin=<date>
--end=<date>
Then the default geometry 3xN should be applied, unless otherwise defined by user.
When --geometry=5:3 is defined and --begin && --end define a period of a year (for example), then the last three 'month' entries should be blanks.
Would that make sense?
Signature · 2 lines
Sami Kerola http://www.iki.fi/kerolasa/
Quoted 43 lines · Sami Kerola
Quoted 24 lines · Karel Zak
Quoted 23 lines · Gennady Kovshenin
Quoted 2 lines
I like the format=auto idea. But we can keep it to just the number of columns instead of a full CxR format.
It would be the best to talk about number of months ;-)
Quoted 11 lines
i.e. format=2 (2x6), format=3 (3x4), format=4 (4x3), and so on. perhaps the parameter should be called --columns/-c instead of format. We can either have an additional auto value to the format, or have it be on by default.
Having auto on by default means breaking compatibility. Some users might be parsing output expecting the default 3x4 view in place and if we abruptly change this to be stretched automatically their scripts might break.Any thoughts on the above? --format vs. --columns? And the default value thereof.
Or something else --horizontal-months[=<num>|auto]
and think we can support arbitrary <num> in range 1-12.
Karel
Quoted 3 lines · Gennady Kovshenin
Agreed. And the default would still be 3, right? For back compatibility.
What's the short version of the flag -z?
Mind the fact the cal is part of posix, so adding short options may cause (theoretically) necessity to be either backwards incompatible or break the standard.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cal.html
Quoted 2 lines
And would the auto mode try to still limit itself to a rectangle? Or stretch indefinitely?
IMHO rectangles are fine if the they are requested with an option something like
Quoted 6 lines
--geometry=x:y
But if the number of months is wanted to be
--begin=<date>
--end=<date>
I haven't seen these flags anywhere in cal. Output is always limited to 12 months in year view.
Why even bother with the rows when asking for the columns is enough?
I'd just go with "width", or "horizontal" as Karel suggested. "width" makes perfect sense wherein users just supply the number of columns in their year view and a value of 0 or auto would autoset it based on the width of the current terminal (limited to a nice rectangle).
Karel, how do you feel about the --width -w option?
Quoted 13 lines
Then the default geometry 3xN should be applied, unless otherwise defined by user.
When --geometry=5:3 is defined and --begin && --end define a period of a year (for example), then the last three 'month' entries should be blanks.
Would that make sense?
--
Sami Kerola
http://www.iki.fi/kerolasa/
Karel Zak
maintainerQuoted 1 line · Gennady Kovshenin
Karel, how do you feel about the --width -w option?
--width seems like option with mandatory argument, command line without another argument (e.g. "cal --width") seems strange.
--horizontal[=<months>] where default is "auto" seems better ;-)
Quoted 2 lines
Quoted 2 lines
Then the default geometry 3xN should be applied, unless otherwise defined by user.
3xN should be be default when no --horizontal is specified.
cal -y ==> 3 columns cal --horizontal ==> depends on terminal width cal --horizontal=6 ==> 6 columns
Karel
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com