It is impossible to fix all scaling issues in Windows. Windows is very bad at DPI scaling compared to other OS and Winbox is definitely not the only program that has small pixel level issues at these settings. Since Winbox is now made in QT, we will not be able to fix all issues, at this point, most of the reports are nitpicking. We will try to do some more work, but there is only so much we can do unti it's easier to just use a different resolution or switch your OS.

There are no any problems with DPI in Windows if you use its API correctly. Also, I've never seen a problem with randomly-sized and jumping icons, fonts, lines, etc. in any other Qt app, only in WinBox 4. Even WinBox 3 doesn't have such issues. Suggesting to switch resolution or OS is a total madness, sorry...

we have so far not been able to see such jumping around issues here. maybe there is something else at play, if you have those problems

I can reproduce them on every machine with >100% screen scaling.
Below is the video. Recorded under the Magnifier, every pixel is clearly visible. I'm just slowly changing the window height. You can see that the outer frame thickness is jumping between 1 and 2 pixels. And you can see that the icons height and fonts height are also jumping. OS scaling is 150%, resolution doesn't matter at all. WinBox scaling was 109% on this video.

Archive password: 123

It is impossible to fix all scaling issues in Windows. Windows is very bad at DPI scaling compared to other OS and Winbox is definitely not the only program that has small pixel level issues at these settings. Since Winbox is now made in QT, we will not be able to fix all issues, at this point, most of the reports are nitpicking. We will try to do some more work, but there is only so much we can do unti it's easier to just use a different resolution or switch your OS.

Well, I'm pretty sure it all depends on the app's scaling awareness. Qt 6 can scale just fine with the proper use off: QT_ENABLE_HIGHDPI_SCALING, QT_USE_PHYSICAL_DPI, QT_SCALE_FACTOR, QT_FONT_DPI, QT_AUTO_SCREEN_SCALE_FACTOR, AA_EnableHighDpiScaling, AA_UseHighDpiPixmaps, highDpiScaleFactorRoundingPolicy(), devicePixelRatio[F]() etc.

teslasystems, this is what I call nitpicking above. If you use the screen at normal resolution, you can't see it. This is why yourself had to make insane zoom for the video, just to show it.

Just curious, what is a "normal resolution" nowadays according to MT?

where mouse cursor is not 20% of the screen size? see the video yourself

teslasystems, this is what I call nitpicking above. If you use the screen at normal resolution, you can't see it. This is why yourself had to make insane zoom for the video, just to show it.

No, it very clearly visible without any zoom. Especially, an awful outer frame. And yes, I've made it under a big zoom just to SHOW it, and to make it clearly visible and understandable for everyone.

where mouse cursor is not 20% of the screen size? see the video yourself

Don't understand what are you talking about. This is just a small part of my screen that was enlarged using a Magnifier tool.

Can you add a button like "Adjust column width" to all windows where is a list of values? The function of that button will be to adjust all columns width, in current view window, to minimum width, where the whole values in the column are visible.

Please let me know if it is required to describe it in different wording :-)

Can you add a button like "Adjust column width" to all windows where is a list of values? The function of that button will be to adjust all columns width, in current view window, to minimum width, where the whole values in the column are visible.

Please let me know if it is required to describe it in different wording :-)

I was also thinking about it tonight, you are reading my thoughts :D
+1 for this idea.

there is an option to disable fractional scaling for winbox, you will then have to use winbox built-in zoom to make it bigger, but there will be no scaling issues due to Windows problems

teslasystems, this is what I call nitpicking above. If you use the screen at normal resolution, you can't see it. This is why yourself had to make insane zoom for the video, just to show it.

I did not mention it before because I did not want to be the one who is nitpicking. But I have to give teslasystems a +1 for pointing this out.

And I have to disagree to the "you cant see it at normal resolution" claim. I can see it very well. When resizing windows the fonts, icons, all UI elements are "jumping"/"moving" up and down. But because it only appears on resizing windows I did not mention it before. Window resizing is something one usually does not all the time. And as long the UI does not start "moving" by itself - I can live with this UI rendering issue. Maybe it gets fixed by some day by some qt update without any taken actions.

what is the opinion about solution suggested in my previous post

there is an option to disable fractional scaling for winbox, you will then have to use winbox built-in zoom to make it bigger, but there will be no scaling issues due to Windows problems

