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.

hire an adequate designer

Requirement: The designer has to be over 40-45 years old and not some kid that the only UI that has ever known is their moms' iphone.

And also hire network engineers that use Winbox everyday to do actual work to test the hell out of it. It's obvious that whoever gave the green light to move forward with Winbox's 4 design, they are not using it professionally, ie: spend all day on it solving problems and seeing all the regressions the new design brought.

Make the before touchscreens/smartphones/hdpi UI/UX great again!

hire an adequate designer

Requirement: The designer has to be over 40-45 years old and not some kid that the only UI that has ever known is their moms' iphone.

... do not forget glasses

:lol: :D :lol: ... do not forget glasses :)

Yes, it's a good requirement. I'm serious. A person with poor sight will definitely make a good contrast interface instead of these barely visible elements and lines that we currently have.

Yeap, poor eye-sight is a must.

Found a bug accidentally. On the login page, if 'RoMON Neighbors' item is inactive, you can't choose it by mouse, but you can choose it by keyboard arrows or by pressing 'End' when this ComboBox is active. This leads to error and crash.
.

While I like the feedback in "green bubble" (or red too) status that appear after a commit ("OK"/"Apply") ... they could use some attention in usability. I guess it's related to the "dirty fields" problem (i.e. two updates to same field, before winbox knows its changed) – which is sticky problem.

But the "green bubbles" acerbate the problem, since they popup just by pressing OK. I find this distracting since I just hit "OK", and expect that work & only see a notification if it failed. For example, if your perhaps OCD, you might click the "Apply" button a few times, just to make sure – even if unnecessary... that causes the "green bubbles" to stack in corner. Again in this OCD user case, the stacked notification only bring attention to something that just worked.

My idea is that "green bubbles" after OK/Apply, should only display if a current value – from winbox POV – changed. That is, notification has some client-side state... so it only popup if it read back newly changed value at least once after an update. The currently logic to always show it on every update is too much — but some "smarter logic/queue" in the notification might be a good stop-gap to problem that "changed fields" are NOT indicated well (colors!).

i.e. a "green bubble" tell me I actually updated something — and help with my general "marking dirty fields in dialog" complaints. The absence of the "red bubble" and remaining in same dialog already would tell you didn't work, so the OK notification is redundant today.

One more issue to my list of 60+ other issues...

The problem here is not just a green bubble, the problem is that v4 is actually doing the change, when there were no any changes. Just go to the log and you will see a new change each time you click 'Apply', it doesn't care that you were not actually changing anything.
WinBox 3 is smarter and doesn't do anything if you just click 'Apply' multiple times without actual changes.

We went from something that worked fine on windows and emulated well on others, most of the time,
to something that doesn't work as well as the old one anywhere...

Unless I misunderstood everything related to most programs I work with...

Apply = commit changes but keep window open
OK = commit changes and close window

No ?

Depends which operations are performed by these actions, some optimizes such actions and do not perform changes if nothing is changed on UI.

Unless I misunderstood everything related to most programs I work with...

Apply = commit changes but keep window open
OK = commit changes and close window

No ?

Yes, that's right. But commit should be done only if there are actual changes. And v4 misbehaves with that.

We went from something that worked fine on windows and emulated well on others, most of the time, to something that doesn't work as well as the old one anywhere...

Yeah, I feel the same way. I really hope MT won't retire v3 before everything’s up to par.

Yeah, I feel the same way. I really hope MT won't retire v3 before everything’s up to par.

v3 is already abandoned. They've said many times that there won't be any changes. Only security fixes. I afraid that some day, after updating to new RouterOS, it will show "Protocol is not supported"...
And I also feel bad with this stupid design in v4. For me it's like a toy currently, I can't use it, because it's simply unusable. The interface is absolutely unprofessional and I'm sure it was done by some iPhone lover...

We went from something that worked fine on windows and emulated well on others, most of the time, to something that doesn't work as well as the old one anywhere...

Yeah, I feel the same way. I really hope MT won't retire v3 before everything’s up to par.

