January 2011 - Dillo-dev - lists.mailman3.com

patch: configure rm libpng version tests

by corvid＠lavabit.com

Jorge wrote: > On Wed, Jan 26, 2011 at 03:49:05AM +0000, corvid wrote: > > [...] > > Is there a good reason not to use whatever libpng-config is linked to? > > I don't know these days, but a few years ago I had to add all > of those tests because of different names of the configure script > and there were distros packing two versions of the library and > using the script name to differentitate among them. > > *Handle with care* Okay, how about rearranging to put libpng-config first to get whatever they prefer, and we can add in backup tests for versions with less... I was going to say 'urgency', but of course we haven't released a version that handles 1.4 yet... (Aside: With eleven years of history now, we seem to run into a lot of "I think a long time ago, we needed that for something" which suggests that we should be a bit obsessive about our documentation. Sometimes you can get a hint from the list archives, but often the pattern is "A release looms, and someone contacts Jorge off-list about whatever problem, and it is quietly patched".)

Jan. 26, 2011

1.3 port status

by obeythepenguin＠gmail.com

Oops, I meant to send this to the list, not just Alexander -- apologies for that. On Wed, Jan 26, 2011 at 9:12 AM, Alexander Voigt <Hole.destructor(a)gmx.de> wrote: > Maybe this is a solution to the upcomming problem(s). ?What one needs > to do is to build an abstraction and an implementor and pack all > toolkit specific things into concrete implementors (i.e. the FLTK 2.0, > or FLTK 1.3 specific things). There's one obvious problem there: the toolkit is *already* an abstraction. ?(FLTK's not strictly an abstraction layer, because it implements its own widget set, but the purpose of any toolkit is to provide some sort of abstraction over the native APIs.) On top of that, this "solution" doesn't really solve anything -- it still takes time away from development, requires developers to learn the new abstraction layer, and won't make up for functional incompatibilities/missing features between different toolkits or versions. ?It sounds like a great idea in theory -- and IIRC, the Dillo renderer (but not the rest of the interface) is already built on an abstraction layer -- but in practice it would mostly amount to needlessly re-inventing the wheel. Disclaimer: I'm not one of the core developers, and this is only my personal view. ~Benjamin

Jan. 26, 2011

1.3 port status

by Hole.destructor＠gmx.de

Dear Dillo developers. > - Twelve years and three toolkits later, there's still no support > for such basic functionality as floating elements (HTML "align=" or > CSS "float:"). See my other two points. If you allow, I would like to make a constructive proposal at this point. There is an interesting Object Orientated Design Pattern called `Bridge', which is intended to separate an abstraction from the implementation. This is especially convenient if one wants to support more than one toolkit or the toolkit changes frequently. (I think one is not forced to use C++ for this purpose. It should be possible to use pure C and select the concrete implementation at compile time.) Maybe this is a solution to the upcomming problem(s). What one needs to do is to build an abstraction and an implementor and pack all toolkit specific things into concrete implementors (i.e. the FLTK 2.0, or FLTK 1.3 specific things). For examples see: http://en.wikipedia.org/wiki/Bridge_pattern and Gamma, E, Helm, R, Johnson, R, Vlissides, J: Design Patterns, page 151. Addison-Wesley, 1995 Kind regards, Alexander Voigt

Jan. 26, 2011

1.3 port status

by obeythepenguin＠gmail.com

On Wed, 26 Jan 2011 01:42:38 -0500, corvid <corvid(a)lavabit.com> wrote: > The hope is that someone (with any luck, not me) will > learn enough FLTK 1.3 to figure out how to make it nice. I'm sorry, but everything about that sentence makes me cringe. Not meaning this to attack anyone personally, but here's how I'd read the situation as an outsider: - Project leadership wants to switch toolkits, not for the first time. This takes time away from "real" development work (new features, bugfixes, documentation...), and suggests poor planning and indecisiveness. - The current developers aren't familiar with the new toolkit, and suggest -- seriously or otherwise -- they aren't particularly interested in learning it. This takes even more time away from real development, potentially results in buggier, lower quality software, and suggests all sorts of other things besides. - Twelve years and three toolkits later, there's still no support for such basic functionality as floating elements (HTML "align=" or CSS "float:"). See my other two points. I really like Dillo, and I really enjoy hacking on it (both for the code and the great development team). But the whole toolkit situation is throwing up all sorts of red flags, so I hope you can forgive me for voicing a few concerns. ~Benjamin

