November 2008 - Dillo-dev - lists.mailman3.com

the Http_must_use_proxy change in CVS
by corvid＠lavabit.com Nov. 11, 2008

Nov. 11, 2008

Is something missing? It gives me a warning because we're sending it a char* now.

2 1

Greetings! -- With Patches :-)
by list-jcr＠designtools.org Nov. 11, 2008

Nov. 11, 2008

Hi list, I guess the best way to show up on a development list is with patches, so I've attached two of them. The diffs were created against cvs with: $ cd /home/jcr/dillo-src/dillo2 $ cvs -d$CVS_DILLO diff -u There was no mention on the site about the preferred diff format, but since I found a few patches in the list archives using "universal" I figured it was the safest bet. Though I've read the docs on dillo.org about submitting bug reports first, and then patches, the first of the patches below is to a feature that has not yet been committed. The first is to fix an over-sight in the following post/patch posted to this mailing list: http://article.gmane.org/gmane.comp.web.dillo.devel/6248 The above patch does not take into consideration font size, so the result can be microscopic/unreadable fonts. I've added the code to scale the font in the same way as you scale other fonts in dillo. Though I've read enough of the dillo docs and code to grasp the basics of formatting, I'm unsure if my formatting of the continuation (split line) is "correct" according to your standards. There are other places in the dillo UI where font handling is still incorrect and can result in unreadable fonts. Some of this is the fault of fltk, since as far as I know there is no ~/.gtkrc equivalent to set defaults for the tool kit. With luck, I'll find and fix them. The second patch is for BUG #832 --If I read things correctly, I'm supposed to file a bug report first, assign it to myself, and then send in patches. Unfortunately, I screwed up pasting my email address in the "submitter" section due to the fact that dillo doesn't actually copy selected text in a form (i.e. with the select/paste of the plain old X Window System). If you want to correct the submitter on the bug to my email address, it would be appreciated. There was no way I could correct it myself. On all popup menus in dillo, you have a non-typical and non-functional "label" (or better said "title") on the displayed popup menu. This was my first adventute into fltk, but according to the fltk2 docs, if you set the "label" of the popup menu to NULL, the "label" will not be shown. You can do it one of two ways, (1) setting the lable to NULL in the instantiation of the class or (2) using the ->label() member function to set the label to NULL. I opted for the former because it's more clean than the latter. Though there were "Accelerator" key bindings in the labels (such as "&PAGE OPTIONS" to get enable win32 meun-ish "<ALT>-P" activation), they don't actually work since the popup menu type ("POPUP123") means they are completely hidden until activated by the mouse buttons. There is still a popup menu placement issue (annoyance) with the Bug Meter when running dillo in full screen (or to the bottom edge of your screen) but it seems to be caused by the fltk "remember last selected" option. It does not properly realize the bottom edge of the screen/window, so some popup menu options are off-screen and you need a mouse-wheel movement to access them. Anyhow, I hope this helps. Kind Regards, Jon Index: src/dillo.cc =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/dillo.cc,v retrieving revision 1.15 diff -u -r1.15 dillo.cc --- src/dillo.cc 10 Oct 2008 20:39:34 -0000 1.15 +++ src/dillo.cc 9 Nov 2008 19:43:45 -0000 @@ -21,9 +21,10 @@ #include <stdio.h> #include <unistd.h> #include <stdlib.h> +#include <math.h> /* for rint() */ #include <time.h> #include <signal.h> - +#include <fltk/Font.h> #include <fltk/Window.h> #include <fltk/TabGroup.h> #include <fltk/run.h> @@ -108,6 +109,16 @@ // WORKAROUND: sometimes the default pager triggers redraw storms fltk::TabGroup::default_pager(fltk::PAGER_SHRINK); + // Fix UI Fonts + fltk::Font *dfont = fltk::font(prefs.vw_fontname, 0); + if (dfont) { + fltk::Widget::default_style->textfont(dfont); + fltk::Widget::default_style->textsize( + (int) rint(14.0 * prefs.font_factor)); + fltk::Widget::default_style->labelfont(dfont); + } + + // Create a new UI/bw pair BrowserWindow *bw = a_UIcmd_browser_window_new(0, 0, NULL); Index: src/menu.cc =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/menu.cc,v retrieving revision 1.23 diff -u -r1.23 menu.cc --- src/menu.cc 22 Oct 2008 18:05:38 -0000 1.23 +++ src/menu.cc 9 Nov 2008 19:43:46 -0000 @@ -308,7 +308,7 @@ if (!pm) { Item *i; - pm = new PopupMenu(0,0,0,0,"&PAGE OPTIONS"); + pm = new PopupMenu(0,0,0,0,NULL); pm->begin(); i = new Item("View page Source"); i->callback(Menu_view_page_source_cb); @@ -360,7 +360,7 @@ popup_url = a_Url_dup(url); if (!pm) { Item *i; - pm = new PopupMenu(0,0,0,0,"&LINK OPTIONS"); + pm = new PopupMenu(0,0,0,0,NULL); //pm->callback(Menu_link_cb, url); pm->begin(); i = new Item("Open Link in New Window"); @@ -404,7 +404,7 @@ if (!pm) { Item *i; - pm = new PopupMenu(0,0,0,0,"&IMAGE OPTIONS"); + pm = new PopupMenu(0,0,0,0,NULL); pm->begin(); i = new Item("Isolate Image"); i->callback(Menu_open_url_cb); @@ -478,10 +478,10 @@ new Divider(); i = new Item("Exit Dillo", ALT+'q', filemenu_cb, (void*)"ed"); pm->type(PopupMenu::POPUP123); + pm->label(wid->visible() ? NULL : "File"); pm->end(); } - pm->label(wid->visible() ? NULL : "File"); a_Timeout_add(0.0, Menu_popup_cb2, (void *)pm); } @@ -498,7 +498,7 @@ popup_url = a_Url_dup(url); if (!pm) { Item *i; - pm = new PopupMenu(0,0,0,0,"&BUG METER OPTIONS"); + pm = new PopupMenu(0,0,0,0,NULL); pm->begin(); i = new Item("Validate URL with W3C"); i->callback(Menu_bugmeter_validate_w3c_cb); @@ -536,9 +536,9 @@ dFree(history_list); if (direction == -1) { - pm = new PopupMenu(0,0,0,0, "&PREVIOUS PAGES"); + pm = new PopupMenu(0,0,0,0,NULL); } else { - pm = new PopupMenu(0,0,0,0, "&FOLLOWING PAGES"); + pm = new PopupMenu(0,0,0,0,NULL); } // Get a list of URLs for this popup

