path: root/old/oldmail/200103.txt

[Dillo-dev]Dpi1 Development

From: <sirver@gm...> - 2001-03-31 23:06

Attachments: dpi1.first.test.tar.gz      

Hi there,

i started implementing the dpi1 plugins.
With the patch and the files included in the tar.gz (is it ok to attach
files on this list, when they <50k ??) dillo searches the paths
"(all listed in rcfile under plugins_dirs):~/.dillo/plugins:/usr/local/share/dillo/plugins" for files named *.dpi1. Those are treated as plugins.
the plugin engine already registers Prefix plugins.
I also included DNS support throu dillo (for caching).
I ran into problems with HTML output: a dpiSendData should have some
HTML tags in his data field. Now, dillo should read them and treat them
like a normal HTML site. I tried this (see the Answer_handling
functions), but dillo coredumps (in cache.c, callback function). I don't
know why and how to change this. Do somebody know a better/working way?
In the attachement ist also a perl script which is my testing plugin. I
hope it will help you.

Thanks.
Holger 



Re: [Dillo-dev]Font modifying tags

From: Sebastian Geerken <S.Geerken@pi...> - 2001-03-31 13:14

Hi,

I intended to post this in a few days, since I'm currently working on
attributes. I wondered what has happened with the implementation of
the <font> tag.

I'll soon upload a few changes, which are a first simple step towards
my (currently still a bit vague) idea of a common style scheme. Some
time ago, Sean posted a problem to the list: handling lists of fonts
(as "Arial, Helvetica, sans-serif") is quite difficult with the
current code. This will solved by the change, the font loading code
will be rewritten to handle lists quite simply.

More on this after finishing the code, and please look at the changes
in a few days.


Sebastian 



Re: [Dillo-dev]Update on Alt patch

From: Sebastian Geerken <S.Geerken@pi...> - 2001-03-31 13:14

Hi,

I've committed the patch, after making some changes, extensions, and
cleanups:

- I've made an own submodule of it, so it can be also used for
other purposes.

- I copied the drawing code from gtktooltip.c, so the tooltips look
(but do not behave) exactly like Gtk+ tooltips. This includes
drawing functions and tooltip size.

I also fixed two bugs in Dw:

1. It sometimes happened that a leave_notify "event" was sent to a
widget already destroyed.

2. Crossing events of the viewport are now recognized (this was
mentioned as a "todo" in the sources).

On Fri, Mar 30, Livio Baldini Soares wrote:
> [...]
> * I tried adding a Dw_image_destroy function, and in the end adding a
> parent_class->destroy (initializing parent_class in
> Dw_image_class_init), but I must have done something wrong because I
> couldn't get it to work... all I got was Segmentation Fault :-(

This may also have been by the first bug I mentioned above?

> [...]
> * Now to tooltip "feels" better. It takes almost one second to appear
> (if the cursor is stoped), and it will disappear immediately when
> you move it.

I changed the delay to 500 ms, this is the standard of Gtk+.

> Well I think that's all. The only problem (at least in my opinion)
> is that the placement of the tooltip inside the image should be better
> chosen then (x+10, y+10) like I currently do. I looked at
> gtktooltips.c and it kind of sucks (at least this part about chosing
> tooltip position). It considers that widget's size is small, but
> working with images is a totally diferent issue (they are too big, and
> can sometimes cover up more than half the screen, and in these case
> Gtk's toolips do badly).

Yes, this is true. I did not change it, since I don't have a better
idea.

On Fri, Mar 30, Jorge Arellano Cid wrote:
> [...]
> - ALT for the IMG element is an alternative for non visual user
> agents. i.e. there's no need to show the ALT text and the image.
> I know that some users like it, just add the necessary toggle in
> dillorc and send me the patch when done.

Yes, the tooltip implementation is indeed not what ALT is intended
for. Nevertheless the code might be used for other purposes, and the
changes in dw_image.c are minimal.

However, ALT may also used by visual user agents, e.g. the text could
be drawn before the image data is retrieved, what is especially useful
if the image URI is broken.


Sebastian 



Re: [Dillo-dev]Bug #116 (alt tags for images)

From: Livio Baldini Soares <livio@li...> - 2001-03-31 08:46

Hi Jorge and all!

Jorge Arellano Cid writes:
> 
> Hi,
> 
> This issue seems to be almost done, but I just wanted to add a
> couple of comments:
> 
> - ALT for the IMG element is an alternative for non visual user
> agents. i.e. there's no need to show the ALT text and the image.
> I know that some users like it, just add the necessary toggle in
> dillorc and send me the patch when done.

Ok, done! New features are:

* "show_alt"=[Yes/No] option in dillorc as preference.

* Fixed Dw_image_motion_notify() return value. Seems that I had to
return FALSE and not TRUE, otherwise I could break the detection of
motion events of other widgets which you need them (like in
viewport, to detect if there's motion in an image which is also a
link, and therefore draw a "hand" cursor).

* Finally got right the Dw_image_destroy() function. The problem I had
before was that was freeing image->buffer, but, as I saw later,
that's a pointer to a Dicache entry :-(

> - The Cache is not related to widget allocations/deallocations,
> it just caches URL contents, and nothing else!

Yes, you're right! Thanks for the tip.

I've sent my patch to Jorge, but the eager ones can always get my
Dillo patches at: http://www.linux.ime.usp.br/~livio/dillo/

-- 
Livio <livio@li...> 



[Dillo-dev]Re: Dillo UI

From: Jorge Arellano Cid <jcid@ne...> - 2001-03-31 02:50

Terry,

> Jorge:
>
> You seem to be the man in charge...
>
> Below is a quick, _clean_ addition to the UI that is half of what Dillo is
> missing. It adds four lines to the
> file menu.c,
> function a_Menu_popup_new,
> line 177:
>
> This adds Ctrl-H and Alt-H as Back and Forward hot keys:
>
> Menu_add(menu, "Back", "<ctrl>H", bw,
> a_Commands_back_callback, bw);
> Menu_add(menu, "Forward", "<alt>H", bw,
> a_Commands_forw_callback, bw);
>
> This was a 'quick' fix and took at least several hours to track down. Could
> NOT figure out how to get that fscking BackSpace key to work so I used Ctrl-H
> instead. Hint hint :-)