That sounds like a solution. I would appreciate having this option to observe how it behaves.

Is it possible to give one more update to WinBox 3.x, where WinBox 3 would convert the content of the multi-line text edits (like the script editor main textbox), and make sure that content with newline separators only consisting of "\n" are converted to Windows' "\r\n" sequence before populating the textbox with that content?

Until now my scripts are edited and saved with WinBox 3 under Windows, and I can see with the /export command that the scripts are stored with "\r\n". But yesterday I made the mistake of editing an existing script with WinBox 4 and it now only saves the newlines as "\n". Not only does this produce unnecessary changes in my version-controlled exports, but when opening the content back in WinBox 3, the newlines are no longer displayed properly.

Either WinBox 4 should still store the newlines as "\r\n", or WinBox 3 should be updated one more time to treat "\n" as newline.

Very happy with the recent update to the software, I've transitioned full time to the new one.

Well done.

*) User interface elements: Update MDI title bar style

Please FIRE your designers! One more crazy design decision. All tabs have the same color and this small line on the top of a tab is absolutely inconspicuous and barely visible. Return back as it was before.

That was definitely bad design decision.

I use the app in the "Light Mode" and those tabs look really bad and attract too much attention with their bold font and white background. The active tab cannot be easily identified because of the way it is highlighted. Please return back the old design of the window title bar. There is no feeling that tabs are part of the title bar anymore.

Please consider implementing automatic column resize on double click on a right column edge, like in MS Excel. That is very convenient. When I try to do this out of habit, the column size decreases by about 1 pixel for some reason...

There is also misalignment between vertical lines of a header and data rows if you resize the column. I use 125% scaling in Windows 11.

It is even worse in dark mode as window frame is colored in almost same blue as this line in top of active tab...

Please FIRE your designers! One more crazy design decision. All tabs have the same color and this small line on the top of a tab is absolutely inconspicuous and barely visible. Return back as it was before.

That was definitely bad design decision.

It was a problem before to know which tab you were on. And, it's actually too subtle in dark mode too. Using similar blue for tab indicator as dialogs outline does look kinda dumb. Personally I'd like the entire active tab label highlighted in some way, not a subtle line at top that blends in window outline.

This time more serious issue.
At least for me (both macOS and also Windows version) for devices that use VLAN offloading via switch chip features - all tabs are missing!

Example for CRS109:
In Windox 4 I go to Switch -> VLAN ... a new window appears, where I can only click New -> new window -> and specify VLAN ID and ports ... finally leading to an error when I click OK or Apply saying "Not supported for this switch"

In Winbox 3 connected to the same box:
Switch -> VLAN ... a new Window appears with total of 7 Tabs
(Tabs are: VLAN, Eg. VLAN Tag, In. VLAN Trans., Eg. VLAN Tran., 1:1 VLAN Switching, MAC Based VLAN, Protocol Based VLAN)

None of that is available in Winbox 4 (unless it got moved elsewhere). Features to work when I configure them via Terminal, so it is a GUI problem.

Cheers,
B.

CRS112 had same problem but it seems to be fixed in beta17

what is the opinion about solution suggested in my previous post

How does it look like? Is it some option that you will add to app settings? Or it's some kind of adding environment variable?
If first, let's try it and check how would it work. If second, I won't agree, because environment variables are global and affect other apps too.

-------------------------------------------------

Please consider implementing automatic column resize on double click on a right column edge, like in MS Excel. That is very convenient. When I try to do this out of habit, the column size decreases by about 1 pixel for some reason...

There is also misalignment between vertical lines of a header and data rows if you resize the column. I use 125% scaling in Windows 11.

Plus and plus.

There was already a suggestion to add some button to adjust ALL columns simultaneously, but having ability to adjust a single column by double-clicking is also often required.

And yes, there is a bug, when you press mouse button down on the edge of a column without moving it, its width decreases. In my case (150% scaling) it's also random: sometimes by 1px, sometimes by 2px. On 100% scaling it's always decreased by 1px, so it's not a scaling issue.

Regarding misalignment, I have this issue too on 150%. And this also randomly changes when you resize some column.
My suggestion is on the screenshot below. I think, everyone will agree that a header separator should be thicker than a grid line to have a good appearance. So, I suggest to increase separator thickness and align its center with a grid line. And please make a normal contrast color for separators as on my screenshot, currently they are almost invisible!
.

