- Dillo-dev - lists.mailman3.com

ui colors again

by jcid＠dillo.org

On Sun, Dec 30, 2012 at 10:52:37AM -0300, Jorge Arellano Cid wrote: > On Sun, Dec 30, 2012 at 03:55:34AM +0000, corvid wrote: > > I wrote: > > > Today I dug up the old ui colors patch from last September, ripped out the > > > part that used system colors as defaults that was a problem*, and played > > > around with it a little. I really like configurable colors, so, since I > > > haven't heard anyone say anything like feature freeze yet, I'll make another > > > push for this thing. > > > > Committed. > > > > - I changed the inactive icon appearance some more. > > - By default it's using the fltk default colors. > > - It might be nice to be able to specify the selection color, too. > > -1 > > The default colors or theme are not easy to define, everybody has > his personal preferences, and there's no single scheme that pleases > everyone. > > The default theme in dillo is kind of a consensus over the > years. This is, when changes were proposed, the most voted one > (or less objected) got to be the default (same for the website). > > This policy works ok for us and is widely used. > > Personally I don't like the change, but I do understand that > other users, may find it fits better. > > So my points are: > > * The default colors should not be changed without consensus. > * The patch should provide a way to keep the previous default > (i.e. How do I get my colors/pixmaps back?) > > PS: WRT the second point, I find the inactive pixmaps too > "live" for my taste (and thus prefer the pixmaps). > PS2: Is good to have the input/dialog backgrounds configurable > but the defaults should be voted. Just trying to make my points a bit clearer, and after playing a bit more with the patch: * +1 to making it configurable (as now) * +1 to add a dillorc option for the second parameter in color_average() call (e.g. setting it to 0.1f makes for the same look as with the handmade pixmaps, so they could be removed). Adding a parameter for the first one may also help (although it's not a priority). * We may suggest some combinations in the web site or dillorc. This way, the traditional look can easily be set, new ones can be created (suggested) and a default scheme voted. Finally, @all, please recieve my best wishes for the new year that's about to start! ;-) -- Cheers Jorge.-

Dec. 30, 2012

CAPI ignores download requests when not in cache or handled by the downloads DPI.

by onepoint＠starurchin.org

I wondered why "Save link as" silently failed on some of my local web pages if I had not already visited the link. It turns out they were "file:///" links and "Save link as" sends a download request which the CAPI silently ignores if the URL is not cached and is not handled by the downloads DPI. I added a MSG_WARN to log this but haven't changed any behaviour. I still found it surprising and was wondering if it could be improved? Regards, Jeremy Henty

Dec. 30, 2012

ui colors again

by jcid＠dillo.org

On Sun, Dec 30, 2012 at 03:55:34AM +0000, corvid wrote: > I wrote: > > Today I dug up the old ui colors patch from last September, ripped out the > > part that used system colors as defaults that was a problem*, and played > > around with it a little. I really like configurable colors, so, since I > > haven't heard anyone say anything like feature freeze yet, I'll make another > > push for this thing. > > Committed. > > - I changed the inactive icon appearance some more. > - By default it's using the fltk default colors. > - It might be nice to be able to specify the selection color, too. -1 The default colors or theme are not easy to define, everybody has his personal preferences, and there's no single scheme that pleases everyone. The default theme in dillo is kind of a consensus over the years. This is, when changes were proposed, the most voted one (or less objected) got to be the default (same for the website). This policy works ok for us and is widely used. Personally I don't like the change, but I do understand that other users, may find it fits better. So my points are: * The default colors should not be changed without consensus. * The patch should provide a way to keep the previous default (i.e. How do I get my colors/pixmaps back?) PS: WRT the second point, I find the inactive pixmaps too "live" for my taste (and thus prefer the pixmaps). PS2: Is good to have the input/dialog backgrounds configurable but the defaults should be voted. -- Cheers Jorge.-

Dec. 30, 2012

PATCH: uicmd.cc prefs.save_dir cleanup

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > > > uicmd.cc exports a get()/set() interface to the default save directory > > that is never used elsewhere, and used only trivially internally. It > > also rereads prefs.save_dir at every save, which is redundant. It > > would be simpler to have an init() interface that is called once. > > There would be no change to the user. > > > > Patch attached. Thoughts? > > Seems like a good change to make... OK, committed. Regards, Jeremy Henty

Dec. 30, 2012

ui colors again

by corvid＠lavabit.com

I wrote: > Today I dug up the old ui colors patch from last September, ripped out the > part that used system colors as defaults that was a problem*, and played > around with it a little. I really like configurable colors, so, since I > haven't heard anyone say anything like feature freeze yet, I'll make another > push for this thing. Committed. - I changed the inactive icon appearance some more. - By default it's using the fltk default colors. - It might be nice to be able to specify the selection color, too.

Dec. 30, 2012

wizard, switching between UIs

by corvid＠lavabit.com

Yesterday I was playing with ctrl-tab, of course, and I noticed how the state of the focused tab would sometimes change. I went through a few rounds of fixing this in different ways before finding something that didn't seem icky. Detailed comment in patch.

Dec. 29, 2012

Dpi_connect_socket retry

by p37sitdu＠lavabit.com

