[Fixed][BUG][EDITOR]Zoomed in, scroll bars don't go all the way to edge of level

[Nepster]

@Proxima: Then that's a bug that is FAR more important than any scroll bar issues.

@namida: I would totally agree with your arguments and find them convincing, were it not for the fact, that the Lix editor doesn't have scroll bars and noone complains there.

MMB for scroll should be implemented if it isn't already, but it should never be the only way to scroll for the reason namida stated.

RMB is fine if it's not being used for any context menus. Since the NL editor isn't a fullscreen app, edge scrolling probably wouldn't work very well.

Dragging with RMB is already implemented, as the NL editor doesn't feature context menus. So do you want to have MMB-scrolling in addition to that?

Zoom scroll by itself is bad, but zoom scroll is something I expect to see in anything with a zoom feature. If the zoom function works how I expect, the zoom scrolling functionality is an emergent property, so I expect that it should be possible to scroll with zooming if the UI is well designed. But it should NEVER be relied on. It's so clunky, especially over short distances (why do I have to zoom out then back in just to move the viewing area like 3 pixels?)

That's why we have RMB-dragging or the arrow keys for short distances.

Pretty much every Windows style GUI application has a scroll bar for scrolling. Lix can get away with not having one because the Lix editor UI happens to look a lot like the Lix game UI, so naturally you might consider trying to scroll the same way you would scroll in game. Actually, I've used one image editor that feels very awkward to scroll in, and I could never really put my finger on why until now - it doesn't have a scroll bar, and can only scroll by zooming (ugh) or with the MMB. Basically, the scroll bar is something useful to have that I don't realize just how much use I get out of it until it's gone.

Actually the one thing I hate about most image editors is that they don't offer a nice way to move around and rely on scroll bars (and sometimes on MMB, which is on my mouse the same as pressing the mouse wheel, which is extremely ugly). As such I almost solely rely on zoom-moving (yeah) for image editors.

[Nepster]

Ok, I fixed at least Proxima's second bug: If the zoomed in level still totally fits onto the screen, then it was centered there. This modified the cursor position relative to the level, so when the "zoom in at cursor position triggered", the cursor was already at a "wrong" position. Now the editor remembers the desired position, so when the "zoom at cursor position" happens it will move to this desired position.

[Proxima]

@namida: I would totally agree with your arguments and find them convincing, were it not for the fact, that the Lix editor doesn't have scroll bars and noone complains there.

Firstly, Lix has edge scrolling, which I think is even better than a scroll bar for moving short distances.

Even more significantly, Lix terrain conforms to the grid. I don't have to zoom in to place pieces accurately -- the grid does it for me. In a typical Lix session, I'm zoomed out most or all of the time, so short-distance scrolling is all I will ever need. In a typical NL session, I'm zoomed in the majority of the time, so needing to scroll by three or four times the width of what's currently on screen is vastly more common. The scroll bar beats all other methods in this case.

[namida]

@namida: I would totally agree with your arguments and find them convincing, were it not for the fact, that the Lix editor doesn't have scroll bars and noone complains there.

The Lix editor also doesn't have a standard Windows GUI type interface. Maybe it's just me, but I'm more inclined to expect a scroll bar when scrolling is possible in something that does use that kind of interface; less so in something completely custom like LemEdit or the Lix editor - if, say, the Lemmix editor lacked it, that would be weird to me.

[Nepster]

I added now the little gray borders IchoTolot asked for. With them the original bug should be fixed.

But I would like to stress one point: Once I started working on the gray borders, I realized after ca. 5 minutes that I would only have to change two single lines of code. Or so I thought... When I actually tested it, the editor crashed! And guess the reason: It were these stupid SCROLL BARS!!! I then spent a few hours fixing all the scroll bar related editor crashes! In that time I could have fixed a few other bugs or implemented like three new features like the max fall height ruler in the editor!
So for everyone asking for scroll bars in the future: Please take into account just how much work they will be and whether spending the coder's (i.e. my) time elsewhere would not be more beneficial.

[IchoTolot]

I feel your rage, but it's still the most intuitive scroll option for windows GUIs and therefore I would consider it time well spent. Even if you yourself don't need the option, it's essential for a lot of other people - as the recent posts here have shown.

I would even say only a fraction of new users would even notice that RMP scrolls in this program.

I will take the scrollbar time factor into account for future suggestions though.