Thing I whipped up today:

jofers · Master

I wrote part of a GUI library today:

Sisophon2001 · Master

Hi jofers:

I prefer Option 1 because it will give smaller exe sizes and that would be my goal, and you have stated that it is also your goal. I think you can cover 90% of needs with a core set of "widgets", and then just leave a general catch all messages function for the remaining 10% of more advanced code. With time others could add more “widgets” to your library without any increase in size of existing user code. With Option 2, the way you described it, I can imagine your code base growing over time and exe size growing and growing with it.

People don’t need to memorize 200 or 2000 function names. They need a list to look up.

Your hooked HookEvent functions must be real functions returning integers, not just subs as in your small example. Then a user can cancel a close event, etc. Perhaps you already are doing this, but you just made a simple example.

Don’t leave out the option for icons!

And yes, I think there is a need for a light weight GUI library for FB.

Have fun

Garvan

Dare2 · Posted: Oct 02, 2005 0:58 Post subject:

Hi jofers,

This is a great idea/project! It would be a real boost.

If I understood your drift ..

Couple of thoughts. As Garvan said, a reference text is all that is needed. Needed anyhow.

Also, syntax could make the calls seem intuitive. Eg:

ButtonTextSet, ButtonTextGet, ButtonStateSet, ... EditorTextGet, EditorTextSet, etc
If the dependencies behind the scenes are worked out well, then with Include Once -ing shared bi files will help keep size down. So, for eg, only structures, udts, api-calls and etc that needed are actually every used.

And finally, things like myHandle = ButtonCreate(x,y,w,h,etc) gives the way the thing can be manipulated later, via myHandle, eg ButtonTextSet(myHandle,"TEXT")

If I missed the point, ignore this! :)

However, a GUI lib sounds ace!

You talking windows or linux.

If windows: I am very scratchy on FB and don't spend a lot of time with it, but time and ability permitting I would be willing to give some help. I have some small experience with windows API, mostly through wading through the SDK documentation trying to learn how to do things.

Mind you, I might waste more of your time asking questions initially than I save by helping. I won't be insulted if you decide to play it safe and decline the offer.

Edit: In fact, thinking it through, perhaps best if I don't participate. But if I see things I can help with I will pass them on to you to use as you see fit.

relsoft · Master

Great!!! My vote: #1

Joakim_ar · Posted: Oct 02, 2005 9:56 Post subject:

Yeah, sounds really neat :) My vote is #1 too.

whitetiger0990 · Posted: Oct 02, 2005 14:04 Post subject:

It's not gonna work on linux is it? =(

winAPIs?

jofers · Master

I don't know much about Linux programming. I'm trying to keep the function names unique so if someone ever wanted to make a GTK wrapper they could.

However, it would be difficult to make a single GUI library that would compile on any platform, because almost every action or function is dependent on the OS. Two separate ports would have to be maintained (and I encourage it, if I go through with it).

You guys really want #1? I'm a little protestant towards it because I work with Java. Dealing with that API is a gaddanged nightmare. You have to look up every little thing, even stuff like remembering string functions. And there are soooo many packages to keep track of. Yuck.

I might meet you guys halfway and remove the FBGui.Button.ChangeText() bit to FBGui.ChangeText() with overloading and unions. It just seems that so much in terms of GUIs overlaps, I shouldn't have to write "button" over and over and over again. But I'm in favor of keeping as few functions to remember as possible.

Z!re · Guest

[Content removed at author's request]

Antoni · Master

I agree with Z!re...

jofers · Master

Okay, here is the system I've decided on, after some careful thought.

1) Users will only use (DIM) two type structures: FBGui.Window and FBGui.Object

2) Object-specific data will handled internally by a void pointer to another structure.

3) Objects will be initialized with control-specific functions: CreateWindow, AddButton, AddScrollBar, etc. These functions will return the object.

4) Users will actually deal with pointers, but that'll be hidden with Type definitions (already implemented in the demo).

5) Each initializing function will load all control-specific routines (SetText, SetTitle, SetWidth, etc) for that control into a big master structure with room for function pointers for every control supported by the library (~1kb in memory)

6) All control-specific functions will be stored in separate modules. Adding a button with AddButton will load all the button routines into your compiled program.

7) When you do call SetText, SetWidth, etc... That function will look up the type from the object you feed it, and then look up the appropriate function to use in the control-specific functions stucture, and then use it.

Pros:
* Users will only have to specify what type of widget their dealing with once, when they initialize it.
* The actual number of manipulation functions is kept low.
* The compiled program will only contain the routines it needs, so simpler programs will be very small.

Cons:
* The simplicity means there will be some monkeying around to find the right functions to use for the right object.

Justification:
* That overhead is miniscule, unless you call those functions 1000s of times a second.

If there are any major protests to this format, let me know, or otherwise this is how the library will work.

Now, I just need one more bit of input from you guys: how should changing widget properties be done? There are two ways:

1) Many functions:
FBGui.SetText(MyObject, ...)
FBGui.SetWidth(MyObject, ...)
FBGui.SetBgColor(MyObject, ...)

2) One function, one extra parameter:
FBGui.Set(MyObject, FBGui.Text, ...)
FBGui.Set(MyObject, FBGui.Width, ...)
FBGui.Set(MyObject, FBGui.BgColor, ...)

Now, this is one occasion where consolidating functions doesn't add overhead, since these functions are just lookups anyway. So #1 is actually bigger than #2. Also, #2 may appear like a more uniform syntax. However, #1 involves less typing, and probably looks clearer to beginners.

So fire away, which should I use? Since I would not like to have functions with dozens of parameters (e.g., many WinAPI functions) or functions that take in a huge user-defined structure (e.g., many WinAPI functions), users will probably have to set some properties after the control has been added to the Window if they don't like the default values.

Also: You can expect very simple programs to be small enough. As you can see in the demo, there will be about 20-25kb in runtime library overhead, .exe format, and window set-up. Simple controls like buttons and input boxes will probably only have about 5-6 functions apiece.

Xerol · Posted: Oct 03, 2005 16:45 Post subject:

#1 looks cleaner, and you've still gotta memorise/lookup stuff for either method, so I'd go with #1.

yetifoot · Master

1) Many functions:
FBGui.SetText(MyObject, ...)
FBGui.SetWidth(MyObject, ...)
FBGui.SetBgColor(MyObject, ...

i prefer this way, looks like the win32 api, which would make it easier for those of us with a modicum of win32 knowledge.

what about the VB style way?

MyObject.Text = "Text"
MyObject.Width = 200

etc?

i'd guess this would mean doing it in a OOP way that i dont know if its possible in FB?

edit.

just seen number #2 is kind of like this but not quite, so maybe i prefer #2 !?!! i dont know!

jofers · Master

This library's goal is in no way to resemble the Win32 API. Using structure properties would be nice, but you would have to scan them pierodically, as FreeBASIC cannot overload operators yet (that will come with object orientation, another feature not available).

I think I will go with #1. #2 is smaller, but I'll trade a few extra kb for clarity.

VirusScanner · Sr. Member

The way of
MyObject.Text = "SomeText"
is called a property, and it's actually another way of calling a function (declared as property set). FreeBASIC doesn't support that, so you'd have to call an Update function every time you did that and I doubt anyone would like that.

yetifoot · Master