In Windows Version, the Apps Dont Have Right Stroke and Shadows

[Shompinice]

Due to the lack of proper strokes and shadows, under Windows, the edges of the application are not visible against some backgrounds, and the application cannot be clearly distinguished from the background behind it.

In contrast, a Windows application's form border is usually (task manager)

 

What it should be

[imagodespira]

I have the same problem with the windows! Thanks that there are other people who feel the same. Also the square main window without shadow don´t looks well and does not separat itself from other software. Horrible

[Guenterm]

Hello,

maybe I don't understand the problem, but I have just played a little bit with the prefernces and for me it looks well. And you can also choose between Dunkel and Hell (Dark/Light)

[imagodespira]

This are all three titles from affinity. Over a day, i switch between multiple design software which are all in dark mode to focus the content. In my case Affinity Photo, Blender and for XML Editing Visual Studio Code. Beside Affinity ones, the Software uses the windows 11 rounded corners with the light gray border and shadow. It is not only a gimmick, it is to separate windows from each other to fokus on the active window. The active window should be visible and as you can see in the image it is not  The windows inside the app is also not great but i also can live with it as my focus is within the running app and i can separate it better from my content (often a dialog is over my image and it is ok for me)

 

EDIT: The main window looks great on MacOS. Here they use the syle guide and the OS windows. Why not on Windows????

[Shompinice]

On 11/10/2022 at 3:14 PM, Guenterm said:

Hello,

maybe I don't understand the problem, but I have just played a little bit with the prefernces and for me it looks well. And you can also choose between Dunkel and Hell (Dark/Light)

 

Not relevant, we're talking about window shadows

There is no shadows in Affinity Windows

[Chris B]

Hi all. The lack of shadows on dialogs/windows is a deliberate design choice for Windows. I asked this question years ago and that's what I was told. I do however sympathise with you.

[Shompinice]

2 hours ago, Chris B said:

Hi all. The lack of shadows on dialogs/windows is a deliberate design choice for Windows. I asked this question years ago and that's what I was told. I do however sympathise with you.

This is just a beautiful excuse for them to deliberately degrade the UI of the Windows version. Don't forget that the people here are designers and painters, and they are all colleagues. Don't lie!

[Mark Ingram]

16 minutes ago, Shompinice said:

This is just a beautiful excuse for them to deliberately degrade the UI of the Windows version. Don't forget that the people here are designers and painters, and they are all colleagues. Don't lie!

Please don’t accuse people of lying, especially when you have zero evidence to back up your claim. 

I’m the Windows Tech Lead, and we implemented a custom drawn window for the app, which means that the Windows OS does not automatically provide shadows for us. We could spend time implementing the missing shadows, or we could work on bug fixes and features instead. It all comes down to priorities - there is no conspiracy. 

[Shompinice]

16 hours ago, Mark Ingram said:

Please don’t accuse people of lying, especially when you have zero evidence to back up your claim. 

I’m the Windows Tech Lead, and we implemented a custom drawn window for the app, which means that the Windows OS does not automatically provide shadows for us. We could spend time implementing the missing shadows, or we could work on bug fixes and features instead. It all comes down to priorities - there is no conspiracy. 

So it's a technical choice not a design choice, it's a technical choice that has nothing to do with UX, visuals, consistency, and aesthetics.

I don't know why Windows applications are always keen to use fully customized Windows Forms. I somewhat think that this is time-consuming and labor-intensive and further leads to a sense of separation from the system.

