- Dillo-dev - lists.mailman3.com

FWD

by Johannes.Hofmann＠gmx.de

On Fri, Oct 16, 2009 at 02:56:32PM -0300, Jorge Arellano Cid wrote: > Hi, > > [Alexandre Berges (alexandre dot berges @ GMAIL) wrote:] > > > Hello > > > > I use Dillo and i like it. > > I have a littel problem with it it's how to use letter-spacing attribut. I > > know this attribut is'nt implemented > > Do you know when this attribute will be implemented ? I guess it would be pretty straight forward to add if we find out how to change the letter spacing in fltk. Cheers, Johannes

Oct. 16, 2009

FWD

by jcid＠dillo.org

Hi, [Alexandre Berges (alexandre dot berges @ GMAIL) wrote:] > Hello > > I use Dillo and i like it. > I have a littel problem with it it's how to use letter-spacing attribut. I > know this attribut is'nt implemented > Do you know when this attribute will be implemented ? -- Cheers Jorge.-

Oct. 16, 2009

auto/abs sizes in image.cc, auto/abs/per in textblock.cc

by corvid＠lavabit.com

I wrote: > Jorge wrote: > > On Sun, Oct 11, 2009 at 05:58:11PM +0200, Johannes Hofmann wrote: > > > > > * Multiple views in dw/*. Either we find and implement a use case > > > for that feature or we should remove it. Currently it just makes > > > things complicated. > > > > Yes. A long time ago I saw Sebastian making some use of it in > > development code and nothing else. Currently it has no use in > > dillo, so I agree with the removal. If one day we need it badly, > > it can be added back. > > I'll look into removing it. Committed. It does touch fltkui.cc enough that you may want to keep an eye on whether forms are submitting what you tell them to. Everything seems right with my form test pages, though...

Oct. 15, 2009

flicker at reload

by Johannes.Hofmann＠gmx.de

On Wed, Oct 14, 2009 at 07:44:41PM +0200, Johannes Hofmann wrote: > On Wed, Oct 14, 2009 at 01:34:43PM +0200, Stefan wrote: > > Johannes Hofmann wrote: > > > On Tue, Oct 13, 2009 at 06:48:51PM +0200, Stefan wrote: > > >> 1) flicker at reload > > >> When doing a reload my screen flickers and I'd like to get rid of that. > > >> I first tried the dillorc option buffered_drawing=0/1/2 but that didn't > > >> make any difference. I then tried to find the source where the screen is > > >> cleared before redrawing the page. I followed the source of redraw() > > >> until layout.cc where topLevel->draw() is executed but I cannot find its > > >> implementation. > > > > > > I'm not sure. It might just be that the freshly loaded page is > > > rendered while it is not 100% loaded, which would blank the screen. > > > Then it is drawn again after loading has completed. > > > I would suggest to put printf()s in FltkViewBase::draw() (the actual > > > draw) and Layout::queueResize() (which requests a complete redraw) > > > to see what is going on. You can also use gdb an breakpoints of > > > course. > > > > Thanks for the feedback to all of you. I'll try to find the origin of > > the flickering. > > > > >> 2) externally trigger reload > > >> I'd like to trigger a page reload externally by another application. I > > >> searched a bit about IPC mechanisms of fltk but didn't find any. So I'm > > >> thinking about using a UNIX fifo or the system signal SIGUSR2. Do you > > >> think this is a good approach? > > > > > > If you just need to trigger a reload, SIGUSR2 might be ok. For a > > > more general remote control fifo's or maybe stdin might be an > > > option. You can check what other browsers do. > > > > Please see below the patch on how I've done it. Two issues: > > a) The signal() function is ambiguous because there's a namespace > > lout::signal in lout/signal.hh. I don't know how to tell the compiler to > > use the correct signal(). I tried std::signal() but that didn't work. If > > I temporarily rename the lout::signal to something else the patch seems > > to work. > > That's a bug. I will fix it. It should be fixed now. Please check again with current tip. Cheers, Johannes

Oct. 15, 2009

flicker at reload

by Johannes.Hofmann＠gmx.de

On Wed, Oct 14, 2009 at 01:34:43PM +0200, Stefan wrote: > Johannes Hofmann wrote: > > On Tue, Oct 13, 2009 at 06:48:51PM +0200, Stefan wrote: > >> 1) flicker at reload > >> When doing a reload my screen flickers and I'd like to get rid of that. > >> I first tried the dillorc option buffered_drawing=0/1/2 but that didn't > >> make any difference. I then tried to find the source where the screen is > >> cleared before redrawing the page. I followed the source of redraw() > >> until layout.cc where topLevel->draw() is executed but I cannot find its > >> implementation. > > > > I'm not sure. It might just be that the freshly loaded page is > > rendered while it is not 100% loaded, which would blank the screen. > > Then it is drawn again after loading has completed. > > I would suggest to put printf()s in FltkViewBase::draw() (the actual > > draw) and Layout::queueResize() (which requests a complete redraw) > > to see what is going on. You can also use gdb an breakpoints of > > course. > > Thanks for the feedback to all of you. I'll try to find the origin of > the flickering. > > >> 2) externally trigger reload > >> I'd like to trigger a page reload externally by another application. I > >> searched a bit about IPC mechanisms of fltk but didn't find any. So I'm > >> thinking about using a UNIX fifo or the system signal SIGUSR2. Do you > >> think this is a good approach? > > > > If you just need to trigger a reload, SIGUSR2 might be ok. For a > > more general remote control fifo's or maybe stdin might be an > > option. You can check what other browsers do. > > Please see below the patch on how I've done it. Two issues: > a) The signal() function is ambiguous because there's a namespace > lout::signal in lout/signal.hh. I don't know how to tell the compiler to > use the correct signal(). I tried std::signal() but that didn't work. If > I temporarily rename the lout::signal to something else the patch seems > to work. That's a bug. I will fix it. > > b) Using SIGUSR, do I have to worry about interrupting the main flow of > dillo at a bad moment, or is it safe the way I've done it? You should just set a flag in the sighandler and do the actual work from the normal context (when the flag is set). Otherwise strange things will happen depending on what dillo is currently doing when you send the signal. Cheers, Johannes

Oct. 14, 2009

auto/abs sizes in image.cc, auto/abs/per in textblock.cc

by corvid＠lavabit.com

Jorge wrote: > On Sun, Oct 11, 2009 at 05:58:11PM +0200, Johannes Hofmann wrote: > > > * Multiple views in dw/*. Either we find and implement a use case > > for that feature or we should remove it. Currently it just makes > > things complicated. > > Yes. A long time ago I saw Sebastian making some use of it in > development code and nothing else. Currently it has no use in > dillo, so I agree with the removal. If one day we need it badly, > it can be added back. I'll look into removing it.

Oct. 14, 2009

auto/abs sizes in image.cc, auto/abs/per in textblock.cc

by jcid＠dillo.org

On Sun, Oct 11, 2009 at 05:58:11PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > On Thu, Oct 08, 2009 at 12:34:44PM -0400, Jorge Arellano Cid wrote: > > On Thu, Oct 08, 2009 at 01:41:00PM +0000, corvid wrote: > > > > > > Web browsers are too complicated; let's make something > > > easy instead :) > > > > This is one of the paramount issues in our project. > > > > The underlying technologies and web pages were infected with > > complexity and broken standards, as part of a plan to stiffle and > > extinguish competition, with the goal of controlling the web > > market for huge profit. Information gathering for more obscure > > objectives came into the scene when the web expanded more and > > more into our lives. > > > > Vested interests in this game are huge. > > > > Dillo remains as a quixotic quest for those of us that want to > > browse the web's information as free citizens, trying to avoid > > the treacherous technologies that usually hide behind a > > friendly-looking aegis. > > > > Others have succeeded in similar quests (e.g. the toolchain, > > the kernel, a C library, cryptography, etc). AFAIS the goal is to > > develop a trusty free-platform that doesn't help to enslave us > > more in this digital era, but on the contrary, that empowers its > > community to communicate and build upon it, in many areas of > > human interest (not only technology), and help it grow stronger > > as they interact with each other. > > I don't have much to add here :) I'll happily assume we agree! > > Our particular success with the dillo project depends on our > > ability to attract more developers that provide the manpower > > necessary to be able to make it more useful for everyone of us. > > > > To attract new developers, we need to show an interesting state > > that inspires them to look forward. I believe that now we have a > > big opportunity when dillo makes it into Debian. If we can make > > it a help browser (by providing a good interface or dpi for > > instance), lots of people would be looking at it, and that would > > also give developers the opportunity to consider whether helping > > dillo grow is a worthy task. > > I think that cleaning up the code and reducing complexity is the > key. That makes it easy and fun to get started. My feeling is exactly. Reducing complexity is and had been the key (e.g. on HTPP, HTML, etc). BTW, corvid's suggested article is inspiring in this matter: http://jezzmo.com/ancestors/haldane/jbsh/obtrs.html Now, IIRC, long ago you mentioned the concept of being useful. It's useful for us, let's make it useful more people. This is also key. If we can find the right tradeoffs dillo would be more attractive to both users and developers. Right now, I see these ones very close: 1.- Rendering of floating objects. (very visible for users) 2.- Providing a remote control. (useful for help-browser and embedded apps.) 3.- Better DPIP API and dpi examples. (useful for developers) All of them don't increase the browser size through a boundary, as described in the article. It'd be great to have them when Dillo makes it into Debian again. > I have two things in mind in particular: > > * Multiple views in dw/*. Either we find and implement a use case > for that feature or we should remove it. Currently it just makes > things complicated. Yes. A long time ago I saw Sebastian making some use of it in development code and nothing else. Currently it has no use in dillo, so I agree with the removal. If one day we need it badly, it can be added back. > * The scrollbar handling is more complicated than needed. I will > refresh my old patch that makes scrollbars part of the GUI and put > it up for discussion. There is this sticky tooltip bug in the > scrolling code lurking, so we need to touch that code anyway. Good, I always liked this patch. -- Cheers Jorge.-

Oct. 14, 2009

flicker at reload

by nst＠gersys.de

Johannes Hofmann wrote: > On Tue, Oct 13, 2009 at 06:48:51PM +0200, Stefan wrote: >> 1) flicker at reload >> When doing a reload my screen flickers and I'd like to get rid of that. >> I first tried the dillorc option buffered_drawing=0/1/2 but that didn't >> make any difference. I then tried to find the source where the screen is >> cleared before redrawing the page. I followed the source of redraw() >> until layout.cc where topLevel->draw() is executed but I cannot find its >> implementation. > > I'm not sure. It might just be that the freshly loaded page is > rendered while it is not 100% loaded, which would blank the screen. > Then it is drawn again after loading has completed. > I would suggest to put printf()s in FltkViewBase::draw() (the actual > draw) and Layout::queueResize() (which requests a complete redraw) > to see what is going on. You can also use gdb an breakpoints of > course. Thanks for the feedback to all of you. I'll try to find the origin of the flickering. >> 2) externally trigger reload >> I'd like to trigger a page reload externally by another application. I >> searched a bit about IPC mechanisms of fltk but didn't find any. So I'm >> thinking about using a UNIX fifo or the system signal SIGUSR2. Do you >> think this is a good approach? > > If you just need to trigger a reload, SIGUSR2 might be ok. For a > more general remote control fifo's or maybe stdin might be an > option. You can check what other browsers do. Please see below the patch on how I've done it. Two issues: a) The signal() function is ambiguous because there's a namespace lout::signal in lout/signal.hh. I don't know how to tell the compiler to use the correct signal(). I tried std::signal() but that didn't work. If I temporarily rename the lout::signal to something else the patch seems to work. b) Using SIGUSR, do I have to worry about interrupting the main flow of dillo at a bad moment, or is it safe the way I've done it? I think other browsers use IPC mechanisms of the toolkit for things like this, but I think fltk2 doesn't provide some such thing. Many thanks Stefan. ----- diff -r 7cdd8e4f8076 src/uicmd.cc --- a/src/uicmd.cc Sat Oct 10 03:04:12 2009 +0000 +++ b/src/uicmd.cc Wed Oct 14 13:20:04 2009 +0200 @@ -15,6 +15,7 @@ #include <stdio.h> #include <stdarg.h> #include <math.h> /* for rint */ +#include <signal.h> #include <fltk/draw.h> #include <fltk/damage.h> @@ -44,6 +45,21 @@ // Handy macro #define BW2UI(bw) ((UI*)((bw)->ui)) + +/* + * sig_usr() + */ +static void sig_usr(int signo) +{ + int i; + if (signo == SIGUSR1) { + for (i=0; i<a_Bw_num(); i++) + a_UIcmd_reload(a_Bw_get(i)); +// a_Nav_reload(a_Bw_get(i)); + } + else + MSG_WARN("received signal %d\n", signo); +} // Platform idependent part using namespace dw::core; @@ -472,6 +488,10 @@ BrowserWindow *a_UIcmd_browser_window_ne win->callback(win_cb, new_bw); + /* setup SIGUSR1 for external triggering of reload */ + if (signal(SIGUSR1, sig_usr) == SIG_ERR) + MSG_WARN("can't catch SIGUSR1\n"); + return new_bw; }

