pulsar wrote:hi,
whenever a control is to be drawn, the full screen is invalidated and all the windows should be drawn once again. this seems to be less efficient, it is just enough to send the invalidate rectanlge information to the window having that control, but it seems more complex right now.
how to send keyboard and mouse messages to the application. should the window manager poll for the events, or some type of callback method can be used?
@Dex4u : in some thread you said, from the beginning itself you have to plan for making windows skinnable. i don't have any idea of how to draw windows using skins?
It is much more efficient to only update rectangles that have been modified, unless it happens to be the majority of the screen. The method provided does seem difficult to update only rectangles, as it is only building a queue of things to do. Another method is to go through the list of windows and see if has changed, if so, call it's draw routine, which in turn calls each of it's controls draw routines. If the window moves, tell it to redraw everything. Many methods, they all can work if done correctly.
As for inputs, inputs or messages are about the only 2 viable methods. Lets break them down a little bit:
Callbacks: Each window/control has a method to be called when you click/move mouse, press key.
Pros: Very fast response time, no wasted memory
Cons: This is interrupt driven, what if another process has the CPU for it's time share, and here we are running a click method for a control, that process just lost it's time slice! I know there are solutions to this, but they are somewhat specific to your design. Is your gui part of your kernel, if so you can put some code in the scheduler to check for events each time, or queue the events in your gui engine, then issue them once it gets control back, this ends up similar to messaging, except only the gui has a master list of events, and issues them out, instead of each process processing it's own messages.
Messages: Each window has a message queue.
Pros: No process will ever wait on another process, because they all process their own messages in their own time.
Cons: Slower response time, must wait for this app to get control again before it will process messages, then it has to process and translate them! Fixes of course include things like informing the schedule that a process has messages waiting and to put it higher in the priority list (may be required for things like Idle processes!).
I dunno, they both have their merits, and ways of correcting defficencies. Either one will work, depends on your OS and stuff as well.
Skinable windows are easy, you simply have a bitmap layed out for the window. Just have the positions in this bitmap static, so if you replaced the bitmap with another it would draw properly. For example: The top left 16x16 area is the top left corner of your window, the next 16 pixels acress is the top right of the window, the 16x16 area under that is the bottom right, and the 16x16 area to the left of that is the bottom left corner. Then you do the same for say, the left,top,right,bottom borders. Now you have a bitmap that you can easily replace with another, and if you put all the pieces in the correct spots will look correct. You can get more indepth like a config file of sorts, something that tells it where each section is located in the bitmap instead, and things like default color or fading colors, etc. My gui I had allows you to set each windows background gradient (horizontal or vertical), the title bar gradient, and uses a bitmap to store the windows edges. You can also asign a different image to the background instead of using a gradient as well. It is very simple to change the color, font color, etc of all of the windows this way.
. Possibly some sort of draw bitmap from memory or similar functionality?
.