Jan. 26, 2011

patch: configure rm libpng version tests

by jcid＠dillo.org

On Wed, Jan 26, 2011 at 03:49:05AM +0000, corvid wrote: > [...] > Is there a good reason not to use whatever libpng-config is linked to? I don't know these days, but a few years ago I had to add all of those tests because of different names of the configure script and there were distros packing two versions of the library and using the script name to differentitate among them. *Handle with care* -- Cheers Jorge.-

Jan. 26, 2011

patch: configure rm libpng version tests

by joerg.sonnenberger＠web.de

On Wed, Jan 26, 2011 at 05:42:33AM +0000, corvid wrote: > Hmm, a quick attempt to look through the autoconf manual doesn't say anything > about how to tell --help to list env variables. What is generally done? AC_ARG_VAR, I think. Joerg

Jan. 26, 2011

1.3 port status

by corvid＠lavabit.com

Yeah, the UI is just rough; that's why it's in a patch and not committed. The hope is that someone (with any luck, not me) will learn enough FLTK 1.3 to figure out how to make it nice. Making a true equivalent to fltk::PackedGroup would go a long way there, for one thing.

Jan. 26, 2011

1.3 port status

by rogerx.oss＠gmail.com

>Other then these, dillo built against fltk-1.3 looks fully functional to me so >far. ...might be one or two more quirks. One more GUI bug found, the "X" at the far upper right corner for closing tabs/windows appears to be completely missing. (imo, it's usually much easier to click ctrl-q anyways. ;-) -- Roger http://rogerx.freeshell.org/

Jan. 26, 2011

1.3 port status

by rogerx.oss＠gmail.com

> On Mon, Jan 24, 2011 at 11:03:35PM +0000, corvid wrote: >Roger wrote: >> I was just using hg update (after the initial hg clone $url). > >hg update is something different. You use hg pull to get changes >from a repository. > >> Here's my description now, pages load, even news.google.com loads! Scrolling >> on news.google.com pauses/lags at times. No images loaded on news.google.com. > >Right now, the scrolling doesn't happen while the cursor wanders >outside of the scrollbar bounds. > >> As for the dillo interface, tabs appear after a few seconds/minutes of mouse >> wandering. I do have buttons, but the "File, View, ..." buttons are still >> hidden. > >After mouse wandering? Of their own accord? >View? I think I see one cause of a bug of the GUI. When opening a bookmark from dpi:/bm/ by right clicking and seleting "open link in new tab", the refresh to redraw the GUI frontend is not occurring. As such, the new tab is created invisibily and the GUI isn't refreshed showing the new tab has been opened until the user tries clicking one of the tabs. Now, once the bookmark url has been visited (I'm guessing cached), closing the tab and then reopening the tab via the same bookmark method as described above, the new tab will be visibily created and the GUI bug can no longer being seen. I'm guessing, a full window or GUI refresh or redraw is being dropped somewhere? Concerning the "File" button above the tab bar, I have none showing ... oh wait, thar it is! It's a big "F" button on the button bar next to the "Tools" button! Other then these, dillo built against fltk-1.3 looks fully functional to me so far. ...might be one or two more quirks. -- Roger http://rogerx.freeshell.org/

Jan. 26, 2011

patch: configure rm libpng version tests

by corvid＠lavabit.com

Joerg wrote: > On Wed, Jan 26, 2011 at 03:49:05AM +0000, corvid wrote: > > Is there a good reason not to use whatever libpng-config is linked to? > > I like the idea of not having to touch configure.in every time there's > > a new minor version, especially given how long we go between releases. > > As long as the libpng-config can be overriden by environment / configure > argument and the name of the variable is documented, that's fine. There is a $PNG_CONFIG in there. Hmm, a quick attempt to look through the autoconf manual doesn't say anything about how to tell --help to list env variables. What is generally done?

Jan. 26, 2011