Ok, I have been toying with the idea of diving into unix programming for awhile now, and the first building block I want to develop is a type of GUI system.
The idea is that all programs are completely seperate from direct user interaction, let me explain...
Say you have a console application, we'll say it's a finance app for this example.
Now, all users are different, and thus have different tastes and needs in interfacing with a program.
So for this console financing application, there's going to be a way to change the IO interface of the program, without changing the program.
The program will be layered as such:
IO Interpreter
Application
What the IO Interpreter does is parse the input from stdin and transfer it to correct function calls which it then makes to the application. When the application needs to report information to the user, it sends unformatted data to the IO Interpreter where it is there formatted and then displayed to the user.
That pretty much sums up the basis of what I'd like to do with console, but you'll see pretty quickly how it can easily interface with the similar GUI system I'm about to explain.
I am including skinnability in this model of a GUI simply because I think skinnability is a paramount ability, not only skinning however, but you'll be able to change how the GUI interacts with the program.
Here's the several layers of the GUI system:
Skin (simply the skin file, be it xml, archive with images, what-have-you)
Skin Interpreter
Gui Engine
Event Interpreter
Application
The skin interpreter is fairly simple, all it does is read in the skin file and translate it into a format that the GUI engine can easily display. Alternate skin interpreters would mean that you could have XML skins as well as simpler methods of skinning, without changing the entire application.
The GUI engine is simply the layer which handles all the window management, button events, menu events ect and relays the commands to the Event interpreter.
The event interpreter is very similar to the IO interpreter above, it takes the input commands from the GUI engine, and translates them into function calls for the application, as well as taking unformatted output from the application and translating it to the GUI engine.
Now, enough of the theory, if you understood at all what I just talked about, I'm wondering whether you can point in the right direction and give me some helping tips as to what methods I need to use to get going on a project like this.
I'd like to keep a good balance between efficiency and convenience. So preferably no scripting or on the flip side I don't want to have to re-compile a program just to use a different interpreter
So far it looks like my options right now are:
DCOP (KDE)
KParts (KDE)
XPCOM (Mozilla)
Although I thought that DCOM had been successfully ported to unix
I'm wondering which would be best suited to my project
I will start with the console IO interpreter method, simply to test out the pluggable components, but after a success in that, I want to move to the GUI system.
A warm heart-felt thanks goes out to all of those that took the time to read my whole post (or most of it)
The idea is that all programs are completely seperate from direct user interaction, let me explain...
Say you have a console application, we'll say it's a finance app for this example.
Now, all users are different, and thus have different tastes and needs in interfacing with a program.
So for this console financing application, there's going to be a way to change the IO interface of the program, without changing the program.
The program will be layered as such:
IO Interpreter
Application
What the IO Interpreter does is parse the input from stdin and transfer it to correct function calls which it then makes to the application. When the application needs to report information to the user, it sends unformatted data to the IO Interpreter where it is there formatted and then displayed to the user.
That pretty much sums up the basis of what I'd like to do with console, but you'll see pretty quickly how it can easily interface with the similar GUI system I'm about to explain.
I am including skinnability in this model of a GUI simply because I think skinnability is a paramount ability, not only skinning however, but you'll be able to change how the GUI interacts with the program.
Here's the several layers of the GUI system:
Skin (simply the skin file, be it xml, archive with images, what-have-you)
Skin Interpreter
Gui Engine
Event Interpreter
Application
The skin interpreter is fairly simple, all it does is read in the skin file and translate it into a format that the GUI engine can easily display. Alternate skin interpreters would mean that you could have XML skins as well as simpler methods of skinning, without changing the entire application.
The GUI engine is simply the layer which handles all the window management, button events, menu events ect and relays the commands to the Event interpreter.
The event interpreter is very similar to the IO interpreter above, it takes the input commands from the GUI engine, and translates them into function calls for the application, as well as taking unformatted output from the application and translating it to the GUI engine.
Now, enough of the theory, if you understood at all what I just talked about, I'm wondering whether you can point in the right direction and give me some helping tips as to what methods I need to use to get going on a project like this.
I'd like to keep a good balance between efficiency and convenience. So preferably no scripting or on the flip side I don't want to have to re-compile a program just to use a different interpreter
So far it looks like my options right now are:
DCOP (KDE)
KParts (KDE)
XPCOM (Mozilla)
Although I thought that DCOM had been successfully ported to unix
I'm wondering which would be best suited to my project
I will start with the console IO interpreter method, simply to test out the pluggable components, but after a success in that, I want to move to the GUI system.
A warm heart-felt thanks goes out to all of those that took the time to read my whole post (or most of it)
