October 2009 - Dillo-dev - lists.mailman3.com

flicker at reload

by Johannes.Hofmann＠gmx.de

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. Cheers, Johannes PS: Please let us know your findings!

Oct. 13, 2009

flicker at reload

by nst＠gersys.de

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. Is the flickering an fltk issue or where is the screen cleared? 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? Many thanks Stefan.

Oct. 13, 2009

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

by corvid＠lavabit.com

Johannes 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. It does indeed. I wonder about fltkpreview... we keep it in good enough shape to compile, but surely it's accumulated enough rot not to work right, whatever it's supposed to do exactly. > * 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. I like the idea of getting to remove some of the scrolling key bindings code. An article on size and complexity in the case of animals, for anyone with spare time for reading articles: http://jezzmo.com/ancestors/haldane/jbsh/obtrs.html

Oct. 11, 2009

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

by Johannes.Hofmann＠gmx.de

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 :) > > 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. 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. * 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. Cheers, Johannes

Oct. 11, 2009

new fltk2 snapshot (Re: [Dillo-dev] textarea multiline input bug)

by corvid＠lavabit.com

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.

Oct. 10, 2009

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

by jcid＠dillo.org

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. 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. @all: Please comment. -- Cheers Jorge.-

Oct. 8, 2009

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

by corvid＠lavabit.com

I wrote: > At http://naturalhistory.museumwales.ac.uk/sharpshooters/ > two of the image tags specify a size for one dimension, giving > it as 100%. When one dimension is auto and the other is percentage, > it doesn't scale properly. > > I see that calculation using percentage has to be in > textblock because it uses availWidth or availHeight, so... > is there a deep need to keep the auto/abs case in > Image's sizeRequestImpl instead of Textblock's calcWidgetSize? > > I was just playing with adding all of the cases to calcWidgetSize > and it looked like it was working except that an unloaded image > with, e.g., height=100% alt=whatever would end up ridiculously > wide because height_of_page / height_of_alt_text * width_of_alt_text > is a large number. I eventually ran into a page where simplemindedly taking, say, width=50% and expanding the height accordingly was bad. It had an <hr>. Hmph. Web browsers are too complicated; let's make something easy instead :)

Oct. 8, 2009

tooltips not clearing properly

by corvid＠lavabit.com

Johannes wrote: > corvid wrote: > > Jorge wrote: > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.31.y.git;a=summa… > > > > > > Go to NOMMU, wait for tooltip, scroll with mouse wheel... > > > > I don't have one, although I'll try to look into it anyway. > > Do links show up and disappear from the status bar > > properly with the mouse wheel? > > > > It may also have to do with our scrolling code. Sometimes it looks as if the tooltip > is cleared partially, but some part "sticks". I will have a look when I find some time. Ah, I see it now if I set buffered_drawing to the default value. Luckily I don't know anything at all about the buffering code :)

Oct. 8, 2009

server downtime

by akemnade＠tzi.de

Hi, due to works on the power supply of the building in the early tomorrow morning, there will be a downtime for everything except hg access. As I'm not sure whether I can be there in time, I have to power down this early evening. Things should be up at 07:00 UTC again. Greetings Andreas Kemnade

Oct. 7, 2009

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

by corvid＠lavabit.com

At http://naturalhistory.museumwales.ac.uk/sharpshooters/ two of the image tags specify a size for one dimension, giving it as 100%. When one dimension is auto and the other is percentage, it doesn't scale properly. I see that calculation using percentage has to be in textblock because it uses availWidth or availHeight, so... is there a deep need to keep the auto/abs case in Image's sizeRequestImpl instead of Textblock's calcWidgetSize? I was just playing with adding all of the cases to calcWidgetSize and it looked like it was working except that an unloaded image with, e.g., height=100% alt=whatever would end up ridiculously wide because height_of_page / height_of_alt_text * width_of_alt_text is a large number.

Oct. 7, 2009