Dillo-dev

Download

By thread

dillo-dev@mailman3.com

1 participants
11683 messages

What's pending for RC2

by jcid＠dillo.org

Hi there, So far we have: [ok] moveToWidget(). Jorge has code for this. [ok] downloads dpi string escaping. [ok] alt text wrapping (which looks like a nice feature). [ok] remove large panel. [ok] https dialog storm (BUG#868). [ok] The findbar input doesn't know about Ctrl+{a,e,d,k}. [ok] something other than "ctab%d" for initial tab label. [ok] single close tab button with tooltip. [ok] valgrind logs: close window [ok] valgrind logs: cancel expected url [ok] segfault with Ctrl-s (web search) [ok] UI_TEMPORARILY_SHOW_PANELS [ok] leave link into a native FLTK widget [ok] remove pointeronlink(), panelmode_cb_i() [ok] the panel problems when resizing from very small. [ok] resize problems when tabs overflow [ok] URL_ILLEGAL_CHARS [ok] Fixed CustLightButton "light" color deactivation. [ok] hoverTooltip glitch (tooltip linger when going into a child DIV). [ok] tab overflow (code a handler) [ok] valgrind error for first tab close, then resize(). [ok] update the Changelog [ ] default search engine [ ] new-tab and window title [ ] CSS adjacent sibling selectors I'd like to comment some: [ok] tab overflow (code a handler) Please send feedback on how it works. Remember that polish and eye candy was left for the next release. [ok] update the Changelog Corvid and Johannes may have some pending items to add. BTW, at this point the Changelog has a summary of user-visible changes, which reduces clutter given that the full history is in hg. Please vote. me: +1 on keeping it this way. [ ] default search engine I've been using search_url="http://duckduckgo.com/lite/?kp=-1&q=%s" and it works quite well for me. Please vote. me: +1 for making it the default Also I'd like to add some default search engines. For instance, this one is very useful for me: search_url="Free Dictionary http://www.thefreedictionary.com/%s" Comments/suggestions? [ ] new-tab and window title This is a simple deatail that I'll look into quickly. [ ] CSS adjacent sibling selectors Johannes has to decide on this. -- Cheers Jorge.-

Aug. 24, 2011

Tab close button gets clobbered by tabs

by corvid＠lavabit.com

Jorge wrote: > On Tue, Aug 23, 2011 at 09:17:12PM +0000, corvid wrote: > > Jorge wrote: > > > OK, current repo has a bare bones handler. It is simple and > > > easy to extend. The idea is to have something solid for the > > > release (and to polish it afterwards). > > > > > > Please test it and send feedback. > > > > It doesn't refresh well after middle-clicking to close. > > > > Also, when you open a new tab and it gets focus, the window title isn't > > updated. > > Please check current tip... It seems to be working well in general so far, but what I mean about the new tab is that I press ctrl-T and I still see the old page title.

Aug. 24, 2011

Tab close button gets clobbered by tabs

by jcid＠dillo.org

On Tue, Aug 23, 2011 at 09:17:12PM +0000, corvid wrote: > Jorge wrote: > > OK, current repo has a bare bones handler. It is simple and > > easy to extend. The idea is to have something solid for the > > release (and to polish it afterwards). > > > > Please test it and send feedback. > > It doesn't refresh well after middle-clicking to close. > > Also, when you open a new tab and it gets focus, the window title isn't > updated. Please check current tip... -- Cheers Jorge.-

Aug. 24, 2011

Tab close button gets clobbered by tabs

by jcid＠dillo.org

On Tue, Aug 23, 2011 at 09:17:12PM +0000, corvid wrote: > Jorge wrote: > > OK, current repo has a bare bones handler. It is simple and > > easy to extend. The idea is to have something solid for the > > release (and to polish it afterwards). > > > > Please test it and send feedback. > > It doesn't refresh well after middle-clicking to close. > > Also, when you open a new tab and it gets focus, the window title isn't > updated. Oh, I made a stupid mistake (which I'll look for now). It worked perfectly until the last commit where making the proverbial "little change that doesn't need testing" screwed the whole thing. Sorry... -- Cheers Jorge.-

Aug. 24, 2011

Tab close button gets clobbered by tabs

by corvid＠lavabit.com

Jorge wrote: > OK, current repo has a bare bones handler. It is simple and > easy to extend. The idea is to have something solid for the > release (and to polish it afterwards). > > Please test it and send feedback. It doesn't refresh well after middle-clicking to close. Also, when you open a new tab and it gets focus, the window title isn't updated.

Aug. 23, 2011

Tab close button gets clobbered by tabs

by jcid＠dillo.org

On Sun, Aug 21, 2011 at 01:38:11PM -0300, Jorge Arellano Cid wrote: > Hi there, > > On Wed, Aug 17, 2011 at 09:44:16AM -0400, Jorge Arellano Cid wrote: > [...] > > [ ] tab overflow (code a handler) > > The idea is to have a tab overflow handler for the release. > > After sorting lots of details, the code I was making works, but > adds lots of complexity for little gain, so I decided to try a > different approach (adding all this stuff just before the > release is too dangerous). > > Fortunately the second prototype works much better and is way > simpler. > > I'll try to have it in the repo soon. If by some reason this > doesn't happen by Aug 24, the release will roll without a > polished tab overflow handler. > > > > I hope to soon have something that works enough for the > > release. In the meanwhile, the repo has had a good testing window > > so the RC dance should be short. > > Please treat current repo as release candidate 1. OK, current repo has a bare bones handler. It is simple and easy to extend. The idea is to have something solid for the release (and to polish it afterwards). Please test it and send feedback. FYI, even though eye-candy animation looked cool here I preferred to leave it out of the source tree for the release. -- Cheers Jorge.-

Aug. 23, 2011

modifier keys (Re: [Dillo-dev] Two bugs in the Dillo GUI (both Mac and ubuntu))

by corvid＠lavabit.com

I wrote: > Can anyone with windows keys verify that they don't set FL_META? > There _is_ code for: > > // For the first few years, there wasn't a good consensus on what the > // Windows keys should be mapped to for X11. So we need to help out a > // bit and map all variants to the same FLTK key... > switch (keysym) { > case XK_Meta_L: > case XK_Hyper_L: > case XK_Super_L: > keysym = FL_Meta_L; > break; > case XK_Meta_R: > case XK_Hyper_R: > case XK_Super_R: > keysym = FL_Meta_R; > break; > } > > and maybe there's something going on somewhere that I haven't noticed. > I ask because perhaps we'll want to open an STR to get FL_META set. I think I see what happens. On X (well, x.org, anyway), it apparently comes through for free as the Mod4Mask bit in XButtonEvent.state, so expecting to see the word 'meta' somewhere was no good.

Aug. 22, 2011

modifier keys (Re: [Dillo-dev] Two bugs in the Dillo GUI (both Mac and ubuntu))

by corvid＠lavabit.com

I wrote: > By the way, the only mention of FL_META in Fl_x.cxx is > > # ifdef __sgi > // get the meta key off PC keyboards: > if (fl_key_vector[18]&0x18) Fl::e_state |= FL_META; > # endif > > I'd assumed that, for FLTK under X, Meta was a synonym for Alt, > or maybe the windows keys or something (which I don't have). Can anyone with windows keys verify that they don't set FL_META? There _is_ code for: // For the first few years, there wasn't a good consensus on what the // Windows keys should be mapped to for X11. So we need to help out a // bit and map all variants to the same FLTK key... switch (keysym) { case XK_Meta_L: case XK_Hyper_L: case XK_Super_L: keysym = FL_Meta_L; break; case XK_Meta_R: case XK_Hyper_R: case XK_Super_R: keysym = FL_Meta_R; break; } and maybe there's something going on somewhere that I haven't noticed. I ask because perhaps we'll want to open an STR to get FL_META set.

Aug. 22, 2011

Two bugs in the Dillo GUI (both Mac and ubuntu)

by corvid＠lavabit.com

I wrote: > Back in June, reza wrote: > > 4. This one is more of a feature request. Like most Mac applications, the > > shortcuts should work with Command key instead of control key. (I know it's > > low priority, and I might give it a shot myself later on). > > I'm wondering whether it would be helpful to mention in keysrc that > meta = command, or would that already be known by (or at least exceedingly > obvious to) everyone using osx? By the way, the only mention of FL_META in Fl_x.cxx is # ifdef __sgi // get the meta key off PC keyboards: if (fl_key_vector[18]&0x18) Fl::e_state |= FL_META; # endif I'd assumed that, for FLTK under X, Meta was a synonym for Alt, or maybe the windows keys or something (which I don't have).

Aug. 22, 2011

Two bugs in the Dillo GUI (both Mac and ubuntu)

by corvid＠lavabit.com

Back in June, reza wrote: > 4. This one is more of a feature request. Like most Mac applications, the > shortcuts should work with Command key instead of control key. (I know it's > low priority, and I might give it a shot myself later on). I'm wondering whether it would be helpful to mention in keysrc that meta = command, or would that already be known by (or at least exceedingly obvious to) everyone using osx? BTW, 1.3 has #ifdef __APPLE__ # define FL_COMMAND FL_META ///< An alias for FL_CTRL on WIN32 and X11, or FL_META on MacOS X # define FL_CONTROL FL_CTRL ///< An alias for FL_META on WIN32 and X11, or FL_CTRL on MacOS X #else # define FL_COMMAND FL_CTRL ///< An alias for FL_CTRL on WIN32 and X11, or FL_META on MacOS X # define FL_CONTROL FL_META ///< An alias for FL_META on WIN32 and X11, or FL_CTRL on MacOS X #endif // __APPLE__ although I don't think this can do us any good in our circumstances.

Aug. 22, 2011

Jump to page: