fixed rule window size

[tessus]

I've just upgraded to 26.1.x (from 25.7) and the upgrade was flawless. Thanks.

Then I checked my DNAT rules (formerly known as port forwarding) and I was shocked that rules were missing. Turns out that they were not missing, but the rules are presented in a fixed sized window (I don't know the term, maybe it's called a container or div - I am not a GUI person) and I had to scroll within that little window to see all my rules.

Previously the window (conainer or whatever) adjusted its size depending on the number of entries you wanted to see (50, 100, ..., All). Now you have 2 separate scroll areas, which is extremly inconvenient. See screenshot.

Is this a bug or a deliberate design decision? If it is the latter, please reconsider and also please explain how this is supposed to be better than it was before.

[nero355]

The KEA DHCP Server webGUI parts have something similar and I am not sure what to think of it yet either...

At least it's a bit better than the ISC DHCP Server webGUI was were you had to scroll over the Settings to get to the Static DHCP Mappings part each time :)

[tessus]

At least it's a bit better than the ISC DHCP Server webGUI was were you had to scroll over the Settings to get to the Static DHCP Mappings part each time :)

This can easily be solved by adding a link (reference within the same page) at the top to jump to the static mappings.

But the fact that the current UI now has 2 scroll areas (and scrolling depends on where your mouse pointer is), is not very user friendly. Especially when I can choose the number of rules to show. This is then basically useless, if the scroll area always stays the same.

Still hoping for an answer to my question:

Is this a bug or a deliberate design decision? If it is the latter, please reconsider and also please explain how this is supposed to be better than it was before.

[Monviech (Cedrik)]

It's a deliberate design choice.

[nero355]

This can easily be solved by adding a link (reference within the same page) at the top to jump to the static mappings.

I was thinking about a seperate sub-menu on the left, but since ISC DHCP Server is EOL officially it's not gonna happen...

It's a deliberate design choice.

With or without a chance that it might get a re-design/small fix in the future ??

[tessus]

It's a deliberate design choice.

Which begs the question: how is this supposed to be better than it was before? (there must be a reason for the design choice. As mentioned before, it renders the number of rules to display pretty much useless now.)

[Monviech (Cedrik)]

If you want to complain please do so on github.

Its most likely decided here
https://github.com/opnsense/core/blob/43c933d6a67cac11841ddc9803565bb279f13219/src/opnsense/www/js/opnsense_bootgrid.js#L772

Please be constructive, "better" is always very individual.

[franco]

I wrote a small haiku-ish poem for you.

Complaints, here before
Complaints, now 20-20
forever fruits of work


Cheers,
Franco

[tessus]

If you want to complain please do so on github.

I was asking a question, and asking the people, who decided on that new design, why it is better is constructive. There must have been a thought process, which I don't understand but want to. If you think this is a complaint, it is not. Not yet, I usually don't complain, but I want to understand why things are the way they are. It is a subjective opinion. I love OPNsense, but dislike the new design with the heat of a thousand suns.
However, maybe I don't understand why the new design was deliberate. Guess what? This is why I asked the question. And then maybe I will think differently.
Also, if it is not better in the eyes of the people who are responsible for this, why was it done in the first place? So don't get me wrong, they must have thought it is better, they didn't just roll a dice, did they? So for them the new design was better, subjective or not. I still want to know what it was exactly.

[Monviech (Cedrik)]

I have linked the code where there is a comment about the new library used (tabulator) having some challenges with this resizing.

The way you initially wrote with bold text and suggestive questions made it look like you were baiting for an argument.

If something should be fixed or re-explored it would be best to discuss it on github so it can be tracked properly.

[Patrick M. Hausen]

The question that bugs me the most - why in *any* UI replicate UI elements the browser already brings? The browser got a dynamically resizable canvas and it's got scroll bars. It's got back and forward buttons. Etc.

The expectation of anyone using a web site or web UI is for these elements to be the main ones to interact with.

Just render an effin' table. And place all "action" buttons at the top. If I need to scroll, I'll scroll. That's what the browser scroll bar is for.

But why create another limited canvas with its own scroll bar outside of the browser's (and the user's!) control? I really do not get it. Stick to the established paradigms of how the web works.

Of course I am not that old fashioned to argue against e.g. pagination. But if at the top I select "show me 50 entries per page" there is absolutely no reason not to just render a table with 50 lines and let the browser and me handle it.

My 2 ct.

[Monviech (Cedrik)]

The browser renders all scroll bars you can see :)

[Patrick M. Hausen]

The browser renders all scroll bars you can see :)

You know what I mean.

[Monviech (Cedrik)]

I understand your point but I already referred to the right channel for this feedback, which is an issue on github.

We are constantly working on improving the user experience with the new tabulator library.

[Patrick M. Hausen]

We are constantly working on improving the user experience with the new tabulator library.

I absolutely appreciate the effort put into the MVC refactoring and the unification of UI elements throughout all of the areas.

I hope there will be attention to detail and dedication to quality left once you are done with the first "sweep". The inconsistency of separate apply actions - yes or no? And the positions of central action buttons is not just mildly annoying. Getting these right at some point in the future would in my opinion distinguish an ok product from a great product.

OPNsense is great. Keep up the good work. Thank you!