3 9

Re: patch: middle-click submits in new window/tab
by jcid＠dillo.org Nov. 10, 2008

Nov. 10, 2008

On Mon, Oct 20, 2008 at 02:49:41PM +0000, corvid wrote: > I could say that it was for the sake of consistency with link behavior, > but really it was because it seemed like a dilloishly simple way > to get the equivalent of pages-remember-form-data. The consistency part is a strong argument. Also interesting is the way we can have a workaround to remember form data, before a more usual way of handling it is implemented. > > (But: who will ever discover that it exists or recognize what it > makes possible?) It may be stated in the FAQ. > 1) fltkui: it might be better to stuff all of the button event stuff > into a bag like fltkviewbase/layout do with EventButton. It certainly > looks nicer having something like a shift mask hidden away in a nice > tidy box, but I wasn't sure that it was actually worth doing. Hmm, I'd say if it's going to be a definitive patch, it's worth the effort. > 2) form: carrying around buttonNo+shifted for a long time > is not pleasing, but oh well. Agreed. Now that Johannes is interested in implementing FORM "memory", I'd say it can be stored in an URL/form-data array. I haven't checked how other browsers (e.g. FF) solve the problem of privacy (aka. when it's desirable to remember data), but most probably a quick look will shed some light. BTW, I can't compile the patch here because: make[2]: Entering directory `/home/jcid/C/Dillo/d2/dillo2-cur/test' form.cc: In member function 'void form::Form::addButtonResource(const char*, dw::core::ui::ButtonResource*, const char*)': form.cc:241: error: cannot allocate an object of abstract type 'form::Form::FormClickedReceiver' form.hh:124: note: because the following virtual functions are pure within 'form::Form::FormClickedReceiver': ../dw/ui.hh:338: note: virtual void dw::core::ui::ButtonResource::ClickedReceiver::clicked(dw::core::ui::ButtonReso urce*, int, int) make[2]: *** [form.o] Error 1 make[2]: Leaving directory `/home/jcid/C/Dillo/d2/dillo2-cur/test' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jcid/C/Dillo/d2/dillo2-cur' BTW2: * The patch changes from "Activate" to "Clicked" signal. * It also seems to change the logic in DilloHtmlInput::activate() - it makes me wonder whether pressing enter on other form widgets may submit. Anyway, it'd be good if you can coordinate with Johannes and decide what approach to take, and send a new patch for it. I'd prefer Johannes to keep working in the CSS front, and you to make the definitive patch, but this is for you guys to decide. -- Cheers Jorge.-

3 3

patch: prefs.vw_fontname as fltk ui's default font
by corvid＠lavabit.com Nov. 10, 2008

Nov. 10, 2008

I was changing the font in a few more places that can take arbitrary user text -- and then having to change it for neighbouring things so that the difference isn't too jarring -- and I reached the point where it seemed like it may be best just to change the font for everything.

3 4

patch: click elsewhere on page, fltk widget loses focus
by corvid＠lavabit.com Nov. 10, 2008

Nov. 10, 2008

{my usual dw disclaimer}, but it's been working just fine so far.

3 2

rebased patch: print numeric addresses instead of pointer
by 4winter＠informatik.uni-hamburg.de Nov. 9, 2008

Nov. 9, 2008

Skipped content of type multipart/mixed

2 2

patch: savefile url name
by corvid＠lavabit.com Nov. 9, 2008

Nov. 9, 2008

Anyway, here's a patch that I've had sitting around for a while. I have a bad habit of hitting space to page down when the Location field still has focus, which would break things when trying to save...

2 1

Few more dillo issues
by sandshrew＠gmail.com Nov. 8, 2008

Nov. 8, 2008

Issues: 1) ssl dpi looping when entering: http://www.elitehackers.info/forums 2) logging into kde forum (forum.kde.org) and gmail (which I reported earlier) doesn't seem to work for same reasons. I guess there should be much more similar cases.