Well, the "saving everything"/"dirty fields" problem and why winbox3 isn't going away are related... It's the L5 protocol (8291/winbox) used. The ISO L6 (i.e. winbox app) doesn't care, or at least it shouldn't....

So, unless they want break every API/REST/TR069/... integration out there, the core attribute scheme cannot change... so winbox3 (at least with the existing dialogs) should work until they want to break every other client app out there... Now where a future protocol and future device-mode/etc defaults to disabling winbox protocol, different question.

But 8991/winbox is stillmessage-based, without any "locks" or "transactions". Issue is the "two writes" at nearly the same time, and model is "last write always wins". But since message are not instantaneous... you can get into a state where YOUR winbox think nothing changed from it's last refresh ... so it may decide not to send update. BUT IF, in small time between when YOUR winbox got the values shown to you & you hit OK/Apply, possible some OTHER winbox/API changes the same value. So if it you "update everything" it keeps WYSIWYG for the entire dialog - without any potential for confusion of what specific attributes got updated. It's a decision, but Mikrotik is kinda in bind since they cannot break winbox protocol...

Anyway, why I suggested that notifications at least represent this "client-side state of attributes". Since it can take the ~0.01% chance an update happened that it missed. And it's same with numerous requests for some COLORabels of "changed"/dirty fields. Which could be based on client-side view of the attributes....

On the colors....perhaps 2 colors for fields: one for ones you changed & another color for OTHER changes from elsewhere since the dialog was opened. Again, showing some colors doesn't effect protocol things, if that was wrong because of "two writers" problems, like the notifications, it more visual clue. Both are regardless of how winbox actually config write decisions – which is different. This VISUALLY show the "multiple writers" in the dialog – or at least potentially – to then NOT make your changes....

I'd give Winbox4 a B+ for college effort. Sticking with Winbox3 for near future. @Normis & Team. Look at Palo or other firewall vendors web interface for "guidance". Or simply hire better developers.

I feel Winbox4 could use some Palo design queues.

Why all this effort on winbox4 when you could instead just wrap everything within Web management? The web management can run inside a container on RouterOS...... We simply download new .npk file or container file for web management updates/changes. Then no worries about publishing or making operating system agnostic... .THINK.

Anyone else think or agree that web based management would be easier for them to design and build....?

Yeah, I feel the same way. I really hope MT won't retire v3 before everything’s up to par.

v3 is already abandoned. They've said many times that there won't be any changes. Only security fixes. I afraid that some day, after updating to new RouterOS, it will show "Protocol is not supported"...
And I also feel bad with this stupid design in v4. For me it's like a toy currently, I can't use it, because it's simply unusable. The interface is absolutely unprofessional and I'm sure it was done by some iPhone lover...

Now you feel what I am regarding "ROSE". There needs to be better leadership and direction. This all could be done via a new web management implementation.

If MikroTik would of finalized their container support, why dont they "eat their own dog food" and build the new management plane to run within a container or .npk file.

Yes, I realize lower power devices such as CAPS cannot run a container. But the AP's can be configured with WebFig or a basic web management function and then the focus be on making the AP's connect to a CAPsMAN controller.....

v3 is already abandoned. They've said many times that there won't be any changes. Only security fixes. I afraid that some day, after updating to new RouterOS, it will show "Protocol is not supported"... And I also feel bad with this stupid design in v4. For me it's like a toy currently, I can't use it, because it's simply unusable. The interface is absolutely unprofessional and I'm sure it was done by some iPhone lover...

It was kind of fun at first to run native macOS and all, but for production, we still use v3. If MT doesn’t manage to get a usable desktop tool in place before v3 stops working, one option might be to switch to WebFig.

On another note, I really hope MT considers bringing in some external experts for a while to set a solid baseline for UI/UX and help the developers sort out the scaling issues.

Please be aware that your macOS version of WinBox v4.0beta17 has an Info.plist file that does not accurately reflect its version.

That is, currently in the file found at WinBox.app/Contents/Info.plist, you will find the lines:

...
<key>CFBundleVersion</key>
<string>0.1</string>
<key>CFBundleShortVersionString</key>
<string>0.1</string>
...

