I would like to make a request...
(or if noone else will bother to do it.. i will after i finishe a few other projects in MeOS)

Currently, the kernal does not allow a process to draw outside its window...
unless you count background stuff... but thats not what i mean.
Also, you cannot draw pixels, lines, etc unless the process HAS a window...

Bassically this prevents having threads do anything graphically usefull.
It also prevents some drawing which could be useful/interesting.

I would like to make GUI code that runs seperate threads... for things like
textboxes,menus, drag and drop controls. Threading would allow for better controll of events to such GUI objects, including mouse movements.

So perhaps the basic drawing procedures could have additions to them that would allow the programmer to draw in any process window, based on its process ID.

What does everyone think?
Wishing

Good Idea, sounds good, I'm sorry but I don't know asm

humm.. I'm not sure how you could efficiently transfer the data from one application to anothers window. You might want to discuss the design as it evolves before doing any coding.

Cheers,

Mike

there would be no data transfer at all...
One application would simply be able to spawn threads
(bassically other applications)
and they would be allowed to write outside of thier own window...
since they are threads... there is no context switch in the cpu... therefore they can access data from the parent process. Things like the window position... then all you have to do is draw 'above' the window below...
All of this stuff already exists witht he exception that threads and programs cannot draw outside thier own windows...

All that is needed is to allow process and threads to be able to draw anywhere on the screen, even if they dont have a window.
there must be some bounding procedure in the drawing routeins that could be overiden...

Wishing

But what happens when another application draws over that 'drawing'. How do you know that the original application must redraw it? What if the drawing went over another applications window?

I haven't played with it myself, but have you tried this function?

61 = DIRECT GRAPHICS ACCESS

ebx = 1 - get resolution -> eax [x] shl 16 + [y]
ebx = 2 - get bits per pixel -> eax
ebx = 3 - get bytes per scanline -> eax

direct access with gs selector : mov [gs:0],dword 0xffffff


Mike.

IMHO, It's much better to have one thread doing all the drawing than several pieces of code all over the place.

Another possibilty would be to use transparent windows. This way we could detect if application X is trying to write over app Y. (& pretend it -is- app Y)

If app Y is a system warning of the
"App X wants to delete all your files, is this ok? [Yes/No]" type.
It's much easier to prevent app X writing "Click yes to continue [Yes/No]" over it.

Mhmm, we already have this bug with the icons (if you click an icon that is half covered by an app, it will "cut" a piece out of the app ) so the code could get handy inhere too

I would think thats having a textbox be seperately threaded would be nice... since then the origonal app could continue drawing whatever while you entered in afilename etc...
To tell if the origonal application must redraw it... the origonal application simply tells the thread to redraw when it needs to redraw... and since the thread is only writing atop its parent process window... thats ok... since if one needs to be redrawn they both do anyways. I dont mean drawing outside of EVERY window like atop the desktop... but drawing only over another window, yet outside your own. Ie you can only draw 'down' the window stack one level.. or something along those lines.

I like the transparent window idea...
also about the icons... the moveable icons I made have problems like that too... they can only get the background image... and not the actual video ram... so when you move em over like the panel bar... they draw the background behind it over it.

Wishing

Wishing, how many processors / system buses do you have on your server?

MATRIX

Why does it matter? were not talking about atomic assembly code... threads have nothing to do with that. What server are you talking about?
I only have one CPU.

I would think thats having a textbox be seperately threaded would be nice... since then the origonal app could continue drawing whatever while you entered in afilename etc...

i was thinking about your previous thoughts especially about that while

MATRIX

I honestly still dont follow you...

are you trying to say there is noo need to have threaded textboxes?

What about as you MADE that post in this forum... werent there .gif smiley animations animating AS you typed in the post textbox?? I wouldnt be surprised if those animations are seperate threads from the one the textbox is. Currently in Menuet, most of the apps must stop and wait for the contents of a textbox to be filled out. Now in some.. this doesnt matter at all... but perhaps in the future it will.

well maeby noone understands me,
no problem i have already got used to it.

MATRIX