January 2013 - Dillo-dev - lists.mailman3.com

ui colors again

by corvid＠lavabit.com

I added some more to the color choosing stuff: http://www.dillo.org/test/choose_colors2.diff It's not terribly nice, careful code at this point. It knows about the more recent prefs, and I spent some time making the menu fancy for some reason. If we can't get the inactive icons at least nearly for free, I'm tempted to go back to the old ones instead of adding special code. (I didn't initially expect us to have much if any of a runtime mechanism to change colors.) I suspect the Tabs doesn't want to send the redraw() down to the tab buttons because of damage bits or something, but I ran out of steam on this for the night...

Jan. 3, 2013

ui colors again

by jcid＠dillo.org

On Wed, Jan 02, 2013 at 09:05:16PM +0000, corvid wrote: > Jorge wrote: > > For instance, adding these vars to the current set: > > > > tab_bg_color, tab_fg_color, > > tab_text_active_color, tab_text_inactive_color > > ui_button_highlight_color > > menu_active_item_color, > > > > would allow for huge themability options. > > > > I know it looks like an overkill, but yesterday, playing with > > the "toy" color chooser, with colors/themes I never use, found > > that some of our "good defaults" are poor choices for completely > > different color schemes. > > > > The good part is that with a detailed color vars set, a theme > > becomes a small set of integers. Quite easy to handle. > > Okay, I'll add a bunch of prefs for us to experiment with. Good. Attached goes some test code I used to test tab colors. HTH. FWIW, I get close to the traditional colors with: ui_fg_color=140040 ui_main_bg_color=c6c6c6 ui_text_bg_color=bfdabf ui_tab_active_color=87aca7 ui_tab_inactive_color=silver > > Ideally yes. Now, it needs some care. For instance, the "toy" > > chooser changes ui background well, but doesn't update the colors > > of inactive buttons with the new backgrounds (which makes a huge > > difference with bluish backgrounds. e.g. ui_main_bg_color=0070c0). > > Yeah, I'll put a little more time into the toy later. Background also > needs to update the gray ramp so that box colors work better, for > instance... OK. -- Cheers Jorge.-

Jan. 2, 2013

ui colors again

by corvid＠lavabit.com

BTW, although our John Grantham icons hold up well when the background is dark, the others don't do as well. It's a pity that I don't have the artistic background to mimic his...

Jan. 2, 2013

ui colors again

by corvid＠lavabit.com

Jorge wrote: > For instance, adding these vars to the current set: > > tab_bg_color, tab_fg_color, > tab_text_active_color, tab_text_inactive_color > ui_button_highlight_color > menu_active_item_color, > > would allow for huge themability options. > > I know it looks like an overkill, but yesterday, playing with > the "toy" color chooser, with colors/themes I never use, found > that some of our "good defaults" are poor choices for completely > different color schemes. > > The good part is that with a detailed color vars set, a theme > becomes a small set of integers. Quite easy to handle. Okay, I'll add a bunch of prefs for us to experiment with. > Ideally yes. Now, it needs some care. For instance, the "toy" > chooser changes ui background well, but doesn't update the colors > of inactive buttons with the new backgrounds (which makes a huge > difference with bluish backgrounds. e.g. ui_main_bg_color=0070c0). Yeah, I'll put a little more time into the toy later. Background also needs to update the gray ramp so that box colors work better, for instance...

Jan. 2, 2013

wizard, switching between UIs

by jcid＠dillo.org

On Wed, Jan 02, 2013 at 05:55:42PM +0000, corvid wrote: > Jorge wrote: > > On Sat, Dec 29, 2012 at 09:21:31PM +0000, corvid wrote: > > > > > > Yesterday I was playing with ctrl-tab, of course, and I noticed how the > > > state of the focused tab would sometimes change. > > > > What's "the state of the focused tab"? > > Suppose you have two tabs open and you ctrl-tab between them. > - If, in the rightmost one, Location had focus, when it gets focus again, > suddenly the whole location text is highlighted (Fl_Input.cxx:616). > - If the rightmost one has Main focused, when you switch back to it, > Location has focus (Fl_Group.cxx:130, 159). Ah, now I see! Please add a comment like this to either the source or the hg patch upon commit. -- Cheers Jorge.-

Jan. 2, 2013

wizard, switching between UIs

by corvid＠lavabit.com

Jorge wrote: > On Sat, Dec 29, 2012 at 09:21:31PM +0000, corvid wrote: > > > > Yesterday I was playing with ctrl-tab, of course, and I noticed how the > > state of the focused tab would sometimes change. > > What's "the state of the focused tab"? Suppose you have two tabs open and you ctrl-tab between them. - If, in the rightmost one, Location had focus, when it gets focus again, suddenly the whole location text is highlighted (Fl_Input.cxx:616). - If the rightmost one has Main focused, when you switch back to it, Location has focus (Fl_Group.cxx:130, 159).

