You may think that, but everywhere I looked (outside winbox I mean) it is a button and shows the status by indicating what would happen when you click it. Go to Youtube, for example. While the video is playing it shows a pause icon and while it is paused it shows a play icon.
Because it is meant as a button, not as a status indicator. The word “Live” or “Paused” would be the status indicator.
Anyway, instead of that I would prefer when some windows would actually be made auto-refresh (BGP Sessions, Tools→Graphing)
Also, it seems that lately whenever a windows is displayed that contains data that is being refreshed, a lot of screen updating is happening even when nothing changes on the screen. When I have a remote desktop open which shows Winbox4, there is a lot of network traffic. That was not the case in the past.
There are so many variants and ways to improve it. No need to downvote, we're just brainstorming. Mikrotik has the final decision anyway. Only one thing is for sure: status quo is not optimal.
One thing the CLI has: on cli you can specify the interval. Not possible in Winbox. Is it known how often a “live” view refreshes? Or is it not a pull-principe and rather a “push” from ROS to Winbox when. Like a socket connection?
No idea, but apparently it is some mechanism that requires support in the mechanism that implements a table view, probably some “subscribe to changes” or similar. It is different in the new BGP, it seems.
Normal apps (if it's not a game) should redraw only when actual data change occurs. For dynamic windows (like 'Interfaces' or 'Torch') this data change should occur once per second by timer, for static windows (like 'IP addresses' list or 'DNS static' list) it should occur on item add/remove/change. WinBox 4 has some problems with that and redraws many times when it's not needed. And that's why it has a very bad performance. Though, I've already wrote a long post about it: 📣 WinBox 4 is here 📣 - #2993 by teslasystems
This tool is still partly unusable, guys. At least for me anyway.
A lot of commands aren’t executed from the terminal. Sometimes they work; sometimes they don’t.
It doesn’t matter whether I type those commands or paste them from the clipboard.
Under “Bridge / Ports” you sometimes see “UNKNOWN bridge” next to a port. You have to go to the first tab (“Bridge”), wait a couple of seconds, then go to “Ports.”
Importing a file from the old Winbox has never worked for me — not once.
I’d rather not talk about ergonomics. I feel like you’re trying to reinvent the wheel.
The old Winbox was pretty much perfect — except for the lack of customizable shortcuts and actions. I don’t think anything in the concept needed to be changed.
Nevertheless, I will not give up and am trying to use it. I am hoping that the same quality as the old Winbox will be carried over to version 4, and it will be great. Eventually
It’s not the first time it’s been pointed out, and it won’t be the last; the Live button is awful design. Not least because people can’t tell what it means at a glance. It’s not even clear that it’s a button. (and that goes for many other buttons, too) Why do I need to be told the data is live? Of course it’s live. Anything else would be useless. And for that matter, do all windows really need it?
There are two very simple solutions;
a) Checkbox labelled “Auto refresh”
b) Button labelled “Pause updates” with a clear active state, similar to the current Freeze button
Yeah, I don’t know if this is still a possibility in QT but in the past such screen libraries had a kind of double-buffer where for each cycle the programmer would write to the “virtual” screen what he wants to display, then calls some kind of “flush” routine that would compare the content of that virtual screen with what is now on the physical screen, and sends only the updated parts to the video driver.
But it seems that now the content is sent every time. E.g. I keep a “log” window fullsized as the background, and there is now continuous traffic even when nothing is being logged so nothing changes.
In winbox3 that wasn’t happening, and I think also not in earlier beta versions of winbox4, it is something that has recently changed.
Current solution of “window switcher” is wrong - activation button is in top bar of the window but after clicking it user is forced to navigate far away to left side of the window. I have few ideas how to solve this:
Combine current overlay view with dropdown menu from previous solution (selection in dropdown as it was pre-beta 42 or 41, but on top of current overlay switcher view - ditching that window list on left side of switcher view overlay)
Move window switcher button to left side so it would be near of window list of switcher overlay view.
Revert to previous solution (dropdown without switcher overlay view).
I would prefer option 1 or 3.
Here’s the illustration of the problem with current implementation.
Agree 100%: what used to be a simple switching action with very minimal mouse movement, is now a real trek to another part of the screen. Preview of the window is simply not needed: the full description/path of the window was enough to identify it.
Its great that there’s now a linux version, but it would be nice to have a single file that includes all of the dependencies, and that could be made portable easily (with the creation of the .config and .home along the program file).
For instance, right now on a clean Arch, it requests “libxcb-icccm.so.4” to start with…
Thanks infabo, yeah ok but i have other machines, some on other distros. Afaik, only AppImages (that include all dependencies) can be put on a usb stick on work right away anywhere, with its settings being loaded properly from with the same folder…