1 0

Re: css prototype on freehg.org
by jcid＠dillo.org Nov. 7, 2008

Nov. 7, 2008

Hi, We've been arranging some CSS things behind the scenes with Johannes (he'll forward some past mails here soon). On Fri, Oct 31, 2008 at 05:00:54PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > I just created a repository > http://freehg.org/u/jh33/dillo-css-prototype/ > > freehg.org is a free mercurial hosting service. > This gives access to the newest version of the css prototyping work. > Also you can check whether you like mercurial. > > To get a copy of the repository call > > hg clone http://freehg.org/u/jh33/dillo-css-prototype/ > > and start hacking. You can commit locally using > > hg commit OK, I'll make some patches with Hg once I grasp how this distributed model works. On the current code, basically it looks OK to me. i.e. we can continue working from that basis (having in mind that it's still in a flux state and that a validation is pending on whether the model is able to handle the current functionality in html.cc). My main comment is that the code needs more comments! :) Accurate comments are written when the code is developed (every detail is in the brain then). I've tried in the past to develop first and comment later, and found it only works OK for small code projects. As with CSS we don't have a main expert (yet), the team will be trying to understand and develop at the same time, and thus comments are very necessary. Even something like "I don't know how to implement this part" helps! I'd suggest to use the same format that's in css.cc. e.g. /** \todo dummy only */ with a view to integrate it smoothly with doxygen docs. in the future. Some specific examples: 1.- What do these functions do? - style0() - startElement() - endElement() 2.- On memory handling, there are some places with: // html->styleEngine->style () = // Style::create (HT2LT(html), &style_attrs); // old_style->unref (); or // (html->styleEngine->style ())->unref (); Why are they commented and left in the code? Is proper memory handling pending, is there a design decision to be made before getting rid of them? 3.- With regard, for instance, to font_factor and visited link color. Do they belong to buildUserAgentStyle() or buildUserStyle() or elsewhere? 4.- strdup/free should be dStrdup/dFree (Please let me use this extremely simple case to make my first Hg patch :-) I know this was just a prototype for the CSS implementation idea, but considering that we don't have any better, and that we agreed on it, now it has attained the status of "official CSS merge effort". ;-) From now comments are paramount, and we may eventually get to a dw-like quality docs in the future. Bottom line: Great, let's get started! -- Cheers Jorge.-

