Hi guys, It seems that FLTK will release their final 1.3 version next week on June 8th. Are we waiting on that to release our own dillo 1.3? The reason I'm asking is that as you know I'm preparing an installable Mac OS package, which I hope to go on dillo's download page (and hopefully introduce dillo to many non-developer users). So I'd like to know if we are just waiting on that final release of FLTK 1.3, or whether there are still open bugs remaining for our next release? Thanks, Reza
reza wrote:
It seems that FLTK will release their final 1.3 version next week on June 8th. Are we waiting on that to release our own dillo 1.3? The reason I'm asking is that as you know I'm preparing an installable Mac OS package, which I hope to go on dillo's download page (and hopefully introduce dillo to many non-developer users). So I'd like to know if we are just waiting on that final release of FLTK 1.3, or whether there are still open bugs remaining for our next release?
Right now, I'm aware of: - the preferred font code in src/dillo.cc. The other day, I put a few minutes into setting, e.g., FL_HELVETICA to prefs.font_sans_serif FL_HELVETICA_BOLD to prefs.font_sans_serif " bold" etc. ..which seemed to be working for XFT but not with it disabled. Maybe the latter wanted the -*-*-*-*-style strings, and I'd meant to ask Johannes whether this was all the right direction to go in, anyway, since he'd done the fonts work in dw/ for this port. - tab titles Just cosmetic issues of: They seem too short, the original title of, e.g., ctab5, is suboptimal, and the ones without a title tag are initially blank. - Still missing is the -f command line option (used by claws). Jorge was waiting for something to do with FLTK before taking action there.
On Sun, Jun 05, 2011 at 08:08:15PM +0000, corvid wrote:
reza wrote:
It seems that FLTK will release their final 1.3 version next week on June 8th. Are we waiting on that to release our own dillo 1.3? The reason I'm asking is that as you know I'm preparing an installable Mac OS package, which I hope to go on dillo's download page (and hopefully introduce dillo to many non-developer users). So I'd like to know if we are just waiting on that final release of FLTK 1.3, or whether there are still open bugs remaining for our next release?
Right now, I'm aware of:
- the preferred font code in src/dillo.cc.
The other day, I put a few minutes into setting, e.g., FL_HELVETICA to prefs.font_sans_serif FL_HELVETICA_BOLD to prefs.font_sans_serif " bold" etc. ..which seemed to be working for XFT but not with it disabled. Maybe the latter wanted the -*-*-*-*-style strings, and I'd meant to ask Johannes whether this was all the right direction to go in, anyway, since he'd done the fonts work in dw/ for this port.
I already played with using the Platform::fontExists() interface here, but it somehow didn't work immediately and I got distracted... I can take another look at it. Cheers, Johannes
On Sun, Jun 5, 2011 at 3:08 PM, corvid <corvid@lavabit.com> wrote:
reza wrote:
It seems that FLTK will release their final 1.3 version next week on June 8th. Are we waiting on that to release our own dillo 1.3? The reason I'm asking is that as you know I'm preparing an installable Mac OS package, which I hope to go on dillo's download page (and hopefully introduce dillo to many non-developer users). So I'd like to know if we are just waiting on that final release of FLTK 1.3, or whether there are still open bugs remaining for our next release?
Right now, I'm aware of:
- the preferred font code in src/dillo.cc.
The other day, I put a few minutes into setting, e.g., FL_HELVETICA to prefs.font_sans_serif FL_HELVETICA_BOLD to prefs.font_sans_serif " bold" etc. ..which seemed to be working for XFT but not with it disabled. Maybe the latter wanted the -*-*-*-*-style strings, and I'd meant to ask Johannes whether this was all the right direction to go in, anyway, since he'd done the fonts work in dw/ for this port.
- tab titles
Just cosmetic issues of: They seem too short, the original title of, e.g., ctab5, is suboptimal, and the ones without a title tag are initially blank.
- Still missing is the -f command line option (used by claws).
Jorge was waiting for something to do with FLTK before taking action there.
Do we have features/bugs for each milestone documented anywhere? http://www.dillo.org/Plans.html is a bit too high level. What comes after 1.3? P.S. Are we going to call Dillo with FLTK1.3 as Dillo3? One problem is that on the surface nothing has changed from Dillo2, so users will probably get confused.
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Do we have features/bugs for each milestone documented anywhere??http://www.dillo.org/Plans.html is a bit too high level. What comes after 1.3? I doubt fltk 1.3 will be released on Wednesday: they have yet to release their RC7 which was supposed to be June 1, P.S. Are we going to call Dillo with FLTK1.3 as Dillo3? One problem is that on the surface nothing has changed from Dillo2, so users will probably get confused. How about call it dillo2.3? Btw, it is unfathomable to me why weekly fltk2 updates continue to be released......hopefully, fltk1.3 will not be as much of a roadblock in terms of facilitating adoption of dillo as fltk2 was. Recall that since they never hit stable, distros such as Fedora did not go for dillo2 (sticking with dillo 0.8.6).
On Mon, Jun 06, 2011 at 06:16:58PM -0700, Globe Trotter wrote:
Do we have features/bugs for each milestone documented anywhere??http://www.dillo.org/Plans.html is a bit too high level.
That's the place we have. We can't do much better without more manpower. BTW, I'm surprised on how accurate it became.
What comes after 1.3?
Floating objects! And maybe some announcements that may surprise our users. The point of fltk-1.3 for the Dillo project is to be back in the distro's repos. This is paramount to us.
I doubt fltk 1.3 will be released on Wednesday: they have yet to release their RC7 which was supposed to be June 1,
It's hard to know when it'll happen. After +5years waiting for fltk2, I can only hope fltk-1.3 is released soon. FWIW, development in this branch is very active so it looks like it could happen soon. IIRC, the first estimated release dates were for December 2010.
P.S. Are we going to call Dillo with FLTK1.3 as Dillo3? One problem is that on the surface nothing has changed from Dillo2, so users will probably get confused.
Probably... And possibly the next fltk release will be fltk-3.0, and we should be able to link against it.
Btw, it is unfathomable to me why weekly fltk2 updates continue to be released......
C'mon, that's an easy one!
hopefully, fltk1.3 will not be as much of a roadblock in terms of facilitating adoption of dillo as fltk2 was. Recall that since they never hit stable, distros such as Fedora did not go for dillo2 (sticking with dillo 0.8.6).
That's the sad part of the story. -- Cheers Jorge.-
Hi all,
P.S. Are we going to call Dillo with FLTK1.3 as Dillo3? One problem is that on the surface nothing has changed from Dillo2, so users will probably get confused. Probably...
Guys, how about putting some images from current Dillo with FLTK1.3 into another table at //www.dillo.org/screenshots/? Once there is no definition about release name, the table title can be something like "Dillo with FLTK1.3", plus (maybe) something catchy as "Coming Soon". My point is, you are all doing a lot of job around FLTK1.3 (Yeah!) and a page update might attract more attention to the project, also helping it to get pushed into distros again :) Best regards, F?bio ps: Great work, folks! 2011/6/9 Jorge Arellano Cid <jcid@dillo.org>
On Mon, Jun 06, 2011 at 06:16:58PM -0700, Globe Trotter wrote:
Do we have features/bugs for each milestone documented anywhere? http://www.dillo.org/Plans.html is a bit too high level.
That's the place we have. We can't do much better without more manpower. BTW, I'm surprised on how accurate it became.
What comes after 1.3?
Floating objects! And maybe some announcements that may surprise our users.
The point of fltk-1.3 for the Dillo project is to be back in the distro's repos. This is paramount to us.
I doubt fltk 1.3 will be released on Wednesday: they have yet to release their RC7 which was supposed to be June 1,
It's hard to know when it'll happen. After +5years waiting for fltk2, I can only hope fltk-1.3 is released soon. FWIW, development in this branch is very active so it looks like it could happen soon.
IIRC, the first estimated release dates were for December 2010.
P.S. Are we going to call Dillo with FLTK1.3 as Dillo3? One problem is that on the surface nothing has changed from Dillo2, so users will probably get confused.
Probably...
And possibly the next fltk release will be fltk-3.0, and we should be able to link against it.
Btw, it is unfathomable to me why weekly fltk2 updates continue to be released......
C'mon, that's an easy one!
hopefully, fltk1.3 will not be as much of a roadblock in terms of facilitating adoption of dillo as fltk2 was. Recall that since they never hit stable, distros such as Fedora did not go for dillo2 (sticking with dillo 0.8.6).
That's the sad part of the story.
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Fabio wrote:
Guys, how about putting some images from current Dillo with FLTK1.3 into another table at //www.dillo.org/screenshots/? Once there is no definition about release name, the table title can be something like "Dillo with FLTK1.3", plus (maybe) something catchy as "Coming Soon".
For the version number, I initially leaned toward 2.3 a little, but now I think I'm leaning toward 3.0 because it's simpler to say "3.x uses 1.3 and runs on [whatever]" than "Starting with 2.3, ..." It'd be interesting to have some screenshots (mostly if anyone contributes ones showing native OSX, if that looks any different from using the X backend) once Jorge decides that there won't be any more UI tweaking. (e.g., will the sizes of the progress boxes depend on their labels? I've noticed that the labels don't fit on occasion, but maybe that's intended to reduce redraws.)
-Reza On Jun 10, 2011, at 3:52 PM, "corvid" <corvid@lavabit.com> wrote:
Fabio wrote:
Guys, how about putting some images from current Dillo with FLTK1.3 into another table at //www.dillo.org/screenshots/? Once there is no definition about release name, the table title can be something like "Dillo with FLTK1.3", plus (maybe) something catchy as "Coming Soon".
For the version number, I initially leaned toward 2.3 a little, but now I think I'm leaning toward 3.0 because it's simpler to say "3.x uses 1.3 and runs on [whatever]" than "Starting with 2.3, ...
How about dillo 2011?
It'd be interesting to have some screenshots (mostly if anyone contributes ones showing native OSX, if that looks any different from using the X backend)
I can take screenshots of the Mac version. It's not that different though, but at least it shows it's cocoa and not running on X.
once Jorge decides that there won't be any more UI tweaking. (e.g., will the sizes of the progress boxes depend on their labels? I've noticed that the labels don't fit on occasion, but maybe that's intended to reduce redraws.)
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
How about dillo 2.1.3? It is a 2 version (fltk, css, ...) with fltk 1.3. Dillo can jump to 3.0 with floating objects :P Diego. 2011/6/11, Reza Farivar <rf.opensource@gmail.com>:
-Reza
On Jun 10, 2011, at 3:52 PM, "corvid" <corvid@lavabit.com> wrote:
Fabio wrote:
Guys, how about putting some images from current Dillo with FLTK1.3 into another table at //www.dillo.org/screenshots/? Once there is no definition about release name, the table title can be something like "Dillo with FLTK1.3", plus (maybe) something catchy as "Coming Soon".
For the version number, I initially leaned toward 2.3 a little, but now I think I'm leaning toward 3.0 because it's simpler to say "3.x uses 1.3 and runs on [whatever]" than "Starting with 2.3, ...
How about dillo 2011?
It'd be interesting to have some screenshots (mostly if anyone contributes ones showing native OSX, if that looks any different from using the X backend)
I can take screenshots of the Mac version. It's not that different though, but at least it shows it's cocoa and not running on X.
once Jorge decides that there won't be any more UI tweaking. (e.g., will the sizes of the progress boxes depend on their labels? I've noticed that the labels don't fit on occasion, but maybe that's intended to reduce redraws.)
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Fri, Jun 10, 2011 at 08:52:18PM +0000, corvid wrote:
Fabio wrote:
Guys, how about putting some images from current Dillo with FLTK1.3 into another table at //www.dillo.org/screenshots/? Once there is no definition about release name, the table title can be something like "Dillo with FLTK1.3", plus (maybe) something catchy as "Coming Soon".
For the version number, I initially leaned toward 2.3 a little, but now I think I'm leaning toward 3.0 because it's simpler to say "3.x uses 1.3 and runs on [whatever]" than "Starting with 2.3, ..."
... and dillo-3.0 works with fltk-1.3, and in the future with fltk-3.0, at least that's fltk devs' plan by now. -- Cheers Jorge.-
On Sun, Jun 05, 2011 at 08:08:15PM +0000, corvid wrote:
reza wrote:
It seems that FLTK will release their final 1.3 version next week on June 8th. Are we waiting on that to release our own dillo 1.3? The reason I'm asking is that as you know I'm preparing an installable Mac OS package, which I hope to go on dillo's download page (and hopefully introduce dillo to many non-developer users). So I'd like to know if we are just waiting on that final release of FLTK 1.3, or whether there are still open bugs remaining for our next release?
Right now, I'm aware of:
- the preferred font code in src/dillo.cc.
The other day, I put a few minutes into setting, e.g., FL_HELVETICA to prefs.font_sans_serif FL_HELVETICA_BOLD to prefs.font_sans_serif " bold" etc. ..which seemed to be working for XFT but not with it disabled. Maybe the latter wanted the -*-*-*-*-style strings, and I'd meant to ask Johannes whether this was all the right direction to go in, anyway, since he'd done the fonts work in dw/ for this port.
I just committed something to get the preferred font stuff working on fltk-1.3. Please give it a try. Cheers, Johannes
Johannes wrote:
I just committed something to get the preferred font stuff working on fltk-1.3. Please give it a try.
Does it work for you with xft disabled? I set font_sans_serif to "helvetica", and got ** WARNING **: preferred sans-serif font "helvetica" not found. PS Do you think we should change the Fl::set_fonts ("-*"); to specify iso10646-1?
On Mon, Jun 06, 2011 at 08:04:37PM +0000, corvid wrote:
Johannes wrote:
I just committed something to get the preferred font stuff working on fltk-1.3. Please give it a try.
Does it work for you with xft disabled? I set font_sans_serif to "helvetica", and got ** WARNING **: preferred sans-serif font "helvetica" not found.
No, doesn't seem to work here either. This is a general problem of the font handling code in fltkplatform.cc and fltk13... I will look into it.
PS Do you think we should change the Fl::set_fonts ("-*"); to specify iso10646-1?
Wouldn't that exclude non-UTF-8 fonts which might work fine for people not caring about special chars? Cheers, Johannes
Johannes wrote:
On Mon, Jun 06, 2011 at 08:04:37PM +0000, corvid wrote:
PS Do you think we should change the Fl::set_fonts ("-*"); to specify iso10646-1?
Wouldn't that exclude non-UTF-8 fonts which might work fine for people not caring about special chars?
I was thinking of the case where you had a latin1 version and a utf-8 version of a font, but I don't know the relevant code well enough to know what happens.
I wrote:
Johannes wrote:
On Mon, Jun 06, 2011 at 08:04:37PM +0000, corvid wrote:
PS Do you think we should change the Fl::set_fonts ("-*"); to specify iso10646-1?
Wouldn't that exclude non-UTF-8 fonts which might work fine for people not caring about special chars?
I was thinking of the case where you had a latin1 version and a utf-8 version of a font, but I don't know the relevant code well enough to know what happens.
The xft version says: // Also, for now I'm ignoring the "pattern_name" and just getting everything... So I guess there's no point in worrying about it.
On Mon, Jun 06, 2011 at 09:26:03PM +0000, corvid wrote:
I wrote:
Johannes wrote:
On Mon, Jun 06, 2011 at 08:04:37PM +0000, corvid wrote:
PS Do you think we should change the Fl::set_fonts ("-*"); to specify iso10646-1?
Wouldn't that exclude non-UTF-8 fonts which might work fine for people not caring about special chars?
I was thinking of the case where you had a latin1 version and a utf-8 version of a font, but I don't know the relevant code well enough to know what happens.
The xft version says: // Also, for now I'm ignoring the "pattern_name" and just getting everything...
So I guess there's no point in worrying about it.
Can you please try attached patch? It seems to work ok with xft enabled and also allows to set e.g: font_sans_serif="helvetica" without xft. Font names in the non-xft case are still a bit odd (e.g. all lower case), but I don't think there's much we can do about that. Cheers, Johannes
Johannes wrote:
Can you please try attached patch? It seems to work ok with xft enabled and also allows to set e.g: font_sans_serif="helvetica" without xft. Font names in the non-xft case are still a bit odd (e.g. all lower case), but I don't think there's much we can do about that.
It looks like I have to get the capitalization right for the xft case now. I have a tendency to specify the fonts in lowercase. For non-xft, xlsfonts says that I have, for instance, "new century schoolbook", but Dillo doesn't list it.
I wrote:
Johannes wrote:
Can you please try attached patch? It seems to work ok with xft enabled and also allows to set e.g: font_sans_serif="helvetica" without xft. Font names in the non-xft case are still a bit odd (e.g. all lower case), but I don't think there's much we can do about that.
For non-xft, xlsfonts says that I have, for instance, "new century schoolbook", but Dillo doesn't list it.
I changed it to Fl::set_fonts ("-*-iso10646-1"); to follow the lead of if (!xstarname) { strcpy(buf,"-*-"); strcpy(buf+3,fl_encoding); xstarname = buf; } and now it can find new century schoolbook.
On Tue, Jun 07, 2011 at 10:09:46PM +0000, corvid wrote:
I wrote:
Johannes wrote:
Can you please try attached patch? It seems to work ok with xft enabled and also allows to set e.g: font_sans_serif="helvetica" without xft. Font names in the non-xft case are still a bit odd (e.g. all lower case), but I don't think there's much we can do about that.
For non-xft, xlsfonts says that I have, for instance, "new century schoolbook", but Dillo doesn't list it.
I changed it to Fl::set_fonts ("-*-iso10646-1"); to follow the lead of
if (!xstarname) { strcpy(buf,"-*-"); strcpy(buf+3,fl_encoding); xstarname = buf; }
and now it can find new century schoolbook.
I committed a slightly modified patch that uses our systemFonts table also for finding the default ui font. Cheers, Johannes
Johannes wrote:
I committed a slightly modified patch that uses our systemFonts table also for finding the default ui font.
I notice that I only have the italic version of URW Chancery L (and a moment of looking things up suggests italic is the only version that exists). If I set font_sans_serif to use it, it is only used for text that should be italicized, whereas dillo2 would use it for any text. I'm not sure whether that's _bad_, exactly, but if we want to or have to stick with this behaviour, it might not make a good default for font_cursive any longer.
On Sun, Jun 05, 2011 at 08:08:15PM +0000, corvid wrote:
[...] - Still missing is the -f command line option (used by claws).
Jorge was waiting for something to do with FLTK before taking action there.
Yes, Matt wrote he planned to solve STR2639 for rc7, but it didn't happen so, I'll commit a patch with workarounds. (FWIW, I would have been surprised with such a change at this stage).
- tab titles
Just cosmetic issues of: They seem too short, the original title of, e.g., ctab5, is suboptimal, and the ones without a title tag are initially blank.
This may be a matter of taste. e.g. Dillo-2.x used "dillo" instead of a blank title, and allowed longer labels. I like the current behaviour with fixed length tabs. YMMV. "ctab<n>" as label is weird, and should be changed. Suggestions? (e.g. tab length, initial string). Keep it simple please ;-) -- Cheers Jorge.-
Jorge wrote:
On Sun, Jun 05, 2011 at 08:08:15PM +0000, corvid wrote:
- tab titles
Just cosmetic issues of: They seem too short, the original title of, e.g., ctab5, is suboptimal, and the ones without a title tag are initially blank.
This may be a matter of taste. e.g. Dillo-2.x used "dillo" instead of a blank title, and allowed longer labels. I like the current behaviour with fixed length tabs. YMMV.
"ctab<n>" as label is weird, and should be changed.
Suggestions? (e.g. tab length, initial string). Keep it simple please ;-)
The case where you open an image. At first the tab title is blank. Then I click another tab and then return to the image. Now it's the beginning of the URL (not that "http://..." is terribly meaningful :)
On Thu, Jun 09, 2011 at 07:50:27PM +0000, corvid wrote:
Jorge wrote:
On Sun, Jun 05, 2011 at 08:08:15PM +0000, corvid wrote:
- tab titles
Just cosmetic issues of: They seem too short, the original title of, e.g., ctab5, is suboptimal, and the ones without a title tag are initially blank.
This may be a matter of taste. e.g. Dillo-2.x used "dillo" instead of a blank title, and allowed longer labels. I like the current behaviour with fixed length tabs. YMMV.
"ctab<n>" as label is weird, and should be changed.
Suggestions? (e.g. tab length, initial string). Keep it simple please ;-)
The case where you open an image. At first the tab title is blank. Then I click another tab and then return to the image. Now it's the beginning of the URL (not that "http://..." is terribly meaningful :)
Patch committed. -- Cheers Jorge.-
participants (7)
-
corvid＠lavabit.com -
darkspirit5000＠gmail.com -
fabio.pasini＠gmail.com -
itsme_410＠yahoo.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
rf.opensource＠gmail.com