A Wicked Awesome GUI

subxero · Posted: Feb 18, 2007 3:28 Post subject: A Wicked Awesome GUI

I've been working on a this for a good while. I stopped development for four or five months, and only recently picked it up again (it was hell getting FB 0.17 to compile it, but it worked.)

All of the controls are provided by dynamically-loaded code (in lib files) produced with gcc and linked with a custom linker. Windows are the same way, as are console objects, menu bars, and their child menus. Menus can be infinitely recursive (menu item opens submenu, who has an item that opens a submenu, and so on.)

The test stuff that's on the screen is produced by a test program that is loaded when the GUI starts up. The entire executable is about 100k, everything else is done by loaded code. All loaded code is, as of now, written in C until I manage to get my linker to wade through FB's output, and until I get FB's runtime lib ported (ouch.)

The skinning system is not my best work. It's not particularly flexible. I'm looking for a better way, ATM.

sir_mud · Master

Looks pretty sweet. Is it responsible for the "Desktop" too? or does it just make windows?

subxero · Posted: Feb 18, 2007 5:00 Post subject:

The windows are organized in a tree. There is the root window, which has children, who can have children, and so on. (Sadly, as flexible as it is, the window drawing routine, as a result, is ridiculously complex, but it's wicked fast.)

The desktop window (root window) can be operated on, it can receive and handle events. It can be drawn on, have controls/windows placed on it, et cetera, all by using the GUI's API. It's pretty easy to do.

axipher · Master

That looks pretty sweet, it's nice and slick, yet sophisticated to a level. Can't wait for a beta release, even more, possibly a Linux port.

Pritchard · Guru

You come out of no where with this all of a sudden? Sheesh, talk about drama. ^_^;;=b Wicked-Sweet.

Dr_D · Hero

looks really nice dude. keep up the good work. :)

subxero · Posted: Feb 18, 2007 6:13 Post subject:

Thanks for your comments :-)

This GUI is one of the reasons I posted a thread about "What's your favorite GUI font?" in Off-Topic a while back -- link: http://www.freebasic.net/forum/viewtopic.php?t=7208
I couldn't find a good, solid font that looked pleasing when loaded by FreeType. Still can't. Microsoft Sans Serif looks to be a winner, but I can't really distribute that :-P

I'm working on finalizing the main GUI engine -- after that, all development will be done in C unless someone wants to help me port the FB runtime library (not the gfxlib, just the rtlib.) My linker can't link C code compiled with any version of gcc other than the one that DJGPP uses (my linker calls LD to put all symbols in a common segment, which it can't do with output from other versions of gcc for some reason.)

After the GUI engine is finalized, I'm probably going to release it, as well as an SDK so that people can begin to write programs for it. I'll also release some type of documentation so that development should be nice and easy.

Would anybody use it, or develop for it, even just for fun?

thesanman112 · Sr. Member

I will develope with a sdk.. no problem.

cha0s · Site Admin

Yeah, that looks good.

Is this an open source project? Written in c/c++?

subxero · Posted: Feb 19, 2007 0:36 Post subject:

The entire GUI engine is written in FreeBASIC. The actual objects (buttons, checkboxes, whathaveyou) are programmed in C, and are loaded in by the main GUI engine. The main GUI engine handles graphics, fonts, tasks, program/library loading, object management, screen redrawing, and a few other things.

For example, right now, there is no option button (radio button) control. You could write one in C, and compile it, and place it in the System folder of the GUI's root folder, and the GUI will load it and its exported functions/data will become available to all programs loaded thereafter.

That makes the entire system ridiculously flexible. The only downside thus far is that programs/libraries written for the GUI must be written in C as of now.

Other than the fact that it's missing an actual kernel and a bootloader and all that, it's an OS in FB -- that's how I like to think of it, 'cause I think this is as far as anybody's ever gotten with an "OS" in QB/FB.

L_O_J · Posted: Feb 19, 2007 3:49 Post subject:

cha0s · Site Admin

gcc? if you can link with a c module, chances are you can link with an FB module too, as there's a lot of work done for binary compatibility.

It's a good idea though, to offload the heavy processing time to [any optimizing c compiler] and use FB for the human interface.

zerospeed · Posted: Feb 19, 2007 4:39 Post subject:

Quite impressive subxero!

Since you've been working under win32, let me ask you a few things:

1) Shared-library: you say that the system will load code from shared libraries that will be available to user (which will code the application with FB my guess). What kind of dynamic/shared-library tool did you implement compatible with DOS? looking AGES for that without any good result (blamming google).

2) Threading: I know will be DOS, but did you implemented or plan to implement/expose some threading library? (CLWP or pthreads?

3) Could you provide a brief overview of what you will provide, how end-user (aka, US) will interface with your "product" and for what the SDK will be for?

Guess the whole "OSness" of this project will be a great combo with FreeDOS to run my programs from USB Sticks :-)

Congratulations subxero!

Regards,

Zero

subxero · Posted: Feb 19, 2007 16:35 Post subject:

The whole loadable code trick is pretty awesome, I think. It works under Win32, DOS, and Linux, provided it's all x86-based.

Essentially, I have my own executable file format. gcc produces an output file using "gcc -c file.c -o file.o" -- the -c switch tells gcc to compile only, not to link. Then, you use a linker (well, not so much a linker as an executable writing tool) that I wrote called "al" (Accelera linker) -- "al file.aex file.o" will build the Accelera executable file.aex from file.o. Multiple .o files may be specified. My linker calls ld (the GNU linker) and creates a common segment for all symbols, and my linker wades through the COFF output and writes the program data and all relocations to the executable file. When Accelera (the GUI, if you didn't catch that yet :-)) loads in the file, it performs linking dynamically for those functions that could not be linked at link-time by al. The GUI exports most (not all) of its functions and internal structures to the global symbol table so that they're available to any programs.

Libraries work in a similar manner -- they are executable programs with an AclLibraryMain function that is called when the library is loaded. Inside this function, you may use the SYM_EXPORT macro to export all of the needed functions to the GUI's symbol table, which may then be used by all executables loaded thereafter.

Currently, I'm extending this to allow private libraries -- you could load in a library with LoadLibrary, and grab functions and data with FindSymbolAddress.

As of now, there is no threading, but there is a way to insert a constantly-running task into the GUI's task list. They're called "event handlers", but yeah, they're tasks. Each event handler has a single procedure that is called for every iteration of the GUI's main loop. There are also timer functions -- you can use CreateTimer to specify an interval and the function to call at that interval. The resolution for timers right now is 1 millisecond, but will be finer in the future after I fix all of the weird bugs with the GUI's engine (mainly memory leaks, as of now.)

If someone wants to implement threading for DOS, be my guest. I can't even figure that one out :-) However, if you succeed, make the implementation as friendly and as simple and clean as possible - that is a design goal for my GUI.

As for the end-user... I want my GUI to come with quite a few useful programs and libraries right off. I want a user to be able to do something cool with it without learning FB or C. The only way I can see that happening is if it comes with a set of useful programs. I definitely want a word processor, that'd just be wicked awesome :-)

Oh, and to FB compiler experts: I want my GUI to run FB-compiled code. To do that, I need to port the runtime library to my GUI. That goes way over my head for the most part. Is anybody willing to try it, or point me in the right direction, or just help me with it? I'm almost always online on MSN Messenger, if anybody has it and wants to contact me, feel free -- subxero at phatcode dot net.

I hope I answered/addressed everything. Thanks again for your comments/support :-)

DrV · Site Admin

There may be DOS threading support in the future (provided through the usual ThreadCreate et al interface) - no guarantees, though. :)