Console, Linux and BRL.System

Archives Forums/BlitzMax Bug Reports/Console, Linux and BRL.System

Brucey

(Posted 2014) [#1]

Currently, you cannot use BRL.System in a console application on Linux, because it adds X Windows dependencies and will segfault on startup if you try to run the program headless (i.e. a session that does not have a valid DISPLAY).

If you want to use standard functionality such as Notify, CurrentDate and CurrentTime, you need to reimplement them yourself - if you don't want your application to have a dependency on X libraries.

There are two possible directions I can see to fix this :

1) Split out the event generation stuff (all those things that require X libraries and a DISPLAY) into a new module, and let any other modules that require that functionality to import that one instead. The remaining BRL.System module would just contain stubs where required (as happens in other places).

2) Acquire events through a more low-level Linux way, that doesn't require use of X Libraries.

1 is probably the easiest fix, as it requires less work and R&D.

Derron

(Posted 2014) [#2]

Sounds like your raspi is not having x libs :p

I think so too about 1) and 2) : as you fix things in the github-brl.mod thing (libpng) you can change this there too.

Of course 2) is the way to only change this portion of source code ... making it more a "replacement" than a "patch".

PS: Did you see this (system.linux.bmx):

	Method Emit( osevent:Byte Ptr,source:Object )
		Throw "simon come here"
	End Method

Another odd thing:

	Method OpenURL( url$ )
		If getenv_("KDE_FULL_DESKTOP")
			system_ "kfmclient exec ~q"+url+"~q"
		ElseIf getenv_("GNOME_DESKTOP_SESSION_ID")
			system_ "gnome-open ~q"+url+"~q"
		EndIf
	End Method

Enjoy playing this on another Desktop... thought to have read about such a "problem" (openurl not working) ... maybe they are on xfce(4).

bye
Ron

Brucey

(Posted 2014) [#3]

Well, it's basically just an issue of mixing things that really shouldn't be packaged in the same module.
Another example is MaxGUI's ComputerName() and UserName() functions, which are certainly not GUI-specific, and should most-likely be in BRL.System (allowing them to be system-driver-implemented if required).

Derron

(Posted 2014) [#4]

Brucey the BM-Janitor :p

Maybe there should be some cleanup sessions till next spring. But first of all, land the other baby so foundation is built then.

bye
Ron

skidracer

(Posted 2014) [#5]

I did a blog about this a while back.

My solution for getting rid of xf86vmode dependency was this:

int bbSystemDesktopWidth(){
  Screen *screen=XDefaultScreenOfDisplay(x_display);
  return WidthOfScreen(screen);
}
int bbSystemDesktopHeight(){
  Screen *screen=XDefaultScreenOfDisplay(x_display);
  return HeightOfScreen(screen);
}
int bbSystemDesktopDepth(){
  Screen *screen=XDefaultScreenOfDisplay(x_display);
  return DefaultDepthOfScreen(screen);
}
int bbSystemDesktopHertz(){
  return 60;
}

a guard for headless displays would possbly be test for null screen, not sure...