- Dillo-dev - lists.mailman3.com

Tab close button gets clobbered by tabs

by jcid＠dillo.org

On Wed, Aug 10, 2011 at 05:31:38PM -0400, Jorge Arellano Cid wrote: > On Tue, Aug 09, 2011 at 01:42:57AM +0000, corvid wrote: > > Rob wrote: > > > 2) From a practical standpoint, the old tabs seemed to behave a little > > > nicer, in that they would adjust their size a little bit to show more > > > of the title of the page opened in it. As it stands with Dillo 3, you > > > can't see much of the title text before it gets an ellipsis. > > > > I, too, would prefer titles that were not so short and that didn't have > > their descenders clipped. > > The attached code does this. I don't have much time now, so > please give it a look. > > Maybe the main point is to decide how to code tab-overflow > handling in a practical way (and to avoid complex code on the > details/preferences, but having a few ;). Well, I haven't had much time these days, but gave it a try anyway; Wow, this is full of details! 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. -- Cheers Jorge.-

Aug. 17, 2011

dillo close dialog and fluxbox on dual head

by corvid＠lavabit.com

higuita wrote: > i dont know if this is a problem with dillo or with fluxbox, but > when i try to close a dillo with several tabs, i get always the close dialog > (title is Choice5) on my secondary X11 head. If i try to setup fluxbox to > force the dialog to open on head 1, it still opens on head 2. > > if i do the same thing for all other dillo dialogs, like open > file, search (title ask), etc , i fluxbox puts the window in the > configured head. If i try to set the position and head, fluxbox puts the > dialog in the right position, but in the wrong head. How are you instructing fluxbox to do this? > If i try to run the fltk-1.3/test/message test, i can setup the > head of those messages without any problem. > > i'm using the latest dillo3 "hg version" with the latest fltk1.3 > svn , running on a slackware64 with Fluxbox 1.3.1 and a dual head setup. > The main head (1) is right, secondary head (2) is left. They are setup > with xrandr on a ati r600 card: > > xrandr --output DVI-0 --auto --primary --dpi 96 --output VGA-0 --left-of DVI-0 --auto --dpi 96 > xrandr --output DVI-0 --primary --set underscan off > > > As dillo is the only app i found with this problem, and even other > dillo windows work fine, i suspect something in dillo3 or in fltk1.3 that > is forcing the Choice5 dialog to stay on head 2... probably just because > is on the left (so closer to the 0,0 X11 virtual display corner), instead > of using the virtual position of each head. > > What you think? should i open a bug in fluxbox, in fltk or is > this a dillo problem? Does xprop show any interesting differences between a choice5 window and an ask window?

Aug. 17, 2011

dillo close dialog and fluxbox on dual head

by corvid＠lavabit.com

higuita wrote: > search (title ask) Hmm, that brings up the point that a_Dialog_input() needs to be renamed now that it has a list of search engines stuck inside it.

Aug. 17, 2011

dillo close dialog and fluxbox on dual head

by higuita7＠yahoo.co.uk

Hi i dont know if this is a problem with dillo or with fluxbox, but when i try to close a dillo with several tabs, i get always the close dialog (title is Choice5) on my secondary X11 head. If i try to setup fluxbox to force the dialog to open on head 1, it still opens on head 2. if i do the same thing for all other dillo dialogs, like open file, search (title ask), etc , i fluxbox puts the window in the configured head. If i try to set the position and head, fluxbox puts the dialog in the right position, but in the wrong head. If i try to run the fltk-1.3/test/message test, i can setup the head of those messages without any problem. i'm using the latest dillo3 "hg version" with the latest fltk1.3 svn , running on a slackware64 with Fluxbox 1.3.1 and a dual head setup. The main head (1) is right, secondary head (2) is left. They are setup with xrandr on a ati r600 card: xrandr --output DVI-0 --auto --primary --dpi 96 --output VGA-0 --left-of DVI-0 --auto --dpi 96 xrandr --output DVI-0 --primary --set underscan off As dillo is the only app i found with this problem, and even other dillo windows work fine, i suspect something in dillo3 or in fltk1.3 that is forcing the Choice5 dialog to stay on head 2... probably just because is on the left (so closer to the 0,0 X11 virtual display corner), instead of using the virtual position of each head. What you think? should i open a bug in fluxbox, in fltk or is this a dillo problem? Thanks in advance for the help and thanks for dillo higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Aug. 17, 2011

Horizontal scrolling with mouse buttons

by jcid＠dillo.org

On Mon, Aug 15, 2011 at 02:18:33PM -0400, saulgoode(a)flashingtwelve.brickfilms.com wrote: > Quoting Jorge Arellano Cid <jcid(a)dillo.org>: > > > Please try dillo-3.0-pre, following these directions [1]. > >Then report back how it goes. > > > > [1] http://www.dillo.org/source.html > > With that build, the horizontal scroll buttons are inactive. To my > mind this is satisfactory behavior as it does not interfere with the > vertical scrolling of the mouse wheel (previously the only way to > restore vertical wheel scrolling was to restart the program). Good! This looks like an issue with fltk-1.3. FWIW, inside fltk-1.3 src/Fl_x.cxx:1443, there's no code to handle those buttons. Having something like the following may be worth a try (if you're a coder): if (xevent.xbutton.button == Button4) { Fl::e_dy = -1; // Up event = FL_MOUSEWHEEL; } else if (xevent.xbutton.button == Button5) { Fl::e_dy = +1; // Down event = FL_MOUSEWHEEL; + } else if (xevent.xbutton.button == Button6) { + Fl::e_dx = -1; // Left + event = FL_MOUSEWHEEL; + } else if (xevent.xbutton.button == Button7) { + Fl::e_dx = +1; // Right + event = FL_MOUSEWHEEL; } else { Fl::e_state |= (FL_BUTTON1 << (xevent.xbutton.button-1)); event = FL_PUSH; checkdouble(); } > Thank you for your response. :) -- Cheers Jorge.-