I'll check that and try to find out a mnemonic key combination
(Maybe Ctrl + '<' and Ctrl + '>') Please be patient because I'm
working on several areas...


> The other thing that is needed from a basic UI perspective is for the Web page
> position to be stacked for recall upon return. Really hate it when I have a
> 1/4 meg web page up, am half way down it, hit a link and then have to find
> where I was all over again after a Back operation. I would contemplate trying
> to fix it, but in view of how long it took just to add a
> couple of accelerator keys,
> you guys will have it fixed before I could even figure it out. But all of this
> is just a
> _minor_ quibble.

Yes, this has being going in my mind from a long time too.
I think a good implementation is to keep the vertical scrolling
position within the history record (within the URL structure that
we're working with Livio). From there it will be a simple matter
to implement. We're working on it now. BTW: I'll try to answer
Livio's request tomorrow (Yes Livio, I've made some progress!).


> Really Fine Work! This is what a browser is supposed to be. Don' need no
> steenkin' key clicks, this is fast enough to make its own sonic crack (Slack
> 7.05 [7.0+2.2.18 kernel] 233Mhz PIII, 64 Meg RAM). Keep up the good work, and
> the speed, and the small size and...oh what the hell, _keep_ producing a
> miracle.
>
> Regards,
> Terry Loveall

Thanks a lot for your comments Terry.

Jorge.- 



[Dillo-dev]Re: dillo

From: Jorge Arellano Cid <jcid@ne...> - 2001-03-31 02:49

Jon,

> Hello, I've been using dillo for the past couple of months. The dillo
> browser is absolutely great, it does not crash, and it is very fast on any
> machine I run it on. I beleive the 0.4.0 version is more stable then my
> netscape.
>
> I just thought I'd put in a good word for the browser because I like it
> alot. One thing I'd like to see, although, is a way to use the mailto:
> command. I use Balsa GNOME email client, it has a command to just bring up
> a 'new message' and let you compose. The command is 'balsa
> --compose=user@ho...' the entire program does not come up, just the 'new
> message' window... Would it not be easy enough to add this feature to
> dillo, allowing to write a responce to a mailto:?

It will be easy when plugins get implemented. A simple task
really. We're working on the plugins implementattion, and I hope
it to begin working soon, at least with the basic functionality.
You'll have to wait until then.

> Thanks again for creating the dillo browser!

You're welcome.
Jorge.- 



Re: [Dillo-dev]Bug #116 (alt tags for images)

From: Jorge Arellano Cid <jcid@ne...> - 2001-03-31 02:49

Hi,

This issue seems to be almost done, but I just wanted to add a
couple of comments:

- ALT for the IMG element is an alternative for non visual user
agents. i.e. there's no need to show the ALT text and the image.
I know that some users like it, just add the necessary toggle in
dillorc and send me the patch when done.

- The Cache is not related to widget allocations/deallocations,
it just caches URL contents, and nothing else!


Jorge.- 



[Dillo-dev]IO progress

From: Jorge Arellano Cid <jcid@ne...> - 2001-03-31 02:49

Hi again,

The last weeks I've been trying to devote most of my time to
finishing the IO engine error control design. This had been a
several times procrastinated task, and I wish to push it forward
as much as I can this time.

The good news is that I've progressed a lot. The whole
querying branch of the browser has been checked, re-structured
and modified to integrate the concomitant control-chain (CCC)
that manages and defines all the data-passing and messaging
between modules.

This is working pretty good on my machine, and solves the
overcaching bug.

I haven't commited my changes to the CVS yet, because I want
to work with the answering branch before I make definitive
changes.


Please be patient.
Jorge.- 



[Dillo-dev]Update on Alt patch

From: Livio Baldini Soares <livio@li...> - 2001-03-30 08:39

Hi everyone!

Thanks so much for all the feedback (learned a lot ;-)!
Now I have a new version (hopefully improved) for you guys to try
out. It's in the same place:
http://www.linux.ime.usp.br/~livio/dillo/alt.diff 

I'll comment the changes, hopefully including everyone's remarks and
opinions: 

Jörgen, your patch worked nicely so I included it along with mine!

Sebastian,