On Thu, Dec 27, 2012 at 04:37:36PM -0300, Jorge Arellano Cid wrote: > As from the patch you sent (same as before), and the > explanation you give (ignoring my explanation), I guess you're > making conclusions out of reading the code in > Dpi_connect_socket() *only*. I made conclusions from reading Dpi_connect_socket() only, because in the case of error in Dpi_blocking_write file descriptor is left open and not passed anywhere else. If it was passed somewhere else, I would read the code there and check if file descriptor was closed there. > Have you checked what you state as fact? (i.e. that the FD is > leaked and not closed by the CCC). FWIW, I did check before > writing my previous answer. Patch that I did for checking is attached. It replaces Dpi_blocking_write call with -1 to simulate fault in Dpi_blocking_write for Dpi_connect_socket(). Introducing the error in Dpi_blocking_write for all functions doesn't work, in this case Dpi_connect_socket is not called at all (because Dpi_start_dpid fails). With this patch applied, I recompiled dillo and pressed "bookmarks" button several times to trigger dpi code. Each time I pressed "bookmarks" button, new descriptor was leaked: % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5 % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5 6 % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5 6 % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5 6 7 % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5 6 7 8 Then I applied the patch I sent before (with hg qpush) on top of the fault patch and rebuilt dillo: "make clean && make". I ran dillo again with ./src/dillo and did the same test with bookmarks button: % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5 % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5 % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5

Dec. 29, 2012

findbar behaviour

by corvid＠lavabit.com

Jorge wrote: > On Thu, Dec 27, 2012 at 08:38:24PM +0000, corvid wrote: > > Jorge wrote: > > > On Wed, Dec 26, 2012 at 11:29:50PM +0000, corvid wrote: > > > > > > > > Here's what resulted, but it seems relatively inelegant: > > > > [snipped long patch] > > > > > > It's much simpler. In this case you can let FLTK do the focus > > > change among widgets: > > > > > > > > > diff -r 20a26b8bb366 src/findbar.cc > > > --- a/src/findbar.cc Wed Dec 26 23:31:48 2012 +0100 > > > +++ b/src/findbar.cc Thu Dec 27 15:32:02 2012 -0300 > > > @@ -158,7 +158,6 @@ Findbar::Findbar(int width, int height) > > > check_btn = new Fl_Check_Button(x, border, 2*button_width, > > > height, > > > "Case-sensitive"); > > > x += 2 * button_width + gap; > > > - check_btn->clear_visible_focus(); > > > add(check_btn); > > > > > > } > > > > > > and that's it, forward with Tab, back with Shift+Tab. > > > > > > > > > Now, if there's a need for something more special, like letting > > > Tab alone cycle around, adding this will do: > > > > > > > > > @@ -179,6 +178,10 @@ int Findbar::handle(int event) > > > if (event == FL_KEYBOARD && modifier == 0 && k == FL_Escape) { > > > /* let the UI handle it */ > > > return 0; > > > + } else if (event == FL_KEYBOARD && modifier == 0 && k == FL_Tab) { > > > + MSG("Findbar::handle FL_KEYBOARD Tab\n"); > > > + (Fl::focus() == i) ? check_btn->take_focus() : i->take_focus(); > > > + return 1; > > > } > > > > > > return Fl_Group::handle(event); > > > > I wanted to make the findbar as functional as one would customarily > > expect, though. > > Please elaborate. Let's see, I wanted to be able to focus the input, the next and previous buttons, and the case-sensitive checkbox. I wanted to be able to activate the buttons and toggle the checkbox with either Space or Enter. I wanted to be able to Tab to each of them, shift-Tab to go back, and to have the tabbing wrap around. I thought a little about bringing the close button into the loop, but then I imagined it being easy to tab to by accident and inadvertently close the bar, especially given that it already has a key combination. I'm not quite sure, though.

Dec. 28, 2012

ctrl-PageUp/Down

by corvid＠lavabit.com

Jorge wrote: > On Fri, Dec 28, 2012 at 07:18:08PM +0000, corvid wrote: > > > > I notice that ctrl-PageUp/Down for cycling through tabs doesn't work > > when a Fl_Input has focus. I can fix that if anyone cares... > > Yes, please. I fixed it for the ones for forms and Location. I wasn't sure whether the findbar one should, since it doesn't have too much and I'm in the habit of closing it so that I can use keys. (Although maybe that should be remedied after all...) In related news, I fixed ^I, ^J, ^L, ^M for form Inputs the other day, and I've been wondering whether I should for Location for any users who have non-default keys. At the moment, I'm leaning toward "yes".

Dec. 28, 2012

Ctrl-Tab and tabs

by jcid＠dillo.org

On Thu, Dec 27, 2012 at 10:46:22PM +0000, Jeremy Henty wrote: > > Johannes Hofmann wrote: > > > it seems that Ctrl-Tab no longer cycles tabs if an input field is > > focused. I did like the previous behaviour better, where Ctrl-Tab > > cycled tabs independent of where the focus was. > > +1. It is annoying that I now often have to click into the URL bar > before doing a Ctrl-(Shift)-Tab . > > It feels as though the browser window is handling the Tab key whether > or not it is modified by Ctrl. If it only handled Tab when Ctrl was > not applied and passed it on otherwise, then maybe that would do what > I would like. But I am guessing here - recent discussions in other > threads suggest that this may be more complicated than I realise. Yes, it's a bit complicated because FLTK doesn't use a signal/slot mechanism to deliver these events, it uses an event distribution algorithm (which is faster), but needs extra care. In the other thread I tried to explain the way I used in UI to handle them and avoid trouble. -- Cheers Jorge.-

Dec. 28, 2012