gtkwebmozilla and firefox3
BlitzMax Forums/Brucey's Modules/gtkwebmozilla and firefox3
| ||
| Building maxide (ce) with gtk in ubuntu hardy yields: /usr/bin/ld: cannot find -lgtkembedmoz Edit: gtkwebmozilla needs libxul0d-dbg (and gtkwebgtkhtml needs libgtkhtml3.8-dev) Is there an updated svn version of bah.gtk? I'm lost. Edit: bah svn Edit: building gtkmaxgui without first installing libgtk2.0-dev yields: /usr/bin/ld: cannot find -lglib-2.0 |
| ||
| I believe xulrunner has libgtkembedmoz.so. When I get home I'll have a look on my Linux box for my settings - I think it's xulrunner I'm using for the library. |
| ||
| maxide ce & gtk & ubuntu have disagreed with each other for some time - certainly on my PC, although I believe others have had luck, and code I found to isolate the problem (segfaults), only did so occassionally, and didn't reproduce same on other people's setups! So, be warned! |
| ||
| maxide ce & gtk Last time I tried the CE ide with gtk I had problems too. At the moment I use the default ide with gtk, which works well enough. |
| ||
| I found libgtkembedmoz.so for xulrunner in http://packages.ubuntu.com/hardy/libxul0d So I installed libxul0d-dbg http://packages.ubuntu.com/hardy/libxul0d-dbg Then linked to the lib with: sudo ldconfig /usr/lib/xulrunner (Edit: may not be necessary) Now I can run maxide ce gtk (1.15) but there is no html display it's just grey. |
| ||
| Building maxide (ce) with gtk Traitor!!!! :P Brucey! Stop stealing my FLTK companion... :P |
| ||
| Yes only one step left and finally I will be free from FLTK.. muhahaha I tried installing xulrunner-1.9-dev http://packages.ubuntu.com/hardy/xulrunner-1.9-dev But the html display is still grey and a search yields only one libgtkembedmoz.so in /usr So I'm stumped again, I'll wait for Brucey. |
| ||
| Last time I tried the CE ide with gtk I had problems too. At the moment I use the default ide with gtk, which works well enough. Last time I looked, I decided it was a weird comination of treeviews and createprocess that was causing the problem. I think if you disable the code that shows the treeview AND avoided any calls to createprocess (i.e. when it calls in bcc in startup), then it worked! By favourite bet was a weird conflict between gtk & createprocess & the change to a tick-less kernel in linux...and at one point had some code that reproduced it for me...but not others... I haven;t tried it since the 1.32 version, and there were some linux fixes around createprocess and timers... |
| ||
| mark - it would be as well you first make sure the default ide compiles okay with gtk, as we know that definitely used to work. I guess 1.32, newer gtk / linux may have caused issue to break even that, but lets hope not... |
| ||
No. I still get this message when I build maxide brl gtk:/usr/bin/ld: cannot find -lgtkembedmoz collect2: ld returned 1 exit status Which is odd as I thought 'sudo ldconfig /usr/lib/xulrunner' would have solved that. Perhaps that's a runtime link and I need a build link? |
| ||
| you can always add the path to /etc/ld.so.conf |
| ||
Refering to this, ld.so.cache yields:~$ ldconfig -p 781 libs found in cache `/etc/ld.so.cache' .. libgtkembedmoz.so.0d (libc6) => /usr/lib/libgtkembedmoz.so.0d libgtkembedmoz.so (libc6) => /usr/lib/xulrunner/libgtkembedmoz.so .. |
| ||
| Sorry, I don't know how to add that path. I followed this thread and updated to the latest gtkmaxgui in bah svn. Now I can build maxide brl gtk and see the helpview but it's horribly slow; maxide ce gtk won't build (segmentation fault) and createhtmlview gtk just shows up grey. :/ Note: the original subject of this thread ends here. |
| ||
| maxide ce gtk won't build (segmentation fault) That'd be the problem I kept hitting, although it sounds like there might be a few other gtk issues - aren't there 2 gtk htmlviews, one plain gtk one imported as default, and another that you can specifically import? In terms of the CE segfault, see above for where I'd got to pinning it down (not far!). I had rather hoped the 1.32 timer & createprocess changes would have at least helped, if not fixed the problems I saw. |
| ||
Yes, I can build maxide brl with both gtkwebmozilla or gtkwebgtkhtml but can build neither with maxide ce and get the error as below.(<unknown>:7210): Gtk-CRITICAL **: gtk_tree_store_set_value: assertion `VALID_ITER (iter, tree_store)' failed DebugLog:AddPanel:Enter DebugLog:AddPanel:Exit (<unknown>:7210): Gtk-CRITICAL **: gtk_tree_store_set_value: assertion `VALID_ITER (iter, tree_store)' failed (<unknown>:7210): Gtk-CRITICAL **: gtk_tree_store_remove: assertion `VALID_ITER (iter, tree_store)' failed Segmentation fault I also get a message in debug mode. Unhandled Exception:Attempt to access field or method of Null object the jumped line 1365 in maxide.bmx being this. helppanel.SyncDocs(bmxpath) Not that this makes much sense to me. |
| ||
| Please wait... building.... everything (yaaaawwwn... just updated everything to 1.32 - takes a wee while to build all my modules) I'll take a look once I get up and running. Should I get the CE from download or out of SVN? <EDIT> This is where my idea for having a multi-process bmk would come in handy - what's the point in having 4 cores if the compile only uses one of them... :-p |
| ||
| I can build maxide brl with both gtkwebmozilla or gtkwebgtkhtml Is that "can build, but then have issues like grey screens" as implied earlier, or "can build and it works, it's only shagged in the CE version" ? VALID_ITER Yup, that rings bells: if I remember correctly, the VALID_ITER error relates to accessing a treeview node that no longer exists. On all other platforms (i.e. macos, win32, fltk), this fails silently, but gtk gets rather stressed - in many ways rightly so. The issue is almost certainly down to the dodgy method of creating & updating the treeview nodes in the IDE : this code is suspect but "clean" in the brl cversion in that it never calls non-existent nodes ; in the CE version it is in theory better / tidier code, but appears to leave duff entries lying around for gtk to trip over. The weird thing was that when trying to pin it down I could never a) detect a null treeview node before gtk barfed on such a null node, despite adding checks, b) find any null nodes if I added to code to search for them at given points in the code, or c) reliably recreate it outside of the CE code! So I never managed to conclude if it was my dodgy code causing the issue, or something else...and it only occurred on linux/gtk, which is not my main platform... Am now re-building an 8.10 VM to take a look myself (upgrading from 8.04 barfed bigtime for some reason). Should I get the CE from download or out of SVN? SVN would be best. |
| ||
| Yeah, I need to add more checks so that you can't do things you shouldn't. Or perhaps better would be to add assertions? Maybe encourage people to clean up their code? ;-) ... I'm running 9.04 (well... whatever version it thinks it currently is - at this point, there are large numbers of new packages to update every week- but at least it is working as well as it was before I did the upgrade from 8.10) |
| ||
| Yeah, I need to add more checks so that you can't do things you shouldn't. Or perhaps better would be to add assertions? Maybe encourage people to clean up their code? ;-) Indeed, although whenever I tried to pin the thing down, it eluded me... One suspicion was that Blitz still has a valid reference to the treenode Blitz object, but has already told gtk to detach it from any other treenodes. If Blitz then thinks it has a valid node, and tells gtk to update it, gtk might be getting annoyed by that? Also, I seem to recall the code assumes it can create a node, deatch it from one treenode and re-attach to another treenode...now if gtk is assuming that once detached it is detahced, then that could well cause this behaviour ...(thinking out loud here, without code in front of me or any real logic behind it) Damn, it's a long time since I looked at this! |
| ||
Heh... now this is funny :brucey@asusC2Q:~/programming/BlitzMax/src/maxide_src$ ./maxide.debug ./maxide.debug: no input files given usage: ./maxide.debug [options] [filenames]. Available options are: - process stdin -l list -o name output to file 'name' (default is "luac.out") -p parse only -s strip debug information -v show version information -- stop handling options brucey@asusC2Q:~/programming/BlitzMax/src/maxide_src$ brucey@asusC2Q:~/programming/BlitzMax/src/maxide_src$ ./maxide.debug -v Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio Um.... |
| ||
| Someone should tell Mr Sibly that the Lua module is building incorrectly... tsk tsk. |
| ||
| Is that "can build, but then have issues like grey screens" as implied earlier, or "can build and it works, it's only shagged in the CE version" ? The latter. maxide brl loads as expected but everything runs at a snails pace, even if there's nothing else running. I'm wondering if it's due to too many imported modules. Createhtmlview is a grey screen, really odd as the code is basically as simple as it gets. |
| ||
| everything runs at a snails pace I'm currently looking into this... ... oooh, at least the process (killed) stuff looks better now :-p Anyway... There's a timer running in the IDE CreateTimer(15). this is what is slowing it down. Notch it up to 60, and it runs as expected. It seems as though this timer drives the update speed of the IDE. It certainly slows down the GTK updating. On delving deeper, perhaps it's to do with the timer itself. On linux it appears to create a thread, which sleeps until it thinks it is time to "tick"... I wonder if that is the problem. either that, or it's because the maxgui event system has changed.... |
| ||
| I've committed a fix which gets things running at normal speed now. Looks like some fundamental things have changed under-the-hood between 1.30 and 1.32... |
| ||
This example works for me :
' createhtmlview.bmx
Strict
Framework BaH.gtkmaxgui
Import BaH.gtkwebmozilla
Local window:TGadget
Local htmlview:TGadget
window=CreateWindow("My Window",30,20,600,440,,15|WINDOW_ACCEPTFILES)
htmlview=CreateHTMLView(0,0,ClientWidth(window),ClientHeight(window),window)',HTMLVIEW_NONAVIGATE)
SetGadgetLayout htmlview,1,1,1,1
HtmlViewGo htmlview,"http://blitzmax.com/"
While WaitEvent()
Print CurrentEvent.ToString()
Select EventID()
Case EVENT_WINDOWCLOSE
End
End Select
Wend
|
| ||
| Yep, just to confirm that both those worked ie. changing CreateTimer(15) in maxide and the fix in bah.gtkmaxgui stopped maxide brl from running like treacle. Fast work Brucey. This example works for me : Oh.. it works here too, after adding Import brl.eventqueue. The exact same code that was a grey screen now loads as expected so it must have been the timer delay. |
| ||
| oh... you can put CreateTimer(15) back in, it seems... |
| ||
| Well, maxide brl is working great (except the F1 key for some reason). Anyway, could I redistribute this build now? The maxide code was made PD so I don't see how there would be any restrictions. |
| ||
| There are issues with hotkeys... I'm working on a fix. PD? So it is... who'd have thought it. And in 2006, no less... |
| ||
| Nice one Brucey - I've just got my Ubuntu VM up and running, will probably take another look at the old ce ide code with this in next few days (imminent new baby arrival allowing!). |
| ||
| Hokay... hotkey/menu support is working again - sometimes I surprise even myself, as it all appears to work first time. (I had a look at the wxWidgets source to see what functions it was calling... seems my original direction when I moved to using the "gtk accel" functionality, was wrong... so I'm now calling a different set of functions which seem to do the job - and much simpler too!) I still see a couple of issues which are new to 1.32... 1) The output window doesn't refresh... but if you click on it, it will. 2) If there is an error, the error window isn't shown, and the tab isn't changed to show the correct page - however, if you click on a tab, it flicks to the correct tab, and shows the error window. Time for bed though... so these will have to wait until tomorrow evening... ... once I sort those I can take a look at the CE IDE... (getting to it... albeit a tad slowly). btw... I realise I'm a bit slow with updates to these things, but if you push enough I will get onto them - as you see today :-p (I get distracted very easily... take my latest module as an example (bah.gdal)) |
| ||
| seems my original direction when I moved to using the "gtk accel" functionality, was wrong... so I'm now calling a different set of functions which seem to do the job - and much simpler too!) Now that sounds good - there was a limitation with the old GTK ACCEL stuff that caused a whole bunch of GTK "WARN" messages in CE IDE - you couldn't change hotkey associations on the fly, which the CE IDE allows and does on startup. So more good news there already in terms of getting CE IDE & GTK on speaking terms once more. ;-) I've now d/l'ed everything (including all your modules as well as ce ide) and in process of building modules in my shiny new ubuntu vm. A few things didn't compile so I just deleted them (libssh2, libcurl, raptor) rather than investigate, probably just a missing dependency on dev libs on my side. We'll see where we get to tomorrow...g'night... |
| ||
| The good news - I can get maxide ce to build now. The bad news - I just rem'd a line or two out so it's still buggy. Line 1365 - I noticed SyncDocs() doesn't have a parameter and calls itself, well it looks wrong. Method SyncDocs() 'helppanel.SyncDocs(bmxpath) ' <- attempt to access null quickhelp = TBMXQuickHelp.Create(bmxpath+"/docs/html/Modules/commands.txt") helppanel.Home End Method Line 319 - in debug mode the build hangs on exiting and another null object message appears. It doesn't hang in release mode. Method CloseAll:Int(warning$="")'dontask:Int) 'returns true if successful Local panel:TGUIPanel Local mypanels:TGUIPanel[] Local cancel:Int, count:Int For panel=EachIn panels If TCodePanel(panel) Then count :+ 1 Next If count=0 Then warning$ = "" If (warning$ = "") Or Confirm(warning$) Then mypanels=panels For panel=EachIn mypanels 'If panel.invoke(TOOLCLOSE) cancel=True ' <- attempt to access null Next Return Not cancel EndIf End Method |
| ||
| Nice one - at work today, will check it out later / over the weekend. BTW, my general opinion on all this stuff is that linux (and in particular gtk) is more fussy about things being done "right", and as such highlights pre-existing issues with code that simply don't show up on other platforms. |
| ||
| linux (and in particular gtk) is more fussy about things being done "right" Or that my code sucks :-) |
| ||
| Or that my code sucks :-) Not so much as maxide CE! (But I'll blame that on being largely lazy and tweaking existing code - I've tried to clean it up and structure it, honest!) |
| ||
| Brucey - scanning through this old thread was kind of interesting, you may want to check it out if you're in gtk mode again as I think some of the latter "issues" raised may not have all got addressed back then. (maybe, but haven;t checked yet!) http://www.blitzmax.com/Community/posts.php?topic=76522 For example, see my reporting the problem with broken hotkeys (sounds like fixed now), and also my comments about gtk_main_iteration_do and writing a simulated wait - I believe your tweak to avoid the timer issue is along these lines! Also suggestion to add an assert if iter=null to highlight the treeview problem. Will fire up Ubuntu later tonight and play... |
| ||
| Also suggestion to add an assert... Yes, I'm thinking we could do with a few of those dotted around the code :-) |
| ||
| Okay, I'm finally up and running, and I now get exact same results as markcw. Burrowing into the gtk code, it looks like the cause of the specific error in gtk is that when freeing a treenode, a call is attempted to tell the parent of that free'd node to refreshchildpaths. I think a check that the node actually *has* a parent helps here - this ensures you can free the treenode *after* you detach it from a parent treenode (which appears to work on other platforms, and I *think* is a valid thing to do!). Unfortunately, applying this fix doesn't really "sort" the first issue in mark's post : uncommenting syncdocs then generates LOTS of ITER warnings on remove, highlighting a problem in CE IDE code. Maxide CE eventually loads and seems happy, but all those ITERs in the debuglog make it dog slow. This is the one that could do with an assert or error being raised in blitzmax to trap that I am doing something stupid. And mark, that's not a call to itself, but to the syncdocs in THelpPanel. Having said that, the help panel is populated if you comment it out, so it *is* a duplicate of something else, so need to check this through to remove the duplication. BTW, maxide ce looks good in gtk with all those icons on menus, tabs, etc! Works a treat Brucey! |
| ||
| It'd be even better if it didn't crash :-p I'm currently working through some of Seb's old list of issues - which are still outstanding... Just to get *my* IDE running properly. Actually, I'll go and download the CE IDE now, and see how bad things really are ;-) |
| ||
| And mark, that's not a call to itself, but to the syncdocs in THelpPanel Yes, sorry I see that now. I have narrowed it down a bit, I can comment line 561 in datanodes.bmx and it still builds which draws attention to a bug note there which may be related. Method Refresh() For Local i:Int=0 To _views.length-1 'RefreshView i Next End Method |
| ||
| Okay, here's my thinking before I head for bed: There are two issues that CE IDE doesn't like about Brucey's GTK implementation. 1) If you try to Free a treeview node that you've already Free'd, then it generates warnings all over. I think the reason why the code is free-ing things already free'd is that I went through a paranoid phase plugging every possible memory leak, possibly over-zealously free-ing things at every turn. However, I don't think it is unreasonable for a BlitzMax coder to do this, and to expect a subsequent attempt to Free something already Free'd should just silently ignore it. This would also match behaviour on all other platforms. Therefore I propose Brucey changes Free() in gtkgadget.bmx so that it checks both myIter and parent before calling each of the two GTK methods in the "Else" block. 2) After fixing the above, CE IDE is left with a handful of GTK warnings about gtk_tree_store_set_value. I believe this is CE IDE code wrongly attempting to update the text of a non-existent node. Not quite so sure what should happen here: I think ideally maxgui should assert this out on all platforms, but unsure if it would be possible something can be done at top level maxgui for all platforms. At the very least, I suggest Brucey adds an assert to populatelistRow in gtkgadget.bmx if iter is null. I then need to track down the handful of dodgy updates to treeview nodes in CE IDE code, and we're sorted...adding the Assert myself points in a very clear direction, so should (hopefully) be easy to pin down now... G'night! |
| ||
| You both posted as I typed the above - hopefully the tweaks I suggest above make sense to you Brucey and I'll sync tomorrow and we'll all see some wood for the trees. ;-) Actually, I'll go and download the CE IDE now, and see how bad things really are ;-) Really nothing like they were! If you add the first of the two tweaks above, it'll startup fine (I haven't dared test further!). If you add the second, then you'll see the "area" of code that is causing issue which I now need to debug further. (And thanks mark, suspect once I dig around I'll either nail it quickly, or hit age-old issue with the treeview code that I need to find a workaround for - one for tomorrow!) |
| ||
Well you seem to have the 'not building' bug solved Mark, but I might as well mention I can comment just line 607 in RefreshView in datanodes.bmx and it still builds, so definitely a problem with treeviews.?Not macos If v._node FreeGadget v._node 'v._node = InsertTreeViewNode(_getindex() , _name , parent_view._node) ? Edit: from debugging it seems this line is being called twice instead of once. |
| ||
| I believe the CE GUI is using the rootnode incorrectly.... As far as I can tell, the rootnode is an invisible node which is only there to attach real nodes to : It's not for displaying stuff... at least as far as the docs imply. This is how I've implemented it on GTK. This is how it is used on Max IDE. |
| ||
| Okay... I've got it starting up fine now. As Mark T suggests, the two problem areas are in Free() and with ModifyNode() (which calls populateListRow()). For ModifyNode(), I don't think it should call that on the rootNode... but anyway... if I add in a check for rootnode, and do nothing if it is, then that seems to solve the problem - well... it makes the problem go away ;-) So, I don't think it needs an assertion raising there. The Free() problem is a real problem, I think - with the CE IDE. It's obvious, as markcw notes, that it is being called twice. Ideally, we have an Assert here, but I think for now I'll just to a dirty myIter test, and skip it if Null... But I want an Assert in there eventually. So, what's going on in the IDE. I'm getting some accel warnings, which I'll take a look at in the morning. If I open a .bmx, the menus don't seem to be enabling (nor the context menu). They are all there - but disabled. Seems it doesn't realise we are editing a bmx file - or something. I'll commit these latest changes for now.... Looking better :-) |
| ||
| Removed all the accel key warnings... now does some more checks. Seems to be able to add/remove hotkeys as required now. |
| ||
| Nice one, and I'll go check the root node issue later. Not sure what the menu issue is, but presumably this doesn't happen on other platforms so presumably must be another "not doing it the way gtk likes" or "not doing it the right way full-stop like root nodes" issue... |
| ||
| Or that my code sucks :-) :-p |
| ||
| I'm sure that comment will apply to one of the two of us! ;-) |
| ||
| Quick play this morning and a few things in CE IDE with GTK: - in debug mode, on win32 & fltk, but not GTK, my memory monitor code shows a little window that shows memory usage - see util/memchecktool.bmx for includeable code that relates. - As Brucey says, the menus don't enable in GTK, but I have checked and they definitely do on win32 and fltk, so clearly gtk specific. See EnableToolMenus in TBMXHost - pretty sure this just works off a list of stored references to the menuitem gadgets in TLists, then runs through them and calls enable/disablemenu... |
| ||
After Brucey's latest changes, maxide ce builds as expected in release but not in debug. The debugger jumps to line 259 in datanodes.bmx but no error prompt appears, it just seems to stop somewhere.Method Hide() If _node FreeGadget _node ' <- _state = NODEVIEW_HIDESTATE End Method Also, hotkeys are working (only tested f1/f3) and are shown in menus with maxide brl. |
| ||
| mark - things seem fine in maxide ce in debug mode for me with Brucey's latest mods and current svn version of maxide ce. Is there something in particular you did that caused the above error to occur? How did you test f1/f3? These keys don't work for me, I think because the "editor" type menu items don't get enabled for me (or Brucey). The other keys (Ctrl+N, etc in File) all seem okay, so I presume the hotkeys are fine, it's just menus causing that problem for me. Are the "edit" menus enabled for you when you open a bmx file? |
| ||
| *sigh*... I've spent ALLLLLL day trying to get the Tabber to work "properly".... and it almost works... but not quite (you know when you *almost* get something working, but there's just that one tiny little niggle? And you try it a different way, and there's another tiny niggle?..... ), so I think I may as well leave it as is, even though it's not really using the GtkNotebook pages... :-( What a fun day for me... |
| ||
| mark - things seem fine in maxide ce in debug mode for me Doh! Just checked out a new version of maxide ce which has fixed the 'not built in debug' issue. It's all dandy now. Must have been something I did to the code. Edit: yeah, I had removed line 260 in datanodes.bmx ie. Method Hide() If _node Then FreeGadget _node '_node = Null ' <- _state = NODEVIEW_HIDESTATE End Method How did you test f1/f3? These keys don't work for me.. I tested the hotkeys only in the default/brl maxide. |
| ||
| I've spent ALLLLLL day trying to get the Tabber to work "properly".... and it almost works... but not quite (you know when you *almost* get something working, but there's just that one tiny little niggle? And you try it a different way, and there's another tiny niggle?..... ), so I think I may as well leave it as is, even though it's not really using the GtkNotebook pages... :-( Ouch - I hate that feeling. What's up with the Tabber? I tested the hotkeys only in the default/brl maxide. Ah, makes sense now! |
| ||
Interesting debug output. I have two sources open. One .m, and one .bmx. Selecting the .bmx results in this :DebugLog:EnableToolMenus : 0 : 1 DebugLog:EnableToolMenus : 1 : 1 DebugLog:EnableToolMenus : 2 : 0 DebugLog:Disabling menu... DebugLog:MenuItem SetEnabled () : 0 DebugLog:Disabling menu... DebugLog:MenuItem SetEnabled (Cu_t) : 0 DebugLog:Disabling menu... DebugLog:MenuItem SetEnabled (_Copy) : 0 DebugLog:Disabling menu... DebugLog:MenuItem SetEnabled (Block Indent) : 0 DebugLog:Disabling menu... DebugLog:MenuItem SetEnabled (Block Outdent) : 0 DebugLog:Disabling menu... DebugLog:MenuItem SetEnabled (Block Comment) : 0 DebugLog:Disabling menu... DebugLog:MenuItem SetEnabled (Block Uncomment) : 0 DebugLog:Disabling menu x... DebugLog:MenuItem SetEnabled (Cu_t) : 0 DebugLog:Disabling menu x... DebugLog:MenuItem SetEnabled (_Copy) : 0 DebugLog:Disabling menu x... DebugLog:MenuItem SetEnabled (Block Indent) : 0 DebugLog:Disabling menu x... DebugLog:MenuItem SetEnabled (Block Outdent) : 0 DebugLog:Disabling menu x... DebugLog:MenuItem SetEnabled (Block Comment) : 0 DebugLog:Disabling menu x... DebugLog:MenuItem SetEnabled (Block Uncomment) : 0 DebugLog:Disabling menu x... DebugLog:MenuItem SetEnabled (Cu_t) : 0 DebugLog:Disabling menu x... DebugLog:MenuItem SetEnabled (_Copy) : 0 DebugLog:Disabling menu x... DebugLog:MenuItem SetEnabled (Block Indent) : 0 DebugLog:Disabling menu x... DebugLog:MenuItem SetEnabled (Block Outdent) : 0 DebugLog:Disabling menu x... DebugLog:MenuItem SetEnabled (Block Comment) : 0 DebugLog:Disabling menu x... DebugLog:MenuItem SetEnabled (Block Uncomment) : 0 DebugLog:EnableToolMenus : 3 : 1 DebugLog:EnableToolMenus : 4 : 0 DebugLog:Disabling menu... DebugLog:MenuItem SetEnabled () : 0 DebugLog:Disabling menu... DebugLog:MenuItem SetEnabled (_Step) : 0 DebugLog:Disabling menu... DebugLog:MenuItem SetEnabled (Step _In) : 0 DebugLog:Disabling menu... DebugLog:MenuItem SetEnabled (Step _Out) : 0 DebugLog:Disabling menu... DebugLog:MenuItem SetEnabled (_Halt) : 0 For EnableToolMenus.... first digit is the menu number, second is the on/off flag. "MenuItem SetEnabled" is the actual call in the GUI module... digit is the on/off flag. For some menus it doesn't appear to see any children? For the others, it doesn't want to enable anything? <EDIT> just to make things clearer : |
| ||
| What's up with the Tabber? The current implementation doesn't actually use the tab panels. The panels themselves are only a couple of pixels high (see the small bar under the tabs). It's a bit of a cheat, but unless you know what you're looking for, it's not too obvious. My attempt today was to try to use the panels properly. It almost worked... The main issue is that you need to shift a panel around with the current tab for MaxGUI, since it doesn't know the concept of separate panels - with MaxGUI you just show/hide the one you think should be current... Anyhoo... maybe I'll return to it one day :-p |
| ||
| Brucey, Is MenuEnabled working? About to fire things up now, but I am just wondering if the line... If MenuEnabled( g ) = enable Then Return ...is always returning true for the current state, hence not attempting to enable as it thinks it already is enabled? (and it isn't that it's not seeing the children : this stuff works by "registerring" each individual menu item as being turn on / offable, and hence it only touches those it might actually need to change.) |
| ||
| Yup, MenuEnabled is always returning True, so that check is always kicking in and preventing anything from being enabled. Comment out that line and all is fine. Now, I'm not completely sure *why* I only check the first gadget in the list, and not just remove the check entirely to *force* the menu's to be updated every single time (other than mild performance paranoia?)...but then I shouldn't enable a gadget twice should I...just like I shouldn't free something twice? ;-) |
| ||
| MenuEnabled is always returning True So it is... hah. |
| ||
| Thanks for that!! Committed a fix. Menus in the CE IDE appear to be behaving now :-) |
| ||
| Thanks Brucey - that's done the trick! |
| ||
| Menu enable/disable works here too. I have a few more bug reports specific to ce maxide gtk: - - Find/Replace not working. - Replace All hangs the ide. - Find/Replace buttons deleting text in the textboxes. - - - |
| ||
| - IDE options window general tab not changing when you select another tab This is almost certainly related to the Tabber issue Brucey spent yesterday trying to fix. I am pretty sure the CE IDE code relies on the tabber gadget hiding / showing / bringing to front relevant gadgets attached to each tab. As the gtk tabber is "faked" to some degree, I suspect this is the root cause. Brucey, maybe you could add some code to gtk to force the hiding / showing of child gadgets attached to each tab? Probably best to do something like move way off screen and restore to correct x,y for the tabber, otherwise you'd have issues with the app hiding / showing gadgets while the user is on another tab. (I could just as well add this to CE IDE code, but I think my expectation of the tabber behaviour is reasonable, and is therefore better to add to the gtk implementation). mark, are you sure all the find/replace issues are gtk specific? I think there are some issues in there with the CE IDE code - the hanging one in particular I think can be caused by a conflict between find/replace and auto-tidy code. I'd have a proper look myself but am heading outside to sort the garden out today... |
| ||
| Unless tabber functionality has completely changed in MaxGUI, it has always been up to the user to determine what tab panels are shown or hidden. There should be nothing wrong with the Tabber functionality on gtk :-p Anyhoo... I'd imagine it's more something to do with the event hooks stuff... which I'm trying to look at now. |
| ||
| mark, are you sure all the find/replace issues are gtk specific? Yes, I made sure to test the fltk ce maxide build which worked fine. Edit: there is a bug with fltk ce maxide that gtk ce maxide does *not* have. - ending a built app also ends/closes the ide. |
| ||
| Unless tabber functionality has completely changed in MaxGUI... I thought it did manage the tabs for you...maybe win32 only? No time to check right now but probably safest for me to add code to manage stuff....although I personally would like to see the tabber manage it's own children, rather than me having to nanny them on all platforms... - ending a built app also ends/closes the ide. eeek! |
| ||
| Ahh... I don't remember ItemExtra() on TGadget. Anyhoo, I've updated various places and the options tabbing seems to work better now. Note that in your code, you are indeed having to manually show/hide the panels. It's one of MaxGUI's design flaws - having to manually deal with things like this. For me, I would prefer the tabber managed the children, as you say you would too - it only makes sense. Oh well.. it makes things more interesting, I suppose :-p |
| ||
| project manager->project properties window buttons activate on mouseover. You should check for button activate... not assume that because the button raises an event, it has been clicked :-) |
| ||
| Note that in your code, you are indeed having to manually show/hide the panels. Shows how long it is since I last touched this beast! You should check for button activate... not assume that because the button raises an event, it has been clicked :-) My bet is that's an inherited one - I've sorted *loads* of things like in the maxide code with assumed events. Time for dinner after a days hard gardening, and I'll see what tweaks I can commit to maxide CE before Lost... |
| ||
| A few more issues in CE IDE with gtk after my own testing and before hacking: - scrolling hotkey list in IDE options doesn't scroll - trying to set a hotkey doesn't pickup keypresses (doesn't work in FLTK either, but does in win32) - font sizes generally seem bigger in GTK than FLTK / win32 - check the About window and IDE options. I don't think this is me, but could be my code, unlikely to be my config as having fiddled with this ubuntu vm. |
| ||
| font sizes generally seem bigger in GTK Yes. They compare favourably with Mac sizes... IIRC, buttons are okay at 28px. But of course this is theme specific too - a problem you'll encounter with MaxGUI's fixed layout scheme. scrolling hotkey list... I noticed that too. Didn't try clicking on any of the buttons yet though. Plenty to do, I see :-) |
| ||
| Yes. They compare favourably with Mac sizes... IIRC, buttons are okay at 28px. Ta for the info - looks like there's a job for me to do there resizing buttons. Might be worth someone doing the same to the buttons in the official maxide source too for Mr S so that people can choose to use gtk with that if they wish. I noticed that too. Didn't try clicking on any of the buttons yet though. clicking the buttons shows up the subsequent fault (can't detect key press, but that seems *linux* specific, not just gtk, so will have a rummage in there in case I'm doing something stupid. I seem to recall that it does rely on a non-visible (off-screen?) gadget, so there could be something dodgy assumed in there. |
| ||
| so that people can choose to use gtk I can't imagine anyone wanting to do that :-p |
| ||
| Brucey / mark, the code for capturing a hotkey uses a small active panel to receive the key presses. Do gtk / fltk / x whatever have any peculiarities here that you know of? |
| ||
| I can't imagine anyone wanting to do that :-p To be honest, now that mark's done such a good job with the htmlview, I'm kind of inclined to agree! |
| ||
| .. I was wondering what Brucey thinks about switching to use gtkwebgtkhtml if libgtkembedmoz.so can't be found for gtkwebmozilla? |
| ||
| Sounds like a sensible fallback to me. I've just committed a couple of fixes to the CE IDE: - IDE options gadgets sizes / alignments sorted - Project manager mouseover hyper-activity fixed Note that in tweaking gadget sizes, it seems "Ok" and "Cancel" buttons need to be a little bigger than 28 in gtk for the icons (and possibly fltk too as that has an icon on "Ok"), so went for 34, which seemed about right. |
| ||
| .. the code for capturing a hotkey uses a small active panel to receive the key presses. I'm not sure why but in Fltk, TKeyOptionsPanel.Poll() does *not* receive EVENT_KEYDOWN(513/$201) but gets EVENT_KEYUP(514/$202) so you can work around it with the snippet below. In Gtk that didn't fix it, it only seems to get EVENT_MOUSEENTER(1029/$405) and EVENT_MOUSELEAVE(1030/$406). Windows gets EVENT_KEYDOWN, EVENT_KEYCHAR(515/$203) and EVENT_KEYREPEAT(516/$204). Also returned are EVENT_GADGETACTION(8193/$2001) and EVENT_GADGETPAINT(8194/$2002). 'optionsgui.bmx Method Poll:Int() Local changed:Int = False ' deal with events here, and set changed to True if anything, er, changed! ' and don't forget to check the eventid!!! Local b:Int=GetButtonID(EventSource()) 'DebugLog " EventID "+String(EventID()) If EventSource() = _capture Then If (EventID() = EVENT_KEYDOWN Or EventID() = EVENT_KEYUP) And _pick Then ' <- fltk fix Local k:Int = EventData() |
| ||
| Thanks - fix committed. |
| ||
| Edit: well the panel callbacks all work and space/enter/arrows work but no other keys or the mouse wheel. :/ |
| ||
| fyi, my wife & 2nd child is going to be induced today, so may not be around for a few days now!!! I have 2 weeks paternity leave after that and expect to get a chance to tidy up the various points above in that time....maybe! |
| ||
| Hmm, keyup fix didn't fully stick in last commit somehow (presumably me being thick) - another commit applied which means hotkeys all work on FLTK. But on GTK, still can't scroll and no detection of key presses. |
| ||
| Hi Mark, congratulations on your 2nd child. I wonder could you commit grable's threading build option when you have the time? I don't know how to commit it myself (any info on this would be great). The changes are in the beta 5 src zip already. I will be trying to fix the fltk 'ending app' bug, I'll leave all other fixes up to Brucey and you. |
| ||
| Thanks mark - Kaitlyn Emma was born on Thursday, and she & mum are doing fine. I'll take a look at the beta5 src zip (in the CE thread, right?) and compare. |
| ||
| in the CE thread, right? Yep, that's the one. |
| ||
| r40 committed with grable's addition of threaded mode. |
| ||
| Great, thanks Mark. |
| ||
| Ho hum.... Well, I'm almost understanding why on Linux, the Gtk GUI is not responsive. Apparently, the way timers work as changed significantly at some point - no idea when. It all appears to run in a separate thread... calling bbSystemPostSyncOp() on each "tick"... which itself calls postAsyncOp(), which adds the "tick" onto the end of a linked list. (see system.linux.c), and writes to a pipe... To get this linked list processed, requires a call to bbSystemPoll()... (or more specifically, bbSystemFlushAsyncOps(), but bbSystemPoll calls this) So... for a timer tick event to be created, you must be polling - else the BlitzMax Event object will not be created. I'm pretty certain this didn't used to work like this. Not sure how I'm going to fix this. In theory, I need a timer which will call bbSystemPoll(). But I can't use a BlitzMax timer, since I need to be polling in order for it to work... I had a dig in the fltk code, and apart from the fact that the FLTK MaxIDE runs like a dog on my quad-core 4gig system (no idea what's going on there... the IDE is completely unresponsive), I see that it manages to fire events as expected. In ftkglue.cpp, it appears to be using flAddFd() to setup some kind of asynchronous callback, which attaches to the pipe mentioned above. Fun fun... |
| ||
| Perhaps this is the way I need to go : http://library.gnome.org/devel/glib/unstable/glib-The-Main-Event-Loop.html#g-source-add-poll which may mirror the stuff that fltk is doing down there... Well, I've had enough of this for now... need to do something where I feel I'm actually making progress, for a while :-p |
| ||
| Sounds nasty - I recall Mark doing a whole bunch of work on timers in linux a while back, although don't recall what and finding that detail in retrospect will be hard. I seem to recall it tied in with the change to a tick-less kernel on most distros also, but not sure that really helps you. For what it's worth, gtk doesn't seem *that* bad here... You could always add keyup & keydown events to gtk canvases as a distraction in the meantime? ;-) |
| ||
| The issue I mentioned above with the CE IDE not showing a memory monitor when compiled in debug is also caused by the timers not working. This is because my code relies on CreateTimer generating EVENT_TIMERTICK and for this to be passed through the EmitEventHook. Not sure it helps you fix up timers, but another element of the bug report I guess! |
| ||
| And after a bit of playing / checking, the issue with non-scrolling list of hotkeys appears to be inherent to the tabber control (possibly part of the reason you were looking at this the other day Brucey). The slider is not mine, but presumably provided by the tabber gadget, and it is therefore presumably completely internal to the tabber gadget as to why the slider isn't scrolling the panel. |
| ||
| The TODO list is getting pretty significant now, eh? :-p |
| ||
| I was wondering about moving these various issues into a separate post (or posts) if that would help? Or should I log them in "issues" on googlecode? Concious this thread is now rather long and no longer directly related... |
| ||
| I've created 3 issues in googlecode for you (canvas key events, tabber scrolling & timer eventhooks), and will add any others there if i find any. Also, did you see this suggestion from markcw? I was wondering what Brucey thinks about switching to use gtkwebgtkhtml if libgtkembedmoz.so can't be found for gtkwebmozilla? |
| ||
| The find/replace bugs are all to do with a new gtk bug: TextFieldText doesnt work on comboboxes - it returns blank regardless of selection. |
| ||
| mark, I can't reproduce the specific problem you mentioned before with undo/redo being disabled in ce ide when removing blocks of text in gtk - I can't reproduce it here. There are a couple of general issues with undo/redo at present on all platforms, so unless you know a specific way to reproduce a gtk specific issue, I'm gonna assume it falls in the known cross-platform pot. I also can't reproduce issues with loading .bmx files from the help view under gtk. For example, if I open the maxgui page from the help treeview, scroll down in the help page to CreateTreeView, then click on example, I get the .example.bmx file opened. Again, specific steps to reproduce, or magically fixed by one of the Brucey fixes? |
| ||
| mark (and seb if reading), I think there's a problem with the helpview in official ide: http://www.blitzmax.com/Community/posts.php?topic=84443 I also get a flickering mouse cursor in the fltk version of the official ide and ce ide (but not gtk!): http://www.blitzmax.com/Community/posts.php?topic=84445 |
| ||
| I can't reproduce the specific problem you mentioned before with undo/redo being disabled in ce ide when removing blocks of text in gtk - I can't reproduce it here. There are a couple of general issues with undo/redo at present on all platforms, so unless you know a specific way to reproduce a gtk specific issue, I'm gonna assume it falls in the known cross-platform pot. Well, here's a step-by-step method (just to make sure you can't reproduce it) - still using bmax 1.32. 1] insert a space char between any word (eg. 'testing' to 'test ing') 2] select a few chars of a word with the mouse and press backspace 3] insert a space char between another word 4] now undo back to the start and it should get stuck on step 2 (ie. forgets all undo/redo) I also can't reproduce issues with loading .bmx files from the help view under gtk. For example, if I open the maxgui page from the help treeview, scroll down in the help page to CreateTreeView, then click on example, I get the .example.bmx file opened. Again, specific steps to reproduce, or magically fixed by one of the Brucey fixes? Yes, sorry about that, it only happens with filenames containing space chars. |
| ||
| My precise steps: 1] Type "testing" 2] Mouse click between s and t and hit space 3] Mouse select "in" and hit backspace 4] Mouse click before e and hit space 5] Undo until it gets to "tes ting" and it will go no further as you say If at step 3 you Undo, then Redo, the Redo FAILS?!? In fact, step 4 is uneccessary (although it proves that adding a space isn't the problem). In fact 2, edit ANYTHIING, then MOVE THE CURSOR (mouse or keys) & backspace and Undo will get stuck & Redo stop working. Typing, backspace (without a cursor move) is fine. But all of this works fine in win32 and fltk?!?!?! My guess is that gtk is reporting cursor pos / selection lengths / events slightly differently to win32 and fltk... I can't reproduce the problem with .bmx files and gtk though. e.g. I can open Samples\threads\threaded image downloader.bmx from the treeview with no issue... |
| ||
| I can't reproduce the problem with .bmx files and gtk though. e.g. I can open Samples\threads\threaded image downloader.bmx from the treeview with no issue... Yes, it works from the treeview but try opening a bmx filename with spaces from the helpview (ie. via a hyperlink). You'll need to find something other than the official help docs though as their bmx files don't have any spaces in them. You could install maxarc (from here http://www.blitzmax.com/logs/userlog.php?user=8652&log=1737) or just edit a html link and file to test. |
| ||
| Okay - the problem is actually with deleting a selected block of text. No fix / fault yet, although I have discovered that GTK SetTextAreaText moves the cursor position when chars are added / removed (unlike other platforms), so vaguely possible this is the cause (but don't think so...) |
| ||
| Perhaps it's best just to stick with FLTK for now, rather than spending all this time on GTK, which appears to be a tad on the sickly side of late... ... and considering it used to work rather well, I dunno where/when it went off the rails. A bit sad really. I want to use a decent editor on Linux, but I hate the FLTK look'n'feel (that and the FLTK IDE runs so slowly it is unusable on my quad core box). With each day, I think a wxIDE looks more and more interesting to me - of which I have a basic framework already. If only I had the time... *sigh* |
| ||
| I wouldn't say gtk is 'sickly' now after your latest fixes - I don't think any of these bugs are actually in the official brl maxide - overall I think gtk is stable and I'm happy with it. It's disappointing that maxide ce exposed these issues in the gtk mod but they do only seem to happen in maxide ce so they may not all be gtk's fault.. |
| ||
| It's disappointing that maxide ce exposed these issues in the gtk mod but they do only seem to happen in maxide ce so they may not all be gtk's fault.. Agreed - if anything, I'm using gtk as a "harsher test case" to prove everything works as it should and fix bugs that simply don't show up on my main platform (win32). I too prefer the gtk look and feel, but am using the fltk version on linux as it works consistently with win32 (and presumably macos...although that's a bit of a leap of faith!). I wouldn't say gtk is 'sickly' now after your latest fixes And I agree with this too - in the main it all works, it's just that there are a few things (missing or inconsistent events across platforms) that really could do with a little attention (and hopefully wouldn't take that much), and others that frankly can wait (or be left as known issues) as they can more safely be coded around (e.g. the latest gtk issue I posted on googlecode which is really rather obscure, and kind of exposes a slightly dodgy assumption). I think the "problem" is that it works fine for simpler apps (which I class the original IDE as), but starts to struggle as it gets put to the test as things get more complex, exactly as the original win32maxgui did before Seb's great work on that front. It isn't helped by the fact I have very little time to devote to CE IDE, and hence isn't necessarily the cleanest test case... With each day, I think a wxIDE looks more and more interesting to me I half wondered about trying to wrap wxMaxGui myself, at least to a "bare minimum" level. But then I decided that if anyone can do it, that'd be you Brucey, and as you feel it would be difficult, why should I feel any different... |
| ||
| I half wondered about trying to wrap wxMaxGui myself No. I'm not going to do that. I'm thinking more on the lines of a fresh executable. If you think about it there isn't too much to the IDE... mostly just an editor with the ability to run stuff. wxMax has some nice features - MVC framework - scintilla - AUI (for pane layout)... which would in theory take away much of the nitty coding work. |
| ||
| No. I'm not going to do that. I realise you're not, which is why I ruled out doing it myself. If you're not up to / for it, I sure as hell aint! |
| ||
| Post for my benefit only: |
| ||
| Gotcha! The cause of weird undos on GTK is because unlike other platforms (win32/fltk), programmatic calls to SetTextAreaText and SelectTextAreaText are generating EVENT_GADGETSELECT and EVENT_GADGETACTION events. Programmatic changes to the text in the gadget should NOT generate such events. Updated code above demonstrates this. (This breaks CE IDE because the undo is applied, then the events get processed, CE IDE thinks the user has typed something so creates a new Undo...so when you hit Ctrl-Z and it looks like nothings happened, it is replaying the Undo/"Typing" and ending up as is. This also explains why Redo stops working - you've added a new Undo step, breaking the Redo path.) Brucey, new issue about to be added to Google Code...that one was really bugging me! Think I'll stop with the GTK attempts now... |
| ||
| programmatic calls to SetTextAreaText and SelectTextAreaText are generating EVENT_GADGETSELECT and EVENT_GADGETACTION events Hmmm... I thought I'd made sure those kind of things weren't happening... ho hum. |
| ||
| Hmmm... I thought I'd made sure those kind of things weren't happening... LOL - Like I thought undo/redo was fixed, hence my determination to find the root cause of this and be 100% sure this was definitely gtkmaxgui, and not a flawed bit of my code that only broke badly on gtkmaxgui. |
| ||
| Mark, your HTML thing with, as I suspected is down to gtk returning file:/// entries with %20 instead of space. I think this is somewhat reasonable behaviour (even if it is inconsistent behaviour with other platforms), and have just added a replace "%20" with " " for file:/// urls to svn. |
| ||
| Thanks Mark, works nicely now. I see brl maxide has the same solution in THelpPanel.OnEvent(). I don't really follow your undo/redo bug report but hopefully Brucey will understand. I thought I'd recap on the gtk ce maxide bug list to get them all into one space. Fixed: - project manager->project properties window buttons activate on mouseover. - IDE options window general tab not changing when you select another tab. - links to .bmx files in the help view not opening [when filename contains space chars]. - no memory monitor window in debug mode - IDE crashing after build (also in fltk) Bugs: - scrolling hotkey list in IDE options doesn't scroll - trying to set a hotkey doesn't pickup keypresses in IDE options window - undo/redo gets disabled in the editor view when selected text was deleted or otherwise removed. - Find/Replace not finding/replacing text. - Replace All hangs the ide. - Find/Replace buttons deleting text in the textboxes. And the gtk 'general' maxide bug list. Fixed: - slowdown issues with BlitzMax 1.32. - hotkey/menu item support [broken in 1.32]. - menus not returning correct state. - tabber not setting extra data. Modified listbox and combobox for same. Bugs: - The IDE output window doesn't refresh... but if you click on it, it will. - If there is an error, the IDE error window isn't shown, and the tab isn't changed to show the correct page - unless you click on a tab. |
| ||
| Thanks mark - are the last two bugs in the official IDE with GTK *and* CE IDE, or just one of them? As it stands, I believe all of the CE IDE ones in the top list are due to GTK working slightly differently to fltk/win32. I imagine the same will apply to the latter 2 if they apply to the official IDE too. Also of note is that the buttons in the CE IDE Options window for picking font styles don't hold their values and picking a font generates an error (both caused by same issue as find/replace problem with TextFieldText and comboboxes). version_history.html in CE IDE contains full list of gtk ce ide issues too which should match the above. |
| ||
| ..are the last two bugs in the official IDE with GTK *and* CE IDE, or just one of them? Well, the 2 'general' bugs relate to both IDEs (technically they are the same bug) but it's actually worse in ce maxide as the output window doesn't update, even when you click on the tab (note that in brl maxide the output window does update when a built app starts and when it ends - so not an issue unless you're debugging). Also of note is that the buttons in the CE IDE Options window for picking font styles don't hold their values and picking a font generates an error (both caused by same issue as find/replace problem with TextFieldText and comboboxes). Well, funny enough the combo-button styles hold their values in gtk but not in fltk. Also, I'm not getting any problems choosing a font in gtk or fltk. |
| ||
| okay, guess I'll take a closer look - I may actually have got mixed up between whether I was in gtk or fltk mode TBH, and as it was all around comboboxes, wrote it off as being related to the known gtk combobox issue. will take a look now... |
| ||
| so many known gtk issues... it's not even funny now :-p I need to find some free time to look at a few of those issues. *sigh* |
| ||
| lol - sorry brucey! good news on the font stuff though, as it looks like this is an fltk only issue as mark says... the font stuff is odd. you're right that gtk works, and it's a problem with fltk. it doesn't remember styles, although if you open ide options straight away when you *know* something is set, change one style or the font, then the pre-existing settings suddenly appear (i.e. all start=Normal incorrectly, then e.g. change remarks to bold and suddenly keywords show correctly as bold). almost like the values have been set, but fltk didn't update the screen??? but then if you hit ok, it sets all to normal...so definitely an fltk oddity and gtk/win32 are okay! the error on clicking the font button was in fltk and actually in my memcheck code - i was receiving an eventhook call with data <> tevent...which shouldn't happen! added a check to make sure data is not null when i cast to a tevent, and all fine for me, so something strange happening there, but i can deal with adding this apparently unnecessary (but sensible) check. (lower caps only as baby is asleep on 2nd arm and daren't move it!!!) |
| ||
| And just to add, my memory checking window listed above as not working in gtk has magically re-appeared in gtk over the past few days. No idea what made that suddenly work again (possibly Brucey removing debugging eventhook??? can't see that being it tho'...). Another known issue with fltk is that for me using ubuntu 8.10 through VirtualBox, I get a very flickery mouse cursor while over the official and CE IDEs in the fltk build. I do not get this in the CE IDE when built with gtk (another plus to Brucey!). |
| ||
re: memory checking window. Confirmed the window now loads. I checked and it was due to adding a bbSystemPoll() to TGTKGuiSystemDriver in gtkgui.bmx line 35.Method Poll() While gtk_events_pending() gtk_main_iteration_do(False) bbSystemPoll() Wend End Method Anyone updated to v1.33 yet? I've still not got round to it. Edit: also now the output window in ce maxide responds a bit more like brl maxide but sadly, now I'm getting the same 'ide crashing after build' bug that fltk has - so this is likely to be ce maxide's fault. It probably won't help but I'll list the trace anyway. |
| ||
| oooo... Double free :-) Someone is being naughty and trying to release the same thing twice... Sounds very familiar, doesn't it? ;-) |
| ||
| LOL - will take a look, but I suspect it's exactly the same issue with treeviewnodes when it builds the helpdocs. When you're getting the crash, it is probably changing the debug tree, so I imagine it's probably freeing up at least some of the nodes twice. Hopefully when I return to that code shortly I will encapsulate the free in one single place and make 100% sure it can;t be called more than once... And no, I haven't moved to 1.33 on linux yet, just windows. |
| ||
| Okay - spent a bit of time looking at datanodes/treeview nodes, and decided that the most likely cause was that I was freeing a treeview gadget higher up the tree first, then explicitly attempting to free the children...which of course would already be implicitly free'd because their parent has vanished. This would explain why all my attempts to null out references to nodes with each free and check not null wouldn't help, and head-scratching before around being confident I only ever free'd each node once... And true enough, I did find that I was freeing the gui elements *before* freeing the child nodes. So I have swapped that round and everything seems to still be working... ...but it hasn't fixed the debugger problem. To be honest, I haven't checked it really has fixed the treeview double free, as that wasn't causing errors following Brucey's tweaks. But I reckon it "probably" does fix that double free, or at least most of them... So I think the debugger problem is something else...but what? Running in debug mode gives no clue - it just bombs out. Will need to add loads of debugstops and try to pin it down. I'm kind of thinking it's most likely to be to do with process handles, etc, as not much happens IDE wise when an app ends. *sigh* |
| ||
| Weirdness. Quick debugstop and stepping through, and process termination seems to be handled fine - all code runs and the app goes back to polling for events. It then receives a timer event (the one that ensures the output window gets updated), and stops the timer, and goes back to polling...then it barfs in the middle of polling for the next event??? Maybe StopTimer is buggered? |
| ||
| Yup, comment out the StopTimer, and it works perfectly. Would explain why official IDE doesn't crash as I think it's timer is left running throughout (I try to be kind on events). So probably an underlying BlitzMax Timer/StopTimer issue on Linux...which wouldn't be unsurprising as Timers were rejigged on Linux recently. No time right now to look into this any further, but must be a simple app I can create to prove this... |
| ||
| Nice work. Confirmed that commenting out StopTimer from TGUIOutput.Poll() in debug.bmx lines 210+211 stops the ide from crashing after a build - and it works in both gtk and fltk. Strange how it was a timer issue. Unfortunately, I'm still getting a message/notify window with an information icon at the point it was crashing at, which has me baffled. COMMAND::/home/mark/BlitzMax/bin/bmk makeapp -r -t gui -a /home/mark/BlitzMax/maxarc/createtextarea.bmx^M /usr/bin/ld: warning: libstdc++.so.6, needed by /usr/lib/libGLU.so, may conflict with libstdc++.so.5 Anyway, fltk ce maxide is basically useable now. :) Edit: hmm, I see in the docs it says once stopped a timer can't be used. So shouldn't you use WaitTimer to pause? |
| ||
| that's just a warning isn't it? Standard stuff, albeit that it should just go in the output window. I've had the official ide show me odd messages too though, so wonder if that's a generic problem. I can reproduce the Timer issue *intermittently* using the below. Sometimes it blows up, sometimes it doesn't. My suspicion is that WaitEvent is internally receiving an EVENT_TIMERTICK, then trying to process it against a timer it no longer knows about (as StopTimer has released it). It's certainly true that an extra timer tick event is received after StopTimer. |
| ||
| Edit: hmm, I see in the docs it says once stopped a timer can't be used. So shouldn't you use WaitTimer to pause? I'm not pausing the timer, I am killing it as I don't want to receive it's events any more. Setting the ref to the timer to null doesn;t do this, and StopTimer is the only way of actually completely stopping the timer from firing events after you have finished with it. I could just have the timer running all the time, and always check the event every 1/10th second like the official IDE...but I prefer to only do that when I need to, i.e. while a compiled app is running. |
| ||
| Workaround committed to svn : on linux, I no longer attempt to stop the timer, just leave it running and reuse it on next run. |
| ||
| The timer stuff on Linux is very strange. It caches ticks on a stack which are uncached when you poll the system. Therefore you either need to : 1) poll often (like you would do in your game loop 2) attached yourself to the FD pipe and react to data appearing on it - which is also written on each tick. The FLTK module does 2, and processes events via a callback trigger. I guess the GTK one would need to do the same kind of thing: see here for all the gory details - http://library.gnome.org/devel/glib/unstable/glib-The-Main-Event-Loop.html#g-source-add-poll In some ways the old way (where it raised 1000 ALRMs per second, was better - but obviously it broke other things by doing that (like, OpenURL for example) |
| ||
| I kind of assumed this was 'max issue, rather tan an fltk/gtk maxgui issue - my example doesn't include maxgui, and your response in the bug report thread makes sense. I suspect "all" that is really needed is for StopTimer to completely flush the event queue of any timer ticks...although as you've said no idea how that works internally! The workaround of keeping hold of the timer and not trying to be friendly and give it up seems to do the job for me for now though, so I'll let someone else worry about fixing up blitzmax StopTimer... |
| ||
| Well, if you want to have a rummage : system.linux.c most notably, postAsyncOp() and bbSystemFlushAsyncOps(). bbSystemStartAsyncOp() - at the bottom of the file - is where it kicks it all off. The struct AsyncOp is a linked list - the "stack" of ticks. This section actually reminds me of how FFMPEG decodes frames in a separate thread, so I guess it's pretty standard stuff. But notice that the actual timer stuff is not here - that's separate. So.. I dunno. You wanna ask the experts :-) |
| ||
| You wanna ask the experts :-) Or work around it. ;-) |
| ||
| So it wasn't ce maxide's fault then?! Apologies for that and thanks for the workaround. that's just a warning isn't it? Standard stuff, albeit that it should just go in the output window. I've had the official ide show me odd messages too though, so wonder if that's a generic problem. No, I'm pretty sure it's not normal for that to appear.. but I'm pretty chuffed there is now a stable linux ce maxide so I won't whine about such a small issue. |
| ||
| And that's the fltk issue in IDE options proven to be a bug in FLTKmaxgui... http://www.blitzbasic.com/Community/posts.php?topic=84726 |
| ||
| Great, thanks again Mark. I had a go at that one myself but couldn't follow it. I did notice that ok resets the combo items but cancel leaves them alone, and also that sometimes a combo would reset another combo but that's as far as I got. |
| ||
| yeah, the cause in CE IDE is that "OK" re-applies the settings (obviously), which includes applying the language settings. The way the language localisation works, all maxgui commands that take text are over-ridden in locale/language.bmx, and it runs through every single gadget ever created and applies the new laguage settings...which for a combobox means a call to ModifyGadgetItem, which on fltk causes the selection to be lost! I have actually added some code around ModifyGadgetItem inside language.bmx to store the selected item and restore after ModifyGadgetItem to (again) workaround the maxgui issue for now. But it did take a little while and much head-scratching! Next up, why does the keyword highlighting seem "sticky" as you type, and why is it over-aggresive on capitalising keywords (e.g. type MODIFIER = ModIFIER). Pretty sure both are down to a stray +1 or -1 mistake that kicks things in too early... |
   |