* I replicated "somewhat" the timeout function used in gtktooltips.c
and it worked nicely! With that I even enabled
Dw_image_motion_notify events to remove the timeout (this goes along
with Eric's suggestion to remove the alt if the cursor has motion).
The timeout "slice" I put is 700 miliseconds which feels fine in my
computer.

* I tried adding a Dw_image_destroy function, and in the end adding a
parent_class->destroy (initializing parent_class in
Dw_image_class_init), but I must have done something wrong because I
couldn't get it to work... all I got was Segmentation Fault :-(

Eric,

* Now the tooltip has borders (and almost looks like a shadows...)
Seems that the correct function to call was gtk_paint_box() and not
gtk_paint_flat_box() which I was using before :-( gtk's
documentation sucks!).

* I removed tooltips arraising when no "alt" is defined.

* Now to tooltip "feels" better. It takes almost one second to appear
(if the cursor is stoped), and it will disappear immediately when
you move it.


Well I think that's all. The only problem (at least in my opinion)
is that the placement of the tooltip inside the image should be better
chosen then (x+10, y+10) like I currently do. I looked at
gtktooltips.c and it kind of sucks (at least this part about chosing
tooltip position). It considers that widget's size is small, but
working with images is a totally diferent issue (they are too big, and
can sometimes cover up more than half the screen, and in these case
Gtk's toolips do badly).

Any ideas or comments about anything said is always appreciated!

best regards to all,

-- 
Livio <livio@li...> 



[Dillo-dev]Font modifying tags

From: Livio Baldini Soares <livio@li...> - 2001-03-30 04:39

Hi all, hi Sean,

I accidently started implementing font tags again :-( I was looking
through Eric's new Html.testsuite when I noticed some tags weren't
implemented, so I eagerly starting hacking...
Then I remembered: "Shit! Sean is doing that already...". 
So Sean, if it isn't any trouble, could you list the tags that you've
already implemented? (The ones I did were the <big> and <small>... I
cheated and implemented then both under one Html_tag_open_*() function
;-)

Please don't think I'm rushing you to finish or commit your code!
I'm just curious to what you've already done and also it will help me
not forget to stay away from certain places in Dillo... :^P

best regards,

-- 
Livio <livio@li...> 



Re: [Dillo-dev]Bug #116 (alt tags for images)

From: Sebastian Geerken <S.Geerken@pi...> - 2001-03-29 14:43

Hi Livio, Eric, and all.

A few answers about the patch.

First of all, tooltips may be used also in other contexts, e.g. for
the "title" attribute of several tags, so I'll perhaps move the code
to a lower level. More on this later.

On Wed, Mar 28, Livio Baldini Soares wrote:
> [...]
> I was going to implement the alt text as a simple tooltip, but after
> trying a little I realized that that would take more time/trouble than
> creating my own little "tooltip" window. So I did it from
> scrap...

Gtk+ tooltips are intended for Gtk+ widgets, so adopting them is hard.
After trying this, too, I think I'll agree you, that it is simpler to
reimplement them.

> [...]
> The first is that on other browsers the alt takes a while to show,
> but the way I've made it, it shows up immediately. What should we do?
> I didn't even bother to think up a way to have this "wait" time before
> activating alt text, but I guess it could be done...

It should be simple, you just have to add a timeout function, and take
care to remove it when the pointer leaves the image before the tooltip
is shown. I think the best way is simply to imitate the behavior of
Gtk+ tooltips, and copy code from gtktooltips.c.

> The second thing is that in Dw_image_enter_notify() I alloc() a new
> alt-window and in Dw_image_leave_notify() I free() it. It might not
> sound good, but I've got a (crude) reason. Generally, what we think to
> do in this case is on Dw_image_init(), alloc() everything we need and
> in Dw_image_{enter,leave}_notify() we just call
> gtk_window_{show,hide}(). But the problem is, when do we destroy it?
> As a matter of fact this is a problem I've seen in Dillo... there
> seems to be more *_new() functions than *_destroy(). But of course
> this would have to be associated with the Cache scheme getting rid of
> unwanted (old-)structs and therefore calling those destroys. My
> question is, what to do now? Leave it the way I did it, or is it
> better to prepare it for when the Cache starts doing some struct
> (data) destruction?

You can add a Dw_image_destroy function. Note that
Dw_image_leave_notify may not have been called when the image widget
is destroyed, so this is a memory leak.

On Wed, Mar 28, Eric GAUDET wrote:
> [...]
> - tooltips are generally drawn in pale yellow, grey looks strange. What about a
> dillorc option for that ?

Livio called the widget "Image alt", so you can modify your ~/.gtkrc.
Perhaps the name should be changed to "gtk-tooltips", like Gtk+ tooltips.

> - I'd prefer the tooltip window to have a border so it looks detached from the
> page. (better yet: if you could draw a shadow, it would be perfect)

This should be the purpose of gtk_paint_flat_box, but it somehow does
not work. Replacing it with

gdk_draw_rectangle (image->img_alt->window,
style->fg_gc[GTK_STATE_NORMAL],
FALSE, 0, 0, width + 7, ascent + descent + 7);

works, but won't honor different themes.

> [...]
> - A tooltip window can hide another image on the right and prevent it to catch
> enter_notify (see the "screenshot" below ;-). If you mouve the mouse cursor
> from "img1" to "img2" passing over the "tooltip" window, the tooltip for img2
> will show only when crossing the rightmost border of the "tooltip" (dran with
> '#'). 
> 
> +-------+ +---------+
> | | | |
> | +---------+ |
> | | tooptip # |
> | +---------+ |
> | | | |
> | | | |
> +-------+ +---------+
> img1 img2

This is because some events get lost, they are sent to the tooltip,
not to the viewport (which is furthermore *not* the parent of the
tooltip window).

If you look at Gtk+ tooltips, you'll notice that this problem does not
occur, since the tooltips are placed outside the widgets. Perhaps this
is a useful possibility.

Furthermore, the Dw event mechanism isn't complete yet.


Sebastian 



Re: [Dillo-dev]Bug #116 (alt tags for images)

From: Jörgen Viksell <vsksga@ho...> - 2001-03-28 23:27

Attachments: patch-alt      

>.... Well the only trouble I was having was to transform strings
>sizes into pixel sizes... it depends on the case, the font and
>sometimes even the letter (like, "i" is narrower than "w").. but then
>browsing through gtk's 1.2.7 source code, I discovered
>gdk_string_{width,height}(), and my life got much better ;-)

I believe you should use gdk_string_extents() instead.
The ascent you get from that function is the strings and thus makes the 
string middle-aligned.
The attached patch does that. (I hope! :-))

>--
> Livio <livio@li...>
>

Cheers,
Jörgen
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. 



RE: [Dillo-dev]Bug #116 (alt tags for images)

From: Eric GAUDET <egaudet@in...> - 2001-03-28 05:59

Hi Livio :-)

-- En reponse de "[Dillo-dev]Bug #116 (alt tags for images)" de Livio Baldini
Soares, le 28-Mar-2001 :
> Hi guys!
> 
> Finally I got the time to make the alt text for images like I
> promised. I had already done them (but badly) before Sebastian's new
> Dw, but wanted to wait for it. Now I'm glad I did... it was so much
> easier and it's more stable... thanks Sebastian!
> 

