- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]Dillo: Bug#568

by Jim Nutt

On Wed, 9 Jun 2004 09:52:44 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> wrote: > in the bug track. I can't reproduce it, so maybe it's a GTK > problem. What version are you using? (BTW dillo 0.8.1 or CVS is > assumed). > > I tried several pages, but for instance, going to our home > page, making the tooltip for bookmarks appear, and scrolling with > the keyboard works OK for me. Can anyone reproduce this bug? If it helps, I can't reproduce it either (running CVS as of 6/8) -- jim nutt home: jim(a)nuttz.org jabber: jimnutt(a)jabber.com work: jimnutt(a)vestek.com ms msg: jim(a)nuttz.org pgp id: 1ECBCC78

June 9, 2004

[Dillo-dev]Dillo: Bug#568

by Jorge Arellano Cid

Hi, There's: 568 Impact: soft error At: run time Type: render bug Comments: When a button tooltip is displayed, and you scroll the page with the keyboard, dillo fails to render the newly exposed content. This is the same behaviour reported for images in bug 289. HTReproduce: Open any page taller than the view area, place the mouse over a dillo control, when the tool tip appears, scroll the page with the keyboard. WorkedBy: nobody Submitter: dmckee*jlab*org in the bug track. I can't reproduce it, so maybe it's a GTK problem. What version are you using? (BTW dillo 0.8.1 or CVS is assumed). I tried several pages, but for instance, going to our home page, making the tooltip for bookmarks appear, and scrolling with the keyboard works OK for me. Can anyone reproduce this bug? Cheers Jorge.-

June 9, 2004

Re: [Dillo-dev][전체회신] Re: [Dillo-dev]Downloads File

by Jorge Arellano Cid

Hi Vinod, On Fri, 26 Mar 2004 vinod(a)etri.re.kr wrote: > Hi Jorge > > > Hi all > Hi Vinod. > I assume you received my email, and after considering, you > decided to work on the GUI dpi for downloads. > (please confirm me that) > > # Yes. I did intend to confirm after reply from mailing list regarding work. Since then I haven't had any news about this. :-( Have you made some progress with the cleanup of the GUI dpi for downloads? Cheers Jorge.-

June 9, 2004

Re: [Dillo-dev]patch for bug 211

by Jorge Arellano Cid

On Sun, 6 Jun 2004, Diego Sáenz wrote: > Hello. Hi Diego. > Here i send a patch for the dillo bug 211 (remember save dir on save and open dialogs) based on a pactch for an old version of dillo (0.6.¿?). it was made for 0.8.1 but apply in current cvs too. Each dillo window remember its own save dir. Sorry if this is not the right place to send patchs. Yes, that's an old need. When I first received the patch from Lars, I asked him to "Please make separate buffers for open and save". It'd be also good to make it browser wide (i.e. not per window), and maybe add a "download_directory" entry to dillorc. The latter doesn't seem urgent though, because we still don't have a graphical dpi for downloads... Please make the suggested changes to the patch. Cheers Jorge.- PS: Feedback is welcome.

June 9, 2004

[Dillo-dev]Using alternate char for TABBING

by Deon Stoltz

I have recently discovered dillo and am delighted! Very fast and lightweight. We want to use if in a settop box application (thus the lightweight requirement). We need to interface to a IR remote control device so no keyboard are available. Web pages can normally be navigated with the TAB key. In our application we need to associate the TAB key with another key eg: ctrl-A. Do somebody know how, where to do this? I had a look in the code but I am not that strong on c++. ANY help will be appreciated! Thanks Deon

June 9, 2004

[Dillo-dev]Content outside table border

by Jorge Arellano Cid

Hi Sebastian, Just found this page: http://www.757.org/~joat/blog/ look at the small calendar! Best Jorge.-

June 9, 2004

Re: [Dillo-dev]Some remarks on the UI

by Jorge Arellano Cid

