BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything.
On Fri, Oct 03, 2008 at 01:07:36PM -0400, Jorge Arellano Cid wrote:
Hi,
Committed.
On Thu, Oct 02, 2008 at 06:58:25PM +0000, corvid wrote:
BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything.
Yeah. Even MenuBar::handle() doesn't see them.
Seems like an FLTK bug/feature. If you try ./menu in FLTK's test/ directory, the CTRL shortcuts for the "Edit" menu don't work. Time to ask or to STR? -- Cheers Jorge.-
Jorge wrote:
On Fri, Oct 03, 2008 at 01:07:36PM -0400, Jorge Arellano Cid wrote:
Hi,
Committed.
On Thu, Oct 02, 2008 at 06:58:25PM +0000, corvid wrote:
BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything.
Yeah. Even MenuBar::handle() doesn't see them.
Seems like an FLTK bug/feature.
If you try ./menu in FLTK's test/ directory, the CTRL shortcuts for the "Edit" menu don't work.
Time to ask or to STR?
I see that if I uncomment the // if (widget->active() && widget->test_shortcut(false)) { // setitem(p, menu, item); // lastkey = 0; // goto EXECUTE; // } in MWindow::handle(int event) in Menu_popup.cxx, ctrl-Q and alt-Q work.
On Fri, Oct 03, 2008 at 07:02:47PM +0000, corvid wrote:
Jorge wrote:
On Fri, Oct 03, 2008 at 01:07:36PM -0400, Jorge Arellano Cid wrote:
Hi,
Committed.
On Thu, Oct 02, 2008 at 06:58:25PM +0000, corvid wrote:
BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything.
Yeah. Even MenuBar::handle() doesn't see them.
Seems like an FLTK bug/feature.
If you try ./menu in FLTK's test/ directory, the CTRL shortcuts for the "Edit" menu don't work.
Time to ask or to STR?
I see that if I uncomment the // if (widget->active() && widget->test_shortcut(false)) { // setitem(p, menu, item); // lastkey = 0; // goto EXECUTE; // } in MWindow::handle(int event) in Menu_popup.cxx, ctrl-Q and alt-Q work.
OK, it's clear it was deactivated by some reason... From: 1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem. 6.- redraw storms (TabGroup pager) 7.- CTRL+q ALT+q don't work from File menu. We have: 1, 2) have patches (for FLTK), and we could wait for a new release or code workarounds for them in dillo. 3) Fixed 4) Easy to code a 128 limit in dillo and avoid the segfault. 5) Fixed. 6) Fixed. 7) FLTK problem, no patch yet. No CRASH with Dillo. What do we do? a) Contact FLTK developers and wait for a patched release, then workaround the rest (if any) in dillo and release. b) Workaround in dillo and release. Comments? -- Cheers Jorge.-
Jorge wrote:
From:
1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem. 6.- redraw storms (TabGroup pager) 7.- CTRL+q ALT+q don't work from File menu.
We have:
1, 2) have patches (for FLTK), and we could wait for a new release or code workarounds for them in dillo. 3) Fixed 4) Easy to code a 128 limit in dillo and avoid the segfault. 5) Fixed. 6) Fixed. 7) FLTK problem, no patch yet. No CRASH with Dillo.
Also I'm seeing that findbar problem. Load a page. ^F to open the findbar. Click in the viewport. Try to click in the findbar again. Can't type in it. (Works fine if you use ^F to return to it, though.)
What do we do?
a) Contact FLTK developers and wait for a patched release, then workaround the rest (if any) in dillo and release. b) Workaround in dillo and release.
Comments?
Trying to get them to fix bugs and apply those that Johannes has given them is good, but at the same time I think I would act as if nothing will come of it -- working around what can be worked around easily and preparing for release. I'd hate to wait while nothing happens...and nothing happens...and nothing continues to happen. And, if it becomes necessary, a patched FLTK2 snapshot can be placed on dillo.org until they fix the official one.
On Sat, Oct 04, 2008 at 12:37:34AM +0000, corvid wrote:
Jorge wrote:
From:
1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem. 6.- redraw storms (TabGroup pager) 7.- CTRL+q ALT+q don't work from File menu.
We have:
1, 2) have patches (for FLTK), and we could wait for a new release or code workarounds for them in dillo. 3) Fixed 4) Easy to code a 128 limit in dillo and avoid the segfault. 5) Fixed. 6) Fixed. 7) FLTK problem, no patch yet. No CRASH with Dillo.
Also I'm seeing that findbar problem. Load a page. ^F to open the findbar. Click in the viewport. Try to click in the findbar again. Can't type in it. (Works fine if you use ^F to return to it, though.)
Fixed in CVS.
What do we do?
a) Contact FLTK developers and wait for a patched release, then workaround the rest (if any) in dillo and release. b) Workaround in dillo and release.
Comments?
Trying to get them to fix bugs and apply those that Johannes has given them is good, but at the same time I think I would act as if nothing will come of it -- working around what can be worked around easily and preparing for release. I'd hate to wait while nothing happens...and nothing happens...and nothing continues to happen.
And, if it becomes necessary, a patched FLTK2 snapshot can be placed on dillo.org until they fix the official one.
Could be. I'd like to provide a patched FLTK2 tarball from our site, just to keep workarounds out of dillo tree, but some people may want to try dillo2 with their distro-provided FLTK2. In that case we may provide a dillo2 tarball for our patched FLTK2, and also a dillo-workarounds patch for the official FLTK2. Anyway, it'd be good to ask the FLTK team... -- Cheers Jorge.-
On Fri, Oct 03, 2008 at 07:05:47PM -0400, Jorge Arellano Cid wrote:
On Fri, Oct 03, 2008 at 07:02:47PM +0000, corvid wrote:
Jorge wrote:
On Fri, Oct 03, 2008 at 01:07:36PM -0400, Jorge Arellano Cid wrote:
Hi,
Committed.
On Thu, Oct 02, 2008 at 06:58:25PM +0000, corvid wrote:
BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything.
Yeah. Even MenuBar::handle() doesn't see them.
Seems like an FLTK bug/feature.
If you try ./menu in FLTK's test/ directory, the CTRL shortcuts for the "Edit" menu don't work.
Time to ask or to STR?
I see that if I uncomment the // if (widget->active() && widget->test_shortcut(false)) { // setitem(p, menu, item); // lastkey = 0; // goto EXECUTE; // } in MWindow::handle(int event) in Menu_popup.cxx, ctrl-Q and alt-Q work.
OK, it's clear it was deactivated by some reason...
From:
1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem. 6.- redraw storms (TabGroup pager) 7.- CTRL+q ALT+q don't work from File menu.
We have:
1, 2) have patches (for FLTK), and we could wait for a new release or code workarounds for them in dillo. 3) Fixed 4) Easy to code a 128 limit in dillo and avoid the segfault.
Patch attached. Cheers, Johannes
On Sat, Oct 04, 2008 at 08:24:00PM +0200, Johannes Hofmann wrote:
On Fri, Oct 03, 2008 at 07:05:47PM -0400, Jorge Arellano Cid wrote:
On Fri, Oct 03, 2008 at 07:02:47PM +0000, corvid wrote:
Jorge wrote:
On Fri, Oct 03, 2008 at 01:07:36PM -0400, Jorge Arellano Cid wrote:
Hi,
Committed.
On Thu, Oct 02, 2008 at 06:58:25PM +0000, corvid wrote:
BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything.
Yeah. Even MenuBar::handle() doesn't see them.
Seems like an FLTK bug/feature.
If you try ./menu in FLTK's test/ directory, the CTRL shortcuts for the "Edit" menu don't work.
Time to ask or to STR?
I see that if I uncomment the // if (widget->active() && widget->test_shortcut(false)) { // setitem(p, menu, item); // lastkey = 0; // goto EXECUTE; // } in MWindow::handle(int event) in Menu_popup.cxx, ctrl-Q and alt-Q work.
OK, it's clear it was deactivated by some reason...
From:
1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem. 6.- redraw storms (TabGroup pager) 7.- CTRL+q ALT+q don't work from File menu.
We have:
1, 2) have patches (for FLTK), and we could wait for a new release or code workarounds for them in dillo. 3) Fixed 4) Easy to code a 128 limit in dillo and avoid the segfault.
Patch attached.
Committed. BTW, I introduced the "WORKAROUND:" tag (akin to "BUG:" and "TODO:"). -- Cheers Jorge.-
Jorge wrote:
From:
1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem. 6.- redraw storms (TabGroup pager) 7.- CTRL+q ALT+q don't work from File menu.
We have:
1, 2) have patches (for FLTK), and we could wait for a new release or code workarounds for them in dillo. 3) Fixed 4) Easy to code a 128 limit in dillo and avoid the segfault. 5) Fixed. 6) Fixed. 7) FLTK problem, no patch yet. No CRASH with Dillo.
I see that Bill Spitzak has committed (1) and RAW_LABEL. It may be that I had too little faith in the FLTKers...
On Mon, Oct 06, 2008 at 02:14:19PM +0000, corvid wrote:
Jorge wrote:
From:
1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem. 6.- redraw storms (TabGroup pager) 7.- CTRL+q ALT+q don't work from File menu.
We have:
1, 2) have patches (for FLTK), and we could wait for a new release or code workarounds for them in dillo. 3) Fixed 4) Easy to code a 128 limit in dillo and avoid the segfault. 5) Fixed. 6) Fixed. 7) FLTK problem, no patch yet. No CRASH with Dillo.
I see that Bill Spitzak has committed (1) and RAW_LABEL. It may be that I had too little faith in the FLTKers...
Given the quick response by the FLTK team, it may make sense to wait for the next release and release dillo after that. Meanwhile I could give some time to the File menu issue, and you may give a look at the session cookies. -- Cheers Jorge.-
On Mon, Oct 06, 2008 at 02:14:19PM +0000, corvid wrote:
Jorge wrote:
From:
1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem. 6.- redraw storms (TabGroup pager) 7.- CTRL+q ALT+q don't work from File menu.
We have:
1, 2) have patches (for FLTK), and we could wait for a new release or code workarounds for them in dillo. 3) Fixed 4) Easy to code a 128 limit in dillo and avoid the segfault. 5) Fixed. 6) Fixed. 7) FLTK problem, no patch yet. No CRASH with Dillo.
I see that Bill Spitzak has committed (1) and RAW_LABEL. It may be that I had too little faith in the FLTKers...
And the TEXTAREA fix! http://fltk.org/newsgroups.php?s3559+gfltk.commit+v3568+T0 -- Cheers Jorge.-
On Tue, Oct 07, 2008 at 09:59:20AM -0400, Jorge Arellano Cid wrote:
On Mon, Oct 06, 2008 at 02:14:19PM +0000, corvid wrote:
Jorge wrote:
From:
1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem. 6.- redraw storms (TabGroup pager) 7.- CTRL+q ALT+q don't work from File menu.
We have:
1, 2) have patches (for FLTK), and we could wait for a new release or code workarounds for them in dillo. 3) Fixed 4) Easy to code a 128 limit in dillo and avoid the segfault. 5) Fixed. 6) Fixed. 7) FLTK problem, no patch yet. No CRASH with Dillo.
I see that Bill Spitzak has committed (1) and RAW_LABEL. It may be that I had too little faith in the FLTKers...
And the TEXTAREA fix!
Excellent. From previous announcements I'd expect the next weekly fltk2 snapshot by friday. Is there anything left we need for the release? What about the binary and config file name? Cheers, Johannes
On Tue, Oct 07, 2008 at 06:12:47PM +0000, corvid wrote:
Johannes wrote:
Excellent. From previous announcements I'd expect the next weekly fltk2 snapshot by friday. Is there anything left we need for the release? What about the binary and config file name?
We have to remember to take clear_double_buffer out before releasing.
I thought we would keep it. Without it things get awfully slow here with more than 5 windows. Also all the backBuffer stuff in FltkViewBase would be unnecessary then. Are you seeing any problems with clear_double_buffer()? Cheers, Johannes
Johannes wrote:
On Tue, Oct 07, 2008 at 06:12:47PM +0000, corvid wrote:
Johannes wrote:
Excellent. From previous announcements I'd expect the next weekly fltk2 snapshot by friday. Is there anything left we need for the release? What about the binary and config file name?
We have to remember to take clear_double_buffer out before releasing.
I thought we would keep it. Without it things get awfully slow here with more than 5 windows. Also all the backBuffer stuff in FltkViewBase would be unnecessary then. Are you seeing any problems with clear_double_buffer()?
In the course of this thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-April/004022.html we learned that drawing with antialiased fonts is exceedingly slow for me for some reason with clear_double_buffer.
On Tue, Oct 07, 2008 at 10:54:47PM +0000, corvid wrote:
Johannes wrote:
On Tue, Oct 07, 2008 at 06:12:47PM +0000, corvid wrote:
Johannes wrote:
Excellent. From previous announcements I'd expect the next weekly fltk2 snapshot by friday. Is there anything left we need for the release? What about the binary and config file name?
We have to remember to take clear_double_buffer out before releasing.
I thought we would keep it. Without it things get awfully slow here with more than 5 windows. Also all the backBuffer stuff in FltkViewBase would be unnecessary then. Are you seeing any problems with clear_double_buffer()?
In the course of this thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-April/004022.html we learned that drawing with antialiased fonts is exceedingly slow for me for some reason with clear_double_buffer.
I thought that had been resolved by changing the color depth. Anyway, what about a runtime option to choose the buffering scheme (patch attached). Please review the wording especially in the dillo2rc comment. Cheers, Johannes
Johannes wrote:
On Tue, Oct 07, 2008 at 10:54:47PM +0000, corvid wrote:
Johannes wrote:
On Tue, Oct 07, 2008 at 06:12:47PM +0000, corvid wrote:
Johannes wrote:
Excellent. From previous announcements I'd expect the next weekly fltk2 snapshot by friday. Is there anything left we need for the release? What about the binary and config file name?
We have to remember to take clear_double_buffer out before releasing.
I thought we would keep it. Without it things get awfully slow here with more than 5 windows. Also all the backBuffer stuff in FltkViewBase would be unnecessary then. Are you seeing any problems with clear_double_buffer()?
In the course of this thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-April/004022.html we learned that drawing with antialiased fonts is exceedingly slow for me for some reason with clear_double_buffer.
I thought that had been resolved by changing the color depth.
16-bit is amazingly slow and 24-bit is less slow, but 24-bit made other things like rxvt quite slow. Turning off antialiasing made it very fast, but then if I want good unicode coverage...
Anyway, what about a runtime option to choose the buffering scheme
Perhaps.
On Wed, Oct 08, 2008 at 03:47:37PM +0000, corvid wrote:
Johannes wrote:
On Tue, Oct 07, 2008 at 10:54:47PM +0000, corvid wrote:
Johannes wrote:
On Tue, Oct 07, 2008 at 06:12:47PM +0000, corvid wrote:
Johannes wrote:
Excellent. From previous announcements I'd expect the next weekly fltk2 snapshot by friday. Is there anything left we need for the release? What about the binary and config file name?
We have to remember to take clear_double_buffer out before releasing.
I thought we would keep it. Without it things get awfully slow here with more than 5 windows. Also all the backBuffer stuff in FltkViewBase would be unnecessary then. Are you seeing any problems with clear_double_buffer()?
In the course of this thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-April/004022.html we learned that drawing with antialiased fonts is exceedingly slow for me for some reason with clear_double_buffer.
I thought that had been resolved by changing the color depth.
16-bit is amazingly slow and 24-bit is less slow, but 24-bit made other things like rxvt quite slow.
Turning off antialiasing made it very fast, but then if I want good unicode coverage...
Well, I know it often looks ugly, but you can turn off antiliasing while keeping xft and using ttf fonts by putting a .fonts.conf file with: <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <match target="font"> <edit name="antialias" mode="assign"> <bool>false</bool> </edit> </match> </fontconfig> in your home directory. Maybe it's worth a try. Cheers, Johannes
Johannes wrote:
On Wed, Oct 08, 2008 at 03:47:37PM +0000, corvid wrote:
Johannes wrote:
On Tue, Oct 07, 2008 at 10:54:47PM +0000, corvid wrote:
Johannes wrote:
On Tue, Oct 07, 2008 at 06:12:47PM +0000, corvid wrote:
Johannes wrote: > Excellent. From previous announcements I'd expect the next weekly > fltk2 snapshot by friday. > Is there anything left we need for the release? > What about the binary and config file name?
We have to remember to take clear_double_buffer out before releasing.
I thought we would keep it. Without it things get awfully slow here with more than 5 windows. Also all the backBuffer stuff in FltkViewBase would be unnecessary then. Are you seeing any problems with clear_double_buffer()?
In the course of this thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-April/004022.html we learned that drawing with antialiased fonts is exceedingly slow for me for some reason with clear_double_buffer.
I thought that had been resolved by changing the color depth.
16-bit is amazingly slow and 24-bit is less slow, but 24-bit made other things like rxvt quite slow.
Turning off antialiasing made it very fast, but then if I want good unicode coverage...
Well, I know it often looks ugly, but you can turn off antiliasing while keeping xft and using ttf fonts by putting a .fonts.conf file with:
<?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig>
<match target="font"> <edit name="antialias" mode="assign"> <bool>false</bool> </edit> </match>
</fontconfig>
in your home directory. Maybe it's worth a try.
It looks like the antialiasing per se isn't the problem. With clear_double_buffer and the above configuration, it takes a few seconds to redraw a page. So I guess I meant "something to do with not using the xft stuff makes it fast"...
On Wed, Oct 08, 2008 at 04:59:24PM +0200, Johannes Hofmann wrote:
On Tue, Oct 07, 2008 at 10:54:47PM +0000, corvid wrote:
Johannes wrote:
On Tue, Oct 07, 2008 at 06:12:47PM +0000, corvid wrote:
Johannes wrote:
Excellent. From previous announcements I'd expect the next weekly fltk2 snapshot by friday. Is there anything left we need for the release? What about the binary and config file name?
We have to remember to take clear_double_buffer out before releasing.
I thought we would keep it. Without it things get awfully slow here with more than 5 windows. Also all the backBuffer stuff in FltkViewBase would be unnecessary then. Are you seeing any problems with clear_double_buffer()?
In the course of this thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-April/004022.html we learned that drawing with antialiased fonts is exceedingly slow for me for some reason with clear_double_buffer.
I thought that had been resolved by changing the color depth. Anyway, what about a runtime option to choose the buffering scheme (patch attached).
CCoommiitteedd. ::--)) Yesternight, I made some tests with an IBM thinkpad 385XD, with a NM2160 Video card (Pentium I 233Mhz with 94MB RAM): With Xft and antialiasing, 16bit depth: buffered_drawing={0,1}: Rendering takes 1 second aprox (PgUp or PgDn). No user noticeable differences with these modes. buffered_drawing=2: Rendering takes 1/3 second aprox (PgUp or PgDn). Feels much better than the former for the user, dragging the scrollbar is also faster. -- Cheers Jorge.-
Johannes wrote:
Anyway, what about a runtime option to choose the buffering scheme (patch attached). Please review the wording especially in the dillo2rc comment.
I just noticed that when I use findtext now, the line above the highlighted line is a bit darker/bolder than the rest. Clicking on a link causes the same thing.
On Thu, Oct 09, 2008 at 06:16:21PM +0000, corvid wrote:
Johannes wrote:
Anyway, what about a runtime option to choose the buffering scheme (patch attached). Please review the wording especially in the dillo2rc comment.
I just noticed that when I use findtext now, the line above the highlighted line is a bit darker/bolder than the rest. Clicking on a link causes the same thing.
Ouch. I forgot the clipping calls in my compile-time to run-time conversion of the double buffering option. Please test attached fix. Cheers, Johannes
Johannes wrote:
On Thu, Oct 09, 2008 at 06:16:21PM +0000, corvid wrote:
Johannes wrote:
Anyway, what about a runtime option to choose the buffering scheme (patch attached). Please review the wording especially in the dillo2rc comment.
I just noticed that when I use findtext now, the line above the highlighted line is a bit darker/bolder than the rest. Clicking on a link causes the same thing.
Ouch. I forgot the clipping calls in my compile-time to run-time conversion of the double buffering option.
Please test attached fix.
Looks good so far...
On Thu, Oct 09, 2008 at 08:22:22PM +0000, corvid wrote:
Johannes wrote:
On Thu, Oct 09, 2008 at 06:16:21PM +0000, corvid wrote:
Johannes wrote:
Anyway, what about a runtime option to choose the buffering scheme (patch attached). Please review the wording especially in the dillo2rc comment.
I just noticed that when I use findtext now, the line above the highlighted line is a bit darker/bolder than the rest. Clicking on a link causes the same thing.
Ouch. I forgot the clipping calls in my compile-time to run-time conversion of the double buffering option.
Please test attached fix.
Looks good so far...
Committed. -- Cheers Jorge.-
On Tue, Oct 07, 2008 at 06:22:20PM +0200, Johannes Hofmann wrote:
On Tue, Oct 07, 2008 at 09:59:20AM -0400, Jorge Arellano Cid wrote:
On Mon, Oct 06, 2008 at 02:14:19PM +0000, corvid wrote:
Jorge wrote:
From:
1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem. 6.- redraw storms (TabGroup pager) 7.- CTRL+q ALT+q don't work from File menu.
We have:
1, 2) have patches (for FLTK), and we could wait for a new release or code workarounds for them in dillo. 3) Fixed 4) Easy to code a 128 limit in dillo and avoid the segfault. 5) Fixed. 6) Fixed. 7) FLTK problem, no patch yet. No CRASH with Dillo.
I see that Bill Spitzak has committed (1) and RAW_LABEL. It may be that I had too little faith in the FLTKers...
And the TEXTAREA fix!
Excellent. From previous announcements I'd expect the next weekly fltk2 snapshot by friday.
Well, maybe Sturday could be a good release day...
Is there anything left we need for the release? What about the binary and config file name?
I think: binary name: dillo version : 2.0 rc file : dillo2rc is OK. Comments? -- Cheers Jorge.-
On Tue, Oct 07, 2008 at 04:44:16PM -0400, Jorge Arellano Cid wrote:
binary name: dillo version : 2.0 rc file : dillo2rc
I think the binary name should be dillo2 . It's consistent with dillo2rc for the rc file. It's also consistent with the established convention for packages like fltk , gtk and gpg where the OS level treats different major versions as entirely different packages (even though the users/developers think of them as merely different versions of the same package). This is critical for library packages which really must support installing multiple versions. For example, I run both fltk and fltk2 applications so it's vital that I can install both major versions and be sure that applications will always link to the right one. This works only because the OS treats the two as entirely different. Of course, dillo2 is not a library package, but I think it should follow the same convention on the grounds of least surprise. (Unless there is a compelling reason not to, but I don't think that there is.) It's like Superman II and The Dark Night, the sequel is better than the original! No need to hide it! Jeremy Henty
On Wed, Oct 08, 2008 at 10:13:23AM +0100, Jeremy Henty wrote:
Of course, dillo2 is not a library package, but I think it should follow the same convention on the grounds of least surprise. (Unless there is a compelling reason not to, but I don't think that there is.)
Does dillo1 offer *anything* over dillo2? E.g. why would you want dillo1 and dillo2 at the same time. If there is no such reason, it doesn't make sense to rename the binary. Joerg
On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote:
On Wed, Oct 08, 2008 at 10:13:23AM +0100, Jeremy Henty wrote:
Of course, dillo2 is not a library package, but I think it should follow the same convention on the grounds of least surprise. (Unless there is a compelling reason not to, but I don't think that there is.)
Does dillo1 offer *anything* over dillo2? E.g. why would you want dillo1 and dillo2 at the same time. If there is no such reason, it doesn't make sense to rename the binary.
Dillo1 is used as an html viewer by sylpheed (claws). I don't know the name of the binary they distribute though. Dillo2 doesn't provide the required CLI switches yet. That's it AFAIR. Dillo2 doesn't have these switches: -x, --xid XID Open first Dillo window in an existing GtkSocket which window ID is XID (decimal). -v, --version Display version info and exit. -h, --help Display this help text and exit. -f, --fullwindow Start in full window mode: hide address bar, navigation buttons, menu, and status bar. -l, --local Don't follow links for this URL(s). -g, -geometry GEO Set initial window position where GEO is <width>x<height>{+-}<x>{+-}<y> -D, --debug-rendering Draw additionaly several lines in a web page, representing its structure. For debugging. Everybody: please add your comment in this thread, even if stated before. -- Cheers Jorge.-
Jorge wrote:
On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote:
On Wed, Oct 08, 2008 at 10:13:23AM +0100, Jeremy Henty wrote:
Of course, dillo2 is not a library package, but I think it should follow the same convention on the grounds of least surprise. (Unless there is a compelling reason not to, but I don't think that there is.)
Does dillo1 offer *anything* over dillo2? E.g. why would you want dillo1 and dillo2 at the same time. If there is no such reason, it doesn't make sense to rename the binary.
Dillo1 is used as an html viewer by sylpheed (claws). I don't know the name of the binary they distribute though. Dillo2 doesn't provide the required CLI switches yet.
That's it AFAIR. Dillo2 doesn't have these switches:
-x, --xid XID Open first Dillo window in an existing GtkSocket which window ID is XID (decimal). -v, --version Display version info and exit. -h, --help Display this help text and exit. -f, --fullwindow Start in full window mode: hide address bar, navigation buttons, menu, and status bar. -l, --local Don't follow links for this URL(s). -g, -geometry GEO Set initial window position where GEO is <width>x<height>{+-}<x>{+-}<y> -D, --debug-rendering Draw additionaly several lines in a web page, representing its structure. For debugging.
Everybody: please add your comment in this thread, even if stated before.
I would prefer "dillo". If anybody wants/needs both versions, mv and ln -s are available to them.
On Wed, Oct 08, 2008 at 02:02:17PM +0000, corvid wrote:
Jorge wrote:
On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote:
On Wed, Oct 08, 2008 at 10:13:23AM +0100, Jeremy Henty wrote:
Of course, dillo2 is not a library package, but I think it should follow the same convention on the grounds of least surprise. (Unless there is a compelling reason not to, but I don't think that there is.)
Does dillo1 offer *anything* over dillo2? E.g. why would you want dillo1 and dillo2 at the same time. If there is no such reason, it doesn't make sense to rename the binary.
Dillo1 is used as an html viewer by sylpheed (claws). I don't know the name of the binary they distribute though. Dillo2 doesn't provide the required CLI switches yet.
That's it AFAIR. Dillo2 doesn't have these switches:
-x, --xid XID Open first Dillo window in an existing GtkSocket which window ID is XID (decimal). -v, --version Display version info and exit. -h, --help Display this help text and exit. -f, --fullwindow Start in full window mode: hide address bar, navigation buttons, menu, and status bar. -l, --local Don't follow links for this URL(s). -g, -geometry GEO Set initial window position where GEO is <width>x<height>{+-}<x>{+-}<y> -D, --debug-rendering Draw additionaly several lines in a web page, representing its structure. For debugging.
Everybody: please add your comment in this thread, even if stated before.
I would prefer "dillo". If anybody wants/needs both versions, mv and ln -s are available to them.
Me too. Citing from the homepage: "Dillo is following an evolving software-model where every new version of it, should be better than the former one; there's no place for unstable releases, so just keep with the latest one" I would even use dillorc for consistency. Cheers, Johannes
On Wed, Oct 08, 2008 at 04:24:59PM +0200, Johannes Hofmann wrote:
I would even use dillorc for consistency.
Yes, if we choose dillo over dillo2 then it should be dillo everywhere. Conversely, I suppose that if choose dillo2 then we should rename ~/.dillo to ~/.dillo2 . Jeremy Henty
On Wed, Oct 08, 2008 at 02:02:17PM +0000, corvid wrote:
Jorge wrote:
On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote:
On Wed, Oct 08, 2008 at 10:13:23AM +0100, Jeremy Henty wrote:
Of course, dillo2 is not a library package, but I think it should follow the same convention on the grounds of least surprise. (Unless there is a compelling reason not to, but I don't think that there is.)
Everybody: please add your comment in this thread, even if stated before.
I would prefer "dillo". If anybody wants/needs both versions, mv and ln -s are available to them.
I would prefer "dillo2". If anybody builds their own version, it should be easy enough for them to change it to "dillo", "dillorc", etc. at compile time. If a distribution is to package it, unless the new program is a drop-in replacement for the old program, the new program should probably have a different name. I haven't looked at fltk-dillo much, but command-line switches acting differently isn't a sign of a drop-in replacement. Are there any incompatibilities with the content of the rc file? Just my haven't-coded-in-a-while opinion... f -- Francis Daly francis@daoine.org
Francis wrote:
If a distribution is to package it, unless the new program is a drop-in replacement for the old program, the new program should probably have a different name.
If history is any judge, they will modify it to remove security and add in buggy features. (Some people even think of dillo as having a reputation for being _crashy_, of all things...) If they rename it, all the better.
On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote:
... why would you want dillo1 and dillo2 at the same time.
I don't know. But when you start saying "No-one could *possibly* want to do that, so let's stop supporting it" then you are riding for a fall. Why make ourselves hostages to fortune? Why not make *sure* we avoid the problem rather than gambling that we've second-guessed our entire user base? Murphy's law applies, so play it safe unless there's a compelling reason not to.
... If there is no such reason, it doesn't make sense to rename the binary.
But we're *not* renaming the binary! We're distributing a new and *different* binary that supports a *different* command line and links to *different* libraries. As far as the OS is concerned that makes them as unlike as chalk and cheese. Therefore we should play it safe by giving them different names. That is the conventional thing to do, and also the safest. Regards, Jeremy Henty
On Wed, Oct 08, 2008 at 03:32:42PM +0100, Jeremy Henty wrote:
On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote:
... why would you want dillo1 and dillo2 at the same time.
I don't know. But when you start saying "No-one could *possibly* want to do that, so let's stop supporting it" then you are riding for a fall. Why make ourselves hostages to fortune? Why not make *sure* we avoid the problem rather than gambling that we've second-guessed our entire user base? Murphy's law applies, so play it safe unless there's a compelling reason not to.
You are adding the overhead of changing user behavior though. The claws backend might be a good reason, frankly it is the only one I see so far. Personally I consider the old version without at least the Xft patches to be plainly useless and everyone I heared talk about using dillo so far had similiar impressions. So changing the binary name (it is still dillo after all) seems just artifical change. The comparisions with libraries doesn't apply. Joerg
On Wed, Oct 08, 2008 at 05:04:29PM +0200, Joerg Sonnenberger wrote:
On Wed, Oct 08, 2008 at 03:32:42PM +0100, Jeremy Henty wrote:
On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote:
... why would you want dillo1 and dillo2 at the same time.
I don't know. But when you start saying "No-one could *possibly* want to do that, so let's stop supporting it" then you are riding for a fall. Why make ourselves hostages to fortune? Why not make *sure* we avoid the problem rather than gambling that we've second-guessed our entire user base? Murphy's law applies, so play it safe unless there's a compelling reason not to.
You are adding the overhead of changing user behavior though. The claws backend might be a good reason, frankly it is the only one I see so far.
OK, just checked Debian and Ubuntu and both have the dillo viewer plugin for sylpheed with a dependency on the plain "dillo" package. Looking around in the FLTK docs, there's this function: CreatedWindow::set_xid() It looks promising. Unfortunately I haven't found a full code example to make it work. If somebody knows how to use it, it'd be simple to make a "drop in" replacement for dillo1, and avoid the problems discussed in this thread. BTW, I'm inclined to using dillorc/dillo/2.0 in the release. -- Cheers Jorge.-
On Thu, Oct 09, 2008 at 04:26:02PM -0400, Jorge Arellano Cid wrote:
On Wed, Oct 08, 2008 at 05:04:29PM +0200, Joerg Sonnenberger wrote:
On Wed, Oct 08, 2008 at 03:32:42PM +0100, Jeremy Henty wrote:
On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote:
... why would you want dillo1 and dillo2 at the same time.
I don't know. But when you start saying "No-one could *possibly* want to do that, so let's stop supporting it" then you are riding for a fall. Why make ourselves hostages to fortune? Why not make *sure* we avoid the problem rather than gambling that we've second-guessed our entire user base? Murphy's law applies, so play it safe unless there's a compelling reason not to.
You are adding the overhead of changing user behavior though. The claws backend might be a good reason, frankly it is the only one I see so far.
OK, just checked Debian and Ubuntu and both have the dillo viewer plugin for sylpheed with a dependency on the plain "dillo" package.
Looking around in the FLTK docs, there's this function:
CreatedWindow::set_xid()
It looks promising. Unfortunately I haven't found a full code example to make it work.
If somebody knows how to use it, it'd be simple to make a "drop in" replacement for dillo1, and avoid the problems discussed in this thread.
I think it's supposed to work more or less like in attached test program. When called with a (decimal) window id (from xlsclients) it draws a small but visible frame on that window. I don't know why it doesn't work correctly. Probabely some more setup necessary... Cheers, Johannes
On Fri, Oct 10, 2008 at 04:13:01PM +0200, Johannes Hofmann wrote:
On Thu, Oct 09, 2008 at 04:26:02PM -0400, Jorge Arellano Cid wrote:
On Wed, Oct 08, 2008 at 05:04:29PM +0200, Joerg Sonnenberger wrote:
On Wed, Oct 08, 2008 at 03:32:42PM +0100, Jeremy Henty wrote:
On Wed, Oct 08, 2008 at 01:09:48PM +0200, Joerg Sonnenberger wrote:
... why would you want dillo1 and dillo2 at the same time.
I don't know. But when you start saying "No-one could *possibly* want to do that, so let's stop supporting it" then you are riding for a fall. Why make ourselves hostages to fortune? Why not make *sure* we avoid the problem rather than gambling that we've second-guessed our entire user base? Murphy's law applies, so play it safe unless there's a compelling reason not to.
You are adding the overhead of changing user behavior though. The claws backend might be a good reason, frankly it is the only one I see so far.
OK, just checked Debian and Ubuntu and both have the dillo viewer plugin for sylpheed with a dependency on the plain "dillo" package.
Looking around in the FLTK docs, there's this function:
CreatedWindow::set_xid()
It looks promising. Unfortunately I haven't found a full code example to make it work.
If somebody knows how to use it, it'd be simple to make a "drop in" replacement for dillo1, and avoid the problems discussed in this thread.
I think it's supposed to work more or less like in attached test program. When called with a (decimal) window id (from xlsclients) it draws a small but visible frame on that window. I don't know why it doesn't work correctly. Probabely some more setup necessary...
Dejan L. sent me this code as an example: http://www.dillo.org/test/gnash.cc ufortunately I can't get to make something that works with it. -- Cheers Jorge.-
participants (6)
-
corvid＠lavabit.com -
francis＠daoine.org -
jcid＠dillo.org -
joerg.sonnenberger＠web.de -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org