Ok, I "carefully reviewed" this feature ;-) and here's what I think (you may
or may not agree with each):
- tooltips are generally drawn in pale yellow, grey looks strange. What about a
dillorc option for that ?
- I'd prefer the tooltip window to have a border so it looks detached from the
page. (better yet: if you could draw a shadow, it would be perfect)
- a tooltip is drawn even if there's no "atl" attribute for the image ! It
shows "png for a png image, etc. I don't like it so much. (If you print the
image size, 320x200 (png), I could like it ;-)
- A tooltip window can hide another image on the right and prevent it to catch
enter_notify (see the "screenshot" below ;-). If you mouve the mouse cursor
from "img1" to "img2" passing over the "tooltip" window, the tooltip for img2
will show only when crossing the rightmost border of the "tooltip" (dran with
'#'). 

+-------+ +---------+
| | | |
| +---------+ |
| | tooptip # |
| +---------+ |
| | | |
| | | |
+-------+ +---------+
img1 img2

...
> 
> The first is that on other browsers the alt takes a while to show,
> but the way I've made it, it shows up immediately. What should we do?
> I didn't even bother to think up a way to have this "wait" time before
> activating alt text, but I guess it could be done...
> 

I'd prefer the tooltip to appear only when the mouse cursor hasn't moved for
one seconde or so over an image, and disapear as soon as the mouse is moved.
This would solve the above issue with tooltip overlapping an image.

...
> 
> The patch can be found at:
> http://www.linux.ime.usp.br/~livio/dillo/alt.diff
> 
> Please send any comments on it. If you have trouble downloading,
> tell me and I can send it by email.
> 

Best,
------------------------------------
Eric GAUDET <egaudet@in...>
Le 28-Mar-2001 a 14:41:04
"In theory, there's no difference between 
theory and practice; in practice, there is.
------------------------------------ 



[Dillo-dev]Bug #116 (alt tags for images)

From: Livio Baldini Soares <livio@li...> - 2001-03-28 04:01

Hi guys!

Finally I got the time to make the alt text for images like I
promised. I had already done them (but badly) before Sebastian's new
Dw, but wanted to wait for it. Now I'm glad I did... it was so much
easier and it's more stable... thanks Sebastian!

I was going to implement the alt text as a simple tooltip, but after
trying a little I realized that that would take more time/trouble than
creating my own little "tooltip" window. So I did it from
scrap... Well the only trouble I was having was to transform strings
sizes into pixel sizes... it depends on the case, the font and
sometimes even the letter (like, "i" is narrower than "w").. but then
browsing through gtk's 1.2.7 source code, I discovered
gdk_string_{width,height}(), and my life got much better ;-)
The final result is that my code is simpler then the tooltip one (but
I guess tooltip must be more robust...), and I think it's ok, except
for the details I bring up below.

The first is that on other browsers the alt takes a while to show,
but the way I've made it, it shows up immediately. What should we do?
I didn't even bother to think up a way to have this "wait" time before
activating alt text, but I guess it could be done...

The second thing is that in Dw_image_enter_notify() I alloc() a new
alt-window and in Dw_image_leave_notify() I free() it. It might not
sound good, but I've got a (crude) reason. Generally, what we think to
do in this case is on Dw_image_init(), alloc() everything we need and
in Dw_image_{enter,leave}_notify() we just call
gtk_window_{show,hide}(). But the problem is, when do we destroy it?
As a matter of fact this is a problem I've seen in Dillo... there
seems to be more *_new() functions than *_destroy(). But of course
this would have to be associated with the Cache scheme getting rid of
unwanted (old-)structs and therefore calling those destroys. My
question is, what to do now? Leave it the way I did it, or is it
better to prepare it for when the Cache starts doing some struct
(data) destruction?

The patch can be found at:
http://www.linux.ime.usp.br/~livio/dillo/alt.diff

Please send any comments on it. If you have trouble downloading,
tell me and I can send it by email.

By the way, I've also been busy doing a new URL-passing scheme,
which Jorge asked for some time ago... This was really tough to do and
is still very bad :-( But anyway I got a "working" patch.
Jorge did you receive the e-mail I sent to you last weekend (I think
Saturday)? I send it to jcid@em... and attached the patch (it's
big). If you haven't then tell me and I'll repost it. (I mean no rush
in sending a comment, it's just that you said you were having emails
problems lately).

Anyone interested and bave enough ;-) can get it at:
http://www.linux.ime.usp.br/~livio/dillo/urlparse.diff
http://www.linux.ime.usp.br/~livio/dillo/urlparse.c
http://www.linux.ime.usp.br/~livio/dillo/urlparse.h

That's all for now. Best regards to all and I promise I'll try to
write shorter posts from now on :^P

-- 
Livio <livio@li...> 



[Dillo-dev]Re: dillo developing

From: Jorge Arellano Cid <jcid@ne...> - 2001-03-28 02:06

Holger,

> Hey there
>
> my name is holger rapp. lookibg around for alternatives. I was
> mentally ready to start a new browser project of the ground.

Oh, that's a big enterprise to undertake!

> but
> then, i found dillo, which is not yet great but it shows good
> ideas.

What ideas do you like of it?

> Now, i'm asking if i might join in development.

That's simple. It a matter of expertise and respecting the
development model we're following (described in the web site).

> I read throu the source and i'm intrested in getting the
> plugins done. especially the ftp plugin is a mustdone for
> useability.

Yeah, sure. Don't miss the plugin draft:
http://dillo.so....net/dpi1.txt

Ah, as for the FTP plugin, I wrote that code a long time ago,
and it worked nicely with the former plugin scheme. Now, after
the new scheme is implemented, it would be a matter of adding the
datagram encapsulation and cleanning it a bit.
If you're willing to do that, I'd gladly send you the code I
have.