It was a problem before to know which tab you were on.

Why do you say it was a problem before? In previous beta it was ok I think. I would agree that it was probably not super-contrast, but it was visible which tab you are currently on. But now...

Can the quick zoom and magnify shortcuts in macOS be changed? I'm accustomed to using them with the trackpad on Command, and it's easy to accidentally touch them.

Me personally, I'd rather MT focus on the under the hood issues before progressing UI issues. Not saying UI issues aren't as important, but many of us are still waiting for issues like LTE signal graphs to be added, among other things - stuff that's been waiting to be sorted since day one. Most of us can use v4 in some capacity with the current UI. Time to focus on the deeper issues and return to UI issues later.

teslasystems winbox already has zoom controls. It means you will have to use them to make winbox bigger or smaller. Not Windows zoom scaling

teslasystems winbox already has zoom controls. It means you will have to use them to make winbox bigger or smaller. Not Windows zoom scaling

Are you suggesting to disable OS scaling and blow-out my eyes because everything will be very small?

No. I already wrote this above. We can disable scaling FOR WINBOX ONLY. You can use Windows zoom scaling for all the other apps. But winbox will be small. You wil then use Winbox zoom buttons to make it big. It will have no glitches then.

No. I already wrote this above. We can disable scaling FOR WINBOX ONLY. You can use Windows zoom scaling for all the other apps. But winbox will be small. You wil then use Winbox zoom buttons to make it big. It will have no glitches then.

I probably misunderstood. So, you can disable it in the next version for example, right? If so, ok, let's test it.

Can the quick zoom and magnify shortcuts in macOS be changed? I'm accustomed to using them with the trackpad on Command, and it's easy to accidentally touch them.

I actually run into this one myself on Mac a few times*... It's actually pretty "sluggish at zooming" when you it too. It really should be "pinch-to-zoom" on MacOS.

My bigger annoyance on Mac and "zooming" is that "Cmd +" / "Cmd –" for zooming control don't work – which is pretty standard on Mac. Since Cmd +/- is how'd I'd want to fix these "accidental zooms"*. In fact, most of my annoyances trend on keyboard shortcuts...


* and, yes, does seem to happen "accidentally"  – in fact, enough that originally I thought it a workspace that causes these "random" zooming changes.

Same here, "Cmd +/-" for zooming on Macs is pure muscle memory these days.

Still no color-change for changed values...
Winbox4 is useless without this feature!



This is a edit, how I wish changed values would show up:

At this moment the comment font is bold, the item name font (in the list) is not-bold (for example /interface print).

Can be the design changed to: comment font not-bold and item name font bold?

In case of longer list of items my focus is then more on text in bold in compare to text not in bold. I'm not using inline comments.

Thank you

Still no color-change for changed values...
Winbox4 is useless without this feature!
...

+1

For me it is not useless, but the described feature will make it more comfortable for me :-)

In System > Scripts, winbox4 will not save a script larger than ~64KB, which may be reasonable. But the problem is the edit box will ALLOWED to enter >64KB – without any indicator your beyond 64KB in the edit control. The really nasty effect comes when you try to Apply or OK a script source with >64KB in winbox4 edit control... See that will NOT provide you ANY error message/popup... Instead, winbox4 (or like the connected router) silently restore the previously applied "source=" field to winbox4. Without any visual or other clues.

If you had made some change that pushed you >64KB... those would have been lost & not had ANY clue since dialog/error popup told you after the "OK" (or Apply). It was harmless in my case, since I was testing this, but boy that be a really good way to either lose code, since easy to think you saved since there is no error/popup...

Expected: System>Script>(Edit Dialog), should NOT let you hit OK or Apply if greater than the script size limit... which avoid the issue of a "false OK".
And, edit control's color changed to RED or something too when beyond limit – there are not enough colors used in winbox4 to indicate status/problems IMO...

Still no color-change for changed values...

+1000

Color change is one thing, it was there in Winbox3 already. But an improvement would be to have some kind of diff/change view collecting all the pending changes so one knows what to expect when "OK" button is clicked.