I have this idea, try to use WPF native forms if you can (I'm not sure what UI framework you guys use), if you use WPF, this is a way to keep Windows Forms suitable for dark mode:

the color of title bar will follow the system settings

The method reference is
http://stackoverflow.com/questions/39261826/change-the-color-of-the-title-bar-caption-of-a-win32-application

 

#include <dwmapi.h>

BOOL USE_DARK_MODE = true;
BOOL SET_IMMERSIVE_DARK_MODE_SUCCESS = SUCCEEDED(DwmSetWindowAttribute(
    WINhWnd, DWMWINDOWATTRIBUTE::DWMWA_USE_IMMERSIVE_DARK_MODE,
    &USE_DARK_MODE, sizeof(USE_DARK_MODE)));

 

There's doc from Microsoft
Support Dark and Light themes in Win32 apps
https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/apply-windows-themes

At the same time, this API does not affect compatibility with older versions, and on Windows 7 or earlier versions of Windows, the API will not work and will not cause strange errors.

https://developer.blender.org/D14847



This way you will be able to keep the current black and white title bar for the Windows version to the greatest extent possible, while at the same time being in harmony with the rest of the form's interior.

 

[Mark Ingram]

The downside of that is we lose the height of the menu bar. As the title bar is “wasted” space, we can maximise vertical space by combining the menu bar and title bar. 

[imagodespira]

Visual Studio Code does it this way. It is for shure not a native window (as transparency is missing) but it works well. For me it is also a problem of visually separating windows. And the guidline in windows 11 brings us a drop shadow and the gray transparent line around windows to separate different windows. 

Today is saw a video from affinity photo where is described to make a floating tool window, in macos it also inline windows/panels have a shadow ... and it is better to see and separate the content from each other... on Windows... i don´t understand. 

And if it is by design and wanted, i really don´t understand it. And yes, bugfixing is more importand. But V2 has as much bugs and problems,  you never get it fixed all and 100 answers in Threads of UI problems should be not pointed as "made by design". 

 

[Shompinice]

21 hours ago, Mark Ingram said:

The downside of that is we lose the height of the menu bar. As the title bar is “wasted” space, we can maximise vertical space by combining the menu bar and title bar. 

Yes, this does sacrifice one menu bar height, but trust me, it will be a no-brainer!

This gives Affinity the same beautiful form edges on Windows as macOS.
This brings Affinity in harmony with Windows' native look and feel.
This allows the form to have the correct edge and drop shadow system, distinguishing between the front and rear of the window.
This makes Windows users realize that they are not outcasts, but are worthy of the same respect as macOS users - at least when it comes to UI/UX.

I think it's worth it.

[Shompinice]

1 minute ago, imagodespira said:

Visual Studio Code does it this way. It is for shure not a native window (as transparency is missing) but it works well. For me it is also a problem of visually separating windows. And the guidline in windows 11 brings us a drop shadow and the gray transparent line around windows to separate different windows. 

Today is saw a video from affinity photo where is described to make a floating tool window, in macos it also inline windows/panels have a shadow ... and it is better to see and separate the content from each other... on Windows... i don´t understand. 

And if it is by design and wanted, i really don´t understand it. And yes, bugfixing is more importand. But V2 has as much bugs and problems,  you never get it fixed all and 100 answers in Threads of UI problems should be not pointed as "made by design". 

 

 

As far as I know, it is very cumbersome to simulate the visual and behavior of Windows native form edges in custom windows. Affinity probably doesn't have enough energy to do this yet, so

http://stackoverflow.com/questions/39261826/change-the-color-of-the-title-bar-caption-of-a-win32-application

This method is more suitable. The only downside is that we'll have a separate menu bar, but I think I'd rather sacrifice the height of the drawing area than the margins that don't align with the system

[imagodespira]

A quick note to menu bar height: 

I assume that people with lower resolution and smaller montiors will use fullscreen, maybe here you lost some space. But almost all software does it, it is a windows design. For this people it does not matter if the window has a shadow or round corners.

But i also assume that many designers works with bigger screens and have enough space. Also for bigger resolutions and bigger screens the workflow is a bit different. There is much space also for reference images or note apps and more. Since i have my 32 inch 4k monitor i don´t use very often fullscreen because i use the space for other stuff and there, the current design version is not great. I also would have space for an empty window border, i work the whole day in blender and it works fine (i switch between blender, Affinity Photo TileEd Editor, OneNote, our game Engine, Explorer window and chat etc. ). Separating windows in a visual way if they are stacked it important for my work.
 

It seems the technical decision is a coder´s one. A designer would never decide this way  In my years of working with coders, it is a common problem... Usability is not the way they think... 

[deeds]

2 hours ago, Mark Ingram said:

We could spend time implementing the missing shadows, or we could work on bug fixes and features instead. It all comes down to priorities - there is no conspiracy. 

That's the definition of a conspiracy. 

 

"We" have decided something, that until now was unknown to all others, for (until now) reasons unknown to others, that the others generally consider to be harmful to their usage and is lesser than the standard operating environment experience.

 

That you rationalise that with time/cost justifications doesn't change those facts.

[Shompinice]

1 hour ago, imagodespira said:

A quick note to menu bar height: 

I assume that people with lower resolution and smaller montiors will use fullscreen, maybe here you lost some space. But almost all software does it, it is a windows design. For this people it does not matter if the window has a shadow or round corners.

But i also assume that many designers works with bigger screens and have enough space. Also for bigger resolutions and bigger screens the workflow is a bit different. There is much space also for reference images or note apps and more. Since i have my 32 inch 4k monitor i don´t use very often fullscreen because i use the space for other stuff and there, the current design version is not great. I also would have space for an empty window border, i work the whole day in blender and it works fine (i switch between blender, Affinity Photo TileEd Editor, OneNote, our game Engine, Explorer window and chat etc. ). Separating windows in a visual way if they are stacked it important for my work.
 

It seems the technical decision is a coder´s one. A designer would never decide this way  In my years of working with coders, it is a common problem... Usability is not the way they think... 

I am absolutely in favor of this.

I mean, if the engineer tells the designer that we have to choose between two options due to cost and time constraints

One is an independent title bar and menu bar, but it has a window edge system consistent with Windows-it has the same appearance and projection as the system window.

The second is to merge the menu bar into the title bar, but you will sacrifice the appearance of the window edges (if you treat the 2px stroke as visual) and drop shadow, it will have nothing to do with the appearance of windows and lack hierarchy

I think normal designers would choose the first option.

@ Mark Ingram

[deeds]

What we're talking about is a general benefit to all users of all Affinity apps on Windows, for all operations of those apps in all contexts, especially those in which they're busy and have multiple windows of multiple apps open and are doing more professional work.

 

In other words, this general benefit is of more benefit the more a user uses Affinity products within Windows environments.

That, alone, should be cause for significant consideration of this benefit.

 

Sufficient consideration to realise that this benefit can be easily faked with alpha transparent, 9 slice scaling of a simple drop shadow with an edge.

 

How long would that take a graphics design development engineer to code for the surrounds of windows with known, fixed corner radii? 

 

[Shompinice]

21 hours ago, Mark Ingram said:

The downside of that is we lose the height of the menu bar. As the title bar is “wasted” space, we can maximise vertical space by combining the menu bar and title bar. 

I mean, if the engineer tells the designer that we have to choose between two options due to cost and time constraints

One is an independent title bar and menu bar, but it has a window edge system consistent with Windows-it has the same appearance and projection as the system window.

The second is to merge the menu bar into the title bar, but you will sacrifice the appearance of the window edges (if you treat the 2px stroke as visual) and drop shadow, it will have nothing to do with the appearance of windows and lack hierarchy

I think normal designers would choose the first option.

 

 

[Old Bruce]

11 hours ago, Shompinice said:

I mean, if the engineer tells the designer that we have to choose between two options due to cost and time constraints

The Designer can tell the Engineer "this is how it should look" and the Engineer can tell the Designer "that will add a minimum of two years work."

The engineer and the designer get together and tell us, the software purchasers, "You can choose two of the following three: "Good, Cheap, and Fast""

[debraspicher]

17 hours ago, Chris B said:

Hi all. The lack of shadows on dialogs/windows is a deliberate design choice for Windows. I asked this question years ago and that's what I was told. I do however sympathise with you.

That made me chuckle. I don't know why.

[Shompinice]

1 hour ago, Old Bruce said:

The Designer can tell the Engineer "this is how it should look" and the Engineer can tell the Designer "that will add a minimum of two years work."

The engineer and the designer get together and tell us, the software purchasers, "You can choose two of the following three: "Good, Cheap, and Fast""

I don't know why Windows applications are always keen to use fully customized Windows Forms. I somewhat think that this is time-consuming and labor-intensive and further leads to a sense of separation from the system.

I have this idea, try to use WPF native forms if you can (I'm not sure what UI framework you guys use), if you use WPF, this is a way to keep Windows Forms suitable for dark mode:

the color of title bar will follow the system settings

It is a cheap ，quick and beautiful and  UX/UX friendly way in both design and development

 

Quote

#include <dwmapi.h>

BOOL USE_DARK_MODE = true;
BOOL SET_IMMERSIVE_DARK_MODE_SUCCESS = SUCCEEDED(DwmSetWindowAttribute(
    WINhWnd, DWMWINDOWATTRIBUTE::DWMWA_USE_IMMERSIVE_DARK_MODE,
    &USE_DARK_MODE, sizeof(USE_DARK_MODE)));

 

[debraspicher]

@Chris B Sorry, my humor is fairly dry (or so I'm told). I just get an image of the average developer person silently protesting furiously with post-it notes in their private journal while all the big wigs sit around making grand decisions to amazing effect. Entirely unrelated to actual reality, just some Dilbert-esk humor.

[hohoooj]

The sentence in the advertisement 'Hello! I'm Mac!'

[imagodespira]

Here an image of Firefox on Windows. It seems to be possible to follow the new Win11 Design guide with a menu (it is open source if you need the code ). To be fair it needs a bit more space around but it works and is better than we have in V2.

[Shompinice]

 it shouldn't be here at all, because the decision was wrong from the start, and the developers are always crazy about redrawing Windows Forms and turning it into a piece of shit, rather than Reluctance to use native Windows controls, even if it's cheaper, cleaner, and less work