Re: [Dillo-dev]new here

[Sebastian G. <S.G...@pi...>]

Allan Clark wrote:
> 
> Hi
> As the subject says I'm new here,

Welcome!

> but I would like to submit a patch,
> which I *think* fixes bug number 62 where the horizontal rules mean that
> when Dillo reformats after being down-sized it gives the user an
> unneccesary horizontal slider.
> I defined a new flag in dw.c which is set when a widget is a set to fill
> all the horizontal space available, then dw_hruler.c is changed to set
> this flag and then dw_page.c is changed so that we check for the flag
> when reformating and deal with it accordingly.
> The way I have dealt with it means that the hrule will be as long as the
> text of the page is, this means that it won't be as long as an image
> which may be longer (check with dillo on the dillo homepage to see
> this), this is the way Netscape renders it, but would be easy to change
> if you don't like it.

It is planned to port Dw to Gtk+, and I'm currently working on DwPage.
DwHruler will then not used anymore (at least, unless all attributes
will be supported), but simply GtkHSeparator.

(I've some general doubts on the port, and wrote Jorge about it, but
didn't get an anser yet.)

I thought that size negotiation should be similar as in Gtk+, i.e.
containers should (mainly) be responsible for it, plus a few
extensions (look into the list archives). This is just your idea,
except that all parameters are stored in the container. For this I
defined:

struct _DwPageChild
{
   GtkWidget *widget;
   gfloat rel_width;	/* 0: do not resize,
			   otherwise: relative to DwPage's width */
   gfloat rel_height;	/* analogue */
};

/* ... */

void a_Dw_page_add_widget (DwPage *page,
			   GtkWidget *widget,
			   gfloat rel_width,
			   gfloat rel_height,			   
			   gint attr);

Compare it e.g. with GtkBoxChild resp. gtk_box_pack_start.

I tested it with GtkHSeparator (setting rel_width to 1.0), and it
(mainly) works. This also makes rules with other widths simple (as
soon as centered text is implemented).

> Also I think it mucks up slightly if the horizontal rule is not directly
> after a hard break, (that is the hrule isn't on a line all by itself, again
> this should be easy to fix) it seems to render slightly further than it should.
> Anyway see what you think.

Since <hr>'s are allways the only widget on a line, it is probably the
best to insert hard breaks before and after them.

> [...]

Sebastian