> I saw in the code, that the plugins are searched in
> /usr/local/bin which is not useable, methinks. But b4 i start
> doing anything that wouldn't fit in the ideas of other plugin
> developers i thought, i better drop you a note.

You'll probably find the answers in dpi1.txt.
I'm not sure, but Eric was willing to review the draft and
start implementing the protocolo. He may have informed you
better though.

> Thanks a lot for dillo.
> Holger

you're welcome
Jorge.- 



Re: [Dillo-dev]Introduce myself

From: Jorge Arellano Cid <jcid@ne...> - 2001-03-28 02:06

Holger,

> ...
> For this i have some questions:
> a) in IO/proto.c a_Proto_get_url: After forking the process there is this strange lines:
> io = g_new(IOData_t, 1);
> io->Op = IORead;
> io->IOVec.iov_base = g_malloc(4096);
> io->IOVec.iov_len = 4096;
> io->Callback = a_Cache_callback;
> io->CbData = (void *) Url;
> io->FD = filedes[0];
> a_IO_submit(io);
> I got, that those lines should install a callback for when data
> is there to read. But a_Chache_callback doesn'tz define an action
> for IORead. Is this callback just a placeholder for a usefull
> plugin callback, who cares about the communication with the
> plugin.

a_Chache_callback defines explicit actions for IOClose and
IOAbort, but if neither the case, IORead is assumed and the
control flow continues within the function.

i.e. this is the function that handles the incoming data.

> And the seconde question:
> the forked process stdout gets connected to the parents FD for
> this io with a unnamed pipe. But this way, the parents proecess
> is not able to send any data to the client, just the client can
> send. How should a good plugin run without the voice of his
> master?

That's why we're definning a new protocol. The answer to your
question can be found at http://dillo.so....net/dpi1.txt.

> I'm thinking of implementing plugins over named sockets, like
> xmms does (/tmp/dilloXXXXXX or so). It's not secure andjust
> portable under *Xes, but, well, it's something to start with.

Portability is very important in this project.

> Would really like to know, what you think about this all.

I hope this helps.


Jorge.- 



RE: [Dillo-dev]Introduce myself

From: Eric GAUDET <egaudet@in...> - 2001-03-27 01:45

Hi,
I've been working on a patch for plugins with the previous design. This patch
answers some of you questions. This can be a good start for you, as it already
have the callback mecanism and pipes working.
I plan to start from here when the plugin design is completely discussed: I
still have some suggestions I want to submit to Jorge.

Here's where you can download the patch and some explanations:
http://www.rti-zone.org/dillo/

Note that this patch and plugin protocol are deprecated and the new plugin
design submitted by Jorge is what we want to implement.

Feel free to contact me if you have any question.

Best,
Eric

-- En reponse de "[Dillo-dev]Introduce myself" de Holger Rapp, le 26-Mar-2001 :
> Hi,
> 
> my name is holger. I'm new at dillo development. I plan to hack the simple
> plugins, especially the ftp plugin is in my interest.
> For this i have some questions:
> a) in IO/proto.c a_Proto_get_url: After forking the process there is this
> strange lines:
> io = g_new(IOData_t, 1);
> io->Op = IORead;
> io->IOVec.iov_base = g_malloc(4096);
> io->IOVec.iov_len = 4096;
> io->Callback = a_Cache_callback;
> io->CbData = (void *) Url;
> io->FD = filedes[0];
> a_IO_submit(io);
> I got, that those lines should install a callback for when data is there to
> read. But a_Chache_callback doesn'tz define an action for IORead. Is this
> callback just a placeholder for a usefull plugin callback, who cares about
> the communication with the plugin.
> And the seconde question:
> the forked process stdout gets connected to the parents FD for this io with a
> unnamed pipe. But this way, the parents proecess is not able to send any data
> to the client, just the client can send. How should a good plugin run without
> the voice of his master? 
> I'm thinking of implementing plugins over named sockets, like xmms does
> (/tmp/dilloXXXXXX or so). It's not secure andjust portable under *Xes, but,
> well, it's something to start with.
> 
> Would really like to know, what you think about this all.
> Greets
> Holger
> 
> _______________________________________________
> Dillo-dev mailing list
> Dillo-dev@li...
> http://lists.so....net/lists/listinfo/dillo-dev

------------------------------------
Eric GAUDET <egaudet@in...>
Le 27-Mar-2001 a 10:39:31
"In theory, there's no difference between 
theory and practice; in practice, there is.
------------------------------------ 



[Dillo-dev]Introduce myself

From: Holger Rapp <sirver@us...> - 2001-03-26 18:26

Hi,

my name is holger. I'm new at dillo development. I plan to hack the simple plugins, especially the ftp plugin is in my interest.
For this i have some questions:
a) in IO/proto.c a_Proto_get_url: After forking the process there is this strange lines:
io = g_new(IOData_t, 1);
io->Op = IORead;
io->IOVec.iov_base = g_malloc(4096);
io->IOVec.iov_len = 4096;
io->Callback = a_Cache_callback;
io->CbData = (void *) Url;
io->FD = filedes[0];
a_IO_submit(io);
I got, that those lines should install a callback for when data is there to read. But a_Chache_callback doesn'tz define an action for IORead. Is this callback just a placeholder for a usefull plugin callback, who cares about the communication with the plugin.
And the seconde question:
the forked process stdout gets connected to the parents FD for this io with a unnamed pipe. But this way, the parents proecess is not able to send any data to the client, just the client can send. How should a good plugin run without the voice of his master? 
I'm thinking of implementing plugins over named sockets, like xmms does (/tmp/dilloXXXXXX or so). It's not secure andjust portable under *Xes, but, well, it's something to start with.

Would really like to know, what you think about this all.
Greets
Holger 



[Dillo-dev]Html.testsuite Updated

From: Eric GAUDET <egaudet@in...> - 2001-03-24 06:09

