- Dillo-dev - lists.mailman3.com

[PATCH] Open a new tab by middle clicking on tab close button

by a1ex＠dismail.de

Hi, This patch enables the 'tab close' button to open a new tab when middle-clicked. This allows us to open a new tab with just one click instead of two. Of course it is possible to add a separate button for this, but to prevent clutter this might be a better solution. Regards, Alex diff -upr a/src/uicmd.cc b/src/uicmd.cc --- a/src/uicmd.cc Sat Jul 26 21:03:50 2025 +++ b/src/uicmd.cc Wed Jul 30 12:23:52 2025 @@ -223,6 +223,9 @@ static void close_tab_btn_cb (Fl_Widget *, void *cb_da if (b == FL_LEFT_MOUSE) { a_UIcmd_close_bw(a_UIcmd_get_bw_by_widget(tabs->wizard()->value())); } + if (b == FL_MIDDLE_MOUSE) { + a_UIcmd_open_url_nt(a_UIcmd_get_bw_by_widget(tabs->wizard()->value()), NULL, 1); + } } int CustTabs::handle(int e)

July 30, 2025

[PATCH] Use contrasting color for widget selections

by a1ex＠dismail.de

Hi, Here is a cleaned up version of my previous patch. I have been testing it quite a bit and for me it is working OK with both dark and light backgrounds. Just to recap the issue: Dillo currently hard-codes the color black to be used as the widget selection color (checkmarks, radio buttons, etc). When using a dark background, these selections appear to be invisible. With this patch, we ensure that the selction is visible by contrasing the selection color against the background. Any feedback welcome. Regards, Alex --- a/dw/fltkui.cc Sun Apr 27 18:56:44 2025 +++ b/dw/fltkui.cc Thu May 22 15:02:20 2025 @@ -1171,8 +1171,11 @@ void FltkToggleButtonResource<I>::setWidgetStyle (Fl_W core::style::Style *style) { FltkResource::setWidgetStyle(widget, style); - - widget->selection_color(FL_BLACK); + FltkColor *bg = (FltkColor*)style->backgroundColor; + int normal_bg = bg->colors[FltkColor::SHADING_NORMAL]; + int style_fg = ((FltkColor*)style->color)->colors[FltkColor::SHADING_NORMAL]; + Fl_Color fg = fl_contrast(style_fg, normal_bg); + widget->selection_color(fg); }

May 22, 2025

Re: Question regarding styling input checkbox element

by a1ex＠dismail.de

<a1ex(a)dismail.de> wrote: > Here is a working patch which I believe fixes it so that it uses the > foreground color: Sorry, I hit send too fast! It doesn't actually use the CSS foreground color, but creates a contrasting color based on the background. Maybe not ideal, but probably better than the current behavior.

May 21, 2025

Re: Question regarding styling input checkbox element

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > For some reason is always hardcoded to be black. Here is making it > always red: Thanks, looks great now! > See commit fa967f233fe6da82a98aaf3e2149d7aa5e1516cc for context, but > not sure why is not just inheriting the CSS foreground color. Here is a working patch which I believe fixes it so that it uses the foreground color: diff -upr a/dw/fltkui.cc b/dw/fltkui.cc --- a/dw/fltkui.cc Sun Apr 27 18:56:44 2025 +++ b/dw/fltkui.cc Wed May 21 14:01:08 2025 @@ -1171,8 +1171,12 @@ void FltkToggleButtonResource<I>::setWidgetStyle (Fl_W core::style::Style *style) { FltkResource::setWidgetStyle(widget, style); - - widget->selection_color(FL_BLACK); + FltkColor *bg = (FltkColor*)style->backgroundColor; + int normal_bg = bg->colors[FltkColor::SHADING_NORMAL]; + int style_fg = ((FltkColor*)style->color)->colors + [FltkColor::SHADING_NORMAL]; + Fl_Color fg = fl_contrast(style_fg, normal_bg); + widget->selection_color(fg); } Regards, Alex

May 21, 2025

Re: Question regarding styling input checkbox element

by Kevin Koster

