BlitzMax v1.30 Linux IDE (New Test Build)
BlitzMax Forums/BlitzMax Module Tweaks/BlitzMax v1.30 Linux IDE (New Test Build)
| ||
| Hi, I think I've managed to iron out most of major bugs that were preventing MaxIDE from starting on Linux. Other improvements, include: Features > Hack to at least get some right-clicking in text-areas. > No glibc errors at startup. > New theme. > Improved toolbars so they actually respond like buttons, including tooltips and transparency. > Right-click on project folders. > Titlebarless splashscreen. > Support for bold and italics in the highlighting. > Left, Right and Centered text in statusbar like on Win32/Cocoa. > Autoindent should now work. > Fixed crash when clicking on the "Home Button" with code open. > Fixed crash when pressing F1 twice over a keyword. > Fixed inability to terminate programs from the IDE, although a few problems still remain. They've mostly come about from improvements made to the FLTK module - it's still not perfect, but its definitely getting there. Here's the Official MaxIDE built with the latest bug fixes: Official MaxIDE FLTK Build 7 NEW in Build 7! > Anti-aliased fonts! > Improved rendering of HTML. NEW in Build 6! > Fixes a few memory leaks when treeview was repopulated in MaxIDE. > Clicking the (X) on the Command Line window should now close it. > Debugger should now highlight the desired line properly. > A larger range of colors should be able to be set for highlighting. NEW in Build 5! > Benefits from markcw's most recent Help View tweaks. > New and improved treeview. > New and improved splitter. NEW in Build 4! > Fixed an undo bug. > More Windows-esque Open/Save As file requester. > Fixes missing right-mouse clicks. > A few more of markcw's HTMLView fixes. NEW in Build 3! > Fixed permanently disabled step controls in toolbar when resuming execution after a DebugStop call. > Improved layout of help pages in HTMLView (a big 'thanks' goes to markcw). > New status-bar design. NEW in Build 2! > Uses XServer color schemes to draw windows. > Requester windows should now stay on top. > Fixed crash when clicking certain images in the docs. > A few less child process spawning/termination crashes. Feedback compulsory! :-P Seb |
| ||
| Seems to work fine, just closed and opened it ten or so times. |
| ||
| Ohhhh....I can read the help for the first time on the Linux version!!!! [It lacks of some CSS stlye - I presume - but at least it's readable now) Toolbars and general GUI is decisely better than the older one. Well done. |
| ||
| A little problem. Start the IDE. Click (from the help page) on a link (what you want) - it will bring to the associated link (ie: Language Reference > Projects) Now click on the menu....if you can! I need to double click on the window title to 'refocus' the IDE and the menus are usable. |
| ||
| Just trying to get 1.30 up and running for some GTK work, and I forgot just how bad FLTK is... Talking of Help pages... looks like Seamonkey is the way forward re embedding mozilla browser... so will look into that some more too. The default Browser distro is only 11 meg or so, but comes with all the required shared objects - like what Firefox doesn't appear to any more... |
| ||
| This MaxIDE starts fine. Needed to rebuild the documentation but it seems fine. Documentation got slightly better, but there are still texts overlapping each other. Would be nice if this could be fixed. But it's better than nothing :-). Thanks. |
| ||
| Improvements with this build over 1.30 IDE, using Ubuntu 8.04. > Right-clicking on source window now retains selected text. > The white toolbar buttons are gone and they now respond to mouseovers. > The HTML window's strange alignment bug is gone. This was most noticable on the index page. Problems with this build. > Current selected tab is now not highlighted. > CSS still not loading in HTML window. |
| ||
| > Current selected tab is now not highlighted. In the old FLTK theme, the selected tab was tinted yellow, but I removed this in the build as it appeared as a solid yellow in the GTK+ theme, and looked really unsightly. The selected tab is *slightly* larger than the others. Personally, I am able to tell at a glance what is selected, but I have to admit it isn't exactly obvious. > CSS still not loading in HTML window. Unfortunately, I don't think this ever will be fixed as it is a limitation of the FLTK toolkit. The HTML renderer is a single .cxx file(!) with a rudimentary parser for text and inline images, but that's about it. It's only really designed to display basic HTML-based help files. Anything past <p>, <a> and <img>, forget it! :-( |
| ||
| Even when it's only <p>, <a> and <img> why is it that paragraphs overlap each other? Why use FLTK in the first place? Or won't you use GTK because it's Gnome specific? The selected tab color isn't much of a problem for me. My tabs in Firefox don't have different colors so it doesn't really bother me. I'm used to it. |
| ||
| Another improvement in this build. > Able to select text in HTML window and Ctrl+C it. Re: Current selected tab is now not highlighted. Yes, it does look better now, but I have to squint to see the selected tab. What about a lighter shade of grey instead of yellow? Re: CSS still not loading in HTML window. What version of FLTK does this build use? I'm not sure since there's 2 or 3 different versions. I've been looking at FL_Help_View.cxx in 1.1.9 and it looks ok apart from totally ignoring CSS. I think the file could be modified to support CSS but it wouldn't be a nice job. |
| ||
| I just purchased MaxGUI and recompiled MaxIDE with GTK+. Also tried to compile MaxIDE CE but it gave me errors. Now the FLTK version won't boot anymore (same error message) and the GTK+ version won't either. Perhaps it'll be fixed with a reboot. But I can't reboot at the moment as I'm about to leave for a few days. |
| ||
| Even when it's only <p>, <a> and <img> why is it that paragraphs overlap each other? It appears that's just the FLTK way. I haven't got a clue. I can't say I've noticed that particular problem myself, but it's still by no means perfect. One other problem I've noticed, is that the code examples in the docs are positioned to the far right of where they are supposed to be. :-/ What version of FLTK does this build use? The latest build (above) upgraded the module so that it uses a (slightly customised version) of 1.1.9. It seems 1.1.9 still has a few bugs internally which I had to fix first, before moving onto the MaxGUI wrapper. I think the file could be modified to support CSS but it wouldn't be a nice job. You're right, it could be modified but it isn't going to be easy and I don't know enough about parsing to be able to make a good crack at it. I just purchased MaxGUI and recompiled MaxIDE with GTK+. Yep, it seems that all the Linux MaxGUI drivers have something wrong with them at the moment whether it be the official FLTK or Brucey's GTK one. Have been working on fixes, and the MaxIDE posted in the top post is built using these fixes so use that as the IDE for now. Actual fixes for the FLTK MaxGUI modules should be available once we've got the IDE sorted. Obviously, we're hoping to get this addressed ASAP... |
| ||
| Its starts properly now, and the text font is now readable. |
| ||
| It did crash though when opening the MaxGUI documentation. I noticed that doc page being fairly big. Perhaps it can't handle big documents? |
| ||
| It did crash though when opening the MaxGUI documentation. I noticed that doc page being fairly big. Perhaps it can't handle big documents? Which doc page was this? You might want to try one last re-download as I sneakily uploaded a memleak fix in Fl_Help_View.cxx late last night, which *may* help. |
| ||
| Yes, it does look better now, but I have to squint to see the selected tab. What about a lighter shade of grey instead of yellow? New version now up with a slightly darker "selected" tab, and a few more free()s back where they should be. If you guys could re-download and test one more time, so that the IDE included in BlitzMax 1.30 can be replaced. |
| ||
| Thanks SebHoll. Improvements with this version over your last build. > Selected tab now highlighted darker grey. > Text in sidebar is more readable than last build which was in turn more readable than 1.30 IDE. > Improvements in last build all still work. Well I'm going to have a go at adding CSS to FL_Help_View.cxx but don't hold your breath, it should take a long time. I'll post here if I make any improvements. |
| ||
| Well I'm going to have a go at adding CSS to FL_Help_View.cxx Cool! Mr Sibs has committed the latest MaxGUI fixes to SVN so, providing you are a registered user, you can now checkout the FLTKMaxGUI module used in these builds from SVN. I would very much appreciate it if you could tweak the MaxGUI SVN version of Fl_Help_View.cxx directly as I have changed a few lines in there to fix some glibc free() errors in the 1.1.9 distribution. The SVN repository URL is in step 4 of the following guide (if you haven't checked out MaxGUI via SVN previously): MaxGUI SVN Thread Unfortunately the selected tab highlighting fix hasn't been committed yet, but everything else should have been. Good-luck! |
| ||
| I know this is a bit off-topic but are you going to report the bugs you fixed to fltk? It says in FAQ article 825 that only urgent bugs will be fixed in 1.1.9 now as they have moved on to developing 1.3. |
| ||
| It says in FAQ article 825 that only urgent bugs will be fixed in 1.1.9 now as they have moved on to developing 1.3. Yeah, I saw that. The bottom line was that I wanted to, but got so frustrated with the website and its awkwardness that I gave up. I went to all the hassle of registering, tried to make a post and it wouldn't let me submit it - it kept throwing up loads of errors. Unfortunately, I've not got the time to persevere with it, atm. The noticeboard is some sort of archaic newsgroup wrapper, I think. |
| ||
| Wouldn't it be better to port to v2 instead, if you are going to go to *all* the trouble to try to get something so broken to work? |
| ||
| Wouldn't it be better to port to v2 instead, if you are going to go to *all* the trouble to try to get something so broken to work? I know that FLTK 1.1 isn't perfect, but have you seen the list of bugs outstanding for FLTK 2 (http://www.fltk.org/str.php?L+P0+S-2+C0+I10+E0+Q2.0) (213 bugs/requests as of today)?!?!?!?! If I was going to rewrite the Linux MaxGUI driver, I'd much rather do it for a GUI API more complete/future-proof/bug-free like GTK (but someones already done that :-P). |
| ||
| Seb, I added your 2 fixes in Fl_Help_View.cxx to the bug board. Post is here. http://www.fltk.org/str.php?L2003 Hope that's ok. |
| ||
| Seb, I added your 2 fixes in Fl_Help_View.cxx to the bug board. Post is here. http://www.fltk.org/str.php?L2003+P0+S-2+C0+I160+E0+M10+Q Hope that's ok. That's great. You've saved me a job, so thanks. As I said, I wanted to report them as I like to give something back, but that website just hates me (or is it me hating the website). :-P There was another fix in Fl_Text_Display.cxx (line 1480) and Fl_read_image.cxx (lines 127-138) that addressed more puzzling crashes. The former was an if() check to make sure we weren't freeing something that wasn't there (caused random crashes most of the time), and the latter was an X-server problem I experienced on Ubuntu where the image read from the screen should be bounded by the window size as well as the screen size otherwise we crashed. I don't think that the Fl_Help_View.cxx or Fl_Text_Display.cxx would be OS specific to Linux, but the last one probably is, what with being related to XServer. All of them I would have perhaps classed as high priority as they result in fatal crashes. Cheers P.S. How's the Fl_Help_View.cxx v2 (now with CSS support) coming along? |
| ||
| Ok, I added those and reposted the Fl_Help_View.cxx fix. Posts are here. Hope that's ok now. http://www.fltk.org/str.php?L2004 http://www.fltk.org/str.php?L2005 http://www.fltk.org/str.php?L2006 The CSS code is going swimmingly well. Currently 0% is complete. :) I have got FLTK installed and am now able to build stuff. Woohoo! I am reading tutorials on FLTK, then I've to brush up on my CSS and CPP. |
| ||
| Sorry off-topic again maybe I should start a new thread... I just noticed that if you pass the standard command-line arguments to window->show then instead of the grey FLTK colors you get the Linux window colors. Fl_Window::show(int argc, char **argv) |
| ||
| Ok, I added those and reposted the Fl_Help_View.cxx fix. Thanks Mark Sorry off-topic again maybe I should start a new thread... I don't class this as off-topic, in fact its very much on-topic as it changes will lead to improvements in the IDE. Still, feel free to start a new "FLTKMaxGUI Tweaks & Enhancements" topic if you would like to. I just noticed that if you pass the standard command-line arguments to window->show then instead of the grey FLTK colors you get the Linux window colors. Fl_Window::show(int argc, char **argv) Nice find! I'll fire up my Ubuntu PC and have a look when I get a free moment. Looks like a nice and easy tweak for flShowWindow() in fltkglue.cpp and would definitely improve the overall appearence. |
| ||
| Just returned from a few days off. I redownloaded the test build but it's giving me a appstub.linux signal handler 11 error again. As of now I have no working IDE under Linux :-). Edit: New install seems to fix it. |
| ||
| Do what I do and rename MaxIDE to something else before you extract the latest one. |
| ||
| Removing the cfg folder also works :-) |
| ||
| Just got replies to those FLTK bug reports I posted. Matt just states "Should be applied to 1.3 because 1.1.9 is final" meaning they aren't updating 1.1.9 at all now. So if FLTKMaxGUI is going to be upgraded further it would need to be ported to 1.3 which is a redesigned version of 1.1.x. I have looked at 2.0 a bit and it's a very different beast, many functions and classes are not even there. I got the impression it is a games-oriented version. |
| ||
| IMHO, if BRL want a linux flavour of maxgui, they should probably adopt gtk, and we work on getting that up to speed. Or a maxgui wrapper for Brucey's wx wrapper...if there's any point... |
| ||
| The thing that worried me about FLTK 1.3 is that it's supposed to be a branch where they aren't afraid to change the API which could mean that FLTKMaxGUI could choke (even more so than it is ATM) with each release. If 1.1.9 really is the final build though, we may have to consider it. |
| ||
| Why was FLTK chosen in the first place anyway? Because of licensing or portability? The GUI's created with it are really ugly in my opinion. GTK or wx gets far better results. But this would also mean that a new driver has to be written, which will be a lot of work if I'm not mistaken. It would be nice though if the Linux GUI's created with MaxGUI would look a lot more modern. Even so, I'm long glad that MaxGUI is cross platform :-). |
| ||
| IMHO, if BRL want a linux flavour of maxgui, they should probably adopt gtk, and we work on getting that up to speed. I really wouldn't like reinventing the wheel on that front, seeing as Brucey already has a GTKMaxGUI driver (even though it is a bit broken atm). Unless Brucey is prepared to hand over the reigns (although obviously, he's put a lot of effort into it already and I don't think I would particularly want to do that if I were him), I'm not sure that MaxGUI will *officially* support GTK in the near future. Or a maxgui wrapper for Brucey's wx wrapper...if there's any point... I did have a brief look into this, but the problem is that the two APIs work completely differently. wxWidgets is very much OOP (not that that in itself is a problem) and also handles resizes completely differently to MaxGUI. It's layout system uses box/sizers as opposed to coordinates. As a result, although I started coding a wrapper, I very quickly realised that I don't have the required knowledge of wxWidgets to be able to take on something like that. I haven't coded a single app in wxWidgets as it seems alien to me, let alone a wrapper. :-( Why was FLTK chosen in the first place anyway? Why FLTK? |
| ||
| Thanks. I didn't realize that MaxGUI is already a couple of years old. |
| ||
| The thing that worried me about FLTK 1.3 is that it's supposed to be a branch where they aren't afraid to change the API which could mean that FLTKMaxGUI could choke (even more so than it is ATM) with each release. If 1.1.9 really is the final build though, we may have to consider it. Yeah, the way I understand it is 1.3 is a redesign/improvement of the underlying architecture of 1.1.x but it's not stable yet as it's only been in development for 3 months. I think a lot of the stuff in 1.3 is still near identical to 1.1.9 though, so you could use it to improve and bug-fix 1.1.9 with a bit of searching. |
| ||
| I get no code highlighting with this IDE- just white text. Is it just me or is everyone experiencing this? |
| ||
| I get no code highlighting with this IDE There is a bug that means that sometimes files aren't parsed, but this is only experienced in about 1 in every 10 files opened. If you are consistently experiencing no syntax highlighting when opening .bmx files, make sure that you have rebuilt docs (Program->Rebuild Documentation menu) from within the IDE, and then reopen MaxIDE. |
| ||
| That worked! Thanks SebHoll. |
| ||
| Another new build is up which inherits the recent FLTKMaxGUI tweaks. Same link as before (in top post). Looks slightly better than the old one, and the HTMLView is a lot more usable (thanks markcw!). |
| ||
| Hi Seb, I like how you changed the window text size to 12, looks much better. I noticed that the font is still 14 in the About window and in the 'save changes to $filename' window. So I had a little snoop and found it in fl_ask.cxx on line 57, that appears to set the font size for the body text in all the notify-type windows. |
| ||
| I like how you changed the window text size to 12, looks much better. Cheers I noticed that the font is still 14 in the About window and in the 'save changes to $filename' window. Yeah, I noticed that too, and wasn't at all sure why it wasn't using the default Widget font. Was gonna have a look at some point but you beat me to it. So I had a little snoop and found it in fl_ask.cxx on line 57, that appears to set the font size for the body text in all the notify-type windows. Got it! Probably won't commit this immediately though, but will instead wait until I can commit it with something else. Thanks! ;-) |
| ||
| Rather than just change the value in fl_ask.cxx I see you can use the function in fl_ask.H. From the function reference: fl_message_font(Fl_Font fontid, uchar size) That lets you set the font size variable in fl_ask.cxx. |
| ||
| Rather than just change the value in fl_ask.cxx I see you can use the function in fl_ask.H. From the function reference: fl_message_font(Fl_Font fontid, uchar size) That lets you set the font size variable in fl_ask.cxx. Even better! Good find Mark! |
| ||
| Another new build is up benefiting from a few more FLTKMaxGUI fixes/improvements (again, available from the first post in this thread). |
| ||
| MaxIDE FLTK Latest Build 3 is now up which fixes a crash when clicking images in the help pages, and permanently disabled step controls when resuming execution after a DebugStop. |
| ||
| SebHoll...you've made working with BlitzMax in Linux enjoyable. Thank you!! |
| ||
| Build 4 is now up with a few more tweaks and bug fixes. Enjoy! ;-) |
| ||
| There was another fix in Fl_Text_Display.cxx (line 1480) [] that addressed more puzzling crashes. [It] was an if() check to make sure we weren't freeing something that wasn't there (caused random crashes most of the time) []. Hi Seb, just to let you know that Fabien on the fltk boards has queryed this fix: http://www.fltk.org/str.php?L2005 |
| ||
| Hi Seb, just to let you know that Fabien on the fltk boards has queryed this fix: Hi Markcw, Thanks for letting me know. I'm on holiday at the moment with limited internet connectivity, but I've had a quick flick through the discussion while I'm here (I don't have my Ubuntu Desktop PC with me atm). Although it's been a while since I made that fix and can't exactly remember the precise bugs/glitches it solved, I think it fell under the "random glibc memfree errors" crashes. Looking back at it now, I can see what they are saying about the impossible positive evaluation of the if statement, however there must have been something that went wrong. There was another fix in Fl_Text_Display.cxx (line 1480) and Fl_read_image.cxx (lines 127-138) that addressed more puzzling crashes. The former was an if() check to make sure we weren't freeing something that wasn't there (caused random crashes most of the time) As I don't have access to a Linux PC while I'm away, I can't really investigate further. If you've got a spare few minutes, you might wanna remove my additional if() and see whether you are getting crashes when selecting and manipulating text (might have been something related to the resizing of textareas too but I can't honestly remember). Cheers |
| ||
| Ok, I tested it out in BMax 130 and the latest svn BMax with a printf to see if it is ever called and then tried selecting/manipulating text and resizing the textarea and there was never any prints in my tests. So I'll leave it at that. Hope you're having a nice rest anyway. :) |
| ||
| bug in build 4: when you compile in debug mode and your game crashes, the ide tells you whats wrong, but it does not select the wrong line anymore. |
| ||
| A new version is now up (build 5) and is available to download from the top post. when you compile in debug mode and your game crashes, the ide tells you whats wrong, but it does not select the wrong line anymore. I can't seem to reproduce this in the latest build, so it may well be fixed. Please confirm. |
| ||
| Debug line highlighting in build 5 working fine here. |
| ||
| Uhh.. FLTK never seemed to have syntax highlighting, for me atleast.. Still using the GTK-compiled 1.15 CE-IDE. |
| ||
| Uhh.. FLTK never seemed to have syntax highlighting, for me atleast.. That's strange... :-/ Are you still getting this with the latest version of BlitzMax (v1.30b) and build 5 of MaxIDE (downloadable from the top post in this thread). Also, in the newer versions of BltizMax, you have to explicitly do a "Rebuild All Docs" (from the Program menu) after having opened MaxIDE for the first time for the newer IDEs to highlight when restarted. |
| ||
Rebuilding modules does not work. I won't even bother using an ide if its going to be fltk, just thought I would mention a possible bug. (I have the fltk libraries installed if it makes any difference) By 1.30b do you mean SVN? If so, no. |
| ||
| Hi Plash, By 1.30b do you mean SVN? If so, no. No, if you have a look at the link on the Product Updates page, the Linux file is named v1.30b, as the original v1.30 distribution had a broken MaxIDE that wouldn't even open. Looking at your screenshot, you'll notice that although some is highlighted, everthing else is white. This is actually considered a feature of the FLTK toolkit in that it will override colors that it considers are too close to the background, in order to save your eyesight. :-P Each to their own, but I certainly couldn't use those combinataion of dark similar colors to code in. I think most will agree that they are quite similar to the black background, but I know it's a personal thing. If you deleted your ide.cfg so that it uses the default syntax highlighting colors, you will find that everything highlights perfectly. I might have a look into making it a bit more tolerable with the colour contrasts, but there appears to be little point if, to quote, you... won't even bother using an ide if its going to be fltk, Apart from your syntax highlighting problem concering the colours you have chosen, do you really think that the FLTK IDE in its current state is that bad? |
| ||
| Apart from your syntax highlighting problem concering the colours you have chosen, do you really think that the FLTK IDE in its current state is that bad? Haven't a clue, I can't use an IDE that doesn't like my favorite colors! |
| ||
| Hi Seb, I've been using latest build at work this week for some linux stuff, has been going really good. The inability to debug C++ is my only gripe, so was going to look into some sort of gdb layer if I get some down time next week, but thats another story. Anway, hats off to you and markcw! re Whay FLTK? Originally FLTK was the smallest, simplest Linux solution, and being one of those keep it simple people it won at the time. I'm kind of glad that 1.19 is frozen, it's goal of operating in a double buffered GL environment was noble, but I think ultimately flawed. I always wanted to try hoooking up Max2D for font / graphics rendering duties, it seemed like a not enormous undertaking and a sizable step to getting a pure maxgui implementation into view. Hmmm, if you focus somewhere between your nose and the screen the fonts seem to go smooth on their own so maybe not worth the bother... |
| ||
| The inability to debug C++ is my only gripe, so was going to look into some sort of gdb layer That would be amazingly useful, especially when debugging pesky FLTK crashes. At the moment, I have to go through the labourious process of splattering a load of printf statements and rebuilding modules every two minutes. If you do decide to have a play around with MaxIDE, drop me an e-mail and I'll send you the latest source. I sent a version with a few memory leaks plugged to Mark last night, but I'm not sure when he'll be committing it. Just so that we are using the same version. ;-) Hmmm, if you focus somewhere between your nose and the screen the fonts seem to go smooth on their own so maybe not worth the bother... FLTK is really starting to grow on me. Yes - it still doesn't have anywhere near as much development as GTK, but it's extremely customizable, and with the new GTK theme and the recent changes made to FLTKMaxGUI, I find myself using my Linux PC a lot more for BlitzMax. As for Max2D interfacing (I assume you mean for making in-game menus etc), I think I'll need to spend alot more time learning the ropes before I would even be able to attempt it by myself. A few weeks ago, I tried getting FLTKMaxGUI to compile on Windows (which could be a start), but the XServer and Linux specific code in fltkglue.cpp is just a bit too over my head at the moment. I only started using Linux for BlitzMax, and its the only thing I do use my Linux PC for, but I'm learning slowly (I think!!!)... |
| ||
| OK, new build is now up (build 6), which benefits from a few MaxIDE memory leak fixes, and a problem whereby the command line window wouldn't close on clicking the (X). Plash: I've tweaked FLTK so that it allows a greater range of colors. Can you retry your color scheme with the latest build and let me know how you get on? |
| ||
| Yeah it all shows up now. |
| ||
| Yeah it all shows up now. Glad to hear. ;-) Thanks for letting me know. If you do decide to have a play around with MaxIDE, drop me an e-mail and I'll send you the latest source. Mark has now committed my latest maxide.bmx so you should be able to just check it out of the BlitzMax SVN. ;-) |
| ||
| Hi Seb, just wondering. Do you know why there is no MaxIDE svn version? Wouldn't it make sense for your builds to end up in svn? |
| ||
| Do you know why there is no MaxIDE svn version? I think it's probably because it adds a level of complication because MaxIDE is stored in the root BlitzMax folder, which, as it houses the modules, is designed to be a single cross-platform repository. Adding MaxIDE for all versions to that one repository would be undesirable as it would mean Windows/Linux users would get strange ".app" folders etc. Also, unlike the MaxGUI SVN, I don't have any special privileges with the BlitzMax SVN and so it would be a lot harder for me to maintain as everything has to go through Mr Sibly. |
| ||
| Re: Fix for clip_children in Fl_Group.H This has been closed with an extra change you should be interested in Seb. http://www.fltk.org/str.php?L2017 |
| ||
| Re: Fix for clip_children in Fl_Group.H This has been closed with an extra change you should be interested in Seb. Thanks markcw! That's great news! I noticed that they've committed a few of the other fix too. Btw, I think I remember that we posted a fix to Fl_Read_Image a while back, but I later found out that although it fixed a few cases, there were still occasions where it would crash. As such, a more permanent solution is to catch the error, and resort to the alternative method if it fails for any reason. I can't remember exactly which lines were changed, but if you have a look at fl_read_image.cxx you should be able to find it. I did comment a few of the changes, but others I just edited silently, so it may be best to DIFF revision 68 with the original 1.1.9 file to find out exactly what was changed. I deemed this a critical bug fix so it could really do with being fixed. Are you going to be submitting your Fl_Help_View over-haul to FLTK.org or are you waiting for a specific milestone? |
| ||
| I think I already found all your uncommented changes in fl_read_image.cxx, incidentally this has just been closed today. http://www.fltk.org/str.php?L2021 Here are all the changes I could find. // line 80 // Used to catch (and ignore) any exceptions when calling XGetImage static int xgetimageerrhandler(Display *display, XErrorEvent *error) {return 0;} // line 130 int dx, dy, sx, sy, sw, sh, ww, wh; //Seb was here // line 134 //Seb was here XTranslateCoordinates(fl_display, fl_window, RootWindow(fl_display, fl_screen), win->w(), win->h(), &ww, &wh, &child_win); //Seb gone XTranslateCoordinates(fl_display, fl_window, RootWindow(fl_display, fl_screen), X, Y, &dx, &dy, &child_win); // screen dimensions Fl::screen_xywh(sx, sy, sw, sh, fl_screen); if (ww < sw) sw = --ww; if (wh < sh) sh = --wh; // line 144 // the image is fully contained in the window, so we can try the traditional method, // however, if the window is obscured etc. the function will still fail. Make sure we // catch the error and continue, otherwise an exception will be thrown. XErrorHandler old_handler = XSetErrorHandler(xgetimageerrhandler); image = XGetImage(fl_display, fl_window, X, Y, w, h, AllPlanes, ZPixmap); XSetErrorHandler(old_handler); } if (!image){ I'm going to wait until I have fixed all the bugs I can find and added new stuff like CSS before I submit my changes to Fl_Help_View. |
| ||
| I think I already found all your uncommented changes in fl_read_image.cxx, incidentally this has just been closed today. Yep! That's the one - thanks once again! ;-) I think that means we might be able to return to using an un-edited version of FLTK, or perhaps even migrate to 1.3, at some point. |
| ||
| Some of my fixes seem to have gone? I possibly wiped them out myself before the move to new repos. I can only find my name attached to the one text leading tweek. *Fl_Bitmap::copy is more broken than ever for stride based bitmap windows, and the fact it was reported and never fixed led me to have lower opinion of fltk developer, not that i claim to be more cleverer in any way but I'm pretty sure my patch is MIA. Will look into it. |
| ||
| Hi Simon, that would be a pity if we have lost your fixes. Maybe you have a backup? I checked the svn version of Fl_Text_Display.cxx and they haven't added your tweek on line 387, I suppose it needs an explanation. mMaxsize+=2; //simon was here Seb, how do you use diff? I'm lost in all the options. |
| ||
| Some of my fixes seem to have gone? I possibly wiped them out myself before the move to new repos. They may well have been lost in the move to FLTK 1.1.9, although I was especially careful that I diffed each file with the original to see if you had made any changes, and attempted to copy them over to the FLTK 1.1.9 ones. What exactly is this bitmap bug that you are experiencing? Seb, how do you use diff? I'm lost in all the options. Are you using RapidSVN on Linux or the command-line for checking stuff out? If it's the latter, then I really would recommend that you give RapidSVN a go as as it improves the usability of SVN enormously. RapidSVN (*click*) allows you to specify the path of any DIFF viewer (have a look in your distro's universal repository if you don't already have one) which comes in really useful when comparing revisions or the your working copy with the latest version on SVN. |
| ||
| I'm using RapidSVN but I was trying the command-line diff which had me confused. I have Meld Diff Viewer and have just tried it out, it's cool. I feel like a boy with a new toy, hehe. Thanks. |
| ||
| I have Meld Diff Viewer I feel like a boy with a new toy, hehe. Thanks. Yeah, I think that's the one I use on my Linux PC. It's not quite as nice as WinMerge & TortoiseSVN on Windows, but its not bad. ;-) I think it was as simple as typing 'meld' (no-quotes) into RapidSVN's diff tool textfield, and hitting 'OK'. |
| ||
Uhm... |
| ||
| Hey Seb, link targets (ones on the same page) aren't stored in the IDE browser history. I've had a look at maxide.bmx but it's confusing for me so could you shed any light on this. |
| ||
| I'm not sure I've understood you properly, but if by "IDE browser history" you mean the forward/backward buttons on the toolbar, then all that these buttons do is simply call HTMLViewForward() and HTMLViewBack() respectively on the HTMLView gadget. It's therefore up the MaxGUI implementation as to whether it should jump to the last page visited, or the last bookmark. In short, the MaxIDE source itself doesn't keep track of the URLs that have been visited. Also, on Windows, pressing 'Back' when two bookmarks have been visited on the same page still causes the HTMLView to navigate to the last HTML file, as opposed to the previous bookmark. |
| ||
| Yes, by IDE browser history I mean the forward/back buttons. The way FLTK handles this is in Fl_Help_Dialog rather than Fl_Help_View, where it uses char file_[100][256] for the filenames. So it is left up to the app rather than Fl_Help_View to manage the file history. Unfortunately, I am a BMax newbie and can't follow what's going on in there. |
| ||
| Oh yeah, while I'm bothering you Seb... What do you think about setting the statusbar text to a filepath when hovering over a link in the help window. Not really essential but it would be a nice touch. |
| ||
| Re: Fix for XTranslateCoordinates in fl_read_image.cxx http://www.fltk.org/str.php?L2006 |
| ||
| Hi Mark, Thanks for letting me know... I should have mentioned that that patch is now obselete after matt committed the more water-tight error handling patch here: STR #2021: Fix for XGetImage error in fl_read_image.cxx Btw, I've only just noticed your post concerning the status-bar text. What do you think about setting the statusbar text to a filepath when hovering over a link in the help window. Not really essential but it would be a nice touch. Nice idea, but in order to do this we would have to introduce new MaxGUI events and tweak all of the HTMLView implementations so that we know when the user is hovering over a link. It could well end-up being quite a big job... :-( |
| ||
| Ok, I posted a follow up to: Fix for XTranslateCoordinates in fl_read_image.cxx. In Fl_Help_View there is a private function, find_link, which can be wrapped by a new public function to get the link under the mouse. I'll do this at some point anyway. That was just a suggestion if you were interested, if not no problem. Also, I'm going to try modifying link targets in Fl_Help_View soon to see if I can get them recorded in history. |
| ||
| Ok, I posted a follow up to: Fix for XTranslateCoordinates in fl_read_image.cxx. In Fl_Help_View there is a private function, find_link, which can be wrapped by a new public function to get the link under the mouse. I'll do this at some point anyway. OK, thanks. Also, I'm going to try modifying link targets in Fl_Help_View soon to see if I can get them recorded in history. Cool - might it be better to do this in fltkgui.bmx? I can add it to my to do list when I eventually get the time to start working on MaxGUI again... |
| ||
| I'm kind of confused about this. Is this IDE the offical IDE for linux Blitzmax? Is the source available? |
| ||
| Is this IDE the offical IDE for linux Blitzmax? Yes - this was the official MaxIDE for BlitzMax v1.30. The latest source for MaxIDE is provided in the "Product Updates" page, if you want to have a look... You will need to be a MaxGUI license holder, though. However, the Linux BlitzMax v1.32 package which was just released has an even newer version of MaxIDE included, so this topic is somewhat rendundant now. Please download BlitzMax v1.32 instead which includes the latest MaxIDE currently available. |
   |