Oct. 14, 2009

Re: new fltk2 snapshot (Re: textarea multiline input bug)

by dennisn＠dennisn.dyndns.org

On Sat, 10 Oct 2009 00:44:53 +0000, corvid wrote: > I wrote: > > Dennis wrote: > > > In textareas (multiline form input), say for example: > > > > > > http://translate.google.ca/translate_t > > > > > > ... if I first enter the following line into the textarea: > > > > > > yo soy anarco-capitalista > > > > > > ... and after submitting it, I edit it (the previous contents are > > > retained -- although I suspect internally there might be something > > > broken -- not sure where it breaks exactly.), by inserting a > > > newline at the very beginning (pressing enter), then backspacing > > > (removing the newline) to make it appear exactly the same, then > > > resubmitting the form, strange stuff happens. > > > > > > (I remember earlier posting experiences some of my lines getting > > > duplicated, and other strange stuff. I think it only happens when > > > I edit stuff at the beginning.) > > > > You have found a FLTK bug. > > > > I think in the beginning of TextBuffer::text(), > > where it goes > > > > if (!gapstart_ && length_) { > > buf_[length_+gapend_] = 0; > > return buf_+gapstart_; > > } > > > > they want > > > > if (!gapstart_ && length_) { > > buf_[length_+gapend_] = 0; > > return buf_+gapend_; > > } > > The new FLTK2 weekly snapshot has the fix. Thank you!