Hi all,
I just updated the Html test suite. New version indicates what's working in
tarball 0.4.0, and a reference image for all HTML4 named entities.

enjoy !
------------------------------------
Eric GAUDET <egaudet@in...>
Le 24-Mar-2001 a 15:07:35
"In theory, there's no difference between 
theory and practice; in practice, there is.
------------------------------------ 



[Dillo-dev]Simple plugins

From: Jorge Arellano Cid <jcid@em...> - 2001-03-22 16:05

Hi,

For those interested in plugins, the fourth draft is finished,
you can find it at:

http://dillo.so....net/dpi1.txt


Jorge.- 



Re: [Dillo-dev]Miscellanea

From: Ron Farrer <rbf@fa...> - 2001-03-18 16:19

Attachments: Message as HTML      

Jorge Arellano Cid (jcid@em...) wrote:

> Dillo on the Alpha:
>=20
> A few days ago, I played with an old Alpha server; the compiler
> raised some warnings due to different data type-sizes, so I fixed
> them. That Alpha is still not able to run dillo (it produces the
> binary, but dillo hangs), so I'll try to check it out next week.
> If anyone here has an Alpha at hand, please let me know if
> dillo runs ok on it, and what compiler/version was used.

Yes it runs. I have personally run it on an AS200 (233MHz, 64MB) and
a Ruffian (600MHz, 256MB). Runs great on both. 0.4.0 works VERY well
(kudos).

gcc version 2.95.2 20000220 (Debian GNU/Linux)

Ron
--=20
Email: <rbf@fa...> or <rbf@de...>
Home: <http://www.farrer.net/~rbf/>
Alpha Linux Powered: <http://www.alphalinux.org> 



[Dillo-dev]Miscellanea

From: Jorge Arellano Cid <jcid@em...> - 2001-03-18 16:06

Hi!


Here's a miscellanea by topic:
------------------------------

Dillo weekly news:

A long time ago, Allan wrote me telling he was going on
holidays to Australia, and that he could not maintain the dillo
weekly news of our site. He should be back in June, so if anyone
here wants to take charge of that while he travels, just drop me
a note please (Dillo weekly news is a very appreciated thread).


Dillo on the Alpha:

A few days ago, I played with an old Alpha server; the compiler
raised some warnings due to different data type-sizes, so I fixed
them. That Alpha is still not able to run dillo (it produces the
binary, but dillo hangs), so I'll try to check it out next week.
If anyone here has an Alpha at hand, please let me know if
dillo runs ok on it, and what compiler/version was used.


URIs with entities:

Finally I got into the problem of entities-parsing inside
SGML-URI-attribute-values. As you may remember, the URI/URL rfc
says nothing about entities, but when an URI appears as an
attribute value inside a SGML application (HTML 4.01), they must
be parsed.
In brief, dillo parses them inside the "href" attribute-value
in <A>, <BASE> and <AREA> elements, and inside "src" for <IMG>.


Plugins:

Eric sent me his latest draft (on the plugin design), and I'm
studying it in detail. There'll be two types of plugins, a simple
one that is very similar to CGIs, and a full blown that
interacts with widgets.
We're working on the first type, and the second one will have
to wait, at least, until dillo renders TABLES and FRAMES.
Eric: The the draft is better than my first impression. I'll
simplify it, and make the new draft available ASAP.


IO Error control:

Yes, I've been busy, but I made some progress anyway! I hope to
work on it full time after I finish the simple-plugins draft.



That's all folks!
Jorge.-


PS [Pablo]: Did you receive my email on BUG#78 and the quoted
parsing problem? 



RE: [Dillo-dev]bug in some pages

From: Eric GAUDET <egaudet@in...> - 2001-03-16 02:37

The problem is you page uses tables, and Dillo doesn't support tables yet.
Several people are working on it, and Dillo is likely to support tables for
version 0.5, which might be in a couple of monthes.

Best,
Eric


-- En reponse de "[Dillo-dev]bug in some pages" de lqx, le 16-Mar-2001 :
> Hi,Eric
> 
> Did you received the page I sent you?Did you see the bug in it? Does anybody
> to fix it?
> 
> regards,
> 
> Qiaoxia Li
> 

------------------------------------
Eric GAUDET <egaudet@in...>
Le 16-Mar-2001 a 11:38:48
"In theory, there's no difference between 
theory and practice; in practice, there is.
------------------------------------ 



[Dillo-dev]bug in some pages

From: lqx <liqx@st...> - 2001-03-16 02:14

Attachments: Message as HTML      

Hi,Eric

Did you received the page I sent you?Did you see the bug in it? Does =
anybody to fix it?

regards,

Qiaoxia Li 



Re: [Dillo-dev]Newcomer

From: Sebastian Geerken <S.Geerken@pi...> - 2001-03-13 11:46

On Sun, Mar 11, Xavier Ordoquy wrote:
> [...]
> However, the rendering engine has not been documented until now.
> I've start browsing the code, I think I'm going to document what I
> understand and you'll check this after.

There is doc/Dw*.txt describing a rendering framework mainly
independent of (although, of course, designed for) dillo, based on
Gtk+. The widgets provided by Dw are fed by several other modules
(Html, Plain, Image ...), but do not refer to the other modules
(well, there is one reference, but my goal is to remove it in
future). If it is incomplete, I'll ask your questions, on the list or
privately.

There are several layers, which I don't know that detailed, and they
are indeed not perfectly well documented. Track down the functions,
starting in the Nav module.

> Moreover I'll closly looking for
> the table implementation. I really want to see it done very soon ;)

I recently posted some ideas about it. I'm currently not working on
it, but instead involved in cleaning up the page widget.

A note if you want to start: I plan to implement margins, borders,
and padding at the level of DwWidget, quite close to the CSS spec.
They will anyway needed for other purposes (except CSS in future:
e.g. floating objects).

