Re: patch: images: working menu, deferred loading; page menu works
Hi, On Mon, Oct 29, 2007 at 11:18:21PM +0000, place wrote:
(I could have sworn that I sent you a patch making the page menu work, but since I didn't realize that it wasn't in the main tree until I was preparing this patch, it's included here. I'll likely end up separating it out as we go through the process of refining the rest of this patch...)
This has an extra argument in the link signals, as you recommended, instead of the array of image handlers that my previous version used.
I had to add an x_img to style.
The link block stores the Image and the url until loading is requested.
Great! I made an extensive revision of the patch and commited it with some minor changes (attached so you can review and sync more easily). Urbi et orbi, this patch set more or less is: - Added code for the image menu and hooked it to dw2 signals. - Hooked the page and link menus. - Added code for optional image loading (nice interface) very advanced! - Fixed the position of the Bug Meter popup menu. - Added an extra argument in the link signals - Aded an x_img camp to style (an image array index, like x_link).
Although there's no placeholder, if there's anything to click on, left click loads instances of that image and middle click loads all images on the page. The latter should probably be in the page menu instead.
The patch is very advanced and here go my comments: Yes, a place holder is the next step (sometimes image size is provided as attributes in the IMG element, some others not; in which case we can use a standard size). Note that with the current patch, images that are also links are not working (i.e. clicking on them loads the image but doesn't follow the link). I understand that left-clicking to load an image is quite handy. Now, FLTK2 has a nice feature with popups and it's that they can remember a menuitem position. If we make the right click popup remember the "load image" item, the same easeness of user interface may be attained (you may look in the test/menu program inside fltk2 sources). I also agree that "load all images" naturally belongs to the page menu. BTW, with regard to the toggle button, in the past I thought of a toolbox icon with a popup holding things like: "Load images" // toggle item "Force my colors" // toggle item "Restrict width" // toggle item ... It looks lilke a good idea to me, but I don't know whether in practice this is as convenient as it looks. Comments welcomed. -- Cheers Jorge.-
Note that with the current patch, images that are also links are not working (i.e. clicking on them loads the image but doesn't follow the link). I understand that left-clicking to load an image is quite handy. Now, FLTK2 has a nice feature with popups and it's that they can remember a menuitem position. If we make the right click popup remember the "load image" item, the same easeness of user interface may be attained (you may look in the test/menu program inside fltk2 sources).
Oops! Images that are links work in my personal tree, but I overlooked in when making the patch... The first click loads the image, and subsequent ones follow the link. Are you saying that you would prefer that it be moved to the menu anyway? I've been using left click to load for years now, and I would find it significantly less convenient to use the menu for every image...
On Thu, Nov 01, 2007 at 04:53:48PM +0000, place wrote:
Note that with the current patch, images that are also links are not working (i.e. clicking on them loads the image but doesn't follow the link). I understand that left-clicking to load an image is quite handy. Now, FLTK2 has a nice feature with popups and it's that they can remember a menuitem position. If we make the right click popup remember the "load image" item, the same easeness of user interface may be attained (you may look in the test/menu program inside fltk2 sources).
Oops! Images that are links work in my personal tree, but I overlooked in when making the patch... The first click loads the image, and subsequent ones follow the link.
Are you saying that you would prefer that it be moved to the menu anyway? I've been using left click to load for years now, and I would find it significantly less convenient to use the menu for every image...
The point is that it may be handy to follow an image-link without loading the image (I'm not sure how useful though). The idea is to try how does it work with the right-click-popup + item preselection. This is you right click (don't move the mouse), and the "load image" item is right there, and thus you can just right-click to load an image and also right click + move mouse for other options. If this is not as useful as the former, we can go back (or make it a preference), but I see some value in trying, because that way, the orthogonality of the UI, as a whole, is preserved. -- Cheers Jorge.-
On Thu, Nov 01, 2007 at 03:03:31PM -0300, Jorge Arellano Cid wrote:
On Thu, Nov 01, 2007 at 04:53:48PM +0000, place wrote:
Are you saying that you would prefer that it be moved to the menu anyway? I've been using left click to load for years now, and I would find it significantly less convenient to use the menu for every image...
The point is that it may be handy to follow an image-link without loading the image (I'm not sure how useful though).
I think it's definitely useful, for example when you have a slow internet connection. Moreover, text browsers link elinks show that browsing without images has its uses. BTW, the "reload" button does not reload the current page, but the most recent one in the history list. This is not the same if you have gone back one or more pages. Cheers, -- Matthias Franz
BTW, the "reload" button does not reload the current page, but the most recent one in the history list. This is not the same if you have gone back one or more pages.
I've attached a small patch that appears to work for me.
On Fri, Nov 02, 2007 at 07:45:01PM +0000, place wrote:
BTW, the "reload" button does not reload the current page, but the most recent one in the history list. This is not the same if you have gone back one or more pages.
I've attached a small patch that appears to work for me.
This bug is just one in a set, but it has a simple solution: diff -pru dillo2/src/nav.c dillo2-cur/src/nav.c --- dillo2/src/nav.c 2007-10-25 17:18:04.000000000 -0300 +++ dillo2-cur/src/nav.c 2007-11-02 19:14:03.000000000 -0300 @@ -70,7 +70,7 @@ int a_Nav_get_top_uidx(BrowserWindow *bw { nav_stack_item *nsi; - nsi = dList_nth_data (bw->nav_stack, a_Nav_stack_size(bw) - 1); + nsi = dList_nth_data (bw->nav_stack, a_Nav_stack_ptr(bw)); return (nsi) ? nsi->url_idx : -1; } Commited. ;) -- Cheers Jorge.-
Jorge wrote:
Yes, a place holder is the next step (sometimes image size is provided as attributes in the IMG element, some others not; in which case we can use a standard size).
I made an image placeholder in place of a placeholder image... I'm not sure whether I offer this in jest or in earnest, but it's simple, anyway. And suffices for me.
participants (3)
-
jcid＠dillo.org -
matthias.franz＠ujf-grenoble.fr -
place＠gobigwest.com