Re: [fltk.bugs] [HIGH] STR #2634: fl_help_view bug fixes and new features
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2634 Version: 1.4-feature Getting around to revisiting this. Unfortunately the changes suggested so far aren't in patch format, so it's hard to determine what changed to merge into current code. I'll see if I can recreate a diff from the latest code attached here, and attach that to this STR so we can see what can be merged into current. Link: http://www.fltk.org/str.php?L2634 Version: 1.4-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2634: fl_help_view bug fixes and new features
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2634 Version: 1.4-feature I'm also attaching a zip that contains Domingo's changes from a posting he made to fltk.dev on 03/08/2010 with the same files broken out: orig -- fltk's original src (based on svn id's from Domingo's files) new -- Domingo's files patch -- patch versions of the changes (diff -Naurw) So between these two zips, we can probably pull what we need to make a merge that includes the best of both. Link: http://www.fltk.org/str.php?L2634 Version: 1.4-feature Attachment: http://www.fltk.org/strfiles/2634/mingodad--03-08-2010-Fl_Help_View-orig-vs-new-as-patches.zip ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] This was proposed before and rejected but just in case here it'sagain Fl_Help_View
On 12/12/10 06:08, Domingo Alvarez Duarte wrote: Due to the massive modifications there is no patch here it's the whole new Fl_Help_View Re-awakening this old thread to revisit.. Domingo, unfortunately I think the code you attached in this thread is the original fltk source code for r7903.. the attachment being different only by having DOS line endings. I just downloaded fltk r7903 (this is the svn ID rev in the code posted) and xdiff'ed the FLTK source against your attachment; seems to be the same code. I know I've seen your mods before.. will look back in the forums and STRs. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Help_View code cleanup and optimizations revised with minimalindentation changes, attached 100KB
On 03/08/10 08:03, Domingo Alvarez Duarte wrote:
I've got the original files and inserted on then only the changes I
made, quite a lot !
OK, here's an older thread with your Fl_Help_View.{cxx,H} files
that have your changes; add these to STR# 2634 as a zipfile:
mingodad--03-08-2010-Fl_Help_View-orig-vs-new-as-patches.zip
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] fltk and high res retina display?
I just upgraded to a newer mac laptop, and discovered that fltk apps don't render in the new highres mode. It seems like it shouldn't be too hard for text at least, but I wasn't able to find an enable high res flag after a bit of looking at https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Introduction/Introduction.html#//apple_ref/doc/uid/TP40012302-CH1-SW1 There is kWindowHighResolutionCapableAttribute but it's for Carbon. The implication seems to be that for Cocoa apps it should just work. Any of the more mac knowledgeable sorts know what's going on here, or should I keep poking through the apple docs? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] best way to get an int from Fl_Menu_Item user data
marty wrote: long li = (long)v; works fine. Yes; this is a good option, everywhere *except* Win64... On Win64, a long is still only 32-bit (everyone else decided that in their 64-bit generation a long would be 64-bits, but MS decided they needed to preserve the sizeof(long) == sizeof(int) relationship that is assumed in the WIN32 API...) So, probably, fl_intptr_t is the more portable choice. Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
I tried to show some html-text for help, but Fl_Helpview doesn't take
care of br and mucks up formatting. Doc tells, Fl_Helpview should take
care of br, shouldn't it?
Is there a way to get linefeeds, as aspired in the following example. My
system shows no distance between the two lines:
#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Help_View.H
const char* cHTML=
!DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01 Transitional//EN\
html
head
meta http-equiv=\content-type\ content=\text/html;
charset=ISO-8859-1\
/head
body
First Linebr
br
br
Second Line after 3 times lt;brgt;br
br
/body
/html;
int main()
{
Fl_Double_Window Win(400, 200, Helpview);
Fl_Help_View* pHV= new Fl_Help_View(10, 10, 380, 180, );
Win.end();
pHV-value(cHTML);
Win.show();
return Fl::run();
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
I tried to show some html-text for help, but Fl_Helpview doesn't take care of br and mucks up formatting. Doc tells, Fl_Helpview should take care of br, shouldn't it? Hmm, yes, that does seem a bit broken... As a hackaround, it looks like replacing b with p/p seems to do something... Any good? Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
MacArthur, Ian (Selex ES, UK) schrieb: As a hackaround, it looks like replacingb withp/p seems to do something... Any good? Thank you, that solves my problem. I tried to make a little all inclusive tool - one file containing program, helpfiles, info and a picture - and that was last thing preventing me from publishing it. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
On 04/04/13 02:52, MacArthur, Ian (Selex ES, UK) wrote: I tried to show some html-text for help, but Fl_Helpview doesn't take care of br and mucks up formatting. Doc tells, Fl_Helpview should take care of br, shouldn't it? Hmm, yes, that does seem a bit broken... As a hackaround, it looks like replacing b with p/p seems to do something... Any good? Yes, P should give you a paragraph break. But sometimes you want to put two, three, or four blank lines. Another trick that seems to work is to inject nbsp; between the BRs, eg: single spaceBRsingle space BRnbsp;BR double spaceBRnbsp;BRdouble space BRnbsp;BRnbsp;BR triple spaceBRnbsp;BRnbsp;BRtriple space It'd be good if we could fix adjacent BR's though. I recall our html parser's source being a bit tricky to grok, but I think I worked on a small part of it once.. will see if I can figure this one out. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
and that was last thing preventing me from publishing it. http://www.edzeg.net/pt100/ Not sure, whether there is any interest, because this is a german tool for solving a particular electronic problem, now published in an electronics group. And I failed in writing a fltk-config-makefile, so it's plain source. :o/ ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
It'd be good if we could fix adjacent BR's though. I recall our html parser's source being a bit tricky to grok, but I think I worked on a small part of it once.. will see if I can figure this one out. I've seen that commenting out line 657 of file src/Fl_Help_View.cxx seems to fix this problem. But does this have other negative effects? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
On 04/04/13 09:44, Manolo Gouy wrote:
It'd be good if we could fix adjacent BR's though.
I recall our html parser's source being a bit tricky to grok,
but I think I worked on a small part of it once.. will see if
I can figure this one out.
I've seen that commenting out line 657 of file src/Fl_Help_View.cxx
seems to fix this problem. But does this have other negative effects?
Comment out the 'hh = 0;' line? Interesting:
else if (strcasecmp(buf, BR) == 0)
{
if (line 31)
line ++;
xx = block-line[line];
yy += hh;
hh = 0; // -- COMMENT THIS OUT
}
That does seem to allow multiple BRs to work.
But also seems to badly affect the document height calculations
such that the scrollbar doesn't let one reach the bottom of the
document.
For instance:
#include FL/Fl_Help_Dialog.H
int main() {
Fl_Help_Dialog *help = new Fl_Help_Dialog();
help-value(single aaabrsingle rsingle ccc
brbrdouble dddbrbrdouble eeebrbrdouble fff
brbrbrtriple gggbrbrbrtriple hhhbrbrbrtriple
iii
brbrbrbrquad jjjbrbrbrbrquad
kkkbrbrbrbrquad lll
brEND);
help-show();
return(Fl::run());
return (0);
}
With 657 left alone, one can view the above document up to the last
line (END)
using the scrollbar.
But with 657 commented out, the document becomes larger (due to the
extra lines
the working BR's now do), but the bottom lines are cut off in the
window,
and there's no scrollbar. One can enlarge the window vertically to see
the missing
lines.
Perhaps block-h needs to be adjusted for this to work correctly.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
On 04/04/13 14:32, Greg Ercolano wrote:
On 04/04/13 09:44, Manolo Gouy wrote:
I've seen that commenting out line 657 of file src/Fl_Help_View.cxx
seems to fix this problem. But does this have other negative effects?
[..]
That does seem to allow multiple BRs to work.
But also seems to badly affect the document height calculations
such that the scrollbar doesn't let one reach the bottom of the
document.
[..]
Perhaps block-h needs to be adjusted for this to work correctly.
OK, looks like to solve the scrollbar issue, one has to comment out
the corresponding hh = 0; line in the Fl_Help_View::format() function.
So I think together these two changes work a bit better (still not sure
if there are other negative effects):
_
--- Fl_Help_View.cxx(revision 9857)
+++ Fl_Help_View.cxx(working copy)
@@ -654,7 +654,7 @@
line ++;
xx = block-line[line];
yy += hh;
- hh = 0;
+ //hh = 0;
}
else if (strcasecmp(buf, HR) == 0)
{
@@ -1298,7 +1298,7 @@
xx = block-x;
block-h += hh;
yy += hh;
- hh = 0;
+ //hh = 0;
}
else if (strcasecmp(buf, CENTER) == 0 ||
strcasecmp(buf, P) == 0 ||
_
It looks like Help_View::format() and Help_View::draw() methods
depend on each other's code to be symmetrical.
I usually find code like this hard to maintain if managed in separate
functions, because it's too easy for the code to get out of sync.
I usually try to keep symmetrical code designs such that each block
of code is kept close together, so other programmers can clearly
see modifying one code block affects the other, eg:
void HtmlClass::Handle_BR(..) {
if (formatting) {
..code to handle BR formatting..
} else {
..code to handle BR drawing..
}
}
I've had to do this sort of thing with complex state machines
and receive/transmit code.. works well when the code blocks are short,
so it's easy to see matching code in a single page.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