> Another point the about plugins. I'm going to have a look a the way the
> are implemented in mozilla and konqueror.
> I do understand that one will not be able to use the netscape plugin
> system for other processor than x86, but I'de like to see this implemented
> for the architecture so that I can remove netsape/mozilla/konqueror from
> my desktop ;)

There is already a simple framework: functions for creating
DwWidget's, and for feeding them with data, look at mime.c for
details. The plugin scheme should be bound to this. The simplest
solution could be .so files, with the disadvantage of decreasing
stability (AFAIK Netscape does this). Any other system could perhaps
be included by wrappers, however, there are several free
implementations we could use.

> I fully agree it's another issue, but it might be very interessting to
> have a full gtk browser for gnome for ex.

Dillo is already mostly capable of rendering pages conforming to
"typical" recommendations (no frames, no dependences on javascript,
embedded objects etc.), except that tables are rendered different
(which is IMHO only a real handicap when tables are used as
_tables_). ;-)

Sebastian 



RE: [Dillo-dev]jpeg images

From: Eric GAUDET <egaudet@in...> - 2001-03-12 10:01

-- En reponse de "[Dillo-dev]jpeg images" de lqx, le 12-Mar-2001 :
> Hi,
> 
> I found a bug when dillo dealt with more than two jpeg images in a
> line,please visit http://startman.start.com.cn and you will see the
> fault.Will anybody fix this bug?I used dillo v0.4.0.
> 
> regards,
> 

Unfortunatly, I can't acces the page. It seems there's a route loop in the way:
7 205.158.0.71 (205.158.0.71) 9.846 ms 9.600 ms 9.742 ms
8 fe9-1-0.core1.scl-ca.us.xo.com (207.88.3.193) 9.605 ms 11.087 ms 22.777
ms
9 205.158.0.71 (205.158.0.71) 11.273 ms 10.330 ms 16.958 ms

Did you see the error with other pages ?
Can you send me the page (along with the images) by email, so I can include it
in the testsuite and developpers can investigate the problem ?

------------------------------------
Eric GAUDET <egaudet@in...>
Le 12-Mar-2001 a 19:00:57
"In theory, there's no difference between 
theory and practice; in practice, there is.
------------------------------------ 



[Dillo-dev]jpeg images

From: lqx <liqx@st...> - 2001-03-12 09:21

Attachments: Message as HTML      

Hi,

I found a bug when dillo dealt with more than two jpeg images in a =
line,please visit http://startman.start.com.cn and you will see the =
fault.Will anybody fix this bug?I used dillo v0.4.0.

regards, 



Re: [Dillo-dev]Newcomer

From: Xavier Ordoquy <xordoquy@au...> - 2001-03-11 10:45

> Frankly, the best way to get involved, and to know what's dillo
> project about, is the one I described above (we put a big effort
> in creating those docs.).
> 
> Jorge.-

However, the rendering engine has not been documented until now.
I've start browsing the code, I think I'm going to document what I
understand and you'll check this after. Moreover I'll closly looking for
the table implementation. I really want to see it done very soon ;)

Another point the about plugins. I'm going to have a look a the way the
are implemented in mozilla and konqueror.
I do understand that one will not be able to use the netscape plugin
system for other processor than x86, but I'de like to see this implemented
for the architecture so that I can remove netsape/mozilla/konqueror from
my desktop ;)
I fully agree it's another issue, but it might be very interessting to
have a full gtk browser for gnome for ex.

---
Xavier Ordoquy,
Aurora-linux, http://www.aurora-linux.com 



Re: [Dillo-dev]Newcomer

From: Jorge Arellano Cid <jcid@em...> - 2001-03-11 01:16

Xavier,

> Hi,

Hi!

> I just tried dillo, and it seems very nive to me because it seems fast.
> I whish I can join the project and help you.
> My goal is to make a browser small and usable on desktop as well as
> embedded devices with netscape plugins.

Be careful. Dillo has a very different rendering engine than
Netscape. I don't know if currently netscape plugins are
independent from the invoking program, but sometime ago they were
based on a Netscape protocol that was specific to that browser.

We're just defining a way of implementing simple plugins (as
described in the [Project Notes] link), and full blown plugins
(those that integrate with rendering functions) are far away in
the future...

On the other hand, dillo has been reported to run on the IPaq
and StrongArm based machines.

> Can I have more information about the ongoing developpements ??

Sure, just take a look at the bug track, skim the mailing list
and read what's inside the doc/ directory.

> What about joining the team ?

That's free!

Frankly, the best way to get involved, and to know what's dillo
project about, is the one I described above (we put a big effort
in creating those docs.).


Jorge.- 



Re: [Dillo-dev]Tables

From: Sebastian Geerken <S.Geerken@pi...> - 2001-03-09 15:49

On Tue, Mar 06, 2001 at 06:58:32PM -0300, Jorge Arellano Cid wrote:
> 
> Hi!
> 
> On 4 Mar 2001, Sebastian Geerken wrote:
> 
> > [...]
> > This should make it possible to render tables incrementally, the
> > basic mechanism is the same as the one currently used for simple
> > pages: when the page widget grows, this will delivered to the table
> > widget, which will then recalculates its size. It may be (an
> > approximation is difficult, the best is to test the final
> > implementation) that this takes quite much CPU time, in this case, it
> > may be convenient to find an other priority mechanism instead of Gtk+
> > idle functions. But we'll see ...
> 
> As an alternative, the rendering can be tuned with timeout
> functions (e.g. Table rendering with a 3 seconds interval).

Rendering of tables will be done in the "main" (i.e. the GUI) thread.
If it gets too slow two, two problems arise:

1. it blocks the user interface, and
2. it hogs the CPU in an unreasonable way.

2 could be solved by a timeout, but 1 won't, the only way to solve it
is to do some parts in another thread.

> The problem of rendering cached pages can be solved with an
> idle rendering that's triggered when the whole page has been
> parsed;

