GUI Interacitve
Posted 05-04-2012 at 11:06 AM by rainbowsally
This will be a new subtheme under the GUI Programming topic.
No examples or experiments yet, let's just talk about the how's and why's of doing this.
It's time to start thinking about an interactive layer to communicate with the GUI system. This implies an interpreter, which runs in a loop grabbing commands and executing them (if the syntax is correct) and is really not much different from a bytecode compiler which runs an execution loop to do the same, so we can do this with the notion of expanding this to a bytecode compiler in mind.
The goal is to get more info about the system by executing commands, such as a command to list all the methods for a given class or all the properties and where they come from. This is available in 'assistant' for QT but it's easier to find all the methods (for example) by creating a dummy ui file and editing the connections to see what's available. And even then, we can't copy/paste any results.
And properties are no easier to figure out.
Fair enough? A worthy goal?
And this 'interactive' layer should be generic enough that the interface can be adapted to other GUI systems.
Stay tuned. The Interactive layer will be all mixed up with other experiments and demos due to the way evolution works in the domain of 'knowledge' which is probably pretty much related to how evolution works in nature.
The Computer Mad Science Team
PS. The properties used in the previous preemptive event handler experiment were looked up using other previous experiments that listed methods and properties for a hard-coded widget.
This interactive layer for the GUI is not only a valid goal, it's proven useful already. The 'interpreter'? It was bash with it's own set of syntax rules that disallow params in parens, among other things that make it unacceptable for our GUI-interactive interpreter.
:-)
No examples or experiments yet, let's just talk about the how's and why's of doing this.
It's time to start thinking about an interactive layer to communicate with the GUI system. This implies an interpreter, which runs in a loop grabbing commands and executing them (if the syntax is correct) and is really not much different from a bytecode compiler which runs an execution loop to do the same, so we can do this with the notion of expanding this to a bytecode compiler in mind.
The goal is to get more info about the system by executing commands, such as a command to list all the methods for a given class or all the properties and where they come from. This is available in 'assistant' for QT but it's easier to find all the methods (for example) by creating a dummy ui file and editing the connections to see what's available. And even then, we can't copy/paste any results.
And properties are no easier to figure out.
Fair enough? A worthy goal?
And this 'interactive' layer should be generic enough that the interface can be adapted to other GUI systems.
- The interactive layer will be an interpreter. Interpreters need 'names' of functions to find their execution procedures.
- Names are strings.
Stay tuned. The Interactive layer will be all mixed up with other experiments and demos due to the way evolution works in the domain of 'knowledge' which is probably pretty much related to how evolution works in nature.
The Computer Mad Science Team
PS. The properties used in the previous preemptive event handler experiment were looked up using other previous experiments that listed methods and properties for a hard-coded widget.
This interactive layer for the GUI is not only a valid goal, it's proven useful already. The 'interpreter'? It was bash with it's own set of syntax rules that disallow params in parens, among other things that make it unacceptable for our GUI-interactive interpreter.
:-)
Total Comments 0
