vimprobable-users Mailing List for Vimprobable (Page 5)
Vimprobable is a lean web browser optimised for full keyboard control
Brought to you by:
hanness
Menu
▾
▴
vimprobable-users — Mailing list for Vimprobable users
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(77) |
Sep
(44) |
Oct
(43) |
Nov
(38) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(40) |
Feb
(18) |
Mar
(12) |
Apr
(25) |
May
(12) |
Jun
(13) |
Jul
(17) |
Aug
(3) |
Sep
(20) |
Oct
(42) |
Nov
(9) |
Dec
(2) |
| 2013 |
Jan
(9) |
Feb
(29) |
Mar
(9) |
Apr
(7) |
May
(38) |
Jun
|
Jul
(7) |
Aug
|
Sep
(5) |
Oct
(10) |
Nov
(11) |
Dec
(1) |
| 2014 |
Jan
(16) |
Feb
(18) |
Mar
(11) |
Apr
(5) |
May
(13) |
Jun
(5) |
Jul
(5) |
Aug
(7) |
Sep
(30) |
Oct
|
Nov
|
Dec
(26) |
| 2015 |
Jan
(5) |
Feb
(19) |
Mar
(8) |
Apr
(15) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(16) |
Dec
(10) |
| 2016 |
Jan
|
Feb
(1) |
Mar
(14) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Hannes S. <ha...@yl...> - 2014-12-24 06:32:02
|
On Tue, 23 Dec 2014 19:34:32 +0100, "Daniel Carl" <dan...@gm...>
wrote:
> > Von: "Hannes Schüller" <ha...@yl...>
> > > and to add a stylesheet with the default
> > > styling of the hint elements.
> >
> > This, however, I'm not so keen on. It has been the browser's policy
> > so far never to create files, but only to populate them if the user
> > creates them first. I.e. the browser can be run on any system
> > without leaving any traces. I still like this. Opinions?
>
> Oh, I didn't ment to write something into the style.css file. I
> thought of adding the default style to the html header as style tag.
>
> var e = document.createElement("style");
> e.innerHTML = ...;
> document.head.appendChild(e);
>
> This means the style is considered to be the pages style and can
> easily overwritten by the user styles read from style.css file.
Ah, OK. Agreed, then.
Hannes
|
|
From: Jason R. <jas...@gm...> - 2014-12-23 18:57:44
|
On 23/12/14 at 10:25am, Hannes Schüller wrote: >So, to follow up on the brief IRC discussion: I believe there are two >questions to be asked here: > >1. What should the default styling of the hints be? >2. How to allow the users to change them? > >We've got the second one covered in the discussion so far, and I also >like Daniel's latest suggestion. > >As for the first one, I obviously took those default colours from >Vimperator back in the day. They are optimised for discoverability, I'd >say, i.e. if you're not quite sure what the linked elements even are, >you're sure to spot them all when activating hinting mode, because they >will jump right in your face. > >They are not pretty and some people apparently don't find them very >readable (this is very subjective and hard to measure). I'm open to >change the defaults, but I have some basic requirements: > >- Discoverability still needs to be there. Not necessarily as striking > as it is now, of course, but something too subtle is also not good. >- The contrast should be sufficient for visually impaired users (again, > subjective; I believe there are automated test suites for this, > though). > >Yes, my own system is completely grey on grey as well. I even like low >contrast! That, however, doesn't necessarily make it a sensible default >for the general public. > The current defaults (red on yellow) may pose accessibility issues for people with colourblindness[0], a better combination would be black on yellow (the international traffic standard). This is high contrast enough, and also similarly garish to prompt those who don't require such lurid colours to change them quickly… As to 2), there are three vars that the user should be able to modify: hint_foreground, hint_background and hint_size. How that is actually implemented I'll leave to the technically competent. 0. http://colorvisiontesting.com/color2.htm Cheers, /J -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40] |
|
From: Daniel C. <dan...@gm...> - 2014-12-23 18:34:41
|
> Von: "Hannes Schüller" <ha...@yl...>
> > and to add a stylesheet with the default
> > styling of the hint elements.
>
> This, however, I'm not so keen on. It has been the browser's policy so
> far never to create files, but only to populate them if the user
> creates them first. I.e. the browser can be run on any system without
> leaving any traces. I still like this. Opinions?
Oh, I didn't ment to write something into the style.css file. I thought
of adding the default style to the html header as style tag.
var e = document.createElement("style");
e.innerHTML = ...;
document.head.appendChild(e);
This means the style is considered to be the pages style and can easily
overwritten by the user styles read from style.css file.
Daniel
|
|
From: Hannes S. <ha...@yl...> - 2014-12-23 17:11:03
|
On Tue, 23 Dec 2014 18:18:48 +0800, Morgan Howe <mt...@gm...> wrote: > > We've got the second one covered in the discussion so far, and I > > also like Daniel's latest suggestion. > > Are you referring to allowing these things to be controlled through > the style.css Yes, that's what I meant, sorry. Hannes |
|
From: Hannes S. <ha...@yl...> - 2014-12-23 17:09:59
|
On Mon, 22 Dec 2014 22:36:05 +0100, Daniel Carl <dan...@gm...> wrote: > I like the way of doing style changes > via style.css file. Long story short: I can't imagine that a user > want to add something like following to the config file. > > set > hint-label-css=z-index:100000;font-family:monospace;font-size:10px;font-weight:bold;color:white;background-color:red;padding:0px > 1px;position:absolute; > > According to the initial issue, I'd suggest to rework the hinting to > add and remove only classes and avoid to set inline styles (except of > the position of the labels) Agreed, making this an easily referenced class is the way to go. > and to add a stylesheet with the default > styling of the hint elements. This, however, I'm not so keen on. It has been the browser's policy so far never to create files, but only to populate them if the user creates them first. I.e. the browser can be run on any system without leaving any traces. I still like this. Opinions? Hannes |
|
From: Morgan H. <mt...@gm...> - 2014-12-23 10:19:09
|
Hey Hannes, On Tue, Dec 23, 2014 at 5:25 PM, Hannes Schüller <ha...@yl...> wrote: > So, to follow up on the brief IRC discussion: I believe there are two > questions to be asked here: > > 1. What should the default styling of the hints be? > 2. How to allow the users to change them? > > We've got the second one covered in the discussion so far, and I also > like Daniel's latest suggestion. Are you referring to allowing these things to be controlled through the style.css, or was there more followup discussion? For those of us not in the IRC, would you mind giving us a quick recap of Daniel's suggestion? I'll get in the IRC in the future to hopefully catch these discussions. > As for the first one, I obviously took those default colours from > Vimperator back in the day. They are optimised for discoverability, I'd > say, i.e. if you're not quite sure what the linked elements even are, > you're sure to spot them all when activating hinting mode, because they > will jump right in your face. They certainly jump right in your face! :) > - Discoverability still needs to be there. Not necessarily as striking > as it is now, of course, but something too subtle is also not good. > - The contrast should be sufficient for visually impaired users (again, > subjective; I believe there are automated test suites for this, > though). We should definitely have some sensible defaults, or even consider not changing them at all so things look comfortable for people moving over from Vimperator (or even earlier versions of vimprobable, people usually don't like change). As you said, ultimately what is best is very subjective and nearly every one of us will probably have our own preference, so I think that what we choose as defaults is less important than having the ability to easily change them. Thanks for moving the discussion forward! Morgan |
|
From: Hannes S. <ha...@yl...> - 2014-12-23 09:25:04
|
So, to follow up on the brief IRC discussion: I believe there are two questions to be asked here: 1. What should the default styling of the hints be? 2. How to allow the users to change them? We've got the second one covered in the discussion so far, and I also like Daniel's latest suggestion. As for the first one, I obviously took those default colours from Vimperator back in the day. They are optimised for discoverability, I'd say, i.e. if you're not quite sure what the linked elements even are, you're sure to spot them all when activating hinting mode, because they will jump right in your face. They are not pretty and some people apparently don't find them very readable (this is very subjective and hard to measure). I'm open to change the defaults, but I have some basic requirements: - Discoverability still needs to be there. Not necessarily as striking as it is now, of course, but something too subtle is also not good. - The contrast should be sufficient for visually impaired users (again, subjective; I believe there are automated test suites for this, though). Yes, my own system is completely grey on grey as well. I even like low contrast! That, however, doesn't necessarily make it a sensible default for the general public. Suggestions welcome! Hannes |
|
From: Daniel C. <dan...@gm...> - 2014-12-22 21:36:56
|
Daniel Carl
Morgan Howe <mt...@gm...> wrote:
> 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.
In case of user who get vimprobable as compiled binary installed it makes
sense to allow to change some more things during runtime. But I don't think
that it would be easier for such an user to type in css rules in the config
file to change the look of the hints. The hints are not just a color or a
font. I like the way of doing style changes via style.css file. Long story
short: I can't imagine that a user want to add something like following to the
config file.
set hint-label-css=z-index:100000;font-family:monospace;font-size:10px;font-weight:bold;color:white;background-color:red;padding:0px 1px;position:absolute;
According to the initial issue, I'd suggest to rework the hinting to add and
remove only classes and avoid to set inline styles (except of the position of
the labels) and to add a stylesheet with the default styling of the hint
elements. This makes it easy to style the hints completely by style.css file.
--
Daniel
|
|
From: Hannes S. <ha...@yl...> - 2014-12-22 16:04:40
|
On Mon, 22 Dec 2014 13:15:03 +0800, Morgan Howe <mt...@gm...> wrote: > 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. Agreed. Hannes |
|
From: Morgan H. <mt...@gm...> - 2014-12-22 05:15:11
|
On Fri, Dec 19, 2014 at 5:03 AM, Daniel Carl <dan...@gm...> wrote:
> Morgan Howe <mt...@gm...> 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
|
|
From: Daniel C. <dan...@gm...> - 2014-12-20 22:20:49
|
Marcos Cruz <vim...@pr...> wrote: > I've just visited a page that still uses frames (http://microhobby.org), > and the link hinting works only in the menu frame, even after clicking > the main one. > > Beside, sometimes the hintings remain active and no key works anymore. > The only thing you can do is to click links. This is the first time this > error happens, and I guess it has something to do with frames. > > I've found nothing about frame selection or frame focus in the man page > or the wiki. > > Is there any way to select the desired frame for link hinting? In this case this seems to be a bug in the hinting script. I don't know what's wrong with it. I've made a patch that solves the issue for me, but it's not tested very well. Daniel |
|
From: Marcos C. <vim...@pr...> - 2014-12-19 18:19:02
|
En/Je/On 2014-12-19 18:47, Marcos Cruz escribió / skribis / wrote : > Is there any way to select the desired frame for link hinting? Without opening the frame in a new window, I mean. -- Marcos Cruz http://programandala.net |
|
From: Marcos C. <vim...@pr...> - 2014-12-19 18:14:18
|
I've just visited a page that still uses frames (http://microhobby.org), and the link hinting works only in the menu frame, even after clicking the main one. Beside, sometimes the hintings remain active and no key works anymore. The only thing you can do is to click links. This is the first time this error happens, and I guess it has something to do with frames. I've found nothing about frame selection or frame focus in the man page or the wiki. Is there any way to select the desired frame for link hinting? Thank you. -- Marcos Cruz http://programandala.net |
|
From: Daniel C. <dan...@gm...> - 2014-12-18 21:03:17
|
Morgan Howe <mt...@gm...> 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;
}
--
Daniel
|
|
From: Jason R. <jas...@gm...> - 2014-12-18 08:47:46
|
Hi Morgan, On 18/12/14 at 04:07pm, Morgan Howe 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. There is a patch on the wiki, but you'll still need to recompile… Given this is something that, presumably, won't be changed often, that seems reasonable… http://sourceforge.net/p/vimprobable/wiki/Patches/ Cheers, /J -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40] |
|
From: Morgan H. <mt...@gm...> - 2014-12-18 08:08:05
|
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. Thanks, Morgan PS. Btw, my previous patch for showing link destinations still hasn't been merged. :) |
|
From: Morgan H. <mt...@gm...> - 2014-09-25 09:42:17
|
Hey Hannes, On Thu, Sep 25, 2014 at 1:18 PM, Hannes Schüller <ha...@yl...> wrote: > looks like a certain merge to me functionally. I'd just like to confirm > that there are no major redundancies (code-wise) with the yank function. Aside from the show_link() function extracted from the hoverlink callback, there was nothing that really stood out to me as terribly redundant. I copied the same pattern in the script() function which was already somewhat repetitive to begin with, but it looked like a marginal gain to bother with cleaning up that function at the moment. It might be worth trying to refactor that a bit at some point as it will likely only get worse, but I didn't consider it too urgent or belonging in this patch. Regards, Morgan |
|
From: Hannes S. <ha...@yl...> - 2014-09-25 05:15:32
|
Hi Morgan, looks like a certain merge to me functionally. I'd just like to confirm that there are no major redundancies (code-wise) with the yank function. Thanks! Hannes |
|
From: Morgan H. <mt...@gm...> - 2014-09-25 01:23:49
|
Ping. Any feedback on this, or did it get lost in the weekend shuffle? :) Morgan On Sep 20, 2014 4:17 PM, "Jason Ryan" <jas...@gm...> wrote: > On 19/09/14 at 03:40pm, Morgan Howe wrote: > >> I was getting caught up on some old items from the mailing list when I >> came across this old thread: >> https://www.mail-archive.com/vimprobable-users@lists. >> sourceforge.net/msg00234.html >> >> I agreed with Karryana's idea that a way of showing a link destination >> without having to switch to the mouse or yank to the clipboard would >> be useful, as I know how irritated I was when the status bar >> disappeared from my primary browser. >> >> So, I've went ahead and implemented this, using the ";l" shortcut. >> This included a minor refactoring to share code with the mouse hover >> handling. Please see the attached simple patch and let me know if you >> have any concerns or better suggestions. >> >> > Thanks Morgan: this is a nice addition. > > Cheers, > > /J > > -- > > http://jasonwryan.com/ [GnuPG Key: B1BD4E40] > > > > > ------------------------------------------------------------------------------ > Slashdot TV. Video for Nerds. Stuff that Matters. > > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > _______________________________________________ > Vimprobable-users mailing list > Vim...@li... > https://lists.sourceforge.net/lists/listinfo/vimprobable-users > > |
|
From: captaincurrie <cap...@gm...> - 2014-09-21 16:30:21
|
Hannes Schüller <hannes@...> writes: > > captaincurrie <captaincurrie@...> wrote: > > But now that you mention it, the status bar does show up > > after i press <Tab> to open the 'completion menu' and close it. > > Is that intentional? > > For this issue, could you try the attached patch and see if it has any > other unwanted side-effects? > > Hannes > > Attachment (statusbar_completion.patch): text/x-patch, 614 bytes Hey Hannes, So far works GREAT!!!! I havn't seen my statusbar since. Good ridence! |
|
From: Hannes S. <ha...@yl...> - 2014-09-21 10:20:10
|
captaincurrie <cap...@gm...> wrote: > But now that you mention it, the status bar does show up > after i press <Tab> to open the 'completion menu' and close it. > Is that intentional? For this issue, could you try the attached patch and see if it has any other unwanted side-effects? Hannes |
|
From: Jason R. <jas...@gm...> - 2014-09-20 08:17:05
|
On 19/09/14 at 03:40pm, Morgan Howe wrote: >I was getting caught up on some old items from the mailing list when I >came across this old thread: >https://www.mail-archive.com/vim...@li.../msg00234.html > >I agreed with Karryana's idea that a way of showing a link destination >without having to switch to the mouse or yank to the clipboard would >be useful, as I know how irritated I was when the status bar >disappeared from my primary browser. > >So, I've went ahead and implemented this, using the ";l" shortcut. >This included a minor refactoring to share code with the mouse hover >handling. Please see the attached simple patch and let me know if you >have any concerns or better suggestions. > Thanks Morgan: this is a nice addition. Cheers, /J -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40] |
|
From: Hannes S. <ha...@yl...> - 2014-09-19 08:15:49
|
captaincurrie <cap...@gm...> wrote: > But now that you mention it, the status bar does show up > after i press <Tab> to open the 'completion menu' and close it. > Is that intentional? I would say that's a bug. I will look into it. > Basically, even thou both bars can be set to 'false', > they show up when 'used' and then > stay up. Is that intentional? For the input bar, that's currently intended. Whenever this question came up, I tried to discuss the underlying question of policy. I.e. when to "auto-hide" the bar. Basically, I see two options: - "Auto-hide" it when it is empty anyway. I.e. check whether there is any string in the container, enable if so and disable otherwise. - *Force* the bar to be empty unless it is currently typed in and thus hide it all the time it's "not being used". The second option seemed to be the preferred one in some previous patch attempts. I still don't have a great feeling about it as this disables all browser feedback to the user (first and foremost: error messages will not be shown). Though I'm open to let myself be convinced why this would be a good idea. Hannes |
|
From: Jan N. <jan...@st...> - 2014-09-19 07:52:22
|
Hi, > - Cookie policy to accept no third party cookies. I believe this goes > along with the general privacy philosophy of the browser. I'm aware > that it will 'break' a couple of pages, though I nevertheless believe > it is a sensible default. Agreed. > - Include startpage.com as shortcut s. Since the demise of Scroogle, > this shortcut is not taken anymore. Many people seem to prefer Google > results. This seems to be the most sensible way to provide them. Agreed. > On a related note, is everybody happy with the default search engine > setting? Or is everybody using DuckDuckGo/something else anyway (i.e. > it should become the new default shortcut)? I'm using DuckDuckGo, as it's currently the most promising alternative to Google. I'd make it the default search engine, just to support their cause. > > Comments, supporting or adverse, welcome! > > Hannes > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > Vimprobable-users mailing list > Vim...@li... > https://lists.sourceforge.net/lists/listinfo/vimprobable-users > |
|
From: Morgan H. <mt...@gm...> - 2014-09-19 07:40:46
|
I was getting caught up on some old items from the mailing list when I came across this old thread: https://www.mail-archive.com/vim...@li.../msg00234.html I agreed with Karryana's idea that a way of showing a link destination without having to switch to the mouse or yank to the clipboard would be useful, as I know how irritated I was when the status bar disappeared from my primary browser. So, I've went ahead and implemented this, using the ";l" shortcut. This included a minor refactoring to share code with the mouse hover handling. Please see the attached simple patch and let me know if you have any concerns or better suggestions. Morgan |
2 messages has been excluded from this view by a project administrator.