Jan. 2, 2013

ui colors again

by jcid＠dillo.org

On Sun, Dec 30, 2012 at 07:20:54PM +0000, corvid wrote: > Jorge wrote: > > * 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. > > It would be nice if we had a sort of...minimal covering set of the different > sorts of color schemes that a person could "sensibly" (whatever that can mean) > want for the sake of testing. I imagine the world of graphic design must have > such a thing (if only I knew the right words to find it)... Yes, 3 or four packed themes would be OK (ideally selectable from the UI), but tweakable from dillorc vars (this is a common solution). A set of common "color schemes" is not easy to find though. For instance, I use LXDE/openbox, and it comes with near a hundred packed themes! In openbox's theme set, sometimes a darker color is used to the focused window, other themes use the reverse, and there're plenty which use the same color and a a brighter font to hint focus. With this state of things, I tend to favor specific variables in dillorc over trying to guess what could be right. For instance: tab_bg_color tab_fg_color instead of a fl_lighter()/fl_darker() combination. BTW, the current dillo repo guesses my theme backwards, but it does great for other colors, and not good on others. For instance, adding these vars to the current set: tab_bg_color, tab_fg_color, tab_text_active_color, tab_text_inactive_color ui_button_highlight_color menu_active_item_color, would allow for huge themability options. I know it looks like an overkill, but yesterday, playing with the "toy" color chooser, with colors/themes I never use, found that some of our "good defaults" are poor choices for completely different color schemes. The good part is that with a detailed color vars set, a theme becomes a small set of integers. Quite easy to handle. > Perhaps it would be good to be able to change colors at runtime, especially > since we already allow the panel size to change. I'll have a look at that > color chooser that fltk has. Ideally yes. Now, it needs some care. For instance, the "toy" chooser changes ui background well, but doesn't update the colors of inactive buttons with the new backgrounds (which makes a huge difference with bluish backgrounds. e.g. ui_main_bg_color=0070c0). Of course it should also be able to manage saving the custom defined theme. I'd first try with a certain colors var set, then define some themes, make them UI-selectable, and finally decide whether a color chooser for all of them is worth (YMMV, the reverse approach may also fit ;). -- Cheers Jorge.-

Jan. 2, 2013

wizard, switching between UIs

by jcid＠dillo.org

On Sat, Dec 29, 2012 at 09:21:31PM +0000, corvid wrote: > > Yesterday I was playing with ctrl-tab, of course, and I noticed how the > state of the focused tab would sometimes change. What's "the state of the focused tab"? > I went through a few rounds > of fixing this in different ways before finding something that didn't seem > icky. Detailed comment in patch. Yeah, from time to time, something like the patch you describe is necessary with FLTK (silent resize of hidden widgets comes to mind...) -- Cheers Jorge.-

Jan. 2, 2013

Render bug

by jcid＠dillo.org

On Mon, Dec 31, 2012 at 07:52:11PM +0000, corvid wrote: > Alexander wrote: > > Dear Dillo developers, > > > > sorry for not creating a proper bug report, but the "How to reproduce" > > message field is too small for the example file. :) > > > > The issue > > ========= > > > > After closing the "Save As" dialog, the background color of the HTML > > page is not redrawn correctly (leaving white rectangles instead of the > > background color). > > > > How to reproduce > > ================ > > > > 1. open the appended html file (note the grey background) > > 2. click on "file" link > > 3. move the "Save As" window over the grey background > > 4. close the "Save As" window --> parts of the background are drawn > > white, instead of grey > > What if we do something like the attached? We might be able to get away > with a smaller fix, but this seemed sensible conceptually. +1 It looks OK to me after reviewing/reading it a few times. Although I haven't made tests on it, I'd say please feel free to commit when it passes yours. -- Cheers Jorge.-

Jan. 2, 2013

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

by jcid＠dillo.org

On Tue, Jan 01, 2013 at 10:30:04PM +0000, Jeremy Henty wrote: > > p37sitdu at lavabit.com wrote: > > > On Sun, Dec 30, 2012 at 05:23:18PM +0000, Jeremy Henty wrote: > > > > > > 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. Capi shows a warning in the command line... Anyway, the request (a local file copy) is ignored, but can be implemented easily in the dpi for orthogonality. > [...] > I wonder what is the real benefit of a separate downloads DPI. Is it > actually useful to have one downloads window for all Dillo processes? You'll find the rationale in doc/Dpid.txt -- Cheers Jorge.-

Jan. 2, 2013