application looper objects, stream redirection and other gra
Posted: Mon Nov 17, 2003 3:26 am
Hail Blackhail, oh ye dark warriors...
Ok... Nothing big around these topics. I just need some clarification, because I maybe don't see the wood cuz of the trees.
1: Application looper object:
As far as my understanding reaches, this object is kinda thread of the application which fetches messages coming from the gui-service and processes them (triggers mouse events on button objects or tab objects) - i.e. calls the associated functions/handlers which are t be provided by the programmer. (c ++ interfaces). since I don't want the application to have to communicate too much with the service, most of the drawing - especially controls - will be done by the service upon request (i.e. app says: button1 at x/y) the service takes a button bmp and places it on the requested position in the app window.
this leads to the next question:
where to paint the controls:
Shall the application paint the controls or shall this be done in the gui service? What about Free Draw areas, where the application can put pixels directly (double buffered: local buffer for drawing via library functions, this buffer is located in a shared memory area - and the app sends message to the gui-service, when drawing is finished. gui service picks the data for the free drawing control from the shared memory area and updates the according are on the screen) I think it's faster to have some basic controls ready for use in the gui service: button, scroll bar, tab page, radio button, check box, text control (1 .. n lines), free drawing control for animations and free drawing (special treatment!!)), picture control (for displaying images) and some controls, which the application can layout at need.
Each control can be assigned to a handle via the application looper object, where the controls of the application are registered.
Well, there came up stream redirection...
stream redirection:
At the moment, I have two streams: Input and output. The input stream is only available for the active application. Bad design this is. but the output stream is done via pipes (hm: Buffer locations I call pipes): The best approach to compare them is with sockets: receiver: processID/pipeNumber sender: processID/pipeNumber
Is it possible/good design to assign such pipes to input streams too?
How shall I implement a *standard* input stream?
thank you for feedback!
stay safe
ps: and no, still no filesystem support available, but it is on the way. Have to do some research/learning. No one said it's to grow fast. *gg*
Ok... Nothing big around these topics. I just need some clarification, because I maybe don't see the wood cuz of the trees.
1: Application looper object:
As far as my understanding reaches, this object is kinda thread of the application which fetches messages coming from the gui-service and processes them (triggers mouse events on button objects or tab objects) - i.e. calls the associated functions/handlers which are t be provided by the programmer. (c ++ interfaces). since I don't want the application to have to communicate too much with the service, most of the drawing - especially controls - will be done by the service upon request (i.e. app says: button1 at x/y) the service takes a button bmp and places it on the requested position in the app window.
this leads to the next question:
where to paint the controls:
Shall the application paint the controls or shall this be done in the gui service? What about Free Draw areas, where the application can put pixels directly (double buffered: local buffer for drawing via library functions, this buffer is located in a shared memory area - and the app sends message to the gui-service, when drawing is finished. gui service picks the data for the free drawing control from the shared memory area and updates the according are on the screen) I think it's faster to have some basic controls ready for use in the gui service: button, scroll bar, tab page, radio button, check box, text control (1 .. n lines), free drawing control for animations and free drawing (special treatment!!)), picture control (for displaying images) and some controls, which the application can layout at need.
Each control can be assigned to a handle via the application looper object, where the controls of the application are registered.
Well, there came up stream redirection...
stream redirection:
At the moment, I have two streams: Input and output. The input stream is only available for the active application. Bad design this is. but the output stream is done via pipes (hm: Buffer locations I call pipes): The best approach to compare them is with sockets: receiver: processID/pipeNumber sender: processID/pipeNumber
Is it possible/good design to assign such pipes to input streams too?
How shall I implement a *standard* input stream?
thank you for feedback!
stay safe
ps: and no, still no filesystem support available, but it is on the way. Have to do some research/learning. No one said it's to grow fast. *gg*