Start Menu

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
nuno_silva_pt

Start Menu

Post by nuno_silva_pt »

How can i make a start menu for my o.s.? ???
Whatever5k

Re:Start Menu

Post by Whatever5k »

Come on - that's not the first time you ask this type of question:
Please be more precised - nobody is able to understand what you are trying to say.
Peter_Vigren

Re:Start Menu

Post by Peter_Vigren »

nuno_silva_pt wrote: How can i make a start menu for my o.s.? ???
Please _try_ to stuff at least _some_ information in your post. It really isn't that hard. Better to write too much than, in this case, more or less nothing since no one can give a detailed answer to your questions.

But to your question... you can do it the way Windows do it. Create a directory/folder and display the content of it when the menu is pulled down. Actually this only covers the Program menu... but it can be used on the rest too...

It can be done in various other ways too... but unless you specify your question a bit more I can't answer more precise than this...
Tim

Re:Start Menu

Post by Tim »

To make a start menu:
1) Make an OS
2) Make a GUI
3) Make a start menu
Ozguxxx

Re:Start Menu

Post by Ozguxxx »

Hi, firstly I am just curious: Tim Robinson, is implementing GUI done after creating OS? I mean isnt gui a kind of shell? Shouldnt it be done while ereating os? So shouldnt order be like:
1) Make OS up to GUI stuff
1-a) Implement Buttons
1-a) Implement Icons(OPTIONAL)
1-a) Implement Bar functionalty
1-b) Make a start menu
;D THanx...
Ozguxxx

Re:Start Menu

Post by Ozguxxx »

1) Make OS up to GUI stuff
1-a) Implement Buttons
1-b) Implement Icons(OPTIONAL)
1-c) Implement Bar functionalty
1-d) Make a start menu

Im sorry, I have mistaken... This is the correct form... Sorry for taking space...
elias

Re:Start Menu

Post by elias »

why are people so gun-ho on making GUI's? this seems like the most boring part of writing an OS
Curufir

Re:Start Menu

Post by Curufir »

elias wrote: why are people so gun-ho on making GUI's? this seems like the most boring part of writing an OS
It's the visibility factor, exactly the same principle applies when you see people wanting to get their bootloader finished and jump straight into having the kernel put something on the screen. Visual stuff, even if just text, gives you that easy to achieve boost. The more tiresome work of reading through manuals and tuning the invisible code takes a bit more imagination to get inspired by.
stonedzealot

Re:Start Menu

Post by stonedzealot »

The most boring part? By no means. The GUI is how you show off your OS. Part of the appeal of MacOS (and XP, to a lesser extent) is the nice, curved look, the easy to use interface. You could write a very simple O.S. that basically will read text and write text, and slap a face on it that's beautiful, more people will want to use it than an OS that...burn CDs at twice the burners speed (impossible, I know but I can hope ;)) that looks ugly and is hard to use.
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:Start Menu

Post by Pype.Clicker »

nuno_silva_pt, you're addressing the problem by the wrong edge. When you want to make a word processing program, you don't ask yourself how you will have icons for "save", "print", etc. in a bar that you can move accross your window. You first ask yourself how you will represent text, how you will implement basic operations like extracting text from one paragraph and put text into another one, how you will deal with embedded objects like pictures, etc. or how you will store your text efficiently on a file.

Now, consider back your question. You can easily make a start menu with

Code: Select all

ytop=screen::height-(default::font::height+2*gui::padding);
xend=font::guess_size("Start")+gui::padding*2;
gui::rectangle(0,ytop, screen::width, screen::height,R_FILL,GREY);
gui::rectangle(0,ytop, xend ,screen::height, R_3D,GREY);
font::render(gui::getbuffer(0,ytop, xend, screen::height, USE_PADDING), "Start");
But what will you do with it ?
As long as you have no file system to load programs ? nor an infrastructure to give programs access to the hardware ? The very minimal steps if you want to have a "working" start menu would be:
  • have programs loaded in memory. And provide a fs-approach to access them. It can be very easy if you use GRUB modules to map programs in memory: you just need to create a virtual directory service that will remember at which physical memory address the image of FILE.COM is located and return that address when we do open("file.com")
  • have user-level programs executed when requested. The easiest approach is to create a segment for the user's code and one for its data. Then return to the program. You can even not worry about multitasking and decide every kernel operation will occur when an interrupt arise (that's how DOS works :)
    But you will at least have 1a. implement interrupts support and 1b. implement basic segmentation support. If you're fine with ASM, load ASM programs as a first step.
  • have the kernel access hardware. It should at least be able to receive the keyboard datas (and translate them ?), setup video display and read mouse events. The most simple GUI at kernel level would be get_video_segment(), set_mouse_buffer(), set_keyb_buffer(). The kernel know then where it should put datas.
    You can even protect your "start menu" from the user application by excluding the last lines of the display from the "video segment" you return to the application.
    Required steps are 2a. video driver (get a frame buffer), 2b. mouse driver (have a cursor moving on screen) and 2c. keyboard reader (have keystrokes translated and written to some memory area)
  • read available programs from the virtual file system and build up the list of "start menu" with it. Ideally, this should be done by some programs external to the kernel, but let's say you do it in the kernel (at initialization) for now.
  • when the start menu is clicked, popup the list. When an item is selected, start the application and freeze the currently running one. When the task bar is clicked, unfreeze the selected application. When the "user area" is clicked, defer the click to the application (send it an event).
    this requires 3a. Process control: select which program is currently running and 3b. Process sleep & wakeup: let the application decide that it have nothing to do but waiting something to happen and let the kernel return to the application only when something occured.
Here's the quickest roadmap i can envision ... but lemme tell you that the best you can expect from it is MACOS 1.0 or something alike ...

Maybe with better protection between apps ...
Post Reply