[PATCH] Dialogs and menus have shadows

[kybl]

Hi,
I like Midnight Commander very much but I think that - comparing with Norton Commander, Volkov Commander, or Far Manager - it is not as "nice" from the user experience perspective. I will try to fix that in several next pull requests (if there will be an interest).

One of the things that are not so important but I miss it a lot, is the dialog "shadows". It is something that makes dialogs and menus "above" the rest of the screen, dialogs are not such flat. You can know them from all Norton, Volkov, and Far, which use them by default (and AFAIK there is not even an option to disable them).

Here is a patch that adds an option to enable dialog shadows (it is disabled by default, though).

It works as follows:

• there is a new option in Options => Configuration... => Dialog shadows
• it uses a new color in skin: [core] => shadow
• when a dialog or menu is opened, the background is changed to the shadow color on the right and bottom part of the dialog. Just like dialog would create a shadow on the background (see screenshots)
• it works for all dialogs and menus, even in mcedit, etc.

It works basically in the same way how other commanders do. And it is nicer :-)

I tested it in both Slang and Ncurses on Linux, in both "konsole" emulator, and terminal. The first patch contains code itself, man update, Czech translation. The second patch contains all skins update. Hopefully, it should be usable as-is.

Please let me know if you have any comments. Thanks.

[kybl]

Patch for source code

[kybl]

Patch for all skins

[kybl]

window with a shadow, default skin

[kybl]

menu with a shadow, default skin

[kybl]

window on a window with shadows, seasons-summer skin

[kybl]

shadows in mcedit

[zaytsev]

Wow, that looks very cool, what do you think, Andrew?

[andrew_b]

Replying to zaytsev:

Wow, that looks very cool, what do you think, Andrew?

Really cool.

I made some modifications in the original patch:

• made dialog_shadows option a member of mc_global_t::vfs
• moved "Dialog shadows" checkbox to "Appearance" dialog window. Shadows are on by default. Checkbox is disabled in case of BW mode. The changing of checkbox state is visualized immediately.
• made some changes in tty functions.

Patch was not fully tested.

[andrew_b]

What about applied shadows to editor windows?

[kybl]

Thanks! I like that it is as cool for you as for me!

I made some modifications in the original patch:

Seems good!

Shadows are on by default.

Great! :-)

What about applied shadows to editor windows?

What do you mean by "editor windows"? I don't understand.

[andrew_b]

Replying to kybl:

What about applied shadows to editor windows?

What do you mean by "editor windows"? I don't understand.