On Sun, 6 Jun 2004, Sebastian Geerken wrote: > Hi, > > I've just committed several changes, which fix the issues mentioned > here. Please test and report any bugs. If you are not sure, whether > you have detected a bug, it's certainly a misfeature, so report it > anyway :-) I reviewed the patch and commited some changes. Here go my comments: * I liked very much the new menu-title widget! * gcc showed some "missing initializer" warnings. It was the lack of the latest pointer in three GtkTypeInfo structures. Fixed. * The "." shortcut was not working. Fixed. * There was a warning for a signed/unsigned comparison, so I switched _GtkExtButton's pressed_button to guint. Fixed. * The "View Page Bugs" menu item for the page menu doesn't work. It went to a segfault once. NOT fixed. Some inside comments refer to unused code, for instance on Home and reload buttons. Yes, it was meant for future extensions (e.g. a reload images menu item). Now that there's a new way to code this (as with Back and Forward), the old way can be safely deleted. I changed the text for the tooltips of these buttons. Lots of mouses have two buttons and emulate the middle-click when both are pressed, so "right-click" and "middle-click" are a bit better than numbers in this case. It was nice to see the middle-click over "clear-url" button as a shortcut for paste. It'd be perfect if the entry can be focused at the same time. > > On Tue, Jun 01, Jorge Arellano Cid wrote: > > On Mon, 31 May 2004, Sebastian Geerken wrote: > > > 1. Bug meter: The bug meter button reacts on the "pressed" event, to > > > show the window, but it should react on the "clicked" signal. > > > Popping up a window after a "pressed" signal is usually only done > > > for volatile windows (like menus, or overview windows, like in > > > GIMP, which often vanish again, after releasing the mouse button). > > > > > > Reacting on "pressed" is always a bit problematic, also because the > > > pointer grab initiated with this event can cause side-effects. > > Fixed. > > > > Furthermore, it should not have a relief, compare to the "Hide > > > Controls" button. > > Also fixed, I've removed the relief. Yes, the toolbar icons and the "Hide controls" one are OK without a relief, but after watching how the bug-meter button looks without a relief, and how much it hints the user of being a button, I'd much prefer to have the relief back. Note that the "Hide controls" button has a drawed frame around that helps getting the idea of it being a button! Perhaps a more orthogonal way of doing it is to have a relief for both, but it's simpler to keep it as it was. > > > > 2. The menus behind the "Back" and "Forward" buttons: Consider the > > > following scenario: > > > > > > (i) The user presses button 3 on the "Back" button, and the menu > > > is shown. > > > > > > (ii) He keeps the button pressed, moves to one entry in the menu, > > > and releases the button. Nothing happens. > > > > > > Currently, the menu items only react on "button_press", which is > > > anyway wrong (see above). Furthermore, in this situation, the item > > > should already react on the "release" event, either as described > > > above, or in the way (i) click on menu, (ii) click on menu > > > entry. The current behaviour is that much confusing, that a user > > > may think that it does not work at all. (I did!) > > > > Yes. Sometime ago Ricardo Persichetti sent me a patch for this. > > It's just a couple of lines. Now on CVS for testing purposes, > > plus enhanced pixmaps for Back and Forward that hint their right > > click menus. > > I've written two new widgets, GtkExtMenu and GtkExtMenuItem, which > handle this in a cleaner way. Connecting to "button-release-event" has > several disadvantages, what I've seen until now, is: (i) keyboard > navigation was not handled, and (ii) the menu was hidden too late. > > The new widgets resemble the standard way as far as possible, so > problems shouldf be minimized. Good! > > > BTW, it is not very obvious, that there is a menu behind these two > > > buttons. Perhaps there should be, in the icon, a small arrow > > > directed downdwards, or so. > > > > Done! > > You forgot the small icons, this is fixed now. Also, I've added text > to the tooltips. Cute icons :) > > > 3. Attached is the incomplete code of a new widget, which changes the > > > behaviour of GtkButton: > > > > > > (i) It reacts also on button 2 and 3, this would make multiple > > > functions for one button possible. Actually, this feature > > > should be reserved for very few situation (since it is simply > > > confusing), namely the "Clear URL" button, which may also be > > > used for visiting the URL in the selection buffer. > > > > > > (ii) It provides a function for attaching a menu in a better way, > > > than we have currently, for the "Back" and "Forward" menus, > > > and for the bug meter. > > > > > > Simply copy all files into one directory, call "make", and run > > > "testprg". Look, what happens with different mouse buttons. > > > > Interesting. I went through the code a bit. > > > > It's not obvious to me how to modify them to be able to provide > > the same functionality (new window on middle click on history), > > and not to screw the design at the same time. > > Has been enhanced integrated (for forward, backward, and bug > meter). See comments in the code. Good work. It looks cleaner too. Cheers Jorge.-

