- Dillo-dev - lists.mailman3.com

pasting URL

by jcid＠dillo.org

On Thu, Oct 23, 2008 at 01:07:32AM +0200, Thomas Orgis wrote: > Am Wed, 22 Oct 2008 22:46:52 +0100 > schrieb higuita <higuita7(a)yahoo.co.uk>: > > > you can already paste a URL to the X icon in the urlbar and it > > will load... > > Indeed. Good to know. > > > the midle click on the body is reserved to dragging the page > > Now that's funny. I have my middle button configured to emulate scroll > wheels when pressed+dragging (EmulateWheel option in Xorg config). > This is kindof convenient in all around X11, especiall with a > trackpoint or trackball... > The funny part is that this Xorg feature hides the middle click + dragging > action from dillo -- it gets vertical and horizontal scroll events instead, > while the single middle click that could paste the URL (let through by > Xorg, because of EmulateWheelclickToo) is blocked from that by dillo, which > prepares for movement of the mouse -- which is impossible to get in this > config. > > So an unreachable feature of dillo (dragging) makes a different expected > feature (middle-click pasting into window) unreachable. > > I envision making this configurable in dillo (deactivate dragging to > activate pasting)... or recreate the EmulateWheelclickToo behaviour to > use the isolated click for the differing action. Agreed. -- Cheers Jorge.-

Oct. 24, 2008

css

by jcid＠dillo.org

On Wed, Oct 22, 2008 at 06:36:33PM +0200, Johannes Hofmann wrote: > Hi, > > here comes my proposal to get css support started. Note that I'm new > to this stuff so I will probabely simplify things a lot and miss many > issues that will have to be addressed later on. I like this approach, but please note I'm also new to CSS stuff. Sebastian was the main expert, and he used to give a lot of thought to things before implementing, so I'd rather keep what's in dw2 instead of removing/making changes, at least until more solid knowledge is gained. http://www.dillo.org/CSS.html was written circa 2003, so dw2 probably has a smoother design for CSS. Now, what I like of this approach is it's simplicity and that more or less it's understandable. :) > * Separate out the style handling from html.cc in a new class > StyleEngine (better name welcome). > This class will be fed the html tree via a SAX like interface as the > document is parsed and will hand out the current Style object. By "html tree" do you mean the generated DOM tree? (which scripting would need BTW). > * Initially StyleEngine will be implemented to just mimic the > current behaviour of html.cc. So after this step everything should > work as currently. * Does this mean StyleEngine should understand and parse plain HTML style attributes too (e.g. bgcolor="#FEFEFE")? (I assume it'll parse inline CSS). * Or will it get a style object made by the HTML parser? * In case of clash, which one takes precedence, HTML attribute or CSS style? Please elaborate a bit more on this. > * Then we can design the data structures to hold parsed css data and > make StyleEngine use these structures which will be statically > filled initially. > Again dillo should work as it does now. OK. > * Next we can implement a css parser that is able to fill the data > structures from the last step. > Now we should already be able to set a fixed user style sheet. OK. > * Hooking up the css parser to automatically load css information as > referenced in html pages would be next. OK. BTW, this is simple. > * In parallel to all this we would need to make floating objects > work in dw/textblock.cc. Yay! BTW, currently I don't know which of these two is more urgent: * floats in textblock. * DIV element. I'd say DIV. Anyway, I'd follow a bit the simple/complex CSS attributes division, and start with the simpler ones (as colors). Then go filling the gaps one at a time. > This approach has some issues. In contrast to > http://www.dillo.org/CSS.html it would only be possible to apply > style information that is available when starting parsing of a > document. However we could start rendering with what style > information is available and reload once all css files have been > loaded. It looks more than suitable for a first approach. Complex CSS attributes may change the widget tree. So a repush is necessary in this case anyway. > Currently dillo parses attributes on demand. So we don't have a > complete list of attributes and their values. As StyleEngine might > access any attribute, we might need to change this. > > Comments or more advanced plans would be more than welcome! Let's refine the plan, and once agreed, assign the tasks. -- Cheers Jorge.-

Oct. 24, 2008