And: only values that are actually modified should be set when hitting OK. Those are the blue-colored fields in winbox3.
That should also mean that a value that is inherited from a template (and shown in the edit dialog) is not stored when something else in the dialog is changed.
Even better would be when inherited values would also be shown in a different color.

We can disable scaling FOR WINBOX ONLY. You can use Windows zoom scaling for all the other apps. But winbox will be small. You wil then use Winbox zoom buttons to make it big. It will have no glitches then.

When disabling the Windows scaling for Winbox only, may be also implicitly apply the system scale factor behind the scene?

When disabling the Windows scaling for Winbox only, may be also implicitly apply the system scale factor behind the scene?

Absolutely right. But it should be applied only on first app launch.
Or may be even better to use both system and user zoom to calculate it. I.e.: <Final Zoom> = <OS zoom> * <User zoom in WinBox>

Could you please reimplement "Open in new winbox"?

Maybe even as a right-click or shift-click on "Connect" and "Connect to RoMON"?

Not being able to open multiple Ping windows at once via "New Windows" button which is missing in Winbox 4 is a huge huge issue for me :(

Please revert changes to the tabs in window titles. Those new tabs are burning my eyes. Instead of focusing on the data in tables I stare at that bold header.

Beta 16:
Beta 17:

I’m a big fan of the new Winbox, but I’m finding it a bit tricky to manage my hundreds of routers in Winbox 4. Could you please add a way to import saved connections from Winbox 3 to Winbox 4? That would be superb!

Please fix the appearance of RadioButton interface elements and make a normal offset from their caption. Instead of being closer to its own selector, a caption is closer to the neighbor's selector. And it's very confusing. See the screenshot. First time I looked at it, I thought that 'none' was selected. But then realized that RSTP is selected. Who are these crazy designers...
.

Please consider implementing automatic column resize on double click on a right column edge, like in MS Excel. That is very convenient. When I try to do this out of habit, the column size decreases by about 1 pixel for some reason...

+1 doubleclick on clumn edge to resize column width acording to width of it's text content


File dialog when trying to save configuration via "File > Download", you have to select parent folder where you want to save your file. It would be more intuitive to use actual directory where user is at the moment as the directory where to save, not in to the directory that is highlighted by the user IMHO.


Not a big fan of current "subtle line on top" highligting of the selected section within current window. I do not mind the line on top, but i would preffer other sections to have different background color. Maybe a combination of Beta16 and Beta17 look as @mszru mentioned. Please see attached pic.

Winbox4 is getting there and i see it's potential (especialy in the cross-platform as I am using Linux) keep up the good work.
Thank you!

Current solution has better distinction in dark mode, but in background window instead of focused window - because this blue line on top of a tab has almost same colour as frame of foreground window. In light mode it is equally bad for foreground and background windows. Better way would be to use bold font only for active tab and/or have less contrast on inactive tabs.

I was never using dark mode, just looked how it was in beta16 and... No words. Active tab was very hard to see. Of course, having this tiny line is better than not having anything at all. I think it's better to return to previous design, and make a normal distinguishable active tab color for dark mode.

But overall, better solution is to hire an adequate designer who will be able to create a good contrast interface where every element will be clearly visible. Instead of this stupid design, where separators and frames around column headers are almost invisible, scrollbars are almost invisible (and don't have arrows btw), frames of inactive fields are invisible at all. And now one more "genius" decision with tabs.

The app is pixelated on Sway (Fedora 41) with 200% scaling.

You may need to open attached picture in separate tab to see it.

@TenaciousD
this is how it looks at my system as well. Since first public Winbox 4 beta. I even mentioned this early in the topic, but all was said was to wipe off dust off my screen. Glad to see someone else reporting this with evidence screenshot. I think this needs platform specific Qt rendering settings tweaks. Especially this is both Linux platform. And on MacOS it looks sharp as your terminal window font.

And we are told that "Windows is very bad at DPI scaling compared to other OS"... At least, there is no such "pixeling" problem.

BTW, I don't see any scaling problems on Windows with 200% scale. Assume, it's because this scale is a multiple of 100.

And we are told that "Windows is very bad at DPI scaling compared to other OS"... At least, there is no such "pixeling" problem.

BTW, I don't see any scaling problems on Windows with 200% scale. Assume, it's because this scale is a multiple of 100.

I guess TenaciousD is running a wayland session. The problem is that Winbox comes without wayland backend, thus uses X11 to render. This extra layer causes issue on scaling.

Mikrotik, please build Winbox with the wayland platform plugin enabled!

I still use x.org - not wayland. So it is maybe not related to wayland especially. Rather a x.org thing when Winbox uses this x.org compatibility layer.

I still use x.org - not wayland. So it is maybe not related to wayland especially. Rather a x.org thing when Winbox uses this x.org compatibility layer.

Oh, X11 scaling is scary... :-) Is this on i3wm by the way?

My problem is different. In fact, i KNOW that sway and some other less popular window managers CANNOT properly scale X11 applications. Maybe I should state my problem as "WinBox does not support native wayland mode", but I thought it might be rude to jump one step from my IMMEDIATE issue, which is "Pixelated interface on my 4k display with 200% scaling when running under swaywm" :-)