mceditor has ​Multiple-document interface (#2261). See attached screenshot.

[kybl]

What do you mean by "editor windows"? I don't understand.

mceditor has ​Multiple-document interface (#2261). See attached screenshot.

Thanks, I see. I never used it in this way, though. I tried to apply shadows at this case as well (patching editor/editraw.c:edit_draw_frame). I'm not sure about the typical scenario but I can imagine screen split to two halves – one file on the left, the other one on the right. Or one on top, one on the bottom. In that case, when I have focus on the left (or top) window, there is shadow through the other window. See screenshot. It is quite misleading.

So, personally, I would not apply window shadows in the editor.

Also, I found that when I move a window partially out of the screen to the left, the shadow on the bottom disappears. It is because there is a check in tty_colorize_area if the top left corner of the shadow is on the screen (yx_in_screenx). Maybe that condition is wrong (or not needed at all - it works fine even without it, at least at S-Lang version). Not sure if that can happen in other scenarios.

[kybl]

shadows in MDI in mcedit (see text inside screenshot)

[ossi]

yeah, the shadows don't mix well with tiled windows and windows that touch screen corners. i'd leave it off the MDI, too.

[Roman]

Replying to kybl:

Also, I found that when I move a window partially out of the screen to the left, the shadow on the bottom disappears.

Hi,
I tried to fix it. Now everything should be fine.
But I haven't tested this code (only on paper and in my mind).
If you have any questions, please ask.

void 
tty_colorize_area (int y, int x, int rows, int cols, int color) 
{ 
    cchar_t *ctext; 
    wchar_t wch[10];   /* TODO not sure if the length is correct */ 
    attr_t attrs; 
    short color_pair; 

    if (!use_colors || rows <= 0 || cols <= 0 || y >= LINES
            || x >= COLS || (x + cols) <= 0 || (y + rows) <= 0) 
        return;

    if (x < 0)
    {
        cols += x;
        x = 0;
    }
    
    if ((x + cols) > COLS)
    {
        cols = COLS - x;
    }
 
    tty_setcolor (color); 
    ctext = g_malloc (sizeof (cchar_t) * (cols + 1)); 
 
    for (int row = 0; row < rows; row++) 
    { 
        if ((y + row) >= 0 && (y + row) < LINES)
        {
            mvin_wchnstr (y + row, x, ctext, cols); 
    
            for (int col = 0; col < cols; col++) 
            { 
                getcchar (&ctext[col], wch, &attrs, &color_pair, NULL); 
                setcchar (&ctext[col], wch, attrs, color, NULL); 
            } 
    
            mvadd_wchnstr (y + row, x, ctext, cols);
        }
    } 
 
    g_free (ctext); 
}

[andrew_b]

I think, tty_fill_region(), tty_draw_hline(), and tty_draw_vline() can be used as reference how to draw rectangle area.
See also [e1f2b5b017803ae81312a6195272dfdf644800fb].

[zaytsev]

I like MDI shadows in RHIDE, but if I understand it correctly this requires a real z-index system, so I would just forego MDI shadows in mcedit...

[andrew_b]

Branch: 4102_shadows
changeset:c02911ec0acb73886aa9fcf5eff4d5fee2aadeee

[andrew_b]

Merged to master: [72740285da58735495e442e212476c1798a22881].

[egmont]

Hi guys,

I just came across this new feature for the forthcoming mc.

While I do appreciate the work and enthusiasm you put it in this, I have to admit that I really don't like this change. (And yes I've found that it can be disabled.)

I sincerely don't want to be negative (although I'm afraid it will seem like that), but allow me please to share with you my problems, and as such, put a slight pressure on you to disable it by default. Perhaps I can point to some aspects of this feature that you haven't thought of.

My concerns, in no particular order:

