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:

' redrawgadget.bmx

Strict

Type TApplet 

	Method OnEvent(Event:TEvent) Abstract

	Method New()
		AddHook EmitEventHook,eventhook,Self
	End Method

	Function eventhook:Object(id,data:Object,context:Object)
		Local	event:TEvent
		Local	app:TApplet
		event=TEvent(data)
		app=TApplet(context)
		app.OnEvent event	
	End Function

End Type

Type TSpinningApplet Extends TApplet

	Field	window:TGadget
	Field	canvas:TGadget
	Field	timer:TTimer
	Field	image:TImage
	
	Method Draw()
		SetGraphics CanvasGraphics(canvas)
		SetViewport 0,0,GraphicsWidth(),GraphicsHeight()
		SetBlend ALPHABLEND
		SetRotation MilliSecs()*.1
		SetClsColor 255,0,0
		Cls
		DrawImage image,GraphicsWidth()/2,GraphicsHeight()/2
		Flip
	End Method
	
	Method OnEvent(Event:TEvent)
		Select event.id
		Case EVENT_WINDOWCLOSE
			End
		Case EVENT_TIMERTICK
			RedrawGadget canvas
		Case EVENT_GADGETPAINT
			draw
		End Select
	End Method
	
	Method Create:TSpinningApplet(name$)
		Local	a:TApplet
		Local	w,h
		image=LoadImage("fltkwindow.png")
		window=CreateWindow(name,20,20,512,512)
		w=ClientWidth(window)
		h=ClientHeight(window)
		canvas=CreateCanvas(0,0,w,h,window)
		canvas.SetLayout 1,1,1,1
		timer=CreateTimer(100)
		Return Self		
	End Method
	
End Type

AutoMidHandle True

Local	spinner:TSpinningApplet

spinner=New TSpinningApplet.Create("Spinning Applet")

While True
	WaitEvent
Wend

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!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 filesystem, too.

has been working fine for me too, will be included with next syncmods