Forums Feature Suggestions custom mouse wheel line count scroll

I would like the number of lines that are scrolled when I roll the mouse wheel to be customizable in a channel window, or more regular or predictable, similar to pageup/pagedown keys.

Or can it be scripted?

How is it not regular and predictable? I get 5 lines scrolled in any window with any number of lines each "step" I use of my mouse wheel. If you are getting random numbers of lines, it may be related to your mouse or mouse drivers.

This is set in your Mouse settings in the control panel, AFAIK-- *predictable* would be using the system wide settings, and not customizing/scripting it for each channel...

Okay, but both your positions entail that the page-up key is *not* regular and predictable, which I don't think would be a popular position. So how do we reconcile those definitions?

Either way I obviously don't want a random amount of lines, and it might make sense for the number to vary by the channel, but more so by the window.

It doesn't make sense for the number to vary at all. That actually contradicts your own suggestion. If you want it to be predictable, and "regular", you want it to be the same in every window-- more appropriately, you want scrolling to work the same in every application as well. That means it should work according to the system settings. As far as I can tell, it already does this. What is the problem?

As a sidenote, what exactly is unregular about the page up key? Why did you even bring this up? Page up works exactly as it should. It scrolls up exactly one page. This is pretty much the same behaviour you would see in any other text editor with page up functionality. And more importantly, it is completely consistent with mouse scrolling. You're saying it's not, but I really don't see how, since you haven't presented any evidence.

It would help to move this discussion along if you actually defined what you mean by "regular" or "predictable", given that your standards seem to be disconnected from what most users would expect.

"It doesn't make sense for the number to vary at all."

I said it might. Take a math or comp. sci. channel. Someone posts a formula, and you want to study it. If it's multiple lines, then you have no way to fit it on your screen. You have to copy it to an editor, or position the exact line with the mouse.

Or, you might want to scroll so that the top of the paragraph that was on the bottom of the screen is at the top of the screen in a text editor.

In general, there are a few different ways to specify how much you want to scroll.

1) Fixed number of lines
2) Proportion of the visible screen
3) Proportion of the full document

3 would be pretty rare, except for maybe zooming a camera's field of view in graphics applications, of which I've written a couple myself.

Page up fits in 2; by scrolling 100%. Actually it combines 2 and 1 by scrolling 100% of the screen - 1 line. But it is not "regular" in the sense of a fixed number of lines, or 1.

If you ask me, no application provides all 3 options, but I use mIRC frequently as of today, so I'm asking here.

I am aware of what you said. I am disagreeing. "might" creates inconsistent behaviour. How do you rectify your view that scrolling should work consistently with the idea that scrolling "might" "sometimes" work differently? That doesn't seem consistent to me.

mIRC does #1. Always. This is how Windows scrolls. Therefore, this is how you should expect applications to function. I don't know any examples of applications that do 2 or 3, not with the scrollwheel, anyway. Any application that did not do #1 would be inconsistent as a Windows application, IMO. We're talking about WINAPI applications, not OpenGL simulations or games. Graphics would be an apples and oranges comparison, and simply isn't valid here. mIRC is not a graphics application, it's a text based one with a textarea as the main UI component. You should expect scrolling to work as it does in any other textarea of any other application. If this is inconsistent, mIRC should change. I haven't seen any evidence that it is inconsistent.

But the problem isn't about whether or not other methods exist. I am certainly aware that different applications can perform different types of scrolling, especially when we're talking about different form factors or OS's. -- the problem here is that you haven't defined how mIRC is "irregular" or inconsistent with its scrolling behaviour. That was your original assertion. I haven't yet seen you discuss this. It would be nice if you stopped skirting the issue and actually defined how you see mIRC as being predictable about scrolling. If that's the problem you want solved, you have to actually show us where the problem is, and how your proposed new feature solves it. I'm not seeing the problem or the solution.

As far as your example on copying math formulas go, I really don't understand how scrolling methods #2 or #3 make this any easier to copy text.... How would scrolling proportionally to the screen change how much can fit in a screen? Is that example even related?

There's not enough evidence to conclude whether you're refuting my points, or I'm paranoid, or we're miscommunicating again. However, the force or momentum of my argument isn't as strong as I perceived it was originally.

Your argument has the form, "I can't imagine it, therefore it isn't true," such as when you say, "doesn't seem consistent" and "simply isn't valid". However, I would be flattered and glad you want to understand.

I would guess that most readers of the forum could imagine my argument. Your seniority metric is approximately 100x mine, so my position on that matter is not strong; however you do seem to be speaking for more people than just yourself. Did I perceive the momentum of my original argument incorrectly?

