- Dillo-dev - lists.mailman3.com

Patch: fix the flowchart diagram in the dw::Table class docs

by onepoint＠starurchin.org

The main body of the dw::Table class documentation starts with a flowchart diagram of some dw::Table method calls. But this diagram refers to a method dw::Table::calcColumnExtremes() that is no longer used and has been renamed to dw::Table::_unused_calcColumnExtremes(). (There is a warning that GROWS made some of this documentation obsolete.) So I dug into the code and came up with a patch that I think fixes the diagram. I have attached before and after images of the diagram so that you can compare. I would love some feedback! http://starurchin.org/dillo/patch/doxygen-dw-table-hh-dependency-diagram.ht… And this patch removes dw::Table::_unused_calcColumnExtremes(). http://starurchin.org/dillo/patch/remove-dw-table-_unused_calcColumnExtreme… Comments are welcome. Regards, Jeremy Henty

May 31, 2015

Alternative styles support?

by higuita7＠yahoo.co.uk

Hi! On Sun, 24 May 2015 20:39:55 +0000, eocene <eocene at gmx.com> wrote: > Sebastian wrote: > > Iceweasel (Firefox): > > View -> Page Style -> (No Style | Fresh, Revolution) > Only now do I find that it's possible to get the menu bar back. I hehehe, most people don't know about the firefox menu bar, but is easy to get to it, just press "alt" for a temporary access or right click on the existent bar and select that you want to see the menu permanently > believe mine disappeared when firefox decided to move everything into > that stupid three-horizontal-bars icon because they're trend-followers, Not just trend followers, netbooks have a lot less screen size than desktops and the existence of the status bar and menu bar removes precious screen size, so that decision was to increase usable space. Of course i have the opinion that FF should check the screen size and change the default based on that... but i understand that would break consistency. Back to the on-topic: i would also agree that alternative styles support would be good thing. right now i have to switch off embebed or external CSS to be able to read some sites, a way to use other styles or even force a "personal" style would help in many sites. Best regards, higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

May 26, 2015

long lines and slowness (common when viewing style sheets)

by sgeerken＠dillo.org

On Di, Mai 26, 2015, eocene wrote: > > Now that everyone likes to send their style sheets as one big long line, > like 250k long, viewing them in dillo is slow. > > gprof says > % cumulative self self total > time seconds seconds calls s/call s/call name > 32.47 1.88 1.88 189407242 0.00 0.00 lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const > 29.36 3.58 1.70 187437456 0.00 0.00 dw::Textblock::BadnessAndPenalty::lineCanBeBroken(int) > 28.15 5.21 1.63 29345 0.00 0.00 dw::Textblock::wrapWordInFlow(int, bool) > > and I wonder whether any optimizations are possible. Yes, I know this bug (you sent it me some time ago), and it is on my todo list. Since this occured first with hyphenation (or rather per-line optimization), there is certainly a way to optimize it. A vague guess is that it has to do with the iteration over the line to find the best break point. (BTW: the functionality used for plain text could also be provided by a new widget which is much simpler than Textblock.) Sebastian

May 26, 2015

long lines and slowness (common when viewing style sheets)

by eocene＠gmx.com

Now that everyone likes to send their style sheets as one big long line, like 250k long, viewing them in dillo is slow. gprof says % cumulative self self total time seconds seconds calls s/call s/call name 32.47 1.88 1.88 189407242 0.00 0.00 lout::misc::NotSoSimpleVector<dw::Textblock::Word>::getRef(int) const 29.36 3.58 1.70 187437456 0.00 0.00 dw::Textblock::BadnessAndPenalty::lineCanBeBroken(int) 28.15 5.21 1.63 29345 0.00 0.00 dw::Textblock::wrapWordInFlow(int, bool) and I wonder whether any optimizations are possible.

May 26, 2015

view source hang

by jcid＠dillo.org

On Thu, May 21, 2015 at 07:05:45PM +0000, eocene wrote: > > If a page has null padding, viewing source doesn't complete. > Example attached. I'm working on it... -- Cheers Jorge.-

May 25, 2015

Alternative styles support?

