I wounder whats is the best way to structur the code of an gui Application.
First I think it is good to seperate the gui part and the “mainapp” part (the part that doing the real work). The mainapp and the gui both have an interface to the outer world. For example the gui gives a data structur with all information collected from different views.
Now the question is how to connect this two parts? My idea is to derivate a BApplication class and put the gui and the mainapp into it. The mainapp and the gui can now communicate over the global be_app pointer by sending messages to the BApplication. Then the BApplication forward this messages to the gui or to the mainapp.
Is this I a good way? What can I make better or how you stuctur your application? Are there some docs?
this is explained very nicely in the O’Reilly book “Programming the Be Operating System”. It is out of print, however, it can be downloaded in PDF format here:
Hm, I also have a printed version of this book but as I start programming I don’t like it much. When I looked in it today I found nothing that can explain my question.
There is only “hello world + gui + be” code. I search for something more general. Like what belonges in the gui/ how much programm code should be in the gui or whats the best way to communicate between main programm and gui.
With main programm I mean not the main function but the part that do some real stuff like connect to the net and processing some data from the net.
With gui I mean the part that display the data or gives input to the main programm.
Maybe I miss something in this book because for me it’s no fun to read it. In this case can you give me a chapter?
You are right in the fact that it is common practice for software developers (Especially in the commercial scene, and generally in the OO area) to develop their software in two parts: The View (Or the User Interface, GUI, etc), and the Model (Or the Business Logic, Backend, etc).
You could use a derived BApplication class and then refer to the be_app everywhere in the model.
You could also create a Controller class, so that nothing in the View knows about the Model, and vice-versa.
TBH you really just need to play around with things. Try a few methods, and if they don’t work just chalk them down as experience.
Remember that it’s all really upto the developer. There are preferred methods, but i highly doubt anyone is going to beat you with a stick for not doing it ‘their way’ (At least at this point ;-).
Well that’s my 10cents anyway. I hope it helps.
Mathew Schofield
"Show me someone perfect, and i’ll show you an idiot."