On Mon, Jan 24, 2011 at 06:11:31PM +0000, corvid wrote: Roger wrote:
'hg update' && patch from this thread.
Your backtrace doesn't match up for dw/layout.cc, for instance. Is there an 'hg pull' in there as well? (Also, if it wasn't clear, a new version of the UI patch went up yesterday.)
Going from memory, I believe they were window functions calling the old 2.0 branch names instead of 1.3.
I believe I already sent you the details, but since they were only test programs and didn't hinder dillo from being built, they aren't a high priority.
I fixed up the Browser test to compile a couple of days ago.
Yup. I performed the 'hg tip' and compared with your times and mine still showed older. This is exactly what I was afraid of. svn/cvs update seems so much friendlier! So, I just wiped and re-cloned. Within the following compiler error stdout's, please ignore the "-I/usr/include/fltk-1.1" as the package maintainer for fltk-1.3 ebuilds on bugs.gentoo.org is working to get the library slotted correctly. I only have fltk-1.3 and fltk-2.0 libraries installed here. Here's that pthread issue again: g++ -I/usr/include/libpng14 -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o ui.o uicmd.o bw.o cookies.o auth.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/lib -lpng14 -L/usr/lib/fltk-1.1 -Wl,-rpath,/usr/lib/fltk-1.1 -lfltk -lXext -lXft -lfontconfig -ldl -lm -lX11 -lz dns.o: In function `Dns_server_req': /home/roger/src/dillo/dillo_port1.3/src/dns.c:360: undefined reference to `pthread_create' Too resolve, ./configure --disable-threaded-dns (or am I missing a dep?... I don't think so.) Here's the Flock() function call to the old fltk-2.0 lock function: g++ -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o downloads.dpi downloads_dpi-downloads.o dpiutil.o -L/usr/lib/fltk-1.1 -Wl,-rpath,/usr/lib/fltk-1.1 -lfltk -lXext -lXft -lfontconfig -ldl -lm -lX11 ../dpip/libDpip.a ../dlib/libDlib.a downloads_dpi-downloads.o: In function `main': /home/roger/src/dillo/dillo_port1.3/dpi/downloads.cc:1105: undefined reference to `Fl::lock()' Test programs compiled without errors. On execute, I see the "Back, Forward, Home, ..." buttons with a slice of the bottom of the "File, View, ..." stuff. Everything else seems frozen. If I'm not mistaken, I can see the toolbar window extend a third of the way down the screen. Then the next 2/3's I see the light grey browser window with slider. Then 3/3 I can see the top slice of "File, View, ..." toolbar window. Oh. I found the hidden "File" button from "File, View, ..." toolbar. But I can't open a url. But did get a new blank tab open. No pages loaded yet. ctrl-s gets me search the web, and ctrl-r seems to be reloading an invisible page (likely google.com as I see it loads two images from the text info). ctrl-l (open file) and ctrl-n (new window) works. ctrl-l fails to open an applet (open url). Looks like pages are loading by looking at the console and the text info detailing "images loaded", but everything is invisible ... windows borking? Looks like rendering pages is being done invisible because the applets/windows are failing.
Roger wrote:
Yup. I performed the 'hg tip' and compared with your times and mine still showed older. This is exactly what I was afraid of. svn/cvs update seems so much friendlier!
So, I just wiped and re-cloned.
Had you been using 'hg pull http://hg.dillo.org/dillo_port1.3'? I'll take a look at this pthread/lock matter... UI brokenness: Is the patch applying cleanly for you? I'll send you a screenshot of what I see with and without the patch. It should look rather like ordinary dillo but unpolished.
On Mon, Jan 24, 2011 at 09:39:37PM +0000, corvid wrote: Roger wrote:
Yup. I performed the 'hg tip' and compared with your times and mine still showed older. This is exactly what I was afraid of. svn/cvs update seems so much friendlier!
So, I just wiped and re-cloned.
Had you been using 'hg pull http://hg.dillo.org/dillo_port1.3'?
I'll take a look at this pthread/lock matter...
UI brokenness: Is the patch applying cleanly for you? I'll send you a screenshot of what I see with and without the patch. It should look rather like ordinary dillo but unpolished.
I was just using hg update (after the initial hg clone $url). Totally scratch the buggy GUI description I gave! I forgot to apply 1.3_ui_hardcoded.patch from this thread! 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. 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. Images do load for "http://forecast.weather.gov/MapClick.php?zoneid=AKZ222" and www.google.com. But negative images for news.google.com ... no biggy as I only really read text. I'll try the pthread patch next.
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?
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/
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/
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.
On Wed, 26 Jan 2011 01:42:38 -0500, corvid <corvid@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
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
Benjamin, 1) If your boat is sinking, you get into a different boat. 2) Man, the idea with Free Software is community and sharing and common good, and not Corvid-does-everything-himself.
On 1/26/11, corvid <corvid@lavabit.com> wrote:
Benjamin,
1) If your boat is sinking, you get into a different boat.
All I'm saying is Dillo seems to get into a *lot* of leaky boats.
2) Man, the idea with Free Software is community and sharing and common good, and not Corvid-does-everything-himself.
I didn't mean that as personal criticism -- I was simply pointing out how the situation might look to an outsider not really active in Dillo development. (I work as a technical editor, so reading too much into things is literally my job.) My point, in short, is that Dillo's already had to switch from one obsolete toolkit, and doing it again doesn't reflect well on the project, however necessary or justified it is. This is the "damned if you do" to everyone else's collective "damned if you don't." But I suppose I've wasted enough words in making my point. ~Benjamin
Roger wrote:
Here's that pthread issue again: g++ -I/usr/include/libpng14 -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o ui.o uicmd.o bw.o cookies.o auth.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/lib -lpng14 -L/usr/lib/fltk-1.1 -Wl,-rpath,/usr/lib/fltk-1.1 -lfltk -lXext -lXft -lfontconfig -ldl -lm -lX11 -lz dns.o: In function `Dns_server_req': /home/roger/src/dillo/dillo_port1.3/src/dns.c:360: undefined reference to `pthread_create'
Does the attached fix this for you?
participants (4)
-
corvid＠lavabit.com -
Hole.destructor＠gmx.de -
obeythepenguin＠gmail.com -
rogerx.oss＠gmail.com