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 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 :)
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.-
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
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
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.-
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.
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...
corvid wrote:
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. ...
... I agree with the removal. ...
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.
My test forms still work OK, so it can't be *too* badly broken. :-) Regards, Jeremy Henty
participants (4)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org