mIRC scrolls differently depending if you use the mouse wheel or page key. That much is empirical although our positions differ significantly on what that means. Furthermore, that may be true of other applications, but, returning to my "information display" thread, it's less important in applications where screen space isn't quite so scarce compared to content. mIRC may even be scarce (or unique) in that regard, since the television equivalent of IRC would be a dedicated bidirectional radio feed and camera for every viewer, such that every viewer could control their camera motion, applicable to both sports and fiction; that is, investigate the scenes independently; or in other words, interactive video.

Certainly we're not unfamiliar with scrolling the paragraph we're reading off the screen in other applications; the math example is merely an example of that, something where you'd want all and only certain information on the screen at once.

Long story short, I want the mouse wheel to be changed to behave like the page key, although also accommodate long paragraphs. That might or might not be precedented, but with enough scripting API's, I could pursue it myself, and possibly be able to announce some good balance or compromise between those two constraints later.

Also, disinterested health and safety reminder to everyone to go easy on the carpal.

Yes. But this is neither inconsistent nor surprising. The mouse wheel is not meant to scroll the way page up/down does-- it is meant to scroll as it is configured in the Mouse properties of your control panel-- the setting has no bearing on how keyboard buttons work. If you want to scroll up a page, use your page up key. If you want to scroll up by the amount configured for your mouse driver, use your mouse. The fact that these values differ is a feature, not a bug.

Certainly you've experienced this difference before in other applications, and I'm guessing you never complained before. This is exactly how other text based programs work. Your web browser, your word editing document-- they all function this way. What is different about mIRC? Why aren't you complaining to the Firefox guys that your scrollwheel doesn't scroll a page at a time, or the Word team at Microsoft?

Remember, let's keep the comparison at what it is: text based data. Your hypotheticals about graphical applications, "bidirectional radio feeds" and television sets go way beyond the scope of what an IRC client is. Yes-- if mIRC was not mIRC, then another UI might be warranted. But mIRC is not a radio feed or a game. You still haven't really explained why, in the context of mIRC as an IRC client, this behaviour is actually needed. In the absence of any good examples, I'll side with maintaining UI consistency.



I am familiar with scrolling paragraphs in other applications. In fact, I am familiar with it because it works exactly as it does in mIRC. So I am actually confused by your example, because I would be doing the same thing in any other application that I would do in mIRC if I needed to get all of the data into the screen at once (I would just scroll to the location). If anything, your example proves why you don't need to change mIRC's behaviour to do what you want, since other applications do this the same way mIRC does. For instance, if I was in a web browser and a large snippet of code was cut off at the bottom of my screen, I would simply scroll down until it was no longer cut off. I don't know any other magic trick in a web browser to do this-- why does mIRC need such a magic trick?

