A blinking Cursor is an eye catcher for those who are searching for the Cursor in a file of lot of lines. So this Thing is reasonable for some users. Sure we can’t handle all Little tweaks and Options and we shouldn’t but we should have a look what are the big cases for those users. One case, that I can Image is the delay of the Code completion. Me I don’t want a delay time, some others want them like not seeing the completion while typing, etc. This Thing is configuratble, but not via Options, only inside the files. This is one case where users want that delay customizable. There is a ticket for this too.
Yes there are good reasons for almost everything like do or don’t and we should think About it and let the user choose what they want. But if we have a ticket like, please do this and it will be implemented and some other creates a ticket with please do this, what is the complete opposite, this goes into differnet directions and then you only make one user happy with it. Sure 1 user could be 100 and the other user could be 200 but we should think about that. You can’t make everything good and everything Default. And if you have a Default, it should be changeable. Maybe not everything but most of them. Yes today it is the blinking Cursor and tomorrow it could be some other stuff. I’m for advanced Settings too, for such Settings. If the user is willing to click on that advanced Settings button, he should be able to Change whatever he wants and thinks, which could be inside of it. To give Defaults only to one user groul instead of a lot of more People, is not a good Point, in my opinion. Things can Change so let the user/developer decide. Cheers Chris Von: Tim Boudreau Gesendet: Montag, 14. Mai 2018 09:07 An: [email protected] Betreff: Re: Expose Caret Settings in Editor Options On Mon, May 14, 2018 at 2:15 AM, Christian Lenz <[email protected]> wrote: > Of Course, it will increase a bit of the complexity but it is as it is. > This shouldn’t really not a reason why not doing this. > IMO, maybe it should. From an oldie but a goodie: *Pull up the Tools | Options dialog box and you will see a history of arguments that the software designers had about the design of the product.* - Joel Spolsky - https://www.joelonsoftware.com/2000/04/12/choices/ I was around for the original rewrite of the options window - the BeanTreeView with a property sheet that somebody mentioned used to be around as the "advanced" view. Now, part of that was the fact that, as we learned the hard way with videotaped usability studies, the tree + property sheet interface was completely baffling to a lot of users. But a lot of it was the sheer volume of options - who actually wants to customize "Editor scroll jump insets"? You could. The *job*, in creating usable software, is to make good choices about defaults, so nobody wants to customize them. The way to abdicate that responsibility is to avoid choosing "let's make that an option". Everybody has some little thing they'd like to be able to tweak. And for many of them, there are two people in the universe that will ever tweak them. The overwhelming lesson of the data about what options people actually used that we gathered was that most people customize nothing. Don't open Pandora's box. Today it's caret blink rate. What will it be tomorrow? If someone simply *must* have a non-blinking caret, it would be trivial to write a plugin that sets that one setting via its layer.xml - and given that in 19 years of working on NetBeans or being involved with it, this is the only request I have ever seen for that, a downloadable plugin seems like the right level of discoverability. People who search the web for "netbeans caret blink" will find it, but we don't pollute the UI with a setting for something almost nobody on earth is going to care about. And I say that, thinking, I'd probably actually like a non-blinking caret and install that plugin. But I am also, as one of its developers, not the target audience, and what makes me happy can drive others away. -Tim
