Rendering and System Interfaces for Python apps

Discussion about using Python with libRocket.

Rendering and System Interfaces for Python apps

Postby Digitante on Tue Nov 25, 2014 6:30 am

I am developing an application in Python, and want to use Rocket to manage menus. Apparently, I need to provide or create a graphical backend for it to work with. Can anyone recommend good choices for this, and/or how one might go about doing it from a Python perspective?

I don't have too much concern over what engine is used. However, I have a bit of experience using SDL (via PyGame), and as I am also using VLC (libvlc), which has an SDL backend. So that might be a good, simple option for me, if it's available (VLC has other backends, though).

Am I going to have to write C++ code to make this happen (I'm extremely rusty with C/C++, and would much rather stick to Python), or can this really be done with "a simple Python module" as the manual claims (but does not demonstrate!)?

And what is the "System" interface -- is that relating to input?

And BTW, this seems to be a very weak spot in the Python Manual. It's really not written from the point of view of a Python app developer -- it seems to assume a lot more familiarity with C++ than seems reasonable to me. If and when I figure out how to make this work, I could probably write up some material for the introduction that would be a lot clearly than the one throwaway sentence that is there now about 'providing interfaces'.
Posts: 2
Joined: Tue Nov 25, 2014 4:53 am

Re: Rendering and System Interfaces for Python apps

Postby Supertim on Tue Nov 25, 2014 7:44 am

I will try to answer the easy parts first :)

The documentation is written from the C++ developer's point of view, with perspective on python as the project's embedded language, and refers to interfaces as they are known in object oriented programming. The System interface is very simple, but covers (typically) platform/application-specific functionality, such as timers, messaging, etc. These methods are pasted below for your convenience:

Code: Select all
   /// Get the number of seconds elapsed since the start of the application.
   /// @return Elapsed time, in seconds.
   virtual float GetElapsedTime() = 0;

   /// Translate the input string into the translated string.
   /// @param[out] translated Translated string ready for display.
   /// @param[in] input String as received from XML.
   /// @return Number of translations that occured.
   virtual int TranslateString(String& translated, const String& input);

   /// Joins the path of an RML or RCSS file with the path of a resource specified within the file.
   /// @param[out] translated_path The joined path.
   /// @param[in] document_path The path of the source document (including the file name).
   /// @param[in] path The path of the resource specified in the document.
   virtual void JoinPath(String& translated_path, const String& document_path, const String& path);

   /// Log the specified message.
   /// @param[in] type Type of log message, ERROR, WARNING, etc.
   /// @param[in] message Message to log.
   /// @return True to continue execution, false to break into the debugger.
   virtual bool LogMessage(Log::Type type, const String& message);

   /// Activate keyboard (for touchscreen devices)
   virtual void ActivateKeyboard();
   /// Deactivate keyboard (for touchscreen devices)
   virtual void DeactivateKeyboard();

The functions above are actually virtual methods of SystemInterface class, and must be implemented by your C++ application for the application to compile, and for that functionality to be available.

This brings us to the rendering of things - render interface - which is another class that you have to implement for the program to render the graphics on screen. The advantages of this being setup as an interface are tremendous (from C++ perspective), and obvious, deliberate, and difficult steps appear to have been taken to make this C++ library as flexible as possible. Some of the obvious advantages: ability to integrate with any rendering library, can use DirectX/OpenGL/etc in your interface implementation, etc.

I'm not a python user by far, but to my knowledge to use libRocket you will need to have a C++ program built for the platform/architecture that you intend to execute on. I'm open to correction, but I'm not aware of standalone python modules that maintain libRocket bindings on a cross-platform basis (nothing stopping you from being the first ;)), and I don't think you can use libRocket by running python code directly from the default python interpreter for your platform.

SDL usage with libRocket typically takes advantage of SDL for tasks like creating a window, grabbing input, and creating OpenGL/DirectX context - but not for literally drawing rocket elements, those are composed entirely by libRocket. Try building the samples that come with the library, and you may have some practical results.
Rocket Engineer
Rocket Engineer
Posts: 16
Joined: Sat Jun 14, 2014 5:31 am

Re: Rendering and System Interfaces for Python apps

Postby Digitante on Wed Nov 26, 2014 9:21 pm

Rocket does build and install a Python module that can be imported by the Python interpreter. This strongly suggests that a true Python binding is the intent. The Rocket module as built by default, is, however, non-functional. In fact, it fails silently without reporting the problem, when it should probably generate a traceback indicating that no Rendering or System interface is available.

However, looking into the C++ manual, it appears that code for an OpenGL backend is included with the "shell" sample?

If that's the case, it seems extremely silly not to simply include that as a default in building the Rocket Python extension module.

Am I correct in thinking that all that is needed to create a functional Python module on OpenGL systems is to link that code with it?
Posts: 2
Joined: Tue Nov 25, 2014 4:53 am

Return to libRocket and Python