And we are told that "Windows is very bad at DPI scaling compared to other OS"... At least, there is no such "pixeling" problem.

BTW, I don't see any scaling problems on Windows with 200% scale. Assume, it's because this scale is a multiple of 100.

Well, it is. Not our fault.
Tried different zooms here (from 84% up to 132%).
Didn't see any scaling issue now, didn't see before either - using at 84% zoom for some time already.

OpenSuse Leap 15.6
RTX3060
X11 / KDE
NVidia drivers 570.86.16
Monitors are 2 Dell P2421D, running native resolution (2560x1440) on each of them.

Tried different zooms here (from 84% up to 132%).
Didn't see any scaling issue now, didn't see before either - using at 84% zoom for some time already.

Are you talking about WinBox zoom or OS zoom?

Are you talking about WinBox zoom or OS zoom?

Winbox Zoom. Why would I use OS Zoom? If I want to change the size of my screen elements, I just change font and icon size. Much better this way.

Winbox Zoom. Why would I use OS Zoom? If I want to change the size of my screen elements, I just change font and icon size. Much better this way.

Then you won't see any of these issues. They only appear with OS zoom.

Then you won't see any of these issues. They only appear with OS zoom.

And do You need it? I mean, there is Winbox Zoom, and all OS screen elements should be at an adequate size. No? Here they are scaled based on the monitor DPI.

Then you won't see any of these issues. They only appear with OS zoom.

And do You need it? I mean, there is Winbox Zoom, and all OS screen elements should be at an adequate size. No? Here they are scaled based on the monitor DPI.

Seems you were never using HiDPI screens. Everyone, who uses such screen, has OS scale more than 100% and it depends on DPI. Scale (%) = DPI / 96 * 100.

A high DPI screen should not matter in this context. For the simple reason the OS knows the monitor DPI and adjusts (should adjust) screen elements accordingly. As per "high DPI monitor", we will need some definition here: how much high would be "high DPI"? I hate when the marketing team runs amok, and starts using meaningless terms. Mine has 122 DPI, for what is worth.

I still use x.org - not wayland. So it is maybe not related to wayland especially. Rather a x.org thing when Winbox uses this x.org compatibility layer.

Oh, X11 scaling is scary... :-) Is this on i3wm by the way?

Yes, i3wm.

There are 2 types of apps: DPI-aware and DPI-unaware, i.e. they either support scaling or don't support scaling.
If an app supports scaling, it adjusts interface by itself based on OS scale value. OS doesn't participate in this process.
If an app doesn't support scaling, OS is just enlarging its window and everything becomes blurry.

So, normally, OS shouldn't adjust anything, it only occurs in shitty or old apps that don't support scaling.

DPI is high, when it becomes hard to use it with 100% scale. But this term doesn't mean anything in our context. The problem is scaling. And scaling is just a consequence of high pixel density.

Yeah, and if MT is using their own Layout Manager, scaling might not work as well if DPI awareness isn't handled properly. The built-in Layout Manager scales just fine on high-resolution screens. Try the example app "Thermostat".

Just for testing: I did the OS scale test. Several values, between 100% and 150%. Did not see anything weird.

But there is ONE thing that may help: KDE only allows me to do increments of 6,25% - just in order to avoid scaling problems. I imagine this increment will vary with DPI and resolution. Makes sense: there is no way to show fractions of a single pixel. Well, not in a good way, one could do interpolation but...