This indicates that the program is at v0.1, when, in fact, it should be showing v4.0beta17.

It is a minor point, but does impact both the ability of macOS users to easily discern what version of WinBox they have installed using Finder (where you RIGHT-click on a file and choose Properties, for example) as well as impacting any tools that might look for such version information such as any MDM offerings. I say this as I was looking to add WinBox to my Munki setup, which relies on AutoPkg recipes. But as it stands, I suspect that there is no way for AutoPkg to be able to detect a version change, as I'll go out on a limb and suspect this has been set to 0.1 for some time now.

Anyway, thought you all should know.

That is, currently in the file found at WinBox.app/Contents/Info.plist, you will find the lines:
...
<key>CFBundleVersion</key>
<string>0.1</string>
...

Well, it matches the "my.example.com" as bundle id string, in same Info.plist ... although that's vendor is not visible in Finder.

But, actually, there is not a way in winbox itself to know the version.... It's not anywhere, unless I'm missing something. It used to clutter the title bar if I recall, so it not being there is GOOD... But it should be somewhere... The settings should perhaps show the version at bottom? Or even some story like "Get Info" in Finder working...

Anyone else think or agree that web based management would be easier for them to design and build....?

There are pros and cons, but in general WinBox is better than a WebUI.

- WinBox is very lightweight on the host routers CPU.
- WinBox is much faster to navigate than any WebUI.
- WinBox updates very quickly
- WinBox allows Mikrotik to efficiently add custom features that would have large CPU overhead on the router if it were done with a WebUI.
- WinBox also allows for complete flexibility in regard to layout.

This is from someone who has spent the last 22 years using the WebUI's of major firewall vendors.

PAN-OS is a customized CentOS install, and each device has a large amount of local storage. Even with this, PAN-OS is very slow to navigate, configure and commit changes on. Mikrotik devices range from small routers designed for SOHO deployment right up to routers used in ISP's, RouterOS and its configuration system e.g. WinBox need to be high performance on all of these, I cant see that being the case with a modern WebUI like PAN-OS has (and it could be argued that PAN-OS is actually old and clunky by modern standards)

In Winbox3 there is option to filter by ports in [ /ip/firewall/connections ]
there were such filters: Src. Address/Port, Dst. Address/Port, Reply Src. Address/Port, Reply Dst. Address/Port

In the new version of Winbox4 beta they are not there, how can I filter connections by ports now?

Dear, @Normis

In winbox 3.x version, the menu is horizontal (very convenient), then in winbox 4 version it is vertical (very inconvenient to use), each time you click the mouse, you have to scroll up and down many times to see it, while in winbox 3.x, you only need to click the mouse to view it immediately or at most one scroll time.

I have managed to make WinBox 4 use Segoe UI on Windows. Everything is much sharper on my 96DPI screen and I no longer need to use the 84% zoom in WinBox. At 100% texts look reasonably small and very usable.

If you want try, just use the Font Substitution feature of Windows. Open Regedit, go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes and Add four string entries for:

* Manrope MD
* Manrope MD Medium
* Manrope MD SemiBold
* Manrope MD ExtraBold

with the replacement fonts of your choice:


I am using Segoe UI and Segoe UI Variable Display Semibold as replacement 😊. If you don't like the Terminal Font, it's JetBrains Mono.

One more complain about interface usability. It's related to layout in editing windows mostly.

Just look at this screenshot at the end and compare v4 and v3.

• First thing, when I see this mess with [+] and [-] buttons all around, I'm freezing like an old PC from 90's while thinking where I am, and what should I do to change something; [+] button is located on the left, but [-] appears on the other side... You may just accidentally click wrong [+] and you'll have to move a cursor to another side to click [-]. Even WebFig is little better in this.
  In v3 there is not such problem, all buttons have an adequate layout and clearly speak for themselves.