I just don't see any specific reason why this behaviour needs to be scriptable within mIRC. The demand doesn't seem to be all that high (first time I've ever seen this requested, and I've been here a while, which means you're probably the only person that would use this feature), and the use case is a single very obtuse one that doesn't seem to match up with other UI behaviours in a text based applcation.

However, if you REALLY want to break the laws of UI consistency and roll your own, feel free to write a DLL. You certainly have free reign to write a window hook and capture the mouse scroll events yourself, and replace it with pgup/pgdn. Probably isn't that hard to do. Then again, perhaps you could just hit pageup/pagedown if you want that functionality?

"...feel free to write a DLL."

Well, that's what I might end up doing, that or a COM object. MinGW won't compile a shared DLL with the "stdcall" calling convention, or I haven't figured out how, not that this is a MinGW forum. MSVC might do it, but an IRC client isn't hard to write from scratch, using Python and wxWidgets. Mine is about 300 lines long, though it's new and has no features. So, I'm not here because I have to be; I'm here because others might want the same thing.

"[Other applications don't.]"

No, most don't. But should mIRC continue to allow scripts, even though Firefox doesn't? Is mIRC groundbreaking enough as it is?

What is different about mIRC is that it only displays information you want temporarily, and then obscures it in favor of newer information that you sometimes want less.

Regardless, other applications do also need good scrolling. I can't change them all, or post on every forum. I use mIRC more than Word as of today, so that's where I want to start. No reason we can't use the same strategies for user interface control elements as other domains.

"I'm guessing you never complained before."

Ok, no I haven't, but in my judgement the feature isn't within reach for other applications; or they have bigger problems.

"I would simply scroll down. ...What is different about mIRC?"

No, the information isn't unacquirable; it's a matter of its quick and speedy display. You seem like a cool, reasonable fellow. Surely you ask rhetorically; surely you know how mIRC displays information. Obviously, if you could have the mouse wheel and page key scroll the perfect amount, you would.

And as for why you'd want it faster, and why you wouldn't want to waste time, you had might as well ask why I go on IRC in the first place. And surely I don't need to answer that.

I recognize that the mouse wheel and page keys are very important to you. Perhaps you worry that others scripting that behavior, is the first link in a long chain to forbidding, changing, or eliminating for you the behavior you know and need. I am not a dev of mIRC; I cannot reassure you on that count. But if you can script it, then you can stay the same, even if mIRC changes.

Besides, I'm registered.

There is a large difference in your comparison of scrolling and scripting. Adding or removing a feature (scripting) is one thing. Changing how something like scrolling works in an app while it works differently in just about every other application is something else entirely. People expect scrolling to work the same in every application. They aren't going to appreciate having different applications scroll different amounts because it will quickly become confusing. That would be the same thing as saying that you think the space bar should act like a TAB when used at the beginning of a line in one program when it doesn't function that way anywhere else, or some other similar change. It doesn't make sense to change something that is standard behavior unless there is a plan to change the behavior across the board. Every time an application decides to ignore standard behavior and do their own thing, a LOT of people complain. It never turns out very well.

Besides, how will the application know what a given person wants to happen? One person might want it to scroll by paragraph/message. One person might want it to scroll by sentence. Another might want it to scroll by page. Yet another might want it to scroll from image to image (if there were images in mIRC). And so on. It is far better to have a fixed scroll amount instead of trying to make it do what one person wants while making it worse for others. And you can't make it work the way everyone wants because everyone would have different needs or wants. Having a fixed amount makes it work the same for everyone and people have been used to scrolling for a very long time, so they can easily handle it.

As far as being quick, a scroll bar is very easy to access and your hand is already on the mouse if you're using the mouse wheel and that gives you all the fine tuning you need when scrolling.

In conclusion, if you want the mouse wheel to act like page up/page down, then as long as you keep your window at the same size so the same number of lines are on the screen all of the time, then most mouse drivers allow you to adjust how many lines the wheel scrolls at a time. Just change it to match the number of lines in your mIRC window. Not only will this fix the "problem" in mIRC, but it will fix it for all of your other applications as well as long as they have the same number of lines displayed in a window.

And if you really believe that changing the way a mouse scroll wheel functions is important, then send your suggestions to mouse manufacturers or Microsoft, Apple, and the various Linux distributions and if they think it's worthwhile, they can make the change there. It really isn't the application's place to make changes in how scrolling works.

Everyone seems to be saying, "Yes, it would be a nice feature, and extremely pleasant and useful but."

1) We need it in all the other applications.
2) We can only get it used in one application, which is hardly any.
3) If there are all those variants, why script it, just make it an option. (I think Riamus implied generic DOM elements in webpages.)
4) You can't script everything, so don't bother; if the docs (the API) were any bigger, mIRC would be unusable.
5) mIRC shouldn't be the first!

Of these, I can only agree with 1. However, as you gather, I can relate to 2-5. Freedom of mouse wheel isn't in my country's constitution, but it's a darned good idea anyway.

If you ask me, the API should be 2-10x bigger.

I don't think anyone other than you is saying it would be a nice feature. I think everyone is saying it should not be a feature. And as I stated, if it was something that people wanted, then it's not the place of each application to implement it. It's the place of mouse manufacturers and/or OS developers.

For your numbered list... 1) No, we don't. 2) Not even sure what you're trying to say here. 3) That's the opposite of what's said... if there are a lot of different variants that people might want, then scripting it (this includes using DLLs, which was suggested) is preferable to a built-in setting. 4) Who said this? 5) No. mIRC shouldn't be breaking standards.

In short, your numbered list makes little sense. It's as if you took what people said and tried your best to twist it into what you wanted.

Well, I feel cornered.

There are no grounds for the argument that my idea is behind the times. Unfortunately, that was all that Mr. Argv0 seemed to be saying. There might be grounds for the argument that my idea is ahead of its time, but Mr. Riamus2 stopped short of saying that.

If mIRC is determined to be old and bulky, then that ought to appear in the sticky posts and docs: "We are not accepting young, fresh, innovative ideas at this time. Thank you." COM and the DLL interface do not qualify.

Otherwise, you or the forum moderators ought to see to it that feature suggestions are cultivated, not stifled. The former is not what happened today.

There is a difference between supporting ideas that people feel are useful versus supporting every single idea people suggest. For example, if I suggest that mIRC should combine all text into a single window because it makes it less confusing when changing settings about where each event appears and keeps all text in one location... that would be a really bad suggestion. It would not make sense for everyone to support the idea just because I made the suggestion. Suggestions should not be supported just to make people feel better about offering ideas. Suggestions should only be supported if people think they are worth supporting. And ideas that are only going to be appreciated by a few users are not usually a good thing to include in mIRC.

