BRL, why does brl.maxgui import brl.eventqueue?
BlitzMax Forums/MaxGUI Module/BRL, why does brl.maxgui import brl.eventqueue?
| ||
| Hi, I just noticed, the module brl.maxgui imports the module brl.eventqueue, however the module also compiles fine if I comment out this import line. It works without brl.eventqueue just as well as with brl.eventqueue, the only difference is that when importing brl.eventqueue from brl.maxgui there might be some unused code in the compiled application. So I don't understand why this import is needed - it just slows down the built applications. Therefore here's my question: Why does brl.maxgui import brl.eventqueue? |
| ||
| Perhaps because if you want to make a GUI you have to use events so it's almost a given that it should be included, maybe it just helps keep it simple so you only have to include the MaxGUI module and not worry about also including the event module. |
| ||
| The module may compile, I fail to see how it would be usable unless eventqueue is being imported via somewhere else, the drivers themselves I suppose could directly import it for their postevent requirements but a maxgui app without waitevent??? |
| ||
| Well, of course you need events to write your gui, but you don't need eventqueue, using the eventqueue slows down the programme a lot - using hooks is much faster and produces cleaner code; it was also mentioned in the RedrawGadget documentation. If you're using the queue you will be blocked when the application is in modal loops, for example if the user opens an application's menu - the app hangs in the waitsystem call and the window's background doesn't get drawn till the user selected one of the menu's entries since you're app doesn't process the gadget paint event just because it hasn't registered any hooks. I really understand why you need the events, but not why you need the event queue. Maybe I missed something, but I really thought this "basic"-style event queue was just for backward compatibility to BlitzPlus users - BlitzMax is an OO language, so I thought we were all meant to write more modern code such as the example for RedrawGadget shows: The code doesn't need the eventqueue at all, it just needs brl.event and brl.hook (you could simply replace WaitEvent by WaitSystem, which is much faster since WaitEvent also just calls WaitSystem). I'm programming OO code just like this example - I created a TApplication class which works the same way as the TApplet class in the example. So for me the eventqueue system is just a burden, it lies in all the compiled applications and needs so many cpu ticks to store the unneeded event objects and kill them again because the queue overflows since there's noone receiving these inoperative events, though there's no need. Why do you want to make everyone import that module instead of leaving the choice of importing to the developer? |
| ||
| . |
| ||
| I just took the RedrawGadget example - well, maybe you spotted a bug! |
| ||
| . |
| ||
| Well, I posted the bug report here, but I think this is off-topic now - my question is still not answered, since there's really no need to use the event queue if you want to do gui programming. |
| ||
| OK scrub my last reply, yes, having a quick look, please feel free to remove eventqueue (and standardio while you're there) from your maxgui module. |
| ||
| works fine here, but with the next syncmods the changes become undone. aren't you interested in decreasing an executable's size? come on, the only way to make this better is to remove the import statements from the server. I can't see any reason why these modules are imported by maxgui. if you need them, just include them. if there's another module, which doesn't need this modules itself, which includes them just because the code including this module *might* need it, (which brl.maxgui does) this is just a wast. it increases the resulting executable size by some code which isn't needed ever in the program's execution. I don't understand why you want to import these modules, just because some persons using maxgui might also want to import them. the behaviour is quite unlogical: if you want to write a gui application you probably won't need the standard io stream. and if you're using modern/oo-hook style code you also won't need a queue. if you want to use a module, import it, and don't expect another module to import it! The module may compile, I fail to see how it would be usable unless eventqueue is being imported via somewhere else, the drivers themselves I suppose could directly import it for their postevent requirements but a maxgui app without waitevent??? you should know best that the gui modules just call "EmitEvent" and just because of the queue module the events then get posted to the queue. (and standardio while you're there) .... and filesystem, too. |
| ||
| has been working fine for me too, will be included with next syncmods |
   |