by sgeerken＠dillo.org

On Mo, Mai 25, 2015, eocene wrote: > Sebastian wrote: > > In dillo, it should be rather simple to integrate the styles into the > > tools menu. Perhaps some configuration per site would be nice, too. > > Do you suppose it would be more suitable to keep the user's setting for > a page in nav or in cache? Objectively, cache seems right, but in some > way feels like an unusual intrusion. It should resemble the current behaviour for "Use remote CSS" etc. Which I find rather confusing, admittedly: Switching it in one browser window switches the check boxes in all windows, but re-renders the page only in one window. And, what I meant previously: a simple text file in which pages and sites can be configured. Sebastian

May 25, 2015

Alternative styles support?

by eocene＠gmx.com

Sebastian wrote: > In dillo, it should be rather simple to integrate the styles into the > tools menu. Perhaps some configuration per site would be nice, too. Do you suppose it would be more suitable to keep the user's setting for a page in nav or in cache? Objectively, cache seems right, but in some way feels like an unusual intrusion.

May 25, 2015

Documentation in the tarball?

by sgeerken＠dillo.org

On So, Mai 24, 2015, Jorge Arellano Cid wrote: > On Sun, May 24, 2015 at 02:25:49PM +0200, Sebastian Geerken wrote: > > Hi! > > > > Does it make sense to include all developer documentation into the > > tarball? As an alternative, only user documentation, plus a notice > > where to find the developer docs, could be included, while the rest > > can only be found in the repository at hg.dillo.org. I assume that > > someone who is interested in the internals of dillo will anyway refer > > to the lastest version from the Hg repository. > > > > Keeping it out of the tarball would have advantages: > > > > - It makes the tarball smaller. > > > > - We developers would not have to think that much about file sizes of > > the documentation: these files do not go into the tarball; and for > > those using the lastest version from the Hg repository, it should be > > reasonable to spend some more disc space. > > > > What do you think? > > One disadvantage is no longer having both synced in the same > tarball. > > Now, if docs live in the same hg repo as sources, but just don't > make it into the tarball, I see no problems. They are kept in sync for > devs, and the tarball goes smaller, in which case I do agree. I want to keep them in the same repository, especially since Doxygen works also on the sources. I thought of something simple like removing most files from EXTRA_DIST in doc/Makefile.am. (BTW, EXTRA_DIST has been poorly maintained in the past, so the tarball did have an incomplete documentation sometimes.) Sebastian

May 24, 2015

Documentation in the tarball?

by jcid＠dillo.org

On Sun, May 24, 2015 at 02:25:49PM +0200, Sebastian Geerken wrote: > Hi! > > Does it make sense to include all developer documentation into the > tarball? As an alternative, only user documentation, plus a notice > where to find the developer docs, could be included, while the rest > can only be found in the repository at hg.dillo.org. I assume that > someone who is interested in the internals of dillo will anyway refer > to the lastest version from the Hg repository. > > Keeping it out of the tarball would have advantages: > > - It makes the tarball smaller. > > - We developers would not have to think that much about file sizes of > the documentation: these files do not go into the tarball; and for > those using the lastest version from the Hg repository, it should be > reasonable to spend some more disc space. > > What do you think? One disadvantage is no longer having both synced in the same tarball. Now, if docs live in the same hg repo as sources, but just don't make it into the tarball, I see no problems. They are kept in sync for devs, and the tarball goes smaller, in which case I do agree. -- Cheers Jorge.-

May 24, 2015

Alternative styles support?

by johnfound＠asm32.info

On Sun, 24 May 2015 20:39:55 +0000 eocene <eocene at gmx.com> wrote: > Sebastian wrote: > > Iceweasel (Firefox): > > View -> Page Style -> (No Style | Fresh, Revolution) > > Only now do I find that it's possible to get the menu bar back. I believe > mine disappeared when firefox decided to move everything into that stupid > three-horizontal-bars icon because they're trend-followers, and anyway I > thought that was just the new terrible way of things to not have access > to anything anymore. LOL! That is why I use PaleMoon browser. The same FireFox, but with classic interface. :D -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

May 24, 2015