Scripting is included with mIRC precisely to allow people to do things that are useful to themselves, but which may not be useful (or desirable) for everyone. Features that are directly included within mIRC should be those that are going to benefit most users rather than a limited number of users.

Besides, you're completely ignoring my main point. The way a mouse scroll wheel works should be controlled at the driver or OS level instead of the application level. If you feel the idea will be beneficial to people, then the mouse manufacturers (those who make the mouse drivers) or the OS developers should be the ones who implement it. Specific applications that do unusual things might need to change how a keyboard or mouse or other input device functions, but that is because they don't operate like other programs. mIRC is basically just a text program similar to a text editor or word processor that handles the sending and receiving of text with other users. It should handle input methods the same as in other software whenever possible.

Also, as I pointed out, when software breaks standards to do their own thing, most users don't appreciate it. It wouldn't make sense to break the standards for mouse scroll wheels in mIRC to benefit a few people while annoying most users.

And, let me be clear... I was not in any way implying that your idea is "ahead of its time." I don't believe that kind of scrolling is useful at any point in time (past, present, or future) for mIRC or any other similar software. It might be useful with some software designed for displaying equations or whatever like your earlier example, but that's not the purpose of this software. This is a means of displaying conversations and it does that well and scrolling works just fine for it.

No, only you and argv0 talked about it at that time, there's no way you can use the word 'everyone' here.
One thing is sure: you want to see that behavior implemented, however, argv0 showed that all your arguments/examples/explanations doesn't hold water.
There's a very good reason we had a page up/down button on our keyboard but that we still added the wheel to the mouse, it's because their use is different but both are really used/needed. You might also want to think about it like that, if you don't know any program that does that, it might be because noone want to see that.
Some ways to do what you want has been given so you can do it, but if you want to see this implemented in mIRC you'll have to convince people at some point, especially Khaled.

People here are not saying that your idea sucks even if they think so, they are trying to help you finding some good reasons to implement your idea, or like here, to help you realizing the idea isn't that great. mIRC isn't determined to be old and bulky and we are accepting young, fresh, innovative ideas at this time, but here you are the only one thinking it's a good idea and you can't properly tell why

I'm simply saying that your idea benefits nobody but you-- or, at least, there's no reason to believe it will have enough appeal to warrant Khaled's time. As Riamus said, not every single requested feature is implemented in mIRC. I'm glad you registered your copy of mIRC, but that doesn't make Khaled responsible for writing tailor made code. Again, this is the first request of this nature I've ever seen, both on and off the forums. There has also yet to be anybody chime in on this thread to say that this feature sounds like a good idea to them.

Note that the above two metrics tend to be used to determine the cost benefit of suggestions (among others, of course). So far this suggestion is coming up short in those metrics. That's all I'm saying. I'm also suggesting that it would help you to potentially gather support if you actually had a concrete implementation / idea in order. Currently your description of what you want seems all over the place-- part of this is simply mapping scrolling to pgup/pgdn, the other part is some smart scrolling feature based on actual text. If you can list your suggestion as: "this is the scenario, this is what the user does, and this is what happens (and optionally, how it happens)", it will help people understand what this feature is and why it might be needed.

Now, if you're looking for scriptability-- you can mostly achieve this already through a DLL. So there's really nothing to add. Go ahead and write your script/dll. If you think I'm wrong and that everybody would love this idea and that it will revolutionize scrolling-- well, prove it by writing the DLL. If it's really that amazing an idea, your script will become immensely popular, and there will be many voices asking for this feature in the forums. Until then, there's no reason to believe those voices exist.

No matter which path you take, you're going to end up writing a dll, so get started.

Sidenote: mingw can certainly generate DLLs using the stdcall convention. A quick google search shows that it supports the __stdcall keyword, so it should work out perfectly. I know a few who generate their dlls exclusively with mingw.

Sidenote 2: It's easy to judge a client in theoreticals. It might be nice to have a 2x-10x larger API in mIRC, but if we talk practical examples, there have only been a handful of instances in the many many years I've used the client that I've come across something that could simply not be done in a reasonable way using the scripting engine / dll layers. Practically speaking, the API is about 95-98% of the way there for most users. That's a far cry from 2x-10x too small. Also, by that standard, your 300 line client is orders of magnitude worse, no?

Hey I agree with the OP. Would make a lot of sense scroll by page or screen percentage rather than line count. Seriously... I've found the way windows scrolling works to be less than desirable.

"windows scrolling" -- In other words, Windows (and other OS's) is where you need to go to see this changed.