Windowing Systems by Example: 3 - I Like to Move It

[jojo]

http://www.trackze.ro/wsbe-3-i-like-to-move-it/

This week we utilize the framework we built out last week to finally bring some user interaction to our system in the form of a rudimentary cursor and the ability to raise and drag the window rectangles we've been building around, and finally gloss briefly over why it might not be a bad idea, in the future, to find a way to avoid redrawing every single little thing on the screen on each mouse movement.

As usual, thanks to all of you who have been following along this far! I hope I've brought you at least a modicum of somewhat informational entertainment.

[Octacone]

Again, great job! Your tutorials are really easy to understand and follow. I would like to see them coming out faster. The thing is I can't make my mouse driver work. I just cannot convert mouse movement and data into real world x and y. Your "mouse update location and send it to the desktop" function needs to be called per mouse interrupt and updated with the location accordingly. I can't do that I can't update it with real x and y (from 0-1920 and from 0-1080) because of the way that mouse works. I would also like to mention that it would be easier to merge context and window structures. Why do you keep mentioning JavaScript? JavaScript and C have very different approaches, C can be used standalone to make an OS, JavaScript is a language used for websites and other platform dependent uses. Making a window manager on your own operating system is not equals to making it on already given system interface. I would suggest you keeping your decoration as flat as possible, up to date without gradients and ugly 3D icons, maybe add show us how to make some drop shadows (that are equal to all 4 sides). My point is that it is easier for CPU to draw 15 flat colors than "25346" colors found in a gradient. Keep working on these tutorials, they are really helpful. Cheers!

[BrightLight]

The thing is I can't make my mouse driver work. I just cannot convert mouse movement and data into real world x and y.

Off-topic, and I (and several others) have already said this in another thread, the mouse does not tell you it's current position; it tells you how much it moved and which direction it moved to.
My PS/2 driver.

[Octacone]

The thing is I can't make my mouse driver work. I just cannot convert mouse movement and data into real world x and y.

Off-topic, and I (and several others) have already said this in another thread, the mouse does not tell you it's current position; it tells you how much it moved and which direction it moved to.
My PS/2 driver.

I am fully aware of that. I understand that concept. I just do not KNOW how to get a real location from that direction and how much it moved output. My OS is like 94% pure C so Assembly is no help.

[BrightLight]

I am fully aware of that. I understand that concept. I just do not KNOW how to get a real location from that direction and how much it moved output. My OS is like 94% pure C so Assembly is no help.

You don't have to copy and paste my code. Just read it; it implements the concept you know.

[Octacone]

I am fully aware of that. I understand that concept. I just do not KNOW how to get a real location from that direction and how much it moved output. My OS is like 94% pure C so Assembly is no help.

You don't have to copy and paste my code. Just read it; it implements the concept you know.

Getting off topic but yeah.
I read you code. The only part I am having problems with is the handler.
1.You make sure it is the mouse
2.You have a switch statement that does all the checks
3.3rd part you see what the data is
4.You store that data
5.You convert that data into an actual position -> I don't understand this part, I don't know what is going on (sorry but I am not as good as you when it comes to reading assembly) I only know that you check if mouse went of the screen and move it to maxX/maxY if it did.

[BrightLight]

Getting off topic but yeah.
I read you code. The only part I am having problems with is the handler.
1.You make sure it is the mouse
2.You have a switch statement that does all the checks
3.3rd part you see what the data is
4.You store that data
5.You convert that data into an actual position -> I don't understand this part, I don't know what is going on (sorry but I am not as good as you when it comes to reading assembly) I only know that you check if mouse went of the screen and move it to maxX/maxY if it did.

I'll explain everything in the private message.

[Octacone]

Getting off topic but yeah.
I read you code. The only part I am having problems with is the handler.
1.You make sure it is the mouse
2.You have a switch statement that does all the checks
3.3rd part you see what the data is
4.You store that data
5.You convert that data into an actual position -> I don't understand this part, I don't know what is going on (sorry but I am not as good as you when it comes to reading assembly) I only know that you check if mouse went of the screen and move it to maxX/maxY if it did.

I'll explain everything in the private message.

Thanks! Waiting for your message.

[jojo]

Hey, octacone, thanks as always for the words of encouragement. I really appreciate it and am enamored that someone is keeping so up to date with my frivolous ramblings.

To answer a few of your questions:

I would like to see them coming out faster.

Me too, of course. But between work, my other actual side-projects, the girlfriend and the rest of my personal and social life I'm quite frankly amazed that I've even been able to keep up with the weekly schedule so far. But this is also why I'm so thankful that anyone's getting anything out of it at all.

Why do you keep mentioning JavaScript?

Trying not to be too rude, here, I do think it's pretty clearly explained at the end of each article as well as in the README in the github repo that I have structured the follow-along-at-home code to be easily built with emscripten so that there's as near to zero barrier-to-entry for those who want to try out the concepts.

Thanks to this approach, I can both present the concepts using only one language -- and a language which can be trivially dropped into a bare-metal project at that -- while also providing an almost zero-dependency way for anyone following along to play with things. While I'd like to think that it's a near-perfect compromise, it does occasionally raise the odd complication; In this case, that dropping a while(1) into your code will hang your browser's render loop. Can't wait until web workers are more universal.

Making a window manager on your own operating system is not equals to making it on already given system interface.

