application looper objects, stream redirection and other gra

[distantvoices]

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*

[Pype.Clicker]

honestly, i'm rather for the server-side rendering of GUI stuff. It now has been sufficiently proved with techniques such as PostScript, Flash, html, TrueTypes, etc. that complex rendered object can be abstract in a small data file and interpreted as close from the screen as possible.

As we're both in a microkernel approach, there are several things we can do that a monolithic system cannot (or hardly can):
1. the video server has plenty of virtual memory to load plug-ins. Loading the font renderer once in the video server will be more efficient and easier to handle than loading the font rendering library in every application.
2. crashing the video server is not that painful as in a monolithic system: it's just a service that *caches* some of the display features (i.e. which window is drawn, etc. is also known by the application, and thus the whole display could theorically be restored after the server respawns).
3. if needed, the video plugins could be instanciated as independent user-level programs (for beta/alpha stage plugins)