• There is one single color that's used for shadowed area. That's not how shadows work, shadowed area should have its underlying color automatically darkened. (I know it's not possible with the 16-color palette, probably possible in a very limited way with the extended 240 colors, but ideally would require a skin to use truecolors only. There's no such skin, even the truecolor ones still use palette colors for the editor's syntax highlighting.)

• Along with the colors, the attributes (bold, italic, underlined etc.) are also common for all the shadowed cells. Again, this is obviously not how shadows are supposed to work, bold or italic typeface are not supposed to become regular upright when shadowed.

• There is no consistent concept of z-index. Example 1: Take two nesting dialog boxes, for example open Options -> Appearanece and also open the skin list. Let's say the panels have z-index of 0, and the Appearance dialog is at z-index of 1. What's the z-index of the skin list? If it's 1 then it shouldn't cast a shadow on the Appearance dialog. If it's 2 then the shadow it casts on the panels should be offset by twice the current amount.

• There is no consistent concept of z-index. Example 2: The "Left File Command..." menubar is at z-index 0 (because it doesn't cast a shadow on the panels). The menus opened from here have z-index of 1. Yet looking at these two UI items it really doesn't look like one is closer to me than the other, there's no separator, nor change in color, nothing that would suggest so, I can even drag the mouse from one to the other.

• I do various tasks on my computer, including running applications inside the terminal, running graphical applications (GTK, QT etc.), also visiting various webpages (search engine, wiki, coding sites, webmail, social media etc.). The recent trend is to go with simple, flat UI elements. I hardly see any shadow anywhere, and even if I do, it's a pretty weak one, usually surrounding the element in all four directions. Pretty much everything else I do on my computer mimics that there's ambient light lighting my desktop. Yet mc's new appearance mimics the light coming from a diagonal 45 degree angle from the upper left.

The traditional look of mc is elegant, clean, reasonably nice compared to the constraints of a terminal, pleasant to work with.

The new look is inconsistent with everything else I use, and has very little connection with how shadows in real life actually work. It's a nonsense optial illusion messing with my brain.

I'd appreciate if you reconsidered whether you really wish to enable this by default. Also consider whether providing the "usual" experience to Norton, Volkov, Far users, or providing the "usual" experience to old-timer Midnight folks is the more important.

I think it'd much better remain disabled by default. Just my 2 cents. Thanks for reading, cheers!

[andrew_b]

Ok, no problem. Let's disable by default.

[kybl]

Hi,

I would like to respond to egmont concerns (actually thanks for them!):

There is one single color that's used for shadowed area.
…
Along with the colors, the attributes (bold, italic, underlined etc.) are also common for all the shadowed cells.

Yes, I agree, these are valid points. This is not how exactly shadows work.

However, it does not care too much. That shadow is just an optical hint more than an actual shadow. While there is theoretically possible to make "true" shadow in 16M color palette, actual implementation would make this patch incredibly complex (we probably don't want to do this just for a shadow illusion).

There is no consistent concept of z-index. Example 1: Take two nesting dialog boxes, for example open Options -> Appearanece and also open the skin list. Let's say the panels have z-index of 0, and the Appearance dialog is at z-index of 1. What's the z-index of the skin list? If it's 1 then it shouldn't cast a shadow on the Appearance dialog. If it's 2 then the shadow it casts on the panels should be offset by twice the current amount.

Z-index of skin list should be 2. Shadow should not be twice the current amount (when something is already in the shadow, another elements on the way between the source of light and actual object do not add another shadow).

But maybe I don't understand this concern. What is the point of this?

There is no consistent concept of z-index. Example 2: The "Left File Command..." menubar is at z-index 0 (because it doesn't cast a shadow on the panels). The menus opened from here have z-index of 1. Yet looking at these two UI items it really doesn't look like one is closer to me than the other, there's no separator, nor change in color, nothing that would suggest so, I can even drag the mouse from one to the other.

You are right here. Menu on the top should have a shadow too. However, shadow is not here because:

1) menu is just one line on the whole top, shadow here would be more confusing than a benefit. Especially when there is menu visible all the time by default
2) shadow here is just not common in other programs (see my later point)

I don't think it is an issue.

I do various tasks on my computer, including running applications inside the terminal, running graphical applications (GTK, QT etc.), also visiting various webpages (search engine, wiki, coding sites, webmail, social media etc.). The recent trend is to go with simple, flat UI elements. I hardly see any shadow anywhere, and even if I do, it's a pretty weak one, usually surrounding the element in all four directions. Pretty much everything else I do on my computer mimics that there's ambient light lighting my desktop. Yet mc's new appearance mimics the light coming from a diagonal 45 degree angle from the upper left.

Personally, I would not say there is a trend with flat elements. Flat elements were on top in 2005 or so, since then, I see shadows more and more. The reason is an optical distinguish between various windows, or form elements. I have shadows on my Linux desktop, on Android phone. When I google, I see shadows both on latest Windows: ​https://i.imgur.com/gj1u8a9.png and MacOS: ​https://venturebeat.com/wp-content/uploads/2020/06/bigsur.jpg
But I definitely agree with you that shadow looks differently: they are just slight and they to all four directions, so different what is here. Such slight shadow is hard to achieve in text environment.

I see one reason why to use shadows by default: They are actually very common, not just in user interface in general but even in text user interface. Try to google "text user interface" and see where is one window above another. There are a plenty examples from various programs, and almost all of them have shadows; they are exactly or almost the same, as they are in the patch:

​https://winworldpc.com/res/img/screenshots/967c1c190fa98b954e706b532193194d0bac135b24e577a11cf12325aeba31cb.png
​https://qph.fs.quoracdn.net/main-qimg-5612859524b224986c787b4a5743216f
​https://vivaclipper.files.wordpress.com/2013/10/qb45tuinterface.jpg
​https://i.stack.imgur.com/0sRMM.jpg
​https://i.imgur.com/3Fab3oQ.png
​https://upload.wikimedia.org/wikipedia/en/3/3b/Norton_Utilities_6.01_UI.png
​https://upload.wikimedia.org/wikipedia/commons/c/c5/Fdedit.png

You can see screenshots also in articles about text graphical interface:

​http://www.petesqbsite.com/sections/express/issue21/tuiseriespart1.htm
​https://laptrinhx.com/text-based-user-interface-css-framework-1092471173/
​http://toastytech.com/guis/text.html
​http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-ig-x8664-multi-en-4/s1-guimode-textinterface.html

Actually, I have a hard time to actually find something WITHOUT shadows. One of few exceptions from this rule is Midnight Commander. I wrote this patch because I missed shadows in MC too much and basically fill this gap in MC UI.

But of course, I see your point here:

providing the "usual" experience to old-timer Midnight folks is the more important.

Even shadows are IMHO common elsewhere, a person working with just MC for ages could be surprised and messed, like you are.

I still think that this optical illusion, despite how inexact it is, helps for better orientation in general and it will be consistent with similar user interfaces.

Please reconsider the default settings again.

[egmont]

Hi,

Thanks a lot for your detailed response!

Z-index of skin list should be 2. Shadow should not be twice the current amount (when something is already in the shadow, another elements on the way between the source of light and actual object do not add another shadow).

But maybe I don't understand this concern. What is the point of this?

Let's suppose that when an object of z-index 1 casts a shadow on an object of z-index 0, the offset for the shadow is 2 character cells to the right and 1 character cell to the bottom. This is how it is now.

When an object of z-index 2 casts a shadow on an object of z-index 1, it's the same.

But when an object of z-index 2 casts a shadow on an object of z-index 0, the shadow's offset, relative to the object that causes it, should be twice the previous amount, that is, 4 character cells to the right and 2 to the bottom.

If it's not done like this then my brain receives contradicting pieces of information and can't imagine a valid set of z-index values. It tells me that C is one level closer to me than B, B is one level closer to me than A, yet C is one level closer to me than A. This is what I called a nonsense optical illusion.

Is this perhaps easily fixable?

You are right here. Menu on the top should have a shadow too. However, shadow is not here because:

Again, exceptions like these bring inconsistency and a mental confusion.

Thanks for the list of apps you provided.

For the graphical ones, the shadows are way less prominent than in mc, no shadow at all would IMO be closer to those solutions than the new overly prominent shadow of mc.

For the text ones, apparently you tend to use a different set of apps than I. When it comes to text mode apps that I occasionally or regularly use, or at least or used to use, the list goes something like vim, emacs, nano, joe, top, htop, alsamixer, ranger, pine, mutt, dselect, tmux, curl wttr.in, maybe I could also mention how mysql and friends format the tables etc. No shadow in these.

---

[As a former terminal emulator developer (most notably gnome-termina/vte, but having contributed to some others too), an interesting idea occurred to me now.

It would be really cool if apps could communicate the z-index of each cell towards terminal emulators, similarly to how colors and other attributes are communicated. Then terminal emulators could implement a nicely looking, thin, soft shadow that is not restricted by the cell grid.

This would need a new convention, a coordination among some terminals that are interested, then some terminals actually implementing it, plus ncurses and slang also adding support, plus of course quite a few apps that are keen on adding this feature (e.g. text editors could decrease the z-index at the desired right margin, that could look great).

Realistically it's not going to happen, too much work for marginal benefits, this idea is not really viable unfortunately.]

[kybl]

How a shadow looks now (with just one z-index)

[kybl]

How shadow with proper z-index is proposed

[kybl]

But when an object of z-index 2 casts a shadow on an object of z-index 0, the shadow's offset, relative to the object that causes it, should be twice the previous amount, that is, 4 character cells to the right and 2 to the bottom.

Aah, I see it now. You are right. Technically, the shadow should be moved even more.

I tried to make a fake screenshot of how it would look like. Yes, it is more logical but maybe also more confusing. Not sure how easily it can be realizable but not sure if this is desired.
Compare ​state now
with ​state with fixed shadow
(those light square on the bottom right is actually a defect, non-related to shadows. It is a cursor but there should be no cursor at all at this point. I'm going to address this issue later.)

Maybe I'm thinking just more with symbols. A shadow is just a symbol of one window above another one. It is not a true reality.

Is the second screenshot a state you would like better?

For the graphical ones, the shadows are way less prominent than in mc, no shadow at all would IMO be closer to those solutions than the new overly prominent shadow of mc.

Yeah. However, the shadow is just a symbol. There is probably not possible to have such slight shadows in the text user interface.

For the text ones, apparently you tend to use a different set of apps than I. When it comes to text mode apps that I occasionally or regularly use, or at least or used to use, the list goes something like vim, emacs, nano, joe, top, htop, alsamixer, ranger, pine, mutt, dselect, tmux, curl wttr.in, maybe I could also mention how mysql and friends format the tables etc. No shadow in these.

I know/use just some subset of these programs but these are other types of programs. They are very plain, they have barely any colors. And most importantly, there are no overlaps. At least at programs from this subset I know, I did not find any use case where one window would be above the other one. So there is no need for shadows. And no shadows work with such a plain interface better.

Midnight Commander is actually almost the same as the other category of programs with a rich text user interface (most of them are quite old, however). It looks basically the same, except the shadows (and maybe some other minor things, like button look).

an interesting idea occurred to me now …

Yes, that would be cool.

What I miss really much here is Midnight Commander with just one panel on the right, and output from a live terminal on the left. Just like NC/VC/Far were. But that needs to ability to read the terminal output and this is not supported (or almost not supported, AFAIK).

[ossi]

A shadow is just a symbol of one window above another one. It is not a true reality.

indeed, and that's why No UI Ever (TM) actually implemented physically accurate shadows.
the windows themselves often contain 3d-ish rather than plain 2d or actual 3d content, so the presentation remains "unrealistic" anyway.

btw, there is an alternative to drop shadows: shadow/desaturate everything outside the current window, as compositing window managers typically can be configured to do. this avoids the rather confusing artifacts resulting from a limited resolution+palette, sidesteps questions of nesting, and is simpler to implement. obviously, this is applicable only to modal dialogs, but i kind of argued for that anyway.

[zaytsev]

Hi Egmont,

I will for once disagree with you... I think that you are making all valid points from the "how to translate shadows to the desktop metaphor" angle, and indeed desaturation and/or soft shadows from the realistically positioned light source / proper z-index layering is where the current graphical world is going.

However, in this case, shadows are just a deliberately simplified symbol following a particular tradition. For that reason, I would be against the z-index correction, because either one should accept this symbol as is (and kybl has provided quite a few screenshots that show how this tradition is followed) or just don't do it, and do something else instead - changing it will confuse and annoy people used to TurboVision-style shadows, and will not make you completely happy anyways.

As to making it disabled or enabled by default - I think the bottom line is whether one has grown up with such interfaces and got used to them / likes them or not. Those who did will find it awesome, those who didn't will find it confusing. I don't think that either of us could correctly predict the sizes of those two groups among mc users.

Therefore, I would really like to have it enabled by default to gain exposure, and then if enough people complain possibly disable it by default. Otherwise, I fear nobody will find out that the shadows now even exist. The looks of mc have changed very significantly from 4.5 / 4.6 releases and nobody made a drama out of it, so I think that even if many people didn't experience shadows before, there will be little backlash if at all.

P.S. Of course, I'm biased, because I'm totally blown away by shadows - all those memories of hiew, nc, Word & Deed, Borland and Microsoft IDEs coming back immediately... oh my.

Yury

[egmont]

Thanks a lot to all of your responses!

Apparently, despite the problems I pointed out, you all seem to be in favor of this new feature and argue that those problems aren't as bad.

I also only meant to – and hopefully made that clear – put a slight pressure on you to reconsider the default. Seems that you've done and rejected my request. It's fair and I accept it (and I'll switch off this feature for myself). Thanks for taking the time to explain your take on the story!

---

There's one more thing I'd like to point out.

I have a pending, long forgotten patch in #3169 which lets you individually configure some of the user interface flags. In a comment in its parent bug, at https://midnight-commander.org/ticket/2165#comment:10 andrew_b's opinion was that this change is undesired and skins themselves should define these properties.

The consistent behavior with that would be if there was no config option for the shadows either, but each skin file would contain whether shadows are to be used or not. Now that's clearly not what I want to do.

andrew_b: Can I take your approval and the merge of this change a sign that you changed your mind, and would give green light to those features?

It's mostly a hypothetical question as I'm unlikely to work on those any time soon. But maybe someone else feels like updating and finishing that work.

[zaytsev]

Oh man, we should really get the Lua-fork in someday :-/ but where to find money to pay the bills, so that we could work on mc instead of $dayjob?