• Second, where are indents for groups like 'Limit' or 'Time' ? Group name and values are on the same level without any indents for values. Making them just bold doesn't help at all. Very hard to percept. Also compare with absolutely clear view in v3.
• Third, this 'Enabled' checkbox... Well, it could be helpful sometimes, but return Enable / Disable buttons back! In WinBox 3, while testing some rules or any other things, I can just click a button in the window to turn it on or off. In v4 I should first check / uncheck this checkbox and then click 'Apply' button that is located on the opposite edge of a window. It's just ... I won't say.
• Comments. Return previous editing mechanism with Ctrl+M shortcut! No need to do anything with current mechanism, just add a quick editor for comments as it was in v3, while saving both ways.
• And finally, move 'New WinBox' button to its legal place and return 'Exit' button also. It's unhandy, when this button is located somewhere on the top.

This interface is a disaster. And all these complains are not about tastes or personal preferences, they are about convenience and usability.
.

In winbox 3.x version, the menu is horizontal (very convenient), then in winbox 4 version it is vertical (very inconvenient to use)

What menu are you talking about?

v4 Menu on the right, v3 Tabs on top...

v3 is more clear.
For example is clear separation between connection limits and other subsection, on v4 is all grouped together.

Oh, it's what they call "anchors" now. I doubt that they will return to tabs, but I would agree that having them on top is much more convenient.

@teslasystems you have a good sense for usability. Mikrotik user interface designers should look at your side-by-side view and learn from these mistakes.

@teslasystems you have a good sense for usability. Mikrotik user interface designers should look at your side-by-side view and learn from these mistakes.

All they have to do, is copy winbox3 UI menu for menu, tab for tab, window for window.
They already had perfection when in comes to productivity and they've completely ruined it just for "better" looks.

Thanks for support :)
Sometimes I think I'm alone with that, because I don't see these complains very often. May be this interface is ok for an average home user (though, for home user web interface is enough), but when you spend a whole day in WinBox sometimes, it's unusable.

@teslasystems Probably because there are many like me who when they see this new little toy for fun of someone turn away and hope that the v3 lasts as long as possible...

The transition from v6 to v7 didn't teach him anything...

First you do something identical to v3, with the same features and aspect, for all platoforms, then maybe you improve it.

It almost seems like the incentive to work on something comes out only if it's something new against those who work on it.

I feel the same, but this fear

I afraid that some day, after updating to new RouterOS, it will show "Protocol is not supported"...

keeps me to test, find the issues and report. More similar reports - more chances to be heard.

v4 Menu on the right, v3 Tabs on top...
v3 is more clear.

Like all others softwares.... tabs are always on the top.

I have managed to make WinBox 4 use Segoe UI on Windows. Everything is much sharper on my 96DPI screen and I no longer need to use the 84% zoom in WinBox. At 100% texts look reasonably small and very usable.

If you want try, just use the Font Substitution feature of Windows. Open Regedit, go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes and Add four string entries for:

* Manrope MD
* Manrope MD Medium
* Manrope MD SemiBold
* Manrope MD ExtraBold

with the replacement fonts of your choice:


winbox4-byebye-manrop.png


I am using Segoe UI and Segoe UI Variable Display Semibold as replacement 😊. If you don't like the Terminal Font, it's JetBrains Mono.

Great work. I prefer this font and look over what MikroTik has done with the decision to create their own. They need to see this.

Still no way to have two sub-windows opened with the filter and the raw table... still need to switch between tabs.
I've just discover the option to hide tabs... what is the interest ?

I've just discover the option to hide tabs... what is the interest ?

This is one of a few things I like in v4. For example, I'm using only 6-7 tabs in 'Interfaces' window and simply hide all others.

I started with RouterOS v6 Webfig then CLI and never caught the Winbox or Dude diseases.
If cancelling or postponing Winbox accelerates RouterOS v7 development then I vote so.

Still no colour change for edited fields (4.beta17).
Still useless software!!

Is the use of keychains being considered in Winbox 4?

Does Winbox 3 or 4 has any kind of integration with Vault or Password Manager tool?

I mean tools like:

• Lastpass
• 1Password
• Bitwarden

• Hashicorp Vault
• Infisical
• Configu