But, yes. No problems for me - using either/both OS scaling and/or WinBox scaling.

Oh, X11 scaling is scary... :-) Is this on i3wm by the way?

Yes, i3wm.

Winbox must be a disappointment to i3vm users... always organizing these overlapping winbox windows "manually" seems a PITA ;)

MacOS Sequoia has nifty tiling options, so I feel the pain.

+1 for some "Tile" options to organize the main workspace

And, I'm still on the theme taking more UI cues from Windows 3.1, which had "tile" in right menu"

To normis

To test a behavior with disabled OS scaling, I've temporary set it to 100% in my OS and used internal WinBox zoom only. The problem is that internal WinBox zoom doesn't work properly by itself, because some interface elements are not affected by WinBox zoom value, they have the same size on all zoom values.

Until these issues are not addressed, disabling OS scaling will lead to bad result on non-standard DPI.

----------------------------------------------------------------------------------------------------------------------

Here is what I was able to find:

1. Internal windows don't change their size and position, when your change zoom value. In scenarios, when you work locally on one DPI and then connect remotely from another PC that has different DPI, it will be a huge headache. You will have to adjust all windows each time your DPI changes. Same, if you drag the app to second monitor with different DPI value.
When you increase zoom from 100% to 250% it looks like this:
. ----------------------------------------------------------------------------------------------------------------------

2. Some internal windows don't change their internal <Minimal Width> value together with zoom. For example, in interface editor window (dbl-click on any interface in Interfaces window) this value adjusts together with zoom, you may see that minimal width limit is higher on 250% zoom than on 100% zoom. But in Address List window, minimal width is same on all zoom values.

----------------------------------------------------------------------------------------------------------------------

3. Because of issue (2) and because minimal width is initially incorrect in some windows, you may see that buttons are painted outside of a window. The minimal width should be limited so, that all these buttons are fully visible inside.
. ----------------------------------------------------------------------------------------------------------------------

4. Status indicators, collapse/expand arrows don't change ther size. Buttons and title field don't change their width. BTW, we are still waiting for fixing scrollbars overlapped with content, on high WinBox zoom this issue is much more noticable.
. ----------------------------------------------------------------------------------------------------------------------

5. Lines don't change their thickness. I mean all lines (internal windows frames, edit fields frames, internal separator lines, grid lines, etc.). You have 1px lines on 100% and you have the same 1px lines on 250%. So, the higher DPI you have, the thinner these lines will look. They should change their thickness together with zoom. If a scaling factor lies in a middle of two integers (1.5, 2.5, 3.5 etc.), I would suggest to round it up to scale the lines. I.e. on 150% you should have 2px lines, on 250% - 3px, on 350% - 4px, etc.

----------------------------------------------------------------------------------------------------------------------

6. Workspace ComboBox also doesn't change its width. Looks awfully on 250% scale.
. ----------------------------------------------------------------------------------------------------------------------

7. If you open some window with filter and then increase zoom, the fields don't change their width. All values in these fields become clipped, they don't fit in the fields. But if you close and reopen the window, they are adjusted a little bit, but not always and values may still not fit.
. ----------------------------------------------------------------------------------------------------------------------

8. Graphs don't change their dismensions either. As a result, you will see this mess with zoom > ~160%.
. ----------------------------------------------------------------------------------------------------------------------

9. Columns selector drop down list has very small height. On 250% zoom it fits only 6 items. But even on 100% zoom it fits only about 10 items. It's very inconvenient to scroll up and down to find what you need. Please make items more compact vertically and increase the height of this list. Ideally, it should be limited only by main WinBox window height.
. ----------------------------------------------------------------------------------------------------------------------

10. Regarding zoom value itself. I see that the maximum value is 250%. For me personally it doesn't matter, but assume that there are screens with higher values, so please consider increasing this limit. Additionally, it has bad position in settings window, because each time you click '+' or '-' button, it runs away from the cursor. Only Ctrl+Scroll helps.

File drag and drop not working, when I copy file to my PC not working. When I download then working. Is that only problem for me

missing... 😢

Is the "yes" option intentionally placed outside the line?

File drag and drop not working, when I copy file to my PC not working. When I download then working. Is that only problem for me

I was reporting about this issue here and to support, also saw it in the list of known issues. Still waiting for a fix.