Changed by kybl (@kybl) on Jul 5, 2020 at 20:17 UTC

• Attachment dialog-shadow-code.patch (raw) added

Patch for source code

Changed by kybl (@kybl) on Jul 5, 2020 at 20:17 UTC

• Attachment dialog-shadows-skins.patch (raw) added

Patch for all skins

Changed by kybl (@kybl) on Jul 5, 2020 at 20:18 UTC

• Attachment window-with-shadow.png (raw) added

window with a shadow, default skin

Changed by kybl (@kybl) on Jul 5, 2020 at 20:18 UTC

• Attachment menu.png (raw) added

menu with a shadow, default skin

Changed by kybl (@kybl) on Jul 5, 2020 at 20:20 UTC

• Attachment window-on-window-other-skin.png (raw) added

window on a window with shadows, seasons-summer skin

Changed by kybl (@kybl) on Jul 5, 2020 at 20:20 UTC

• Attachment editor.png (raw) added

shadows in mcedit

Changed by zaytsev (@zyv) on Jul 5, 2020 at 20:44 UTC (comment 1)

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

Changed by andrew_b (@aborodin) on Jul 6, 2020 at 18:48 UTC (comment 1.2)

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.

Changed by andrew_b (@aborodin) on Jul 6, 2020 at 18:49 UTC

• Attachment dialog-shadow-2.patch (raw) added

Changed by andrew_b (@aborodin) on Jul 6, 2020 at 18:51 UTC (comment 3)

What about applied shadows to editor windows?

Changed by kybl (@kybl) on Jul 6, 2020 at 20:44 UTC (comment 4)

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.

Changed by andrew_b (@aborodin) on Jul 7, 2020 at 5:36 UTC (comment 4.5)

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.

Changed by andrew_b (@aborodin) on Jul 7, 2020 at 5:36 UTC

• Attachment mcedit-windows.png (raw) added

Changed by kybl (@kybl) on Jul 7, 2020 at 6:48 UTC (comment 5.6)

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.

Changed by kybl (@kybl) on Jul 7, 2020 at 6:50 UTC

• Attachment shadows-in-editor-MDI.png (raw) added

shadows in MDI in mcedit (see text inside screenshot)

Changed by ossi (@ossilator) on Jul 7, 2020 at 12:05 UTC (comment 7)

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

Changed by Roman (romanstrah@….ru) on Jul 9, 2020 at 13:48 UTC (comment 6.8)

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); 
}

Changed by andrew_b (@aborodin) on Jul 9, 2020 at 14:19 UTC (comment 9)

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

Changed by zaytsev (@zyv) on Jul 19, 2020 at 10:54 UTC (comment 10)

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...

Changed by andrew_b (@aborodin) on Jul 19, 2020 at 17:31 UTC (comment 11)

• Component changed from mc-skin to mc-core
• Branch state changed from no branch to on review
• Owner set to andrew_b
• Milestone changed from Future Releases to 4.8.26
• Status changed from new to accepted

Branch: 4102_shadows
[c02911ec0acb73886aa9fcf5eff4d5fee2aadeee]

Changed by andrew_b (@aborodin) on Aug 2, 2020 at 13:15 UTC (comment 12)

• Votes set to andrew_b
• Branch state changed from on review to approved

Changed by andrew_b (@aborodin) on Aug 2, 2020 at 13:16 UTC (comment 13)

• Branch state changed from approved to merged
• Resolution set to fixed
• Status changed from accepted to testing
• Votes changed from andrew_b to committed-master

Merged to master: [7274028].

Changed by andrew_b (@aborodin) on Aug 2, 2020 at 13:17 UTC (comment 14)

• Status changed from testing to closed

Changed by egmont (@egmontkob) on Nov 16, 2020 at 15:03 UTC (comment 15)

• Cc set to 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!

Changed by andrew_b (@aborodin) on Nov 17, 2020 at 16:15 UTC (comment 16)

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

Changed by kybl (@kybl) on Nov 17, 2020 at 19:28 UTC (comment 17)

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.

Changed by egmont (@egmontkob) on Nov 19, 2020 at 8:57 UTC (comment 18)

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.]

Changed by kybl (@kybl) on Nov 19, 2020 at 9:55 UTC

• Attachment shadow-now.png (raw) added

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

Changed by kybl (@kybl) on Nov 19, 2020 at 9:55 UTC

• Attachment shadow-proper-z-index.png (raw) added

How shadow with proper z-index is proposed

Changed by kybl (@kybl) on Nov 19, 2020 at 9:59 UTC (comment 19)

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).

Changed by ossi (@ossilator) on Nov 19, 2020 at 12:25 UTC (comment 20)

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.

Changed by zaytsev (@zyv) on Nov 22, 2020 at 15:43 UTC (comment 21)

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

Changed by egmont (@egmontkob) on Nov 22, 2020 at 17:30 UTC (comment 22)

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 #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.

Changed by zaytsev (@zyv) on Nov 22, 2020 at 20:55 UTC (comment 23)

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?