2 1

[jcid@dillo.org: Re: css prototype on freehg.org]
by Johannes.Hofmann＠gmx.de Nov. 7, 2008

Nov. 7, 2008

----- Forwarded message from Jorge Arellano Cid <jcid(a)dillo.org> ----- Date: Thu, 6 Nov 2008 14:05:33 -0300 From: Jorge Arellano Cid <jcid(a)dillo.org> To: Johannes Hofmann <Johannes.Hofmann(a)gmx.de> Subject: Re: css prototype on freehg.org On Thu, Nov 06, 2008 at 05:31:34PM +0100, Johannes Hofmann wrote: > > > > I'm currently reviewing the CSS work you uploaded! > > > > On Fri, Oct 31, 2008 at 05:00:54PM +0100, Johannes Hofmann wrote: > > > Hi Jorge, > > > > > > I just created a repository > > > http://freehg.org/u/jh33/dillo-css-prototype/ > > > > > > freehg.org is a free mercurial hosting service. > > > This gives access to the newest version of the css prototyping work. > > > Also you can check whether you like mercurial. > > > > Hmm, that's another topic that needs a resolution: > > to git or to hg? > > Featurewise there is hardly a difference. I prefer mercurial because > of it's nice and simple ui. > Just recently there was the same discussion for DragonFlyBSD: > http://leaf.dragonflybsd.org/mailarchive/kernel/2008-10/msg00144.html Yes, I also like simple UIs. > > [...] > > Do you have a recommended quick-start guide? > > http://www.selenic.com/mercurial/wiki/index.cgi/QuickStart > > and a bit longer: > > http://www.selenic.com/mercurial/wiki/index.cgi/Tutorial > > and a lot longer: > > http://hgbook.red-bean.com/hgbook.html Thanks. > > > > > I didn't send this to the list, because I want to be sure that you > > > are ok with this step. > > > > Which one, the mercurial or the CSS code? > > Both. Publishing CSS prototype in a separate repository. For now the Hg repository is OK. I'm yet to grasp the distributed workflow model. It seems our old CVS needs an update. > > > > As far as CSS, after the first review it looks OK, and > > seems the way to go. I'm going more in depth now to try to > > understand how it works and fits in the plan. > > Great. Please keep in mind that the current work tries to find a > proper interface between CSS stuff and the code in html.cc. > It needs to be verified that the concept covers all the edge cases. > One is probabely the table code that stores a separate > table_cell_style on the stack. > Is this to hold cell properties that were set in the <table> or <tr> > tags? I'll check. Most probably that's the case though. e.g. bgcolor. OK, once I've grasped the concept, I'll tell you what I find. > > > Also the CSS prototype contains some code from dillo-0.8.0-css-3 > > > that doesn't have license headers. Can you contact Sebastian to ask > > > if it is ok to use stuff from his prototype? > > > > I have an email from him (long time ago) where he advocates > > on making the CSS prototype code more visible from the website, > > to attract developers. He also said he was working on floating objects! > > > > I'll try to contact him and see what's up with him... > > > > As from his email, and conversations we had long ago, > > I believe it's quite safe to use the code. > > Great. It seems to contain a pretty complete CSS parser. > > Cheers, > Johannes > > PS: We should probabely take this discussion to the list. It's a bit > quiet there. What do You think? Sure, feel free to forward the thread (or relevant parts). -- Cheers Jorge.- ----- End forwarded message -----

1 0