Thanks to the magic of abstraction, that's completely false. If we wanted to, we could write a quick fake_os wrapper for fbdev and be running the demo code on Linux in lieu of X just as easily as you could do the same for your own OS project. Or you could do it with SDL2 or Allegro. Or emscripten and a canvas. All the same code, because the underpinnings are abstracted away.

I would suggest you keeping your decoration as flat as possible, up to date without gradients and ugly 3D icons[...]

While we wouldn't be getting there for a loooooong time anyhow, this series is not intended to perscribe the particulars of graphic design but instead the fundamentals of implementing the mouse+keyboard+window interface paradigm. When we start adding widgets and window chrome, you can feel free to stray from the particulars of my presented aesthetic to make them things appear however you want. And I hope that you do and have a lot of fun with it!

Keep working on these tutorials, they are really helpful. Cheers!

Cheers as well to you, and thank you so much again for keeping up with me and giving me your feedback! I hope omarrx024 gets you sorted with your understanding of relative mouse movement.

[Brendan]

Hi,

Thanks to the magic of abstraction, that's completely false. If we wanted to, we could write a quick fake_os wrapper for fbdev and be running the demo code on Linux in lieu of X just as easily as you could do the same for your own OS project.

Yes; but only if you never want to support things like hardware accelerated 2D (to make things like mouse pointer and window movement insanely fast), or multiple monitors, or device independence. Essentially, as soon as the GUI ceases being a "RGB pixel buffer toy" it has to depend on the OS's device driver interfaces.


Cheers,

Brendan

[Octacone]

@jojo

I found three bugs in your system.
Tutorial number: 3
1.Sometimes a window randomly disappears (not talking about corners)
2.Sometimes when you click to focus, another window behind it disappears
3.When you draw windows they randomly resize

Also couple of suggestions for your series: double buffering, title bars that you can drag windows with, borders that you can use to resize those windows, searching area behind the mouse by tags (for example if(GetTag(mouseX, mouseY) == "border/title bar/window area"), controls (button, label, textbox, scroll bar, picture box), drawing background image, closing windows, opening windows like apps, windows that are hooked with tasks, etc... All windowing system related stuff. I guess before you can start doing them all, you need to have one heck of a stable framework.

[jojo]

@brendan: A good point, but -- while not specifically addressed in my series for simplicity's sake, making the point certainly applicable -- that's the point of having the context class to wrap drawing (obviously jenked from GDI, but it's not an original concept). If you just abstracted things a touch further, you could swap out the given context implementation for one that uses your video card's acceleration for its drawing operations. Really, the only reason I didn't abstract one level up and make 'fake_os' provide a pre-baked context object is because the drawing functions themselves are going to be so critical to making our GUI happen that I would rather show an example of how they could be manually done than not. But it could've been, making my point about abstraction still hold true vs. octacone's original assertion that I was addressing.

UPDATE/EDIT: Also -- and please trust that I wasn't out looking to specifically refute you, it was just a happy coincidence -- I decided to read through everything I'd done so far to see how I was feeling about my direction and I noticed that at this point in the second article I kind of gloss over this point in footnote 7.

I found three bugs in your system[...]

Are you running this in the emscripten harness or in your own os code? If you're running it with emscripten, what browser are you using? If not, how solid is your malloc implementation (that's something that I think could easily cause your issue #2 in the case that the list fails silently in allocating a new list node after the window being raised gets popped out of its position and is in the process of pushing it to the end of the list)?

Otherwise, not to dismiss you, but I've tested this pretty extensively and have not been able to replicate the behavior you describe. If it's in your own OS, it might all still be malloc issues. For instance for some reason your malloc might be overlapping the region allocated for window objects with other objects and if so this could cause values such as that window's dimension properties to get clobbered when writing to the overlapped object (otherwise, I'm not sure what could be causing this as none of the code to this point touches the window dimensions anywhere besides the window constructor). The same could also be causing your disappearing windows if writing to such an overlapped memory region clobbers a window's coordinates so that they're way off the screen.

Anyhow, that's just me wildly speculating. If you could provide me particular test cases that can reliably replicate the behavior you're describing, I would very much appreciate having them so that I can improve any issues that do exist.

Also couple of suggestions for your series:

50/50 thanks for your input/patience grasshopper

[Octacone]

@jojo
I am running it within my own OS. My malloc function is 10 times worse than the worst thing your mind can imagine. Also I noticed that If I set my resolution to something bigger than 1360x768 I get a blue screen of nothingness. So clearly that is the issue, thanks for the output.

[jojo]

Glad I could help guess the right direction. For what it's worth, I just think it's cool as hell to know that anyone following along at home is actually embedding it into their project and tinkering with it in its intended context.

To be quite frank, I myself actually haven't had a chance to bolt it into P5 yet, ironically.

[Octacone]

@jojo @otherGuys
I have some rather interesting news. I have just finished porting this library: https://github.com/Snaipe/malloc
I am still having all those issues. When I move a window to the left it gets shorter and when I move it to the right it gets taller. Also I can't create 1920x1080 buffer, I get a pure blue screen. Now the thing is that I could not really port "sbrk" so I made my own. Now do you think that this version of "sbrk" is legit?

Code: Select all

char* sbrk(int bytes)
{
	char* base;
	base = kernelEnd;
	kernelEnd += bytes;
	return base;
}