- Dillo-dev - lists.mailman3.com

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

textarea multiline input bug

by corvid＠lavabit.com

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_; }

Oct. 2, 2009

textarea multiline input bug

by dennisn＠dennisn.dyndns.org

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.)

Oct. 2, 2009

experimental patch: zero width space (Thai, Lao, Cambodian...)

by corvid＠lavabit.com

Johannes wrote: > On Tue, Sep 29, 2009 at 07:30:22PM +0000, corvid wrote: > > Johannes wrote: > > > On Tue, Sep 29, 2009 at 08:03:53AM +0000, corvid wrote: > > > > PS I did just start trying to move the ideographic test to dw, > > > > but I got stuck when I realized that I can't exactly call fltk's > > > > utf8decode() directly in Textblock, and am not excited by the > > > > idea of calling it through Layout. > > > > > > > > > > I think we could make the utf8 methods in fltkplatform.cc static > > > members. > > > > In this case, that would save us... carrying along a this > > pointer that we weren't using? Does it save an indirection? > > > > (in any case, maybe I should static-ize all of our current > > fltkplatform functions that just call fltk functions) > > Wait. Making them static is not a good idea. Currently we could > have different platforms in a single process and the right methods > would be called. > Are you concerned about speed or readability? It sounded slow to go through layout, but then we do our share of nextGlyph, textWidth, etc, and haven't died from it. Maybe it's time to get gprof out again anyway.

Sept. 30, 2009