a1ex-J7K0XVabL0iELgA04lAiVw(a)public.gmane.org wrote: > When using a dark css theme (I like to use a black background), putting > a checkmark in a checkbox is invisible (black). I tried messing around > with style.css with various configurations for input, but it seems > impossible to make the checkmark anything other than black. > > It's not a huge issue, but when editing bookmarks it becomes a little > annoying. I've got visible checkboxes on a black background with this style.css in Dillo 3.2.0: * {color: #00f400} html {background-color: gray !important} body, div, span, nav, p, a, form, h1, h2, h3, h4, h5, h6, ul, ol, li, table, tr, td {background-color: black} img, map {background-color: gray !important} :link {text-decoration: none !important; color: #00f5e8 !important} :visited {text-decoration: none !important; color: #a020f0 !important} That style does make the bookmarks page look pretty odd with its CSS enabled, but it's intended to avoid dark-on-black content on some websites.

May 20, 2025

Re: Question regarding styling input checkbox element

by Rodrigo Arias

Hi, On Tue, May 20, 2025 at 01:33:43PM +0000, a1ex(a)dismail.de wrote: >Hi, > >When using a dark css theme (I like to use a black background), putting >a checkmark in a checkbox is invisible (black). I tried messing around >with style.css with various configurations for input, but it seems >impossible to make the checkmark anything other than black. > >It's not a huge issue, but when editing bookmarks it becomes a little >annoying. > >Any suggestions, or is this just a limitation of the css implementation? For some reason is always hardcoded to be black. Here is making it always red: diff --git a/dw/fltkui.cc b/dw/fltkui.cc index db7c94e2..2d3882d2 100644 --- a/dw/fltkui.cc +++ b/dw/fltkui.cc @@ -1172,7 +1172,7 @@ void FltkToggleButtonResource<I>::setWidgetStyle (Fl_Widget *widget, { FltkResource::setWidgetStyle(widget, style); - widget->selection_color(FL_BLACK); + widget->selection_color(FL_RED); } See commit fa967f233fe6da82a98aaf3e2149d7aa5e1516cc for context, but not sure why is not just inheriting the CSS foreground color. Best, Rodrigo.

May 20, 2025

Question regarding styling input checkbox element

by a1ex＠dismail.de

Hi, When using a dark css theme (I like to use a black background), putting a checkmark in a checkbox is invisible (black). I tried messing around with style.css with various configurations for input, but it seems impossible to make the checkmark anything other than black. It's not a huge issue, but when editing bookmarks it becomes a little annoying. Any suggestions, or is this just a limitation of the css implementation? Thanks, Alex

May 20, 2025

Re: [PATCH] Revert "Use right button to close tabs by default"

by Plasma (David Paul)

On Wed, 30 Apr 2025 22:52:57 +0200 Rodrigo Arias <rodarima(a)gmail.com> wrote: > On Wed, Apr 30, 2025 at 03:31:21PM -0500, Plasma (David Paul) wrote: > >This reverts commit 6392699316bbdfd027862fa28050cd54253f25d4. > >--- > > > >Notes: > > This change addresses two issues: > > > > 1. This restores the ability to close a tab by middle-clicking on > > it. This matches long-supported behaviour of other browsers. > > Since when do we follow what other browsers do? Ok, maybe that wasn't the best way to phrase that. It's not just browsers that support closing a tab by middle-clicking; it is also the standard behaviour in both my IRC client and my graphical text editor (in addition to my other browsers). Dillo having a different default is disorienting in a similar manner (though, admittedly, not to the same severity) as driving a vehicle and discovering that the functions of the pedals are flipped. > > 2. Right-clicking a tab is now no longer a destructive action. > > It is common user expectation that right-clicking may produce a > > contextual menu. This expectation should not result in a lost tab. > > Not interested in this patch, not all systems have 3 mouse button, > specially old netbooks. If you prefer to use the middle button change > the option in dillorc. Alas. -- Plasma

May 1, 2025

Re: [PATCH] Revert "Use right button to close tabs by default"

by Rodrigo Arias

Hi, On Wed, Apr 30, 2025 at 03:31:21PM -0500, Plasma (David Paul) wrote: >This reverts commit 6392699316bbdfd027862fa28050cd54253f25d4. >--- > >Notes: > This change addresses two issues: > > 1. This restores the ability to close a tab by middle-clicking on >it. This matches long-supported behaviour of other browsers. Since when do we follow what other browsers do? > 2. Right-clicking a tab is now no longer a destructive action. It is > common user expectation that right-clicking may produce a >contextual menu. This expectation should not result in a lost tab. Not interested in this patch, not all systems have 3 mouse button, specially old netbooks. If you prefer to use the middle button change the option in dillorc. Rodrigo.

April 30, 2025

[PATCH] Revert "Use right button to close tabs by default"

by Plasma (David Paul)

This reverts commit 6392699316bbdfd027862fa28050cd54253f25d4. --- Notes: This change addresses two issues: 1. This restores the ability to close a tab by middle-clicking on it. This matches long-supported behaviour of other browsers. 2. Right-clicking a tab is now no longer a destructive action. It is common user expectation that right-clicking may produce a contextual menu. This expectation should not result in a lost tab. dillorc | 2 +- src/prefs.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dillorc b/dillorc index dbe36f53..a3d22adc 100644 --- a/dillorc +++ b/dillorc @@ -424,7 +424,7 @@ ui_tab_bg_color=#b7beb7 # A mouse's middle click over a tab closes the Tab. # With mousewheel mouses, right click feels way better (set to YES). -#right_click_closes_tab=YES +#right_click_closes_tab=NO # Scroll over tabs (using the mouse wheel) to switch among tabs. # If set to NO, the page will be scrolled instead. diff --git a/src/prefs.c b/src/prefs.c index a57c792c..09b693a2 100644 --- a/src/prefs.c +++ b/src/prefs.c @@ -81,7 +81,7 @@ void a_Prefs_init(void) prefs.load_stylesheets=TRUE; prefs.middle_click_drags_page = TRUE; prefs.middle_click_opens_new_tab = TRUE; - prefs.right_click_closes_tab = TRUE; + prefs.right_click_closes_tab = FALSE; prefs.scroll_switches_tabs = TRUE; prefs.scroll_switches_tabs_reverse = FALSE; prefs.no_proxy = dStrdup(PREFS_NO_PROXY); -- Plasma

April 30, 2025