FLTKMaxGUI Tweaks
BlitzMax Forums/BlitzMax Module Tweaks/FLTKMaxGUI Tweaks
| ||
| Actually, I really should have titled this 'Fl_Help_View.cxx tweaks' because I'm only trying to fix up the FLTK HTML renderer for MaxIDE but it also applies to FLTKMaxGUI. All changes were tested on Ubuntu (Edit: also on XP/Vista). The source for the latest Fl_Help_View.cxx and Fl_Help_View.H is here: http://blitzmirror.ueuo.com/fl_help_view.zip (expired) Last update: 4 Sep 2010 Fl_Help_View Worklog rev 27 - fixed compiler errors to get it building with fltk-1.3.x make - fixed seemingly random fonts appearing on Mac, required changes to header - fixed font list not being read properly on PPC Mac - fixed no spaces between words on PPC Mac rev 26 - changed scope of handle() to public - added css functions: load_css(), parse_css(), get_css_value(), get_font_size() - added css properties: background-color, font-family/weight/style/size - added recognition system for css shorthand properties: font, background - fixed table without /tr breaking next row alignment - fixed table without tr not being drawn - added nearest font match to font_face() rev 25 - removed getcwd for init with relative path, need to init with full path. - fixed format_table crash if td colspan width too thin. - added page topline position history, required changes to header/fltkgui. - added javascript:history.back/forward/go support, required changes to fltkgui. - added openurl support for user navigation style, required changes to fltkgui. rev 24 - fixed some more misc bugs. - added new function: setstyle, required changes to header and fltkgui. - added default user navigation style. - added print error page instead of null link. - added getcwd for initializing with a relative path. rev 23 - fixed a few misc bugs. - removed font_find function, not necessary, required changes to header. - fixed build_faces and font_face functions to work with anti-aliased fonts. rev 22 - fixed </a> sometimes not working bug, style spilling into next <td>. - added new methods: filepath and fileislink, for link targets fix. - fixed link targets not stored in link history, required changes to header and fltkgui. rev 21 - removed support for drawing new char refs via Symbol font, not compatible with FLTK 1.3. rev 20 - added new method reformat, for calls to format. - replaced add_block, format_table functions with extended argument versions. - added d-pointer by hijacking Fl_Help_Target, required changes to header. - replaced compare_targets function with cmp_targets, due to d-pointer. - replaced textfont_ and textsize_ with global statics. - moved local statics to d-pointer struct. - fixed links with target values not setting position on new page. rev 19 - changed vertical scroll size, now moves double the amount. - added new methods sansfont, monofont. - added new function font_find, used for new default fonts. - added new functions build_faces, font_face and font_style. - added full support for font face attribute, required changes to header. - fixed bold/italic not working with many fonts. - removed inconsistent resizing tweak in format. rev 18 - fixed nested table overwriting cell heights. - fixed nested table drawn below row height. - improved format speed to 30% less time, required changes to header. - fixed cell width not reset before/after nested table. - fixed nested table popping cell margin. - fixed pre text in tables not increasing cell width. - improved pre tabs width, miscalculated in tables. - added CHR() and MIL() macros. - fixed tables not popping last font. - fixed divide by zero error if table cells empty. - renamed variables and reordered functions alphabetically. rev 17 - fixed mouse over horizontal scrollbar showing active link/hand icon. - fixed last line in <td> misaligned, caused by new block per line system. - fixed empty <td> on end of row affecting next row y position. - fixed wrong line gaps before and after a table. - fixed nested tables overwriting <table> and <tr> 'bgcolor'. - improved color lookup, no hash needed for hex value. rev 16 - improved block system, every line is now in it's own block. - removed line[32] field to drop memory usage to about 30%, required changes to header. - tidied up code comments. rev 15 - improved <hr> and <h1-6> line spacing. - fixed font size not updating line y positions, required changes to header. - fixed nested tables overwriting subsequent <tr> and <td> cell data, required changes to header. rev 14 - added skipping of <script> to prevent drawing of Javascript code, etc. - finished fixes to <ul> and <li> code. - fixed <hr> line spacing miscalculations and added a shadow line. rev 13 - fixed <br> directly after another <br> not taking a new line. - added <li> 'type' support and drawing of circle and square bullets. - fixed <li> bullets on left margin not visible because of no default indent. - added all the missing character references (quote chars) listed in HTML 4. - added support for drawing most of the new char refs via the Symbol font. - fixed control characters not drawing correctly because of null widths. rev 12 - fixed hang caused by resizing window on a big page, included forms.H for timer code. - fixed words longer than window width taking an extra line. - added skipping format below drawing area during resizing, full format is after mouse release. rev 11 - fixed every table expanded to full document width, now scaled to window width. - fixed table widths not scaling to exactly what they should. - fixed text expanded to full document width, now line wrapped to window width. - fixed <hr> not drawn according to horizontal scrollbar position. - added <div> support, 'id' for target links and 'align'. rev 10 - fixed line wrapped images not taking enough new line space. - fixed </table> not resetting the new line space after an image. - fixed text on the same line as an image not aligned to the baseline. rev 9 - added tab spacing support in <pre> with correct tab alignment. - fixed images to align to the baseline instead of the top, required changes to header. rev 8 - fixed table margin indents ignored in formatting, required changes to header. - fixed <td> 'colspan' cells not scaling up when needed, result of previous colspan fix. - improved tables scaling a bit wider than they should. rev 7 - fixed <td> with 'colspan' > 1 causing miscalculation of table cell max column widths. - fixed tables scaling up beyond maximum width. rev 6 - fixed <pre> courier font changing when scrolling down, required changes to header. - reorganized HTML tag checking code, separated some tags and listed them alphabetically. - added all the missing tags listed in HTML 4, they are still unsupported. rev 5 - fixed <h1> font sizes and paragraph spacing. - fixed '<' character assumed to be an HTML tag. - HTML tags in <pre> changing courier font. rev 4 - added smart paragraph system so things like '<p></p>' only take one paragraph. - fixed <ul> margin indent set by font size instead of a fixed width. - fixed </pre> not taking a new line in certain cases. - improved <h1> and </h1> paragraph spacing. rev 3 - fixed <td> margin indent set by font size instead of a fixed width. - fixed </table> not closing the table row width. rev 2 - fixed <td> with 'colspan' > 1 causing miscalculation of table cell minimum widths. - fixed </tr> and </table> not popping the table's margin indent back. rev 1 - fixed </pre> not taking a new line causing text directly after it to draw on the same line. - added <blockquote> support which uses the existing <ul> code. |
| ||
| Fixed another bug today in Fl_Help_View.cxx. This one you'll also see in User Guide>maxide if you scroll down until you get to the header called The Edit Menu, this table is indented to the width of the last table's first column. If you scroll on down to The Program Menu header it is indented to the width of the last two table's columns, and so on. This is because the margins are only popped back by </td> but not by </table>. The tables in this page don't end with </td> tags hence the bug appears. The fix simply pops the margin in the </table> code. I have checked to make sure this doesn't cause a problem in nested tables. Edit: Well I thought it was ok but now I see there is a bug there. Doh! Got to go fix it now. Edit 2: ok, I appear to have fixed that bug now. I had to add an array to allow for nested tables and their <td> tags in order to sort it out. I could have just used a couple of variables but it wouldn't have been as good. The source is in the link in the first post. I'm now trying to fix another table margin bug, but it's still got me stumped. |
| ||
| Nice work Mark! I really appreciate the time that you are dedicating to this. I'm doing some work on CocoaMaxGUI / Win32MaxGUI atm, but I'll make sure that I'll take a sneak peek at your fixes in the next few days. |
| ||
| Hey Seb. Thanks for the encouragement. I have just uploaded a new version of Fl_Help_View.cxx, see link in first post. This fixes 2 more bugs and also corrects a previous fix. The first bug you'll see if you go to Modules>MaxGUI>MaxGUI.ProxyGadgets, under the header Function Reference there is a big space between the two columns. This is caused by the first row having a colspan of 2 which increases the first columns minimum width. The fix ignores columns with a colspan > 1. The second one, this was pretty tough to fix. If you go to Modules>MaxGUI>MaxGUI.MaxGUI you'll notice that the horizontal scrollbar is very big and if you scroll down to around the middle of the page the tables are all basically fubar. This is because nested tables take over the alignment. It's related to the previous fix for indented tables in User Guide>maxide but is for </tr>. The correction is for the fix for indented tables in User Guide>maxide in the </table> tag. I took out the td array and loop as I realised it wasn't necessary. Not sure if those last two are final yet. The table code is really buggy so a lot more fixes are needed there. |
| ||
| Looking better here too! |
| ||
| markcw, Just checked it out and it's definitely looking better than it was. Well-done! I've just attempted to get the Fl_Window::Show() GTK colour thing working, that you mentioned, and got a few signal handler 11's. How was it that you implemented it? I assume we need to somehow get BlitzMax's AppArgs passed to flShowWindow, but maybe there's an easier method. |
| ||
| Thanks you guys. Good to know. I have just nailed that bug I mentioned last night wasn't final. This is my third attempt at fixing it and is also the simplest, but it works. The first used a td array but that was just silly, so I simplified it to just a table count but then I realised that would break as soon as you have a whole page nested in a table, so now I just check if </tr> was called with a flag and if not then </table> pops the margin instead. Now Modules>MaxGUI>MaxGUI.MaxGUI looks even better. I was building tutorial examples with FLTK and noticed the Hello World example used the Linux colors but other examples didn't. So I've no idea how to implement it in BMaxIDE but here's the source for "hello.cxx" if it helps. // Listing 1 - "hello.cxx"
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Box.H>
int main(int argc, char **argv) {
Fl_Window *window = new Fl_Window(300,180);
Fl_Box *box = new Fl_Box(20,40,260,100,"Hello, World!");
box->box(FL_UP_BOX);
box->labelsize(36);
box->labelfont(FL_BOLD+FL_ITALIC);
box->labeltype(FL_SHADOW_LABEL);
window->end();
window->show(argc, argv);
return Fl::run();
}
|
| ||
| Just fixed a few more bugs and uploaded the latest Fl_Help_View.cxx. The first one you'll see almost everywhere, if you go to User Guide>maxide and scroll down to the header called The File Menu the text below the header is indented a bit, this is because it's in a table. I don't know why but the <td> code was indenting to the width of the fontsize which is wrong, tables don't indent by default although they do indent a few pixels. The second one was yet another bug in the table code. This time </table> was not closing the table width so if </tr> wasn't in the html then any text after </table> was still bound by the table width. Strange how I didn't notice it earlier. |
| ||
| Found it! Try adding... Fl::get_system_colors()to the bottom of flReset() in fltkglue.cpp and rebuild modules. |
| ||
| Great work, Seb. Amazing that you only had to add one line of code. Definitely better than the default grey color scheme and also now it fits in. |
| ||
| This is in SVN right? I might give it a try tomorrow. |
| ||
| This is in SVN right? Not quite yet... The FLTKMaxGUI version that was used to build the BlitzMax v1.30b IDE has been committed to SVN, but Mr Sibly is the only one who holds the keys, and I haven't got round to sending him the most recent changes that have gone on in this thread. I've also managed to hack in an editable Combobox widget for FLTKMaxGUI (as per Mark Tiffany's request for the CE IDE) and tweaked a few event firing problems on list and node based gadgets. In a few days, I'll probably be submitting this (inc. markcw's Fl_Help_View.cxx tweaks) along with some Windows/Cocoa bug fixes. |
| ||
| I'll be waiting patiently :-) |
| ||
| Cool. Btw, I'm getting a non-critical lib conflict when I build things. The report looks like this: Building snowfall Compiling:snowfall.bmx flat assembler version 1.64 3 passes, 5092 bytes. Linking:snowfall /usr/bin/ld: warning: libstdc++.so.6, needed by /usr/lib/libGLU.so, may conflict with libstdc++.so.5 Process complete Has anyone got this before and know how to fix it? I had a search and the solution seemed to be removing libstdc++.so.6 but when I tried that it marked a ton of useful programs for removal. |
| ||
| That error has always been popping up on Linux. I believe it's harmless. |
| ||
| Has anyone got this before and know how to fix it? Yeah, it's just a warning, but if you really want to get rid of it, you can do by using a tweaked bmk and rebuilding all modules. E-mail me if you want me to send it to you. |
| ||
| markcw, "You've got mail!". ;-) |
| ||
| Great, thanks Htbaa and Seb. If it's just a warning that everyone gets then I'm not so worried. I would be interested in how it can be resolved though. Got your email Seb. Replying now. Btw, I am nearly done with my intelligent paragraphing system for Fl_Help_View.cxx, hopefully will finish it tonight. |
| ||
| Ok, new version of Fl_Help_View.cxx is uploaded. This has the intelligent paragraph system, maybe the word intelligent is too optimistic, so I'll just call it a smart paragraph system. It took longer than I thought because I fixed a few bugs along the way and had to remove a few bits of the old paragraph system. I left any table code alone to keep it simple. I still have a bit of stuff to add but it's basically done now. Three extra bugs were fixed. Indents for <ul> was 4 * fontsize which is wrong, it is a set width. Removed a line in </pre> which was reseting a height value, no idea why this was done. The <h1> etc code was behaving wierd, the paragraph space above an h tag was too small and the paragraph space below was too big. I had to fudge the height value to fix it and then I had to add a check for tags like <p> before it taking a smaller paragraph. Took ages to fix but it's looking really nice now. |
| ||
| So finally the documentation in Linux MaxIDE is going to be readable now? That would be *really* great. |
| ||
| Cool, I'll take a look later when I fire up my Linux PC. Did you get my second e-mail where I resent the attachment? |
| ||
| Seb, yes got the 2nd mail with attachment, thanks. I've been looking at it today. I will mail you back when I'm done. Htbaa, yes it's much more readable now but there are still some major bugs. Next I'm going to try and fix <pre> tags breaking when a "<" char is found. |
| ||
| A "<" char be translated to a < tag, and a ">" char to > tag. Good chance that'll fix it as it's understandable by the HTML renderer. |
| ||
| Htbaa, yes it's much more readable now but there are still some major bugs. Next I'm going to try and fix <pre> tags breaking when a "<" char is found. Just tried it now. For some reason, I've noticed I'm getting X_GetImage BadMatch errors again although I don't know whether this is related to the Fl_Help_View.cxx fixes. It might have been something I was messing around with. Also, I noticed that the text font size is slightly bigger now in the HTMLView. Is this the intended behaviour? |
| ||
| No idea what "X_GetImage BadMatch errors" is but everything is fine here. Yes, the text font size is actually the same, I just changed the default font from times to helvetica as it was more readable. I also looked at setting a custom font but couldn't figure it out. |
| ||
| Ok, new version is up along with a small mod in fltkglue.cpp, see first post. The fix in fltkglue.cpp is related to Fl_Help_View.cxx and isn't really a bug, just that it wasn't right. You'll find it in flWidget() under the FLHELPVIEW case. It was setting the html text size to 15 and I changed it to 12. So now the text size for the help view is 12 instead of 14/15, which I think looks much better. I also added the ability to set the font there. The bug-fix today is for <h1> etc tags. The header sizes weren't right, most of them were the same size. I also tidied up the spacing above and below the headers. So now it looks really nice. |
| ||
| Just uploaded another version of Fl_Help_View.cxx. This fixes a few more bugs. The < less than symbol bug which you can find in Language Reference>Debugging at the bottom of the page and Language Reference>BASIC Compatibility in the code below the Goto and Gosub header. I did this by checking if the text after a < symbol is a valid HTML name or has a !, ? or / symbol after it, otherwise it is treated as normal text. I also added a whole lot of HTML tags that weren't there from the HTML 4 reference. This method isn't bulletproof though, for example if your code had a variable named the same as a HTML tag and no space after the < symbol then it would think it was an HTML tag. I might try to improve this later. Another bug fixed was when a HTML tag was in a pre tag it would revert the pre font back to the default font. This fix exposed yet another bug which I am still trying to fix. When a HTML tag is in a pre tag and you scroll down past the start of the pre tag, it forgets it's a pre tag and reverts to the default font. I've been trying to fix this for a few days now, also I still have to update the table code for the new HTML tags stuff so I'll do that first. |
| ||
| Wow, you've been busy! I've been really busy myself the last few days, so hadn't got the chance to get much coding done, but I thought I'd drop by. Providing I get some free time, I aim to do a FLTKMaxGUI commit in a few days and I'd like to include your Fl_Help_View.cxx fixes. Is there a milestone you are aiming for atm, or are you addressing the bugs as and when they turn up? This fix exposed yet another bug which I am still trying to fix. When a HTML tag is in a pre tag and you scroll down past the start of the pre tag, it forgets it's a pre tag and reverts to the default font. I've been trying to fix this for a few days now, also I still have to update the table code for the new HTML tags stuff so I'll do that first. I think I may hold off for a few days if you've still got some stuff in the pipeline, and anyway, it gives me time to look at those points you mentioned in the e-mail. Keep up the good work! I'm sure all the MaxGUI'ers out there appreciate it. ;-) |
| ||
| Hi Seb, busy enough I guess, all my computer time has been devoted to this fl help view project, so everything else I was doing is on the shelf for now. Well, I'm zoning in on this pre tag bug I mentioned in the previous post so I may have a fix in a few days with any luck. The bug can be seen on several pages such as Tutorials>BlitzMax overview under The nitty gritty part 1 header. That is the next fix but feel free to commit your update any time you like. I'm just working my way through any bugs that I find in no particular order. The first milestone will be when I have all the major bugs fixed I guess but there is no time frame. Then I would like to add new stuff like the CSS code. Re: the email, the only real problem is the changes made to config.h. The colors and text stuff are not a problem really. |
| ||
| Ok, another version of Fl_Help_View.cxx is up. This updates the table code for the new HTML tags stuff. So now the draw, format and format_table functions are in sync with the new check for HTML tags. I have also reorganised this code so that the tags are listed alphabetically so it's much easier to follow now and therefore easier to fix bugs. Some tags are still grouped together as they are so similar eg. <b> and <strong>. I've still to tidy up the <blockquote>, <ul>, etc code but the bulk of the work is done. I still have to fix the 'pre tag reverting to default font' bug though. |
| ||
| Cheers! One of my pet hates is that the sample code in the docs is mis-aligned, and you usually have to scroll to the right for ages until you can see it. Any ideas about what might be causing that? |
| ||
| Hi Seb, I'm not sure what you mean. If you mean that long lines of code go past the width of the browser window, then that is what it's supposed to do as preformatted text isn't supposed to wrap. However, when that happens the rest of the page text not in pre tags also goes to the same length, which is a bug I plan to fix at some point. I have just uploaded a new version. This fixes the 'pre tag reverting to default font' bug, but in order to fix it I had to add some new code to Fl_Help_View.H which you can find a link to in the first post. Please note that you can't use the new Fl_Help_View.cxx without the modified Fl_Help_View.H. What it does is to store the pre, font and font size variables to each block and then reads those in draw to make sure draw doesn't forget anything as it has a tendancy to do. This only fixes <p> and </p> tags found in pre tags, but it was enough to fix all of this type of bug in the BMax help files. |
| ||
| Fantastic! Right, I think it's time for an SVN commit. All the bug fixes (inc. markcw's) are now available from the MaxGUI SVN. From the change-log: MaxGUI.FLTKMaxGUI 1.25 Release > Added markcw's Fl_Help_View.cxx tweaks - thanks Mark! > Changed menu appearance and fixed label SetGadgetFont() redraw problems. > Changed default font size for FLTK to size 12 (in Fl_Widget.cxx). > Tidied up RequestFont() dialog layout and positioning. > Added standardized FLTK LookupGuiFont() handling. > Added support for TEXTAREA_WORDWRAP flag. > Added Fl::get_system_colors() to flReset() so that FLTK looks a bit more like the other apps. > Hacked in an editable combobox, but no EVENT_GADGETSELECT yet. Regarding the mis-aligned sample code, perhaps a screenshot explains it better. |
| ||
| Nice one. Apologies for not getting time to spend on testing Seb (blame FlameDuck for convincing me to finally cave and get civ4!). Regarding the alignment above, looks to me as though the width of the description / information columns is being influenced by the length of the text in the function row. The sizing of the desc & info headings should be based solely on themselves... |
| ||
| Wow, that was a quick SVN commit Seb! I just uploaded a small update to Fl_Help_View.cxx as I just remembered a few mistakes I forgot to fix. One was a tiny bug I accidentally made, which was text in <th> tags not being bold. I created it when I noticed some <h#> tags didn't have a digit check so I just quickly searched through the file for all "h" checks and one was for the h in <th>. The others were in the HTML tag check code, some had extra variables eg. "else if (IMG && incell)" which in theory could cause a bug but I never noticed any, the fix just nests extra checks inside the HTML tag check. The new HTML tag check system works like: if it's not a HTML tag treat it like text. Re: the mis-aligned sample code. Ok, I see now, thanks for the image. I think that's a nested table bug, I'm planning to fix that soon. |
| ||
| I just uploaded a small update to Fl_Help_View.cxx as I just remembered a few mistakes I forgot to fix. Thanks, I've just done a new small commit with your latest Fl_Help_View.cxx changes. Was this the only file? |
| ||
| Yes, cheers for that Seb. I'll update to the SVN version soon. I'm currently trying to fix one of the multitude of table bugs, nested tables are unsupported so anything after a nested table is just popped back - this was one of my fixes before it just kept padding out, td widths don't calculate properly, nested tables without a width specified just take up as much room as the text dictates, hence the bug you refered to, and several more that I don't want to have to recount at the moment. I'm still trying to decide which one to fix first. |
| ||
| markcw, I have another bug/tweak for you to report over at FLTK.org. In FL_Group.h, the clip_children() and clip_children( int c ) functions pairs are defined as protected, and yet they are in the docs as public methods: http://www.fltk.org/doc-1.3/Fl_Group.html All that was required was to move the two function definitions to below public: (see the latest MaxGUI SVN commit). Am I missing something? |
| ||
| Erm, looks like a forum time bug. Happy first of August day! Anyway new version of Fl_Help_View.cxx uploaded. This fixes 3 bugs. The first is my mistake, I messed with the code for the td/th align attribute thinking I knew what I was doing, which I didn't. If it's not broke don't fix it. ;) Anyway, I have fixed my own bug. You'll see it on the help index, the BRL images are both left aligned. The second is a td colspan bug, this is like the td colspan bug I fixed a while ago but applied to another array storing td widths. It basically prevents colspans > 1 from messing with the normal td widths. The third is related to the second. After all the td's (table data cells) are gathered in format_table there is some code to work out the final widths for everything. After some debugging sessions I figured out what was going wrong. Basically, there is a point where the table and cells are either scaled up or down. If they are scaled down there is no problem but if they are scaled up you get cells bigger than they are supposed to be. I added some code to the end of the scale up section to re-adjust the cell widths to what they should be. Now Modules>MaxGUI>MaxGUI.MaxGUI is only a bit too wide, which is due to the nested tables bug. |
| ||
| Hi Seb, as far as I see it clip_children is protected in the docs and is only used by the Fl_Group class (it only appears in Fl_Group.cxx). It probably doesn't matter whether they are public or protected. Edit: actually I don't see how you can tell how something is public or protected from the docs. Sorry, not too hot on the subject. |
| ||
| as far as I see it clip_children is protected in the docs Where? Show me, show me (Seb jumps up and down, tugging at Mark's sleeve!!!). lol It probably doesn't matter whether they are public or protected. Well, it mattered to me in as much that I needed to call clip_children() from within flWidget() in fltkglue.cpp and couldn't if they were protected. :-( Anyway new version of Fl_Help_View.cxx uploaded. This fixes 3 bugs. lol, just missed my last commit by a few minutes. Downloading them now... ;-) Btw Mark, did you get my e-mail that I sent yesterday? |
| ||
| Ask Brucey, or someone who knows stuff. :) Did you read my edit? I just had a quick look at the docs and source code and then wrote some nonsense, it happens. :) Can you not call it as Fl_Group::clip_children in flWidget? Yes, I got your email thanks. Still trying to find my password, I'm sure I've got it here somewhere. :) |
| ||
| Did you read my edit? I just had a quick look at the docs and source code and then wrote some nonsense, it happens. :) Oh right - nevermind then... Can you not call it as Fl_Group::clip_children in flWidget? Errrmmmm... I don't really know as I'm a C++ newbie... I still haven't worked out the difference between using "." and "->" when selecting methods. I use the latter unless it throws compiler errors. Not got a clue what "::" means, though... Any info on this front is greatly appreciated. Yes, I got your email thanks. Still trying to find my password, I'm sure I've got it here somewhere. :) Cool! Just checking that it didn't end up in your SPAM folder, or something... Anyway new version of Fl_Help_View.cxx uploaded. This fixes 3 bugs. Whooo! Not sure what it did, but that has improved things ten fold in the MaxGUI.MaxGUI docs! Excellent work Markcw!!! That's certainly worth an SVN commit of its own (revision 61 iirc). |
| ||
| Well, my C++ isn't great either so I'm not a good person to ask. Any C++ guru reading this is welcome to chime in. :) As far as I understand it (although I may be wrong) public members of a class can be accessed from outside the class, protected members can only be accessed by it's class and inherited classes, and private members can only be accessed from it's base class and not inherited classes. I looked this operator thing up, there doesn't seem to be much difference between using '.' and '->' see here for example. The '::' (called the scope operator) is also for method access except it is used for initializing class members. |
| ||
| You use a '->' when you're working with a pointer. You use '.' for a local object or reference. With :: you can access static methods and static data members. That's about it :-). I hope this code clarifies it a bit.
class abc {
public:
static int d;
int e;
abc();
virtual ~abc();
void f();
};
abc::d = 100;
// Dynamically create the object in some free memory spot
abc *t1 = new abc();
t1->e = abc::d; // t1->e equals 10
// Object must be deleted to free the memory spot that was created earlier
delete t1;
// Local object, memory is already reserved at execution time. So there's no need to free it later on
abc t2;
t2.e = abc::d; // t2.e equals 10
// Make a reference to t2
abc t3 = &t2;
t3.e = 50; // t3.e refers to t2.e, and thus both are now 50
If I'm not mistaken, using pointers will dynamically reserve memory and can keep memory usage as low as possible. Because it will only assign memory when it's needed. So if you write a program with a LOT of global variables it will always at least reserve that amount of memory and your program will always be using that much memory. With pointers this isn't the case, because memory is only being assigned when you're actually assigning something to it. I've been using C++ for about a year and a half and I found pointers and references confusing as well. It can get more confusing when you need to do something like (*ptr)->f(); But once you get the hang of it it's fairly easy :-). |
| ||
| Thanks for the help, Htbaa. I had a look at this clip_children problem. It appears there is a reason clip_children is protected although there isn't much information on it, something to do with restricting when it can be used. To access protected members you have to create a subclass. Seems a bit of a nuisance but I don't think it is a bug. If clip_children is working now then might as well just leave it public. For subclassing see: http://www.fltk.org/doc-1.0/subclassing.html http://www.fltk.org/doc-1.0/opengl.html |
| ||
| Yeah, thanks Htbaa. That seems to have cleared things up a bit... Use "." for accessing methods from local objects, and "->" for pointers. Gotcha! To access protected members you have to create a subclass. Yeah, I thought about doing that, but didn't really want to as I'd have to subclass every single widget that extends Fl_Group. Simply moving the members to public saves me a lot of time and unnecessary bloat code. I still think it should be a public declaration if it is in the docs, though... Anyhoo, I've just committed a few more fixes to SVN which should improve the dialog box handling (inc. Find, Find & Replace, IDE Options) somewhat. Not 100% the same as Windows yet, but we're getting there. Also, it includes your fl_ask.cxx suggestion. MaxGUI.FLTKMaxGUI 1.25 Release > Windows are now extending Fl_Double_Buffer as an attempt to reduce random drawing artifacts. > Child windows should now stay on top, but behaviour still isn't exactly the same as Win32 or Cocoa. > Default message box font is now set to match other fonts. |
| ||
| Hmm, I thought you could access a protected method of a class from a new instance of the class (or subclasses). Anyway, I think you're right Seb, clip_children should be public. Edit: posted a bug report to FLTK here. I had a search and couldn't find a single bit of source that actually used clip_children but I did find the threads that brought about the inclusion of clip_children in FLTK. http://www.mail-archive.com/fltk@... http://www.fltk.org/str.php?L1844 To be sure I built the code in that thread from FLTK and then tested clip_children and it reported the same error, so I made the clip_children functions public in Fl_Group.H and that fixed it. For the record the code I used looks like this. |
| ||
| Hmm, I thought you could access a protected method of a class from a new instance of the class (or subclasses). Anyway, I think you're right Seb, clip_children should be public. Edit: posted a bug report to FLTK here. Thanks Mark. Hopefully the FLTK dev team will get around to committing some of these bug fixes into the weekly releases. Might be more of a reason then to upgrade to FLTK 1.3.X. |
| ||
| Another new commit, this time with the following fixes/improvements: MaxGUI.FLTKMaxGUI 1.26 Release > Changed the status-bar border so that it looks more like one. > BUTTON_DEFAULT now uses Fl_Return_Button instead. > Fixed strange EventX/EventY coords in EVENT_WINDOWMOVE and EVENT_WINDOWSIZE. > Done some work cleaning up EVENT_GADGETSELECT generation by textareas. > Added CharX() and CharY() methods. |
| ||
| I like the new statusbar Seb, haven't noticed any of the other changes. New versions of Fl_Help_View.cxx and Fl_Help_View.H are up. This fixes 2 bugs. The first was the nested tables bug. When tables were indented their x position wasn't taken into account. I wrote before that nested tables weren't supported but they are, just not very well. Anyway, to fix it I had to make a few changes to Fl_Help_View.H so you will need that. The second was a colspan bug. This was a side-effect of fixing the previous colspan bugs. Since colspan was being ignored it meant a long string of text wasn't padding out it's cell as it should. I fixed it by storing the colspan widths in a new array and then used that for a table width check. It's not perfect even though I hacked away at it for several hours but it's ok. You'll notice these changes most in Modules>MaxGUI>MaxGUI.MaxGUI and Modules>Graphics>BRL.Max2D. |
| ||
| Nice work Mark! Finally, we've got MaxGUI docs that don't need a horizontal scrollbar! ;-) The only other change you'd have noticed in the last update would be in the the IDE requester windows - the OK/Find buttons will have a return icon on them to indicate their behaviour. I've just committed a new update, with a few other additions too: MaxGUI.FLTKMaxGUI 1.27 Release > Added EVENT_GADGETMENU for tabbers. > Improved layout of PANEL_GROUP. > Added the latest set of markcw's Fl_Help_View.cxx fixes. Great! Now I've got a challenge for you. One sure fire way of getting the IDE to crash on FLTK is to start-up MaxIDE, navigate to MaxGUI.MaxGUI. Scroll down about a page until you see the subheading "Windows", where there will be three screenshots of windows for each platform. Now click on one of them and the IDE will magically disappear with the following error message: Building maxide Linking:maxide Executing:maxide X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 73 (X_GetImage) Serial number of failed request: 25264 Current serial number in output stream: 25264 Process complete I remember one of my early FLTK fixes that you posted a bug report for fixes some of the X_GetImage errors but it musn't have got all of them. Do you have any ideas why such a message would be generated when an image is clicked? It doesn't seem to happen if you click on the page background, or text. |
| ||
| Found it! Yep, it's what I thought - another fl_read_image.cxx XGetImage bug... Fix is now available from the MaxGUI SVN (rev. 68). I've now implemented a water-tight fail-safe around that call. The default XServer error handler is swapped before the call to a dummy handler (declared earlier on in the file), and then the original error handler is restored once the call has been made. I expect that this is how its supposed to be called. Now, if the function fails, it should simply return a NULL image, which we check for in the proceeding if() statement. If an image isn't loaded at that point (for whatever reason), we use the alternate safe method of capturing an image (I assume the reason that this isn't used initially is that it is slower). Can you amend the current or post another bug report on FLTK.org, markcw? |
| ||
| Nice one, Seb! Updating my maxgui now. I just fixed a similar bug which was causing the IDE to close. This was due to calculating when a value was <= 0, probably it was a divide by zero error but just to be sure I checked two other values used in the calculation. It was actually returning something about a Floating point error, so I was confused as there were no floats used. New versions of Fl_Help_View.cxx and Fl_Help_View.H are up. This fixes two more bugs. The first is a rewrite of the previous colspan fix. The previous code worked for the docs but not for all cases of colspan cells. This version fixes colspan cells properly although you probably won't notice much difference from the last version. The second is a table width bug. Tables were being scaled too wide so the last letters in a table cell were sometimes not readable. This is a big improvement but is still not perfect. The table scaling code is the main suspect I think. Oh, yeah I'll post that bug report. |
| ||
| Just updated Fl_Help_View.cxx again. It's a few changes to do with the divide by zero error in the colspan fix. It doesn't make much if any difference really but it's better code. |
| ||
| Another version of Fl_Help_View.cxx just up. This fixes the draw tabs in pre tags bug. Tabs were not being drawn at all so there was no indents in pre tags unless spaces were used. This implements tab indents properly, so the tab length depends on where it started on the line. |
| ||
| As always, fantastic stuff! I'll take a look tomorrow on my Ubuntu PC. I have another miniature Fl_Help_View bug report, if you are interested. When different sized images are on the same line, they are aligned by their top edges, not by their bottom. Would it be easy to correct this behaviour so that is in line with other browsers? One place I know that this can be seen is on the window images displayed in the MaxGUI.MaxGUI docs, under the Windows subheading at the start of the page. |
| ||
| Hi Seb, I fixed that bug and uploaded new versions of Fl_Help_View.cxx and Fl_Help_View.H. I had to add a new field to the block code in Fl_Help_View.H which stores the max image height per block. Then in draw I add the difference between the image and the max height to the y position. I also had to add a check for when an image is line wrapped as they were being drawn too low. This now draws images from the baseline in MaxGUI>MaxGUI.MaxGUI but I notice that blocks contain lots of stuff and that <br> doesn't create a new block so I still need to look at that, plus I need to see if images in tables are working. |
| ||
| Thanks Mark! This and another fix has now been committed to SVN: MaxGUI.FLTKMaxGUI v1.28 Release > Corrected logic error that was allowing only left-mouse clicks to pass through to widgets. |
| ||
| Oh, you should have waited a bit longer. :) New version of Fl_Help_View.cxx is up. This implements aligning images to the baseline properly. I removed the check in draw() for when images are line wrapped and created a new block in format() for when images are wrapped or a line break is taken. This was needed as the max image height var is only valid for one line. The hard bit was trying to work out a bug with the new code, sometimes lines were starting a few pixels to the left. It took me a few hours to figure out that I had to add the new block before taking a line break so the line array was in sync. |
| ||
| New versions of Fl_Help_View.cxx and Fl_Help_View.H are up. The first fix is a one-line wonder which checks the current height increment variable in the </table> code. If there was just an image in a table and text right after an </table> tag there would be a big space because the height variable wasn't reset. The second fix is aligning text on the same line as an image to the baseline. Text beside an image was aligned to the top which is not the expected behaviour. This needed a new field added to the block struct in Fl_Help_View.H to store the y position of images which is then used as a check in draw() for text at that y position in the same block. Still got to post that FLTK bug report. I keep forgetting. Edit: ok, bug report is here. |
| ||
| Cool! I'm gonna be away for a few days, but I'll commit the changes when I get back as my Linux box is a Desktop PC. It also appears as though I've broken some of the text-area events in my clean-up as Undo isn't working properly anymore in the IDE. I'll have a look at this then too... |
| ||
| Back now and managed to finish off my latest FLTKMaxGUI tweaks, which have now been committed with Mark's Fl_Help_View fixes too (rev 75). MaxGUI.FLTKMaxGUI v1.29 Release > Fixed an undo bug in IDE by getting FLTK to mimic Win32/Cocoa textarea event behaviour more closely. > Dropped in the FLU file requester to replace the default FLTK one. > Some more of markcw's Fl_Help_View.cxx fixes. > Copied FLU source into FLTKMaxGUI folder. You might like to recompile MaxIDE with the latest version of FLTKMaxGUI and checkout the open/save as file requesters (which now uses the FLU extended widgets library). It now looks similar to this (but obviously the Win32 screenshot appears slightly differently on Linux):  |
| ||
| I like the new open/save dialog, Seb. Much, much better! New versions of Fl_Help_View.cxx and Fl_Help_View.H are up. The first fix is for table widths. Tables are now only as wide as they need to be instead of them all being rescaled to the full document width. The second fix sets table widths precisely to what they should be. So text in tables should all be fine now, the exception is nested tables which I will be trying to fix next. The third fix wraps text to the window width instead of the full document width. There is still a small bug here, when the text length is wider than the window width it takes a new line. The fourth fix draws <hr> tags to the window width, these were being drawn without taking into account the horizontal scroll position. The fifth fix adds support for <div> tags ie. the id and align parameters. This can be seen in Tutorials>BlitzMax overview where the target links didn't work because they are div id tags. Oh, I should also say that you need the latest Fl_Help_View.H as I removed a parameter that wasn't needed in format_table() which I added in the last update. |
| ||
| Nice work... Unfortunately, can't commit immediately as the SVN server appears to be down atm, and also after recompiling the IDE I'm getting weird behaviour and a tonne of fl_pop_clip error messages... Eeeekkkkk! Anyway, not sure if the two issues are related, but can you have a look at the following. Download and extract this patched makedocs into your BlitzMax/bin folder, and then rebuild documentation. This should hopefully rebuild docs with all the MaxGUI examples included in the MaxGUI.MaxGUI help files (e.g. see CreateWindow() etc.) like on Windows. Although some of the examples further down the page can be a bit too far indented, a more severe problem I'm experiencing happens when you resize the splitter between the help view and the treeview. For me, the window hangs for ages, from which it may or may not recover. Can you reproduce this? |
| ||
| after recompiling the IDE I'm getting weird behaviour and a tonne of fl_pop_clip error messages... Eeeekkkkk! Easily fixed by bumping the stack size on line 422 of fl_rect.cxx to at least 16 (although I've been using 64 fine without any noticable slow-downs). Will commit a fix a soon as the SVN repo comes back online. I think the problem arose because we have a lot of nested parent groups in MaxIDE, and now that most of them use clip_children() we very rapidly reach the clip limit. The example code misalignment problem is still visible, however, in the MaxGUI docs (after following the instructions I gave above). It's noticeable from about the LookupGuiFont() command downwards. |
| ||
| Some new fixes/improvements are now available from the MaxGUI SVN (rev. 81): MaxGUI.FLTKMaxGUI v1.30 Release > Implemented the FLU Tree Browser to replace the old list-box based treeview. > Increased clipping stack length in Fl_Rect.cxx to suppress warnings when running MaxIDE. > Replaced Fl_Button and Fl_Return_Button with Flu_Button and Flu_Return_Button. > Some more Fl_Help_View fixes from markcw. The new treeview widget is certainly a valuable addition, especially for the IDE. Be sure to let me know what you think... ;-) |
| ||
| > after recompiling the IDE I'm getting weird behaviour and a tonne of fl_pop_clip error messages... Eeeekkkkk! Easily fixed by bumping the stack size on line 422 of fl_rect.cxx to at least 16 (although I've been using 64 fine without any noticable slow-downs). Will commit a fix a soon as the SVN repo comes back online. I think the problem arose because we have a lot of nested parent groups in MaxIDE, and now that most of them use clip_children() we very rapidly reach the clip limit. Strange, I'm not getting any fl_pop_clip errors in debug. I tried it in MaxGUI.MaxGUI and my maxgui mod is about a week out of date, will update soon. I'm not sure how it relates to clip_children, but fl_rect.cxx is line drawing code. Increasing the stack size to something big like 64 may not cause any difference, it may just be badly written code. Download and extract this patched makedocs into your BlitzMax/bin folder, and then rebuild documentation. This should hopefully rebuild docs with all the MaxGUI examples included in the MaxGUI.MaxGUI help files (e.g. see CreateWindow() etc.) like on Windows. Although some of the examples further down the page can be a bit too far indented Ok, I extracted the patch and can see the code indent bug. It happens after nested tables so that's the cause. There are still quite a few bugs with nested tables I need to fix. a more severe problem I'm experiencing happens when you resize the splitter between the help view and the treeview. For me, the window hangs for ages, from which it may or may not recover. Can you reproduce this? Yes, this bug has been there since before I started work on Fl_Help_View.cxx, I'm not sure what's causing it but resizing the splitter is slow and the more content on the page the slower it gets until finally in very big pages like MaxGUI.MaxGUI it crashes. One thing I was looking at that may be related is in Fl_Help_View.cxx at line 216 there is a note about the draw functions needing to be speeded up by replacing them with local copies although I don't know what that means, any ideas? There may be several things causing this crash, but it's still a mystery to me. |
| ||
| Ok, the problem is in Fl_Help_View.cxx in resize(). This calls format() every time you move the splitter and format() is a slow function so when you've got a big page it can't handle the constant calls. Not sure what to do yet but it's good to know the cause. |
| ||
| New version of Fl_Help_View.cxx is up. This fixes the crash/hang when resizing very big pages like MaxGUI.MaxGUI. It's still not as smooth as it should be but it does the job. I included forms.H to get a timer. The code measures how long format took then waits that long before calling format again. It never waits longer than 1/4 sec and that seems to be enough for even really big pages. It also only calls format once the splitter has moved a few pixels. Oh, I forgot to mention that I fixed the bug where words longer than the window width were taking a new line when they shouldn't. This appeared when I wrapped text to the window width. It's a rare bug but better to fix it anyway. Also, I updated my maxgui and like the new treeview, looks more gtk-ish. I see you have got rid of the hard edges around the windows too, which looks better but the vertical scrollbar is slightly covered. |
| ||
| New version of Fl_Help_View.cxx is up. This fixes the crash/hang when resizing very big pages like MaxGUI.MaxGUI. Cheers - I'm up to my neck in FLTK code at the moment, as I thought I'd clean up fltkgui.bmx a bit (one of those jobs that you realize is gonna take much longer than expected ten minutes in). Will make sure I have a look when I get everything straight again. I updated my maxgui and like the new treeview, looks more gtk-ish. Yeah, I think its a lot better too. Just need to implement EVENT_GADGETMENU. I see you have got rid of the hard edges around the windows too Errmmmm... I see what you what you mean, but I don't think that was intentional. Will investigate when I get a minute... Oh btw, make sure you've ran an SVN update from the BlitzMax SVN too to make sure that you have the latest maxide.bmx and doc fixes. |
| ||
| Just updated everything today but when I build maxide and click the close button I get this error box: "unhandled exception:attempt to access field or method of null object" On line 1694 in maxide.bmx: For v=EachIn views If v.node FreeTreeViewNode v.node;v.node=Null Next |
| ||
| Hi Mark, Sorry about the late reply... Can you try replacing TFLNode's Free() method with: Method Free() If Not nodehandle Then Return 'Make sure we don't free twice For Local tmpNode:TFLNode = EachIn kids tmpNode.Free() Next kids.Clear() fluRemoveNode( owner.flhandle, nodehandle ) If textmem Then MemFree textmem;textmem = Null If parent Then 'If not TreeViewRoot() parent = Null;owner = Null;nodehandle = 0 EndIf End MethodI can't commit a fix at the moment, as I'm still trying to get my restructured fltkgui.bmx stable. |
| ||
| Yes that fixed it, thanks Seb. |
| ||
| Good to hear! Btw, are FLTK MaxGUI applications (including MaxIDE itself) taking up a lot of CPU cycles when idle? I've not got a clue what is causing it, when it started happening or whether anyone else is experiencing it... |
| ||
| Not noticing any cpu eating from maxide here. Edit: ah yes, when I open several maxides I get fairly noticable slowdown but I don't think it's that bad. |
| ||
| Another update to Fl_Help_View.cxx and Fl_Help_View.H is up. This improves the resizing of big documents further. I had to add a new global variable to the Fl_Help_View class in Fl_Help_View.H, which is static as I think that is the only way to add to that class now without causing a malloc error. Anyway, I improved the time delay for format so it can now resize super-massive pages. The new code added calls format in handle when the mouse is released after a resize, the second part is in format and this skips formatting anything below the current view when resizing, so it gets slower the further down the page you go. I know this is inconsistant but I thought it was better than not having it. I also tried to avoid formatting above the current view but that turned out to be a nightmare so I left it. The other thing is that I couldn't get the scrollbars to update while resizing big pages, which looks a bit scruffy but they update when the mouse is released so it's only an aesthetic problem. At it's slowest it's now as fast as firefox 3 so I was happy to notice that. |
| ||
| Haven't had a chance to fire up my Linux box since I got back home, but I've committed the Free() patch and your latest Fl_Help_View fixes to SVN from my Windows PC. Thanks |
| ||
| Hi Seb, well in that case the changes made since my last post to the latest Fl_Help_View.cxx have been: - fixed <br> directly after another <br> not taking a new line. - added <li> type parameter support and circle and square bullets. - fixed <li> bullets on far left margin not visible. - added HTML 4 character references to quote_char(). - added support for drawing most of these characters via the Symbol font. - fixed control characters not drawing correctly because of null widths. |
| ||
| I don't want to ruin the party, but I just noticed that FLTK doesn't support Javascript in the html pages. It's true or I miss something or there is a possibile solution? I just tried to run my little program on a Linux machine (here the program), but I noticed that (even if the program runs well) the index.html page is 'messed up' with JavaScript code. You can see here an image of the index.html+javascript error... |
| ||
| Yeah, don't worry there's no party to ruin here. :) FLTK's HTML renderer is very basic and just handles HTML code but no extensions such as CSS and Javascript. I haven't looked at Javascript yet so thanks for the screen. I'll add some code to get it to stop printing Javascript code. To actually support Javascript would mean plugging it into a Javascript VM. |
| ||
To actually support Javascript would mean plugging it into a Javascript VM. OMG! And for what I found with google, I don't understand if neither GTK supports javascript and event it requires an external JS VM. |
| ||
| Well, not exactly a virtual machine I just thought the word 'engine' didn't describe it enough. By VM in this case I mean more of a Javascript 'engine' that parses the Javascript and returns interpreted data that could then be used to render whatever the Javascript intended. The alternative would be to code a Javascript 'engine' from scratch which would probably end up just managing the basic stuff like document.write, etc. Maybe it would need a combination of both I don't know yet because I'm still working on the basic HTML rendering, next comes CSS, then I might look at Javascript. |
| ||
| New version of Fl_Help_View.cxx is up. - added skipping of <script>. Javascript, etc are now properly unsupported. You can use <noscript> for alternative html. - <ul> and <li> are now more or less fully implemented. - improved <hr> line spacing and added a shadow line. - tidied code a bit, fixed a few minor things not really worth mentioning. |
| ||
| Cheers Mark. I'm slowly making progress on the fltkgui.bmx rewrite. If everything goes well, I may even have it committed by this evening. :-P |
| ||
| Thought I wasn't going to make it then, but a brand new commit of FLTKMaxGUI is available from the MaxGUI SVN. MaxGUI.FLTKMaxGUI v1.32 Release > Completely restructured fltkgui.bmx into OO code. > Fixed a small memory leak in text area and treeview. > Fixed OK button text getting corrupted by the new Flu_Button. > RequestFont() dialog should now be modal. > Another set of markcw's Fl_Help_View fixes. fltkgui.bmx has undergone some quite fundamental structural changes, so although I was really careful, I may have introduced a bug or two by accident. Any testing is greatly appreciated... |
| ||
| Very nice MaxIDE build now! I see you have fixed the partly hidden vertical scrollbar too. So far no problems. The FLU lib is really nice! Did you add this to maxgui recently? It doesn't seem to be part of FLTK which seems odd so I found the author's homepage here. There doesn't seem to be a splitter widget there so I was wondering how you managed that as the new one is so much smoother when resizing! |
| ||
| Yeah, I added the FLU lib but it is only used for the file requesters, treeviews and buttons (which turn a lighter shade when the mouse is over them). The "splitter widget" is actually one of my own personal MaxGUI.ProxyGadgets inventions. It came from one of my old MaxGUI programs (back in the days when I was coding with MaxGUI, as opposed to coding MaxGUI itself :-P). I thought it would benefit MaxIDE as I added features, such as the ability to drag the pane to any side of the screen and also you can single-click to toggle too! In addition, it hooks into the window size events, which should mean that it a sidepane never takes up more than half the available window space. Before I was about to bung it in maxide.bmx, I thought others might find it useful, so instead I added it to MaxGUI.ProxyGadgets, which MaxIDE now links in to. You can use it in your own apps by calling the CreateSplitter() command. the new one is so much smoother when resizing I think this is also down to your amazing Fl_Help_View work too. Between the two of us, FLTKMaxGUI is really coming along in leaps and bounds. Once again, thanks for all your contributions. |
| ||
| I've just committed another few tweaks: MaxGUI.FLTKMaxGUI v1.33 Release > Added SetTextColor() method to allow for multi-colored widgets. > Added support for the MaxGUI stepper, complete with repeat buttons. Enjoy! Edit: Btw, I forgot to mention that in the previous commit, the text area memory leak fix appears to have eliminated the problem whereby occasionally .bmx sources wouldn't get parsed by MaxIDE. |
| ||
| Thanks for the info Seb, and for adding your splitter to proxygadgets. I like that toggle feature, never noticed it actually. I also like the way you can just move the sidebar to the other side by resizing, much slicker than having a setting somewhere. I notice your name isn't in splitter.bmx, is there some reason for that? Also, I can't find the 'splitter widget' in FLTK, so could you tell me what MaxIDE was using before your splitter? The old splitter jumped all over the place, even when resizing in the text editor window, so I'm very glad you got rid of it! When you say "occasionally .bmx sources wouldn't get parsed by MaxIDE" do you mean the random 'no syntax highlighting' bug? I tested that out and wasn't able to reproduce it. |
| ||
| I like that toggle feature, never noticed it actually. Thanks. It was a last minute thought just before I committed it, but it's nice to have when you have long lines/comments in the source code... also like the way you can just move the sidebar to the other side by resizing, much slicker than having a setting somewhere. Yeah, I made sure this was possible as I didn't like the way the old MaxIDE splitter was restricted. I notice your name isn't in splitter.bmx, is there some reason for that? I don't know... Modesty? :-P Honestly, I wrote it from scratch, but as MaxGUI.ProxyGadgets only contains my own submissions at the moment, I never felt a need to explicitly state my name... Underneath it simply consists of several standard MaxGUI panels, and some crazy mouse tracking code, but I'm quite proud of it... ;-) All the actual MaxGUI drivers (such as Win32MaxGUI, CocoaMaxGUI or FLTKMaxGUI) see are panels with PANEL_ACTIVE flag set. Also, I can't find the 'splitter widget' in FLTK, so could you tell me what MaxIDE was using before your splitter? It was a really basic implementation that was coded inside MaxIDE's source. If you checkout the latest maxide.bmx from the BlitzMax SVN you should be able to see the original splitter that I Rem'd out (I think it was called TSplit, or it might even have been called TSplitter). In principle, it works the same underneath as mine (i.e. MaxGUI panels and mouse tracking code), just with a bit less polish. do you mean the random 'no syntax highlighting' bug? I tested that out and wasn't able to reproduce it. Yeah that's the one - you posted a step-by-step guide for reproducing it (using an AStar pathfinding sample, iirc). Anyway, as you said, it appears to be fixed now. |
| ||
| I've committed a few new patches since I last posted here, addressing: MaxGUI.FTLKMaxGUI v1.35 Release > Added prelimary pixmap support for push-buttons. > Added text support for group-panels. MaxGUI.FLTKMaxGUI v1.34 Release > Tweaked Fl_Color to accept a wider range of formatting color contrasts before resorting to black or white defaults. |
| ||
| Just to let you know Seb, I'm still working on this and will upload a new version soon. I have been busy lately so haven't had much chance to work on this but I've got a few new things done and am working on reducing memory overhead (an unsung task) and the nested tables bug you mentioned in your makedocs patch (I haven't forgotten!). How's it going yourself? |
| ||
| Hi Mark, Nice to hear from you. Quite honestly, as of 1 week ago, I have been (and will be) unable to do any work on MaxGUI due to a infinite increase in my work load. Also, I don't have access to a Linux PC at the moment, which makes MaxGUI.FLTKMaxGUI development even less-likely. Don't let this dampen your spirits though - I can still commit your welcome fixes to the repository, and marvell at your efforts when I eventually find time to give them a spin myself. ;-) |
| ||
| Ok, no problem I'll continue to work on this. Just uploaded new versions of Fl_Help_View.cxx and Fl_Help_View.H. - improved <hr> and <h1-6> line spacing. - fixed font size not updating line y positions, required changes to header. - fixed nested tables overwriting subsequent <tr> and <td> cell data, required changes to header. So the code examples in your makemods patch are now correctly aligned. :) |
| ||
| So the code examples in your makemods patch are now correctly aligned. :) Nice job! ;-) One thing, looking at the DIFF for Fl_Help_View.cxx there are quite a few chunks of code that have been added and then block commented (/* ... */) out. Is this for a reason, or should they simply be removed? Just wanted to check as it may be best to wait before committing if you're still playing around with it... |
| ||
| Heh, no that's fine don't worry. It's alternative code I'm still working on for lowering the memory overhead which I hope to have done in the next revision. |
| ||
| Heh, no that's fine don't worry. It's alternative code I'm still working on for lowering the memory overhead which I hope to have done in the next revision. Ah well, I may as well wait for that before committing... Cheers |
| ||
| Ok, new version of Fl_Help_View.cxx and Fl_Help_View.H are up. - improved block system, every line is now in it's own block. - removed line[32] field to drop memory usage to about 30%, required changes to header. - tidied up code comments. |
| ||
| Committed (rev. 98)! I've bumped the FLTKMaxGUI version too as these changes probably count as an FLTKMaxGUI update by themselves. Thanks Mark. ;-) |
| ||
| New version of Fl_Help_View.cxx is up, lots of little fixes. - fixed mouse over horizontal scrollbar showing active link/hand icon. - fixed last line in <td> misaligned, caused by new block per line system. - fixed empty <td> on end of row affecting next row y position. - fixed wrong line gaps before and after a table. - fixed nested tables overwriting <table> and <tr> 'bgcolor'. - improved color lookup, no hash needed for hex value. |
| ||
| Exciting!!! ;-) Quick question, is there a reason why the file you uploaded is half the size of the current one? It seems as though the format methods are missing... |
| ||
| No, it's all there, the bottom of the file should have the line: "// End of "$Id: Fl_Help_View.cxx ... blah" maybe you just had an error loading the file, it should be ~157Kb. |
| ||
| maybe you just had an error loading the file, it should be ~157Kb Yeah, the source I downloaded is 157KB but it's just the current SVN version was about 300KB. Anyhoo, I've committed it. Thanks! |
| ||
| New versions of Fl_Help_View.cxx and Fl_Help_View.H are up, big revision this time. - fixed nested table overwriting cell heights. - fixed nested table drawn below row height. - improved format speed to 30% less time, required changes to header. - fixed cell width not reset before/after nested table. - fixed nested table popping cell margin. - fixed pre text in tables not increasing cell width. - improved pre tabs width, miscalculated in tables. - added CHR() and MIL() macros. - fixed tables not popping last font. - fixed divide by zero error if table cells empty. - renamed variables and reordered functions alphabetically. |
| ||
| New versions of Fl_Help_View.cxx and Fl_Help_View.H are up, big revision this time. Committed (see rev. 105)! Thanks! |
| ||
| Hi Seb, just looking in fltkglue.cpp and spotted this comment on line 1827. I don't follow this, what memory do you mean? void flRedirectView(Fl_Help_View *view, char*url) { redirect_url=stringcopy(url); //Seb was here (memory should get freed by Fl_Html_View.cxx) } |
| ||
| I don't follow this, what memory do you mean? I think I was referring to the additional memory that stringcopy allocates. Basically, it was a comment to remind me that it was OK to use stringcopy without having to keep a track of the pointer ourselves as the memory would be freed by Fl_Help_View once it has been processed. |
| ||
| Hey markcw, Finally managed to get Ubuntu 8.10 up and running on my laptop, so I've had a chance to have a look at what you've been up to. Everything Fl_Help_View wise is looking mightily impressive... And the redraw when resizing really is super-fast. Nice work as always! ;-) |
| ||
| Hi Seb, thanks. New updates for Fl_Help_View.cxx and .H are up. - changed vertical scroll size, now moves double the amount. - added new methods sansfont, monofont. - added new function font_find, used for new default fonts. - added new functions build_faces, font_face and font_style. - added full support for font face attribute, required changes to header. - fixed bold/italic not working with many fonts. - removed inconsistent resizing tweak in format. |
| ||
| Thanks! Just committed it now - see revision 109. |
| ||
| Ok, I suppose this is worth a commit, new versions of .cxx and .h are up. - added new method reformat, for calls to format. - replaced add_block, format_table functions with extended argument versions. - added d-pointer by hijacking Fl_Help_Target, required changes to header. - replaced compare_targets function with cmp_targets, due to d-pointer. - replaced textfont_ and textsize_ with global statics. - moved local statics to d-pointer struct. - fixed links with target values not setting position on new page. |
| ||
| Committed! Greatly appreciated! |
| ||
| Hey Mark, I've been playing around with FLTK 1.3 over here, and most things appear to be still working as they were. One thing that doesn't seem quite right (at least on Linux) is your Fl_Help_View. :( If I use the Fl_Help_View from the FLTK 1.3 repo (don't use the last weekly build package as a few bugs have been fixed since then), then text is drawn like it used to be (although it doesn't have any of your amazing layout improvements :P). If, however, I drop your Fl_Help_View.cxx (and header file) in, then the text goes a bit crazy, and some of the letters start overlapping with the previous ones. If you want, I can try and send over an FLTK 1.3 fltkmaxgui.mod, but I thought I'd see if you can think of anything obvious that may be causing this? I'm guessing it's because of the move to UTF8, but I thought I'd ask the expert. ;-) I'll post a screenshot next time I'm in Linux, as I've only just rebooted back into Vista. Thanks in advance |
| ||
| Well at least it doesn't crash. I really have no idea offhand, it would need an investigation. Email it to me if you like and I'll take a look at it. |
| ||
| Email it to me if you like and I'll take a look at it. Thanks! Just found a show-stopper FLTK bug concerning XFT on Linux which could do with being fixed before it's redistributable, but I'll make sure I drop you an e-mail when it is in a suitable state. |
| ||
| E-mail sent. ;-) Thanks! |
| ||
| Ah, seeing the screen it is a miscalc in the width of words somewhere, not sure what I changed but I'll have a look asap. |
| ||
| Ok, new version is up with the fix for fltk 1.3, the .h file is unchanged. This was due to a hack I added in rev 13 for drawing using the symbol font ie. - added support for drawing most of the new char refs via the Symbol font. I call it a hack as the code was a bit messy and obviously because it only worked with fltk 1.1. Spaces between words seem a bit wider now but this happens in the original fl_help_view too, it's not a bug really just looks a bit different. |
| ||
| Lighting fast bug-fix! ;-) I'll reboot into Linux when I get a chance and check it out but I'm sure it'll be fine. I can't say I fully understand what was going wrong though. Was there a specific reason you used the symbol font to draw some of the text? I'm guessing by symbol font, you mean FL_SYMBOL? Does this mean that there is a bug in FLTK 1.3 then? Thanks! |
| ||
| It was an attempt to provide full support for html character entity references, the '& id ;' markup. The symbol font has a lot of these characters, mainly Greek letters and special math operators. I'm not sure what's happening in fltk 1.3 yet but the extended symbols were all ? chars. It may be something to do with utf-8. |
| ||
| Hi Seb, got a nice job for you here. :) This fixes the link targets not stored in history bug. It requires changes to fltkgui but I thought it would be better if I just list the changes here and you can add them rather than me uploading the files. There are new versions of Fl_help_view.cxx and Fl_help_view.h uploaded which are also part of this fix. Note: all lines (or functions) I added have my name after them. I'm also copying bits of code already there so it is clearer. Edit: renamed flSetFilePath, flGetFilePath, flFileIsLink to flSetPathView, flGetPathView, flIsLinkView for better naming convention. First, in fltkglue.cpp around line 224: void flSetView(Fl_Help_View *view, const char *html); void flSeekView(Fl_Help_View *view, const char *anchor); void flRedirectView(Fl_Help_View *view, char *url); void flSetPathView(Fl_Help_View *view, const char *path); // markcw const char *flGetPathView(Fl_Help_View *view); // markcw bool flIsLinkView(Fl_Help_View *view); // markcw int flLoadView(Fl_Help_View *view, const char *file); // markcw Then again in fltkglue.cpp around line 1828: Now on to fltkimports.bmx around line 367: ' htmlview Function flSetView(view,html$z) Function flSeekView(view,anchor$z) Function flRedirectView(view,url$z) Function flSetPathView(view,path$z) ' markcw Function flGetPathView$z(view) ' markcw Function flIsLinkView(view) ' markcw Function flLoadView(view,file$z) ' markcw And finally to fltkgui.bmx around line 2272: Now a little explanation. :) flLoadView isn't used but I added it as that is the other way to do things. The problem was that fltkgui is using value (in flSetView) which uses the file contents rather than the file path. This meant fl_help_view didn't know the current filepath and so couldn't set the link history since that seems to need the link transform callback, which needs a filepath. Catch 22. :) So I have got fltkgui sending the filepath, then fl_help_view adding the link target to that (as fltkgui didn't seem to have targets) which fltkgui gets back and sets the history with. Being a bit of a hack it still didn't work right, so I also added flIsLinkView which tells fltkgui if a nav button or link was clicked, namely the home button wasn't working. |
| ||
| Just noticed links with targets don't work. Should have checked that. Doh! Also, this is tested with fltk 1.3. |
| ||
| Ok fixed it, fingers crossed! The good news is that I only had to change Fl_help_view.cxx. Seems I was getting the wrong directory from getcwd. |
| ||
| Hey, Thanks Mark! I've finally decided to get the latest FLTKMaxGUI upgrade out the door and have now committed it to SVN. See revision 118 for the following fixes: MaxGUI.FLTKMaxGUI v1.38 Release > Updated to FLTK 1.3, rev 6649. > Added markcw's HTMLView forward/back code - thanks Mark. > Fixed event.data on button EVENT_GADGETACTION. > Tweaked to allow module to compile and run on Windows. > Fixed missing mouse wheel events on canvas. > Improved font handling and FontRequest() window. Some MaxGUI'ers may be particularly interested in point 4 - MaxGUI.FLTKMaxGUI will now compile and run on Windows too. So if you fancy seeing how your apps will look/behave on Linux and you can't be bothered rebooting, you can simply import MaxGUI.FLTKMaxGUI into your projects (instead of MaxGUI.Drivers) and rebuild. Note - this is not cross-compiling. You will still be producing a Windows executable, it's just that your GUI interface will be rendered and managed using the same engine as on Linux. Next stop is trying to get the XFT font rendering in FLTK1.3 stable so that it draws anti-aliased text (like Sans) on Linux, without crashing. Therefore, atm, FLTKMaxGUI is using the older, but more stable, text renderer. Btw, a lot of files have changed in this revision, and some files have also been added/deleted so SVN'ers might want to consider a fresh checkout. As always, let me know how you get on... |
| ||
| and some files have also been added/deleted so SVN'ers might want to consider a fresh checkout. You shouldn't need to do a fresh checkout. SVN supports adding and removing of files. |
| ||
| You shouldn't need to do a fresh checkout. SVN supports adding and removing of files. You are right - I have ran all file changes through SVN so it should work, but I thought I'd put that *just in case* some run into trouble. ;-) |
| ||
| The only time you should face trouble, is if you remove a folder and replace it with another of the same name - This way you remove the .svn folder, which is bad news. Ideally, if you were to change the contents of a whole folder, delete all the files within it, and copy in the new ones, leaving the .svn folder intact :-) |
| ||
| Silly me, I thought I was working on fltk 1.3 when I was working on 1.1 so I didn't notice I was working on an older file (rev 20 instead of 21). I have uploaded Fl_help_view.cxx with rev 21 changes added. I'll update to the latest svn now and start on rev 23. |
| ||
| I have uploaded Fl_help_view.cxx with rev 21 changes added. Thanks - committed! |
| ||
| Hi Mark, I've just recompiled MaxIDE on Linux, and noticed that the font of the HTML docs appears to now be a serif font. Speaking of fonts, I've had another look into the MaxIDE crash when FreeType is enabled for the FLTK library. After some rummaging, it appears as though the tweaked Fl_Help_View is the source of the crash. I'm guessing that it may be because of your findfonts() routines that parse XServer font strings, but the format is not the same when using XFT. If you want to have a play around, open config.h inside BlitzMax/mod/fltkmaxgui.mod and comment out line 105, uncomment line 104 (to enable XFT) and save. Next, open up BlitzMax/mod/pub.mod/freetype.mod/freetype.bmx and replace the contents with: Finally, rebuild all modules. If you run the bigsearch MaxGUI sample app, the program will crash as soon as it starts. Other MaxGUI apps (without a HTMLView) seem to compile and run fine, and with nice anti-aliased fonts too! If you could have a look into this at some point, I'd be enormously grateful. Thanks! We're one step away from anti-aliased Linux MaxIDE. :P Edit: Some useful links (perhaps?): http://www.fltk.org/newsgroups.php?s18343+gfltk.general+v18360+T0 http://www.fltk.org/newsgroups.php?s18343+gfltk.general+v18361+T0 http://www.fltk.org/newsgroups.php?s18363+gfltk.general+v18365+T0 |
| ||
| Hi Seb, yes the font is a serif font because that is the default font, the sans font is loaded in the .css file but for now I've set the serif font to the sans font. You are correct, it was my find font routines that were crashing it. I was using Fl::get_font() which in fltk 1.1 returns a string with font name and attributes but in 1.3 only returns the font name. I have now rewritten the code to use Fl::get_font_name() which works the same in 1.1 and 1.3. You will need Fl_help_view.h as well as Fl_help_view.cxx this time as I have modified things in there. Also, I wonder if you get this behavior, in MaxIDE the menu doesn't respond until I minimize and restore the window. It doesn't happen in for example samples/maxgui/bigsearch so I'm wondering if you might know what could be wrong? Edit: also when you hover over the toolbar buttons they flash instead of showing the hover button. Oh yeah, and thanks for getting anti-aliased fonts in. Sooo much better now. :) |
| ||
| We're one step away from anti-aliased Linux MaxIDE. Oh? My MaxIDE's always had anti-aliased fonts?? |
| ||
| Insert FLTK before Linux and repeat the question?? |
| ||
| Ah. I wouldn't know :-) |
| ||
| yes the font is a serif font because that is the default font, the sans font is loaded in the .css file but for now I've set the serif font to the sans font. Oh, OK. If it is the intended behaviour then that's cool - it just wasn't the same as my old (pre FLTK 1.3) FLTK build. If it's supposed to be serif'd by default, then perhaps we should stick to it. You are correct, it was my find font routines that were crashing it. I was using Fl::get_font() which in fltk 1.1 returns a string with font name and attributes but in 1.3 only returns the font name. I have now rewritten the code to use Fl::get_font_name() which works the same in 1.1 and 1.3. You will need Fl_help_view.h as well as Fl_help_view.cxx this time as I have modified things in there. You are a star! ;-) Also, I wonder if you get this behavior, in MaxIDE the menu doesn't respond until I minimize and restore the window. It doesn't happen in for example samples/maxgui/bigsearch so I'm wondering if you might know what could be wrong? Edit: also when you hover over the toolbar buttons they flash instead of showing the hover button. I haven't noticed this, but I will definitely investigate. Oh yeah, and thanks for getting anti-aliased fonts in. Sooo much better now. :) Yeah - definitely looks better now, esp. with the "Sans", "Mono" etc. fonts. We're one step away from anti-aliased Linux MaxIDE. :P Oh? My MaxIDE's always had anti-aliased fonts?? Insert FLTK before Linux and repeat the question?? Ah. I wouldn't know :-) Now, now, Brucey! :P |
| ||
| Just thought I'd mention this small fix now, Seb. In fltkglue.cpp I had a look at your comment in flRedirectView and it turns out Fl_help_view does not free the string. I tested it to make sure. Here's the fix, line 62. The comment after do_callback is just for clarity I didn't edit that line. const char *event_url = "none";
char *redirect_url = 0; // init to null - markcw
static int eventid;
const char *viewcallback(Fl_Widget *view, const char *uri)
{
free(redirect_url); // not freed by Fl_Help_View - markcw
redirect_url = 0;
event_url = uri;
view->do_callback(); // widget callback, OnCallback
event_url = 0;
return (const char *)redirect_url;
} |
| ||
| In fltkglue.cpp I had a look at your comment in flRedirectView and it turns out Fl_help_view does not free the string. I tested it to make sure. Here's the fix, line 62. That's strange... Maybe I was having one of those days. Thanks for the fixes - I've now committed your Fl_Help_View and this patch to SVN. |
| ||
| I've attempted to fix for the text-display crash that is sometimes seen when using 'Close All' etc. in the IDE. Revision 124: MaxGUI.FLTKMaxGUI v1.39 Release > Fixed text-display free crash by implementing a QueueFlDelete() mechanism for text buffers. > Moved about block to separate .bbdoc file. Btw, I still can't reproduce any of this behaviour on my Ubuntu 8.10 installation. Also, I wonder if you get this behavior, in MaxIDE the menu doesn't respond until I minimize and restore the window. It doesn't happen in for example samples/maxgui/bigsearch so I'm wondering if you might know what could be wrong? Edit: also when you hover over the toolbar buttons they flash instead of showing the hover button. What do you mean by 'flash'? Flash to a solid colour, or flashes while the button border changes. Have you always had this happen or only recently? |
| ||
| Hi Seb, I've now committed your Fl_Help_View and this patch to SVN. Yeah, sorry for the confusion but I didn't update Fl_help_view until just now. Should probably have held that little fix off until this revision. New versions of the .cxx and .h file are up. I also have some more copy n' paste jobs for you. :) First, in fltkglue.cpp, line 239. I have remove flLoadView as I decided there's no point when everything uses flSetView, the new function is flSetStyleView, return type for flIsLinkView is changed. void flSetView(Fl_Help_View *view, const char *html); void flSeekView(Fl_Help_View *view, const char *anchor); void flRedirectView(Fl_Help_View *view, char *url); void flSetPathView(Fl_Help_View *view, const char *path); const char *flGetPathView(Fl_Help_View *view); int flIsLinkView(Fl_Help_View *view); // markcw void flSetStyleView(Fl_Help_View *view, int flag); // markcw Next in fltkglue.cpp, line 1890, below flGetPathView, the new and modified functions. const char *flGetPathView(Fl_Help_View *view)
{
return view->filepath();
}
int flIsLinkView(Fl_Help_View *view) // markcw
{
return view->fileislink();
}
void flSetStyleView(Fl_Help_View *view, int flag) // markcw
{
view->setstyle(flag);
}Then in fltkimports.bmx, line 384. The new function. ' htmlview Function flSetView(view,html$z) Function flSeekView(view,anchor$z) Function flRedirectView(view,url$z) Function flSetPathView(view,path$z) Function flGetPathView$z(view) Function flIsLinkView(view) Function flSetStyleView(view,flag) ' markcw And now to fltkgui.bmx, line 2213. Implementation of the new function in TFLHTMLView. Method InitGadget() fltype=FL_HELPVIEW InitWidget() flSetStyleView(flhandle,style) ' markcw EndMethod Finally, in SetURL, line 2282. A few more changes. Seems to all work now, the only thing left is storing the last topline in the history I think. To summarize, this adds default user navigation style, prints error pages and let's you start with a relative path properly. |
| ||
| Hi Mark, After applying all the patches, I get the following page when I click any of the links in the IDE: Error Unable to follow the link "C:\Program Files\BlitzMax\src\maxide/C:/Program Files/BlitzMax/docs/html/Modules/index.html" - Invalid argument. ...and some of the iamges don't display. Refreshing the page (e.g. using the 'Home' toolbar icon) seems to fix this though. |
| ||
| Ah no, it doesn't work properly on windows. :) Will fix next revision. |
| ||
| What do you mean by 'flash'? Flash to a solid colour, or flashes while the button border changes. Have you always had this happen or only recently? It started with fltk 1.3. Flash as in flicker, this stops after a minimize/restore. Edit: I notice the flicker thing doesn't happen all the time but the file menu thing does. Strange how only I get it. |
| ||
| Ok, I just added a small fix to the .cxx file for Windows to try and fix that error. It probably won't fix it anyway. I'll need to set up my Windows version of fltk first. Edit: ok I'm stuck, Seb. I can't build maxide.bmx on Windows with fltk. I have a fairly recent svn for everything and can build createhtmlview.bmx with fltk but maxide.bmx returns an "unhandled mem exception error". I have rem'd Framework maxgui.drivers and added Import maxgui.fltkmaxgui. Am I missing something? :/ |
| ||
| Edit: ok I'm stuck, Seb. I can't build maxide.bmx on Windows with fltk. I have a fairly recent svn for everything and can build createhtmlview.bmx with fltk but maxide.bmx returns an "unhandled mem exception error". I have rem'd Framework maxgui.drivers and added Import maxgui.fltkmaxgui. Am I missing something? :/ Eeeekkk... OK, update to the latest revision just in case, and remember to Rebuild All Modules (instead of just Build Modules). If you run maxide.bmx in Debug Mode, and let me know which line it crashes out on, I'll have a think. Btw, are you using the SVN version of BlitzMax too? |
| ||
| Ok, sorry for the false alarm Seb. I got it working now. I don't know what was wrong because I did rebuild all mods, so maybe it was because I didn't checkout and just copy 'n pasted my linux BlitzMax. I also tried Max 1.30 with MaxGUI svn and it wouldn't build all modules, something about win32button, but maybe that's just me breaking things again. Also, I noticed the latest threaded maxide.bmx renders truetype fonts in the editor at a smaller size and in IDE options>Editor>Background when you choose 10 pt it changes to 9 pt, this is in Windows only. Edit: actually, I'm thinking I should remove the "init with relative path" bit because the HtmlView in Windows needs a path to work and it's not hard to do that from BMax. |
| ||
| Committed! MaxIDE's HTMLView seems nice and stable now. Much better! Ermmm... I've just tried running the CreateHTMLView() example (from the MaxGUI docs) and I get a segmentation fault on the HTMLView line. How do you suggest we go about handling HTTP URLs with Fl_Help_View? Edit: Just noticed that Help - >Modules -> Events - >Hook Functions has some mis-aligned text under the first table on Linux. Are you getting the same bahaviour? Many thanks as always! |
| ||
| I've just tried running the CreateHTMLView() example (from the MaxGUI docs) and I get a segmentation fault on the HTMLView line. I don't get that in Windows or ubuntu. I assume you mean in ubuntu. I had a look and couldn't see anywhere where it might be writing to read-only memory. How do you suggest we go about handling HTTP URLs with Fl_Help_View? If the path is init with "http:" etc then use OpenURL and don't create a HTMLView, I suppose. Edit: change of plan, init with http now prints an error page with a link. ..some mis-aligned text under the first table on Linux. Are you getting the same bahaviour? Yes, that is one of the table bugs I've still to fix. Also.. I did a fresh svn in ubuntu, BMax+MaxGUI, and now when I build that it seems to create fltk 1.1 and building maxide it reports: Unable to determine BlitzMax version. Please reinstall BlitzMax to repair this problem. Was wondering if you can explain. Do you have to start by extracting BMax 1.30? |
| ||
| Also.. I did a fresh svn in ubuntu, BMax+MaxGUI, and now when I build that it seems to create fltk 1.1 and building maxide it reports: Yeah - looks like Brucey forgot to include Linux compiler directives when he sent the UTF8 Pub.FreeProcess tweaks off to Mark. I've sent Mr Sibly a fix, but until it is committed, you'll need to replace the contents of pub.mod/freeprocess.mod/freeprocess.bmx with... I don't get that in Windows or ubuntu. I assume you mean in ubuntu. I had a look and couldn't see anywhere where it might be writing to read-only memory. Strange. My Ubuntu PC was definitely crashing on the flSetView(flhandle,html) call in TFLHTMLView.SetURL() but I've just tried the example in Windows now and it seems to be working perfectly. Hmmm... I'll investigate more next time I'm in Linux. |
| ||
| Just committed: MaxGUI.FLTKMaxGUI v1.39 Release > Added hack to scale up font sizes on Windows. |
| ||
| Also, I noticed the latest threaded maxide.bmx renders truetype fonts in the editor at a smaller size and in IDE options>Editor>Background when you choose 10 pt it changes to 9 pt, this is in Windows only. I think I know what the problem is here, somewhere we have Int(FontSize(blah)). I recently discovered that Int is a straight type cast in BMax so if the value is 9.99 it becomes 9 instead of 10. The solution is to use a Round() function like the one here or just FontSize+0.5 would do. actually, I'm thinking I should remove the "init with relative path" bit because the HtmlView in Windows needs a path to work and it's not hard to do that from BMax. Okay, I'll remove this tweak so it behaves like the Windows htmlview, meaning you have to prove a full path. Yeah - looks like Brucey forgot to include Linux compiler directives when he sent the UTF8 Pub.FreeProcess tweaks off to Mark. I've sent Mr Sibly a fix, but until it is committed, you'll need to replace the contents of pub.mod/freeprocess.mod/freeprocess.bmx with... Thanks Seb. That got rid of the message when building maxide.bmx but it's still fltk 1.1 so I'll just keep working with my older version. Any news on this segmentation fault in ubuntu? |
| ||
| Hi Seb, hopefully I'm in time for MaxGUI 1.32, as this is a nice update although missing a few things I had planned so I could get it out now. All the usual files below are edited for this new update plus the help view header is changed. Changes: - removed getcwd for init with relative path, need to init with full path. - fixed format_table crash if td colspan width too thin. - added page topline position history, required changes to header/fltkgui. - added javascript:history.back/forward/go support, required changes to fltkgui. - added openurl support for user navigation style, required changes to fltkgui. fltkglue.cpp - declares void flSetView(Fl_Help_View *view, const char *html); void flSeekView(Fl_Help_View *view, const char *anchor); void flRedirectView(Fl_Help_View *view, char *url); void flSetLineView(Fl_Help_View *view, int line); // markcw int flGetLineView(Fl_Help_View *view); // markcw void flSetPathView(Fl_Help_View *view, const char *path); char *flGetPathView(Fl_Help_View *view); int flIsLinkView(Fl_Help_View *view); void flSetStyleView(Fl_Help_View *view, int flag); fltkglue.cpp - functions fltkimports.bmx - functions ' htmlview Function flSetView(view,html$z) Function flSeekView(view,anchor$z) Function flRedirectView(view,url$z) Function flSetLineView(view,line) ' markcw Function flGetLineView(view) ' markcw Function flSetPathView(view,path$z) Function flGetPathView$z(view) Function flIsLinkView(view) Function flSetStyleView(view,flag) fltkgui.bmx - TFLHTMLView |
| ||
| Ok, just in case someone reads this, MaxIDE release doesn't work with javascript links but debug does (only tested release now), I suspect this is an inline issue (reason: changed a few members to functions on a notion about d-pointers), still bug hunting.. |
| ||
Just a small update to fix this bug, which was essentially the code below. New versions of fl_help_view and header plus fltkglue.cpp.const char *flGetPathView(Fl_Help_View *view); // bug char *flGetPathView(Fl_Help_View *view); // fix |
| ||
| Thanks Mark! "You got mail!" |
| ||
| Hey Mark, Just dropping by to ask if you are still thinking of submitting your Fl_Help_View tweaks to FLTK.org. I'm sure that they'd love all the improvements you've done to it and it's in an amazing condition. It really is an amazing achievement Mark! |
| ||
| Hi Seb, thanks. I should say the same thing to you about MaxGUI. Yes, I plan to submit it when I have some css in and fixed some more bugs, like that table bug you mentioned. It also has to work with fl_help_dialog which I haven't tested yet. So I'm just suiting myself here for now. |
| ||
| Dumb question... Are the Markcw changes INTERALLY included in the current (1.32?) downloadable revision? To be honest I just found that something is present, something else not (like this one ) I would like to know *which* version of FLTK I'm running :) (of course now I messed up everything trying to copy&paste pieces of code...:P) |
| ||
| Yes. I haven't added anything since 1.32 so it should be identical to this, if you're not sure you can always download from here and then diff to see. |
| ||
| Hey Mark, Would it be possible for you to declare int handle(int event) as public in the next release so that it is possible to subclass Fl_Help_View and override like all other official widgets? I've ammended this in the version I have to allow the code to compile, but just wanted to let you know. Thanks! |
| ||
| Hey Seb, ok. I'm planning on a new revision in a month or two. |
| ||
| Hey Seb, ok. I'm planning on a new revision in a month or two. Awesomeness! |
| ||
| Found a solution for the get system colors bug, well more of a workaround but it's better than nothing I guess. http://www.fltk.org/str.php?L2270 |
| ||
| Hi Seb, pity I'm a bit late with this update but anyway hope you like how it's coming along. Merry Christmas. Changes in rev 26 - changed scope of handle() to public - added css functions: load_css(), parse_css(), get_css_value(), get_font_size() - added css properties: background-color, font-family/weight/style/size - added recognition system for css shorthand properties: font, background - fixed table without /tr breaking next row alignment - fixed table without tr not being drawn - added nearest font match to font_face() |
| ||
| Changes in rev 26 Wow - that's awesome! I just tried recompiling MaxIDE using this Fl_Help_View on Windows, but I can't notice any CSS stuff stylings. Is this affecting the help docs yet, or should I draft up a test page? I only ask in case it's a Windows only FLTK problem. I can fire up Ubuntu tomorrow, and take a deeper look then, either way. :-) pity I'm a bit late with this update And don't worry about that, I was half-expecting to have to release a MaxGUI v1.36 soon after (the even version numbers seem to be stable releases by Blitz convention). :-) |
| ||
| I'm using maxide_v134rc5_src for builds and tested it briefly on XP to check css urls worked and they did so I'm baffled. Maybe a vista/7 issue? |
| ||
| Doh - I'm stupid. I blame it on the fact that it was very early in the morning, but I forgot to 'Build Modules'. :S All I can say is "Wow!", Mark! Apart from the bevelled edges on the cells, that looks almost spot-on. I have no idea how you do it! I'm sure the FLTK team aren't gonna believe their eyes when they see this. :P P.S. Tested with MaxGUI 1.35/maxide_v135_src.zip. |
| ||
| Oh good it was just a mistake then. I just tested it on Vista and it worked fine. I plan on adding table cell spacing/padding next which should make the docs look very close to normal. Hopefully I'll get another revision out before end of january. |
| ||
| Just popped by to let you know that your Fl_Help_View appears to be working well on Mac too - the FLTK devs recently rolled out a Cocoa port of FLTK which is a lot easier to implement with BlitzMax. All the text appears to be in italics though, for some reason, although I'm guessing this an FLTK Cocoa bug as I haven't noticed this on either Windows or Linux. Is there anything I should be wary about, in releasing this with MaxGUI v1.36 shortly? |
| ||
| You got it building on Mac now? Cool. No idea why the text would be italic, I have a pretty solid system to ensure it doesn't do that, but I guess it could be a small discrepancy only on Mac or, as you say, nothing to do with Fl_help_view. Re: v1.36 release. No it should be more stable than the last revision. |
| ||
| Re: v1.36 release. No it should be more stable than the last revision Awesome - rev. 26 has been included in the MaxGUI v1.36 packages. If you have a Mac, you may like to check-out what I meant about the italics. Still can't believe how far you've brought Fl_Help_View. Amazing!!! |
| ||
| I've been busy working on a side project for the last few weeks so sorry for the delay. Yes it's definitely a bug in fl_help_view, it's never been tested on a Mac until now though so this is not really a surprise. I seem to be getting a condensed font, rather than an italic one, for the sans font which is due to it looking for helvetica and finding 'helvetica neue' before helvetica in the list. There is another more serious bug removing spaces from strings and it's also very slow to load big pages but it shouldn't be so slow on a 1.25 ghz g4 powerbook. Just thought I'd post some progress. Btw, what code editor do you use for Mac? I have the xcode ide but without a sidebar goto list thingy it's pretty awful. Oh, almost forgot. I'm getting this every time I build modules using v1.36. Should I report this as a bug? Building Modules Compiling:Fl_Help_View.cxx Archiving:fltkmaxgui.debug.macos.ppc.a libtool: file: /Applications/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/.bmx/fl_overlay_visual.cxx.debug.macos.ppc.o has no symbols libtool: file: /Applications/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/.bmx/scandir.c.debug.macos.ppc.o has no symbols libtool: file: /Applications/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/xutf8/.bmx/keysym2Ucs.c.debug.macos.ppc.o has no symbols libtool: file: /Applications/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/xutf8/.bmx/utf8Input.c.debug.macos.ppc.o has no symbols libtool: file: /Applications/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/xutf8/.bmx/utf8Utils.c.debug.macos.ppc.o has no symbols libtool: file: /Applications/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/xutf8/.bmx/utf8Wrap.c.debug.macos.ppc.o has no symbols libtool: file: /Applications/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/.bmx/Fl_x.cxx.debug.macos.ppc.o has no symbols Compiling:Fl_Help_View.cxx Archiving:fltkmaxgui.release.macos.ppc.a libtool: file: /Applications/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/.bmx/fl_overlay_visual.cxx.release.macos.ppc.o has no symbols libtool: file: /Applications/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/.bmx/scandir.c.release.macos.ppc.o has no symbols libtool: file: /Applications/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/xutf8/.bmx/keysym2Ucs.c.release.macos.ppc.o has no symbols libtool: file: /Applications/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/xutf8/.bmx/utf8Input.c.release.macos.ppc.o has no symbols libtool: file: /Applications/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/xutf8/.bmx/utf8Utils.c.release.macos.ppc.o has no symbols libtool: file: /Applications/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/xutf8/.bmx/utf8Wrap.c.release.macos.ppc.o has no symbols libtool: file: /Applications/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/.bmx/Fl_x.cxx.release.macos.ppc.o has no symbols Process complete |
| ||
| Yes it's definitely a bug in fl_help_view, it's never been tested on a Mac until now though so this is not really a surprise. I seem to be getting a condensed font, rather than an italic one, for the sans font which is due to it looking for helvetica and finding 'helvetica neue' before helvetica in the list. There is another more serious bug removing spaces from strings and it's also very slow to load big pages but it shouldn't be so slow on a 1.25 ghz g4 powerbook. Just thought I'd post some progress. Awesome! Thanks for keeping me posted. :-) Btw, what code editor do you use for Mac? I have the xcode ide but without a sidebar goto list thingy it's pretty awful. I don't do much C/C++/Objective-C programming on Mac, and that which I do do, I usually edit in the official MaxIDE (where I get away with CMD+F'ing my way around the document). I'd too be interested in any suggestions, people might have, for a light-weight Mac C/C++ code editor. Oh, almost forgot. I'm getting this every time I build modules using v1.36. Should I report this as a bug? I get the same message; they are just warnings, likely arising because the contents of those files have been pre-processor'd out. The build process completes successfully, and linking a MaxGUI app against FLTK on OS X seems to work. Even still, I had a go trying to move the imports around a bit, so if you feel like investigating, try replacing the contents of your fltkimport.bmx with: Then rebuild all mods, and let me know if the warnings disappear. Unfortunately, I don't have access to a Mac for a few months so I can't test this out myself. |
| ||
| Hi Mark, Just checked the FLTK newsgroups this morning and I noticed that they are proposing improving Fl_Help_View as a potential project for Google Summer of Code. To save duplicating work, and potentially colliding with changes in the future, you might like to consider posting your pimp'ed Fl_Help_View to the newsgroup relatively soon, in its current state. I know you wanted to wait until you've fixed a few more things, but what you've done already is AMAZING and I think they'd be blown away that you've added basic CSS support too. Hope you are well! |
| ||
| Well sorry Seb, but I just can't build Fltk 1.3 any more. :( I have tried several times in the last few months to build the Fltk source and I just don't know what's wrong. I can't even download the latest tar... What's going on there? [Edit: fixed, download host was down atop] it's only a matter of 'autoconf -o configure configure.in' but we shouldn't have to do that, should we? So then after running './configure', 'make' and 'sudo make install' I get tons of compiler errors and finally after trying 'fltk-config --compile test/hello.cxx' I get this. [Edit: removed error messages] I assumed it was a 64bit issue so recently I reverted back to ubuntu 32bit but that doesn't seem to work either. I'm just going to give up now and go back to working from within Bmx... At least that works. |
| ||
| Hey Seb, well I'm sure you'll be pleased to know I went back to my older PC that I used to build fltk from and got it working again. :) I'm pretty sure the problem is with the versions of gcc, my old PC has 4.3.2 and my laptop (which gets lots of error messages) has 4.3.3. The errors all seem to be rather pedantic and usually easily fixed. What I can't understand is if Bmx is using gcc 4.3.3 why doesn't it get these errors too? Is it on a special non-pedantic gcc setting? Anyway, I just fixed a list of these errors with fl_help_view.cxx (maxgui v141) on my old PC which I think must be fltk-1.3.x-r6649 (but I don't really know as I renamed the folder ages ago). Then I ran test/help (which tests Fl_Help_Dialog) and it worked except there were a few problems. The font is not the same and there's no css showing up which I'll definitely have to fix before I release it to fltk. The other issue is on Mac, the font finding code breaks and even worse there are no spaces between words, which I've so far narrowed down to somewhere in draw(). I think there are slight differences between intel and ppc macs which would explain why you get italics and I get bold helvetica condensed. So here is the diff of fl_help_view.cxx. This isn't a revision yet, it's just to show that I am making some progress. |
| ||
| Awesome news! Check out this link ( http://www.fltk.org/newsgroups.php?s7684+gfltk.bugs+v7690+T0 ) for my fix concerning fl_set_fonts() on Mac. I posted this months ago but they still haven't acknowledged it. *sigh* Edit: Actually, they appear to have committed it in r7681 ( http://www.fltk.org/newsgroups.php?s4883+gfltk.commit+v4900+T0 ). |
| ||
| Yes, they're a bit slow over there. I don't think they get paid enough. Thought you might be interested in this. I just built maxide and createhtmlview with fltkmaxgui on my g3 pismo and got this error. The apps just lock up and need a force quit. Now I know I have pretty much the oldest possible mac you can run Bmx on, so I know I shouldn't be dev'ing on it but I was just wondering if you could make some sense of this error? Doesn't matter if you can't, I can just use my g4 powerbook. |
| ||
| Well I managed to fix the no spaces bug on Mac. It was because fl_width() was returning 0 for single quotes but it works for double quotes ie. not chars but strings. I don't have a macbook so I can't check, but I'm assuming you don't have this no spaces bug. I also get no spaces between font names, for example: 212=TimesNewRomanPS-ItalicMT - I suspect it's a bug in my version of xcode (3.1.3). I did a make of fltk-1.3.x-r7677 on my g4, there were a few error messages but it worked. Then I ran test/fonts and the font names there also have no spaces, so this isn't an fl_help_view bug. I've decided just to parse the font names and insert spaces back in if they're missing, as the problem is too low level for me. I will also post a bug report to fltk. |
| ||
| Well I've fixed the no spaces in font names bug by editing fl_set_fonts_mac.cxx and adding spaces to names in set_fonts(). Now I see my font finding code doesn't parse the Mac font list properly as its layout is a little different, which explains why you get an italic font. Will fix it and get a revision out soon. Edit: I think the no spaces in font names is maybe not a bug but a feature. So I can't edit fl_set_fonts_mac.cxx, I've just to account for it in fl_help_view.cxx |
| ||
| Ok, revision 27 at last! These are all bug fixes. Untested on intel Mac. - fixed compiler errors to get it building with fltk-1.3.x make - fixed seemingly random fonts appearing on Mac, required changes to header - fixed font list not being read properly on PPC Mac - fixed no spaces between words on PPC Mac |
| ||
Sorry about my chronically late reply. Have taken a break from the Blitz scene recently. Anyhoo, it seems to be running perfectly on Mac OS X Intel. Nice work. :-)  There seems to be a lot of activity over at FLTK HQ (two of my fixes were committed) and they seemed to have fixed the infamous Caps Lock shortcut key bug. I guess they may be readying for a 1.3.0 release soon. Consider unleashing your pimped Fl_HelpView to them? Would definitely boost the spirits over there. :-) Last edited 2010 Last edited 2010 |
| ||
| Hey Seb, yeah I guessed you were taking a break from Maxgui. Glad the latest rev passed the 'Seb test'. I saw they fixed those bugs which is great. I do intend to release my flhelpview to the fltk team asap but CSS isn't working in flhelpdialog yet but I'll try to get it done by Christmas. Cheers. |
| ||
| Committed at MaxGUI SourceForge repo. Thanks. :-) |
| ||
| I have finally released fl_help_view to the Fltk HQ. http://www.fltk.org/str.php?L2634 Note that there is only one change in this version and it's to fix a broken css url bug for the fltk library (no effect in BMax). I also did just a bit of tidying. Last edited 2011 |
| ||
| Awesome! I've subscribed to the FLTK thread for notifications to see how it goes. Thanks for letting me know. :-) All the best! :-) |
| ||
| I was terribly slow about it I know, sorry about that, but it was better late than never I suppose. :) |
   |