June 8, 2004

[Dillo-dev]patch for bug 211

by Diego Sáenz

Hello. Here i send a patch for the dillo bug 211 (remember save dir on save and open dialogs) based on a pactch for an old version of dillo (0.6.¿?). it was made for 0.8.1 but apply in current cvs too. Each dillo window remember its own save dir. Sorry if this is not the right place to send patchs. DarkSpirit/Diego Sáenz

June 6, 2004

Re: [Dillo-dev]Some remarks on the UI

by Sebastian Geerken

On Sun, Jun 06, Sebastian Geerken wrote: > I've just committed several changes, which fix the issues mentioned > here. ... Just in case, that someone has already checked this out: There was a bug in the changes, which is fixed in the meanwhile. Sebastian

June 6, 2004

Re: [Dillo-dev]Some remarks on the UI

by Sebastian Geerken

Hi, I've just committed several changes, which fix the issues mentioned here. Please test and report any bugs. If you are not sure, whether you have detected a bug, it's certainly a misfeature, so report it anyway :-) On Tue, Jun 01, Jorge Arellano Cid wrote: > On Mon, 31 May 2004, Sebastian Geerken wrote: > > 1. Bug meter: The bug meter button reacts on the "pressed" event, to > > show the window, but it should react on the "clicked" signal. > > Popping up a window after a "pressed" signal is usually only done > > for volatile windows (like menus, or overview windows, like in > > GIMP, which often vanish again, after releasing the mouse button). > > > > Reacting on "pressed" is always a bit problematic, also because the > > pointer grab initiated with this event can cause side-effects. Fixed. > > Furthermore, it should not have a relief, compare to the "Hide > > Controls" button. Also fixed, I've removed the relief. > > 2. The menus behind the "Back" and "Forward" buttons: Consider the > > following scenario: > > > > (i) The user presses button 3 on the "Back" button, and the menu > > is shown. > > > > (ii) He keeps the button pressed, moves to one entry in the menu, > > and releases the button. Nothing happens. > > > > Currently, the menu items only react on "button_press", which is > > anyway wrong (see above). Furthermore, in this situation, the item > > should already react on the "release" event, either as described > > above, or in the way (i) click on menu, (ii) click on menu > > entry. The current behaviour is that much confusing, that a user > > may think that it does not work at all. (I did!) > > Yes. Sometime ago Ricardo Persichetti sent me a patch for this. > It's just a couple of lines. Now on CVS for testing purposes, > plus enhanced pixmaps for Back and Forward that hint their right > click menus. I've written two new widgets, GtkExtMenu and GtkExtMenuItem, which handle this in a cleaner way. Connecting to "button-release-event" has several disadvantages, what I've seen until now, is: (i) keyboard navigation was not handled, and (ii) the menu was hidden too late. The new widgets resemble the standard way as far as possible, so problems shouldf be minimized. > > BTW, it is not very obvious, that there is a menu behind these two > > buttons. Perhaps there should be, in the icon, a small arrow > > directed downdwards, or so. > > Done! You forgot the small icons, this is fixed now. Also, I've added text to the tooltips. > > 3. Attached is the incomplete code of a new widget, which changes the > > behaviour of GtkButton: > > > > (i) It reacts also on button 2 and 3, this would make multiple > > functions for one button possible. Actually, this feature > > should be reserved for very few situation (since it is simply > > confusing), namely the "Clear URL" button, which may also be > > used for visiting the URL in the selection buffer. > > > > (ii) It provides a function for attaching a menu in a better way, > > than we have currently, for the "Back" and "Forward" menus, > > and for the bug meter. > > > > Simply copy all files into one directory, call "make", and run > > "testprg". Look, what happens with different mouse buttons. > > Interesting. I went through the code a bit. > > It's not obvious to me how to modify them to be able to provide > the same functionality (new window on middle click on history), > and not to screw the design at the same time. Has been enhanced integrated (for forward, backward, and bug meter). See comments in the code. Sebastian

June 6, 2004