Aug. 16, 2011

Horizontal scrolling with mouse buttons

by jcid＠dillo.org

Hi, On Sat, Aug 13, 2011 at 09:53:50PM -0400, saulgoode(a)flashingtwelve.brickfilms.com wrote: > I have a Logitech wheel mouse which supports horizontal scrolling by > pressing the scroll wheel to either the left or right. These actions > generate mouse button events where the button is identified as > either "6" or "7" respectively. > > Dillo handles these horizontal scroll events properly, but afterward > the scrollwheel no longer works for vertical scrolling (the > scrollwheel up/down events are reported as buttons "4" and "5" > respectively); instead the scrollwheel results in left/right > scrolling. > > I am running Dillo 2.2 on a Slackware system. Please try dillo-3.0-pre, following these directions [1]. Then report back how it goes. [1] http://www.dillo.org/source.html -- Cheers Jorge.-

Aug. 15, 2011

Horizontal scrolling with mouse buttons

by saulgoode＠flashingtwelve.brickfilms.com

I have a Logitech wheel mouse which supports horizontal scrolling by pressing the scroll wheel to either the left or right. These actions generate mouse button events where the button is identified as either "6" or "7" respectively. Dillo handles these horizontal scroll events properly, but afterward the scrollwheel no longer works for vertical scrolling (the scrollwheel up/down events are reported as buttons "4" and "5" respectively); instead the scrollwheel results in left/right scrolling. I am running Dillo 2.2 on a Slackware system. Regards.

Aug. 14, 2011

moveToWidget

by jcid＠dillo.org

On Thu, Aug 11, 2011 at 04:13:51AM +0000, corvid wrote: > Jorge wrote: > > On Tue, Aug 09, 2011 at 04:16:13AM +0000, corvid wrote: > > > <div> > > > <a href="http://www.dillo.org">I am a link. How exciting!</a> > > > <div>a div. Move down here and the link url is still shown.</div> > > > Ordinary text outside of the div. Status output is blanked when moving down here. > > > </div> > > [snip] > > > It looks like only testing will tell us whether there're other > > corner cases lurking around. > > Add a title attr to the link. Let the tooltip pop up. Move the mouse > cursor down into the child div. The tooltip remains visible. Oh, yes... Fortunately this is not a problem in the dispatcher. Please check current tip. -- Cheers Jorge.-

Aug. 11, 2011

Tab close button gets clobbered by tabs

by fabio.pasini＠gmail.com

Hello there, >Maybe the main point is to decide how to code tab-overflow >handling in a practical way (and to avoid complex code on the >details/preferences, but having a few ;). Is it feasible to have multiple lines for tabs, something like "Tab Mix Plus" does on Firefox? As an (somehow exaggerated) example: http://thasulinux.files.wordpress.com/2011/03/tab_mix_plus.png When there are too many tabs open, the tab label can become too tiny to be useful, in this cases having multiple lines looks more suitable to me (but, again, it's a personal opinion). Something like keep putting tabs in one line, and if the tabs become too narrow, add a second line, then keep going on (plus displaying a warning popup when some limit is reached) Best regards, F?bio Pasini 2011/8/10 Jorge Arellano Cid <jcid(a)dillo.org> > On Tue, Aug 09, 2011 at 01:42:57AM +0000, corvid wrote: > > Rob wrote: > > > 2) From a practical standpoint, the old tabs seemed to behave a little > > > nicer, in that they would adjust their size a little bit to show more > > > of the title of the page opened in it. As it stands with Dillo 3, you > > > can't see much of the title text before it gets an ellipsis. > > > > I, too, would prefer titles that were not so short and that didn't have > > their descenders clipped. > > The attached code does this. I don't have much time now, so > please give it a look. > > Maybe the main point is to decide how to code tab-overflow > handling in a practical way (and to avoid complex code on the > details/preferences, but having a few ;). > > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Aug. 11, 2011

moveToWidget

by corvid＠lavabit.com

Jorge wrote: > On Tue, Aug 09, 2011 at 04:16:13AM +0000, corvid wrote: > > <div> > > <a href="http://www.dillo.org">I am a link. How exciting!</a> > > <div>a div. Move down here and the link url is still shown.</div> > > Ordinary text outside of the div. Status output is blanked when moving down here. > > </div> [snip] > It looks like only testing will tell us whether there're other > corner cases lurking around. Add a title attr to the link. Let the tooltip pop up. Move the mouse cursor down into the child div. The tooltip remains visible.

Aug. 11, 2011