... or the </table> tag was read ...

> the idle rendering request must cancel any queued
> timeout. That way, if the page has completed downloading, and the
> timeout is still waiting, no noticeable delays would be perceived
> by the user.

If the page is read from the cache, rendering will only be done once,
since idle functions have a lower priority. So, the timeout function
should not be started when the table has been finished. Instead, the
current mechanism via idle functions is used. However, there may be
changes after the table/page has been finished, e.g. by images, which
will cause the table to be resized.

Anyway, the resizing mechanism may be changed without modifying the
widgets itself, so I don't bother about it, but will see whether a
change is really necessary after implementing the table widget.

Sebastian 



[Dillo-dev]Newcomer

From: Xavier Ordoquy <xordoquy@au...> - 2001-03-09 13:24

Hi,

I just tried dillo, and it seems very nive to me because it seems fast.
I whish I can join the project and help you.
My goal is to make a browser small and usable on desktop as well as
embedded devices with netscape plugins.

Can I have more information about the ongoing developpements ??
What about joining the team ?

Xave.

---
Xavier Ordoquy,
Aurora-linux, http://www.aurora-linux.com 



Re: [Dillo-dev]Tables

From: Jorge Arellano Cid <jcid@em...> - 2001-03-06 22:06

Hi!

On 4 Mar 2001, Sebastian Geerken wrote:

> [...]
> This should make it possible to render tables incrementally, the
> basic mechanism is the same as the one currently used for simple
> pages: when the page widget grows, this will delivered to the table
> widget, which will then recalculates its size. It may be (an
> approximation is difficult, the best is to test the final
> implementation) that this takes quite much CPU time, in this case, it
> may be convenient to find an other priority mechanism instead of Gtk+
> idle functions. But we'll see ...

As an alternative, the rendering can be tuned with timeout
functions (e.g. Table rendering with a 3 seconds interval).
The problem of rendering cached pages can be solved with an
idle rendering that's triggered when the whole page has been
parsed; the idle rendering request must cancel any queued
timeout. That way, if the page has completed downloading, and the
timeout is still waiting, no noticeable delays would be perceived
by the user.

Just an idea...


Jorge.- 



[Dillo-dev]Tables

From: Sebastian Geerken <S.Geerken@pi...> - 2001-03-04 20:57

Hi!

Just a few words about tables. The implementation should be tricky,
but quite interesting, and if nobody else feels a strong desire to do
this ;-), I'll start with it soon (aside from some other things).

So far, this is the current state of what I've thought about it.

A simple overview what to do:

1. Write a table widget. It will be a general purpose Dw container,
but will indeed only used for DwPage's.

2. Extend the HTML parser by a page stack, so that it can write
into different DwPage's. This is quite simple, and I already
have the code somewhere lying around on my harddisk.

This should make it possible to render tables incrementally, the
basic mechanism is the same as the one currently used for simple
pages: when the page widget grows, this will delivered to the table
widget, which will then recalculates its size. It may be (an
approximation is difficult, the best is to test the final
implementation) that this takes quite much CPU time, in this case, it
may be convenient to find an other priority mechanism instead of Gtk+
idle functions. But we'll see ...

Table rendering is not trivial. I've made a few thoughts about it,
and later found notes how it is implemented in w3m
(http://ei5nazha.yz.yamagata-u.ac.jp/~aito/w3m/eng/STORY.html,
section "Table rendering algorithm in w3m"), which are quite similar
to my ideas.

For nested tables, there is the need for minimizing the number of
calculations of the real column widths. It should be possible to do
this by knowing only the minimal/maximal width of cells (which are
widgets), and calculating the latter should be quite fast.

Integrating this idea into Dw will look like following:

1. There will be an other way how DwPage allocates the child
widgets. The current is suitable for simple widgets like images
and hrules, but the table widget will have to know the page
width, an extended scheme will make use of set_width etc.

2. DwWidget will be extended by signals returning the minimum and
maximum width. For most widgets, this will be simple and will
done by Dw_widget_real_... implementations. For DwPage's without
child widgets, this is mainly the width of the widest word, and
the width of the widest line, respectively (both should be
stored in DwPage for speed). When there are child widgets, the
minimum/maximum widths of them have to be regarded.

The minimal/maximal width of a table is simply the sum of all
minimal/maximal column widths, and the minimal/maximal column
width are the maxima of all minimal/maximal column cell widths.

Sebastian 



[Dillo-dev]dillo CVS

From: Jorge Arellano Cid <jcid@em...> - 2001-03-04 16:24

Hi!

Today I succeded merging back 0.4.0 branch into the main trunk
of the CVS.

What does that mean? Simply stated, that what we used to call
0.4.0 branch (or "Dw-040") has become our main line of
development, and that it has to be accessed at the main trunk (in
other words: no more '-r Dw-040' arguments).

How to get it from CVS? Just:

cvs -d:pserver:anonymous@cv...:/cvsroot/dillo login
cvs -z8 -d:pserver:anonymous@cv...:/cvsroot/dillo co dillo

That's all!


Cheers
Jorge.-


Ps: [Sebastian]: Needless to say, any new changes
go in the main trunk now! 



[Dillo-dev]0.4.0 release

From: Jorge Arellano Cid <jcid@em...> - 2001-03-04 01:42

Hi there!

I'm exhausted, but finally dillo-0.4.0 is there, ready for
download!!!

The web site was updated, also project notes, primary concerns
and documentation inside the tarball.

040 bugtrack will not be used anymore, just keep using the main
one because 0.4.0 is now our main development branch. That's it!

Eric: Please submit me (or to Sebastian) your HR patch, because
none of us received it.

Well, I'll try to merge 0.4.0 branch into the main trunk of the
CVS tomorrow.

Mark: There's a short overview of the plugin scheme that's to
be implemented in [Project Notes] link.



Good night!
Jorge.-