On Fri, Dec 19, 2014 at 5:03 AM, Daniel Carl <[email protected]> wrote: > Morgan Howe <[email protected]> wrote: >> Is there currently any way to change the config variable in the >> hinting script without recompiling? The defaults are a bit hard to >> look at, but I don't see a way of doing this via scripts or the rc >> file. >> >> I was considering adding support for it, but wanted to make sure there >> wasn't some trick for doing it via the user scripts first. > > It's partially possible to change the hint style by style.css file. But this > allows only to style the hint labels (squares with the hint number in). To > take effect, you need to put '!important' behind the styles in case they are > defined by the hinting script, like shown below. > > #hint_container .hinting_mode_hint { > -webkit-transform:translate(-4px,-4px); > color: #000 !important; > background-color: #fff !important; > border: 1px solid #444 !important; > opacity: 0.7 !important; > font:bold .9em monospace !important; > }
Hey guys, thanks for the suggestions. Sorry for the delay, gmail is doing something weird with my filters so I missed your responses for a few days. :) Changing only the hint labels as per Daniel's post is probably sufficient as that's the hardest part to read, though I still think it should be fully configurable. I agree with you, Jason, that this isn't something that won't be changed often. Still, while it may be reasonable for you (I assume) and me as developers to apply a patch to change this or add the functionality to allow changing it, I feel like we may be excluding potential users who do not have this knowledge or ability. Something as simple as changing the default hint colors should be available out of the box, and I think some people may be put off immediately when they find out it's not. Although it's unfair, if such an obvious (and hotly debated! :) option of changing basic color schemes isn't possible, it wouldn't be unreasonable to expect the rest of the experience to be equally inflexible. Sure you could argue that a vim-like browser is not something non-developers would ever be interested in to begin with, but I think we might be selling the project short by making that assumption. I think we should try to move as many of these compile time settings as is reasonable out to configurable settings, and be vim-like not only in behavior, but flexibility as well. It should be possible to do so while still maintaining a good balance between minimalism and configurability, and will allow us to provide a browser that distributions will be able to include in their repos that is ready to meet the needs or tastes of most users without a recompile. I do not intend this as a rant or any kind of philosophical statement and would be very interested to hear others thoughts on whether or not this would be a worthwhile goal to work toward. Best regards, Morgan ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Vimprobable-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/vimprobable-users