Oct. 14, 2009

flicker at reload

by jcid＠dillo.org

On Tue, Oct 13, 2009 at 07:13:45PM +0200, Johannes Hofmann wrote: > Hi Stefan, > > On Tue, Oct 13, 2009 at 06:48:51PM +0200, Stefan Strobl wrote: > > Hello > > > > I'm new to both dillo and fltk. I'm trying to do two things and I'm > > hoping you can point me in the right directions on how to do it. > > > > 1) flicker at reload > > When doing a reload my screen flickers and I'd like to get rid of that. > > I first tried the dillorc option buffered_drawing=0/1/2 but that didn't > > make any difference. I then tried to find the source where the screen is > > cleared before redrawing the page. I followed the source of redraw() > > until layout.cc where topLevel->draw() is executed but I cannot find its > > implementation. > > I would recommend to start in FltkViewBase::draw(). Or maybe > FltkViewport::draw() if you are interested in scrolling too. > > > Is the flickering an fltk issue or where is the screen cleared? > > I'm not sure. It might just be that the freshly loaded page is > rendered while it is not 100% loaded, which would blank the screen. > Then it is drawn again after loading has completed. > I would suggest to put printf()s in FltkViewBase::draw() (the actual > draw) and Layout::queueResize() (which requests a complete redraw) > to see what is going on. You can also use gdb an breakpoints of > course. > The flickering is certainly caused by dillo code and is not a > general issue of fltk. > > > > > 2) externally trigger reload > > I'd like to trigger a page reload externally by another application. I > > searched a bit about IPC mechanisms of fltk but didn't find any. So I'm > > thinking about using a UNIX fifo or the system signal SIGUSR2. Do you > > think this is a good approach? > > If you just need to trigger a reload, SIGUSR2 might be ok. For a > more general remote control fifo's or maybe stdin might be an > option. You can check what other browsers do. Ditto. I have the idea of a remote control dpi for dillo that allows to command it as necessary (think of a help browser). In this case you'd need reload and maybe the ability to send it to other pages or make it cycle or whatever. This feature needs a revision of the dillo plugin protocol (DPIP). I've been working on it for some time now, and hope to commit big changes this month. With regard to using dillo as a display for embedded devices, the idea is feasible and you'd be good testing with SIGUSR2 and reload by now. The golden idea is to use dpip to be able to update individual widgets using DOM. That would be really good. Specially if there was an interested sponsor! ;) -- Cheers Jorge.-

Oct. 13, 2009