Nuklear immediate mode GUI - C and small

[Eggy]

Hello, all!

I just discovered Pelles C today, and I am very happy to have a minimal C with such a great IDE!

I am trying to learn a lot from the ground up, so minimalism is my mantra. I know how to program console apps in C, but now I am moving to graphics. I have a little OpenGL experience in other languages, but I found this immediate-mode GUI called Nuklear

https://github.com/vurtun/nuklear

...and I was wondering if anybody could look at it briefly and maybe let me know where to start? I have tried a dozen or so things, but I have not been able to get the example or one of the examples working with Pelles C. I tried the Example on the readme page at the very bottom.

Here is the code so far from the page:

Code: [Select]

#define NK_IMPLEMENTATION
#include "nuklear.h"


/* init gui state */
struct nk_context ctx;
nk_init_fixed(&ctx, calloc(1, MAX_MEMORY), MAX_MEMORY, &font);

enum {EASY, HARD};
int op = EASY;
float value = 0.6f;
int i =  20;

struct nk_panel layout;
nk_begin(&ctx, &layout, "Show", nk_rect(50, 50, 220, 220),
    NK_WINDOW_BORDER|NK_WINDOW_MOVABLE|NK_WINDOW_CLOSABLE);
{
    /* fixed widget pixel width */
    nk_layout_row_static(&ctx, 30, 80, 1);
    if (nk_button_text(&ctx, "button", NK_BUTTON_DEFAULT)) {
        /* event handling */
    }

    /* fixed widget window ratio width */
    nk_layout_row_dynamic(&ctx, 30, 2);
    if (nk_option(&ctx, "easy", op == EASY)) op = EASY;
    if (nk_option(&ctx, "hard", op == HARD)) op = HARD;

    /* custom widget pixel width */
    nk_layout_row_begin(&ctx, NK_STATIC, 30, 2);
    {
        nk_layout_row_push(&ctx, 50);
        nk_label(&ctx, "Volume:", NK_TEXT_LEFT);
        nk_layout_row_push(&ctx, 110);
        nk_slider_float(&ctx, 0, &value, 1.0f, 0.1f);
    }
    nk_layout_row_end(&ctx);
}
nk_end(ctx);


Thanks for any help you may lend me here.

Rob

[Scripter]

I just discovered Pelles C today, and I am very happy to have a minimal C with such a great IDE!

I am trying to learn a lot from the ground up, so minimalism is my mantra. I know how to program console apps in C, but now I am moving to graphics. I have a little OpenGL experience in other languages, but I found this immediate-mode GUI called Nuklear

Pelles C is a full development environment. I've been using it exclusively for about 8 years now and have created a number of small to medium size projects with it. Most everything you need is provided but there are a few things you will need to make GUI mode programming easier...

Probably the most important lesson is that "GUI code ain't nothing like console code". For all it's dissimilarities it might as well be two different programming languages... but C being the workhorse it is, handles it all very nicely.

If you want to learn GUI mode C you will need to learn about message queues and tossers as well as  a very different program structure for windows. It's more complicated than console... but not that hard once you understand it.

Here are a couple of tutorials and books to get you started...

http://www.winprog.org/tutorial/start.html
https://www.geekbooks.me/book/view/programming-windows-5th-edition

You will also want a copy of the Windows SDK (Software Development Kit). The best one to start with is in the link below. It downloads (free) as an ISO file and covers you up to Windows 7.  I would not recommend starting with the "latest and greatest" as Windows 8 introduced those annoying tiles and Windows 10 has a mess of other stuff that makes programming both more restrictive and more complex. You can always move forward when confidence permits.

https://www.microsoft.com/en-ca/download/details.aspx?id=8442

If you want to integrate the SDK into the Pelles IDE you can get "addins" for the task here...

http://www.johnfindlay.plus.com/pellesc/addin/addin.html

Near the bottom you will find a collection titled simply "ADDINS" this will give you what you need to integrate the  SDK for F1 searches from the code editor and also a set of better tools to edit and create workspaces.

Hope this helps...

[Eggy]

Thank you for such an informative reply.

I had programmed win 32 GDI years ago for very small toy programs, so I am familiar with it.

I am leaning more towards things like a minimal OpenGL GUI, or slightly higher-abstracted GUI kits made with SDL2, SFML, or GLFW. I saw Nuklear and thought it would be great for my game jams to develop quick GUIs interactively and leave it that way for these competitions, not a polished endware.

Even GIMP is using GEGL, and Blender3D has always had their GUI in OpenGL allowing transparency on the various user windows or system windows you can have open.

Today I saw libui for C, and I am going to have to try that.

Nuklear is not as built up as Dear imGui is, but that is C++. I cannot get the demo/example to work in GCC or Pelles yet, so it is me, not Pelles! I was hoping somebody else may have an interest in it to get me past the first hurdle of running the demo. I am not very knowledgeable about the Pelles setup (yet!).

Thanks again for your reply. I will be sure to share back what progress, if any, I make.

Rob

[Scripter]

Thank you for such an informative reply.

I had programmed win 32 GDI years ago for very small toy programs, so I am familiar with it.

I am leaning more towards things like a minimal OpenGL GUI, or slightly higher-abstracted GUI kits made with SDL2, SFML, or GLFW. I saw Nuklear and thought it would be great for my game jams to develop quick GUIs interactively and leave it that way for these competitions, not a polished endware.

Even GIMP is using GEGL, and Blender3D has always had their GUI in OpenGL allowing transparency on the various user windows or system windows you can have open.

Today I saw libui for C, and I am going to have to try that.

Nuklear is not as built up as Dear imGui is, but that is C++. I cannot get the demo/example to work in GCC or Pelles yet, so it is me, not Pelles! I was hoping somebody else may have an interest in it to get me past the first hurdle of running the demo. I am not very knowledgeable about the Pelles setup (yet!).

Thanks again for your reply. I will be sure to share back what progress, if any, I make.

Rob

You're welcome.  I try to be helpful...

Of course there is one other source of excellent information about Pelles C ... the help file.  It's one of the best I've ever seen.

I suppose the only additional suggestion I can make here is that you should give the Windows API a try. It's the most direct way to work with windows and Pelles C will get you right down to the nuts and bolts of it very nicely. If you aren't a "quick and dirty" specialist, you may find the added depth quite useful.

My experience with both Object Oriented Programming (OOP) and multiple levels of abstraction would seem to indicate that most of the time all these techniques succeed in doing is bloating your code and introducing new bugs. Certainly they are not faster or easier to use. At some point in all these many layers of code, these so called "high level" development kits *still* have to call the Windows functions to make things happen... so why not go right to the source?

Take a peek at my website... download the "Portable Editor"... note the file sizes.  Yes, that's a fully unicode enabled, drag and drop, 64 bit notepad in less than 128k .... and... almost a third of that (46k) is the high colour 256x256 Win7 icon.  You won't do that with high level libraries.

I think (perhaps incorrectly) that most people avoid the Windows API because they don't understand it. I would suggest that is a challenge to learn not a cue to run... but that's just me.

[frankie]

The idea behind nuklear seems good, but the implementation is really poor.
Something declared as ANSI-C cannot have code in header files  . This is the nemesis of a standard compliant code!
Said that, the code is clearly wrote using C++ habits in many other aspects. This leads to problems when using a C only compiler as PellesC (of course if you use VC it will happily compile).
To check the capability of this code I attach an hacked piece demonstrating GDI.

[Scripter]

Said that, the code is clearly wrote using C++ habits in many other aspects.

Translated from C++, I'm guessing.

[frankie]

Maybe, but some comments make me think that is not a translation, but just a trial to write Ansi-C from a C++ background...
See the following piece of code:

Code: [Select]

struct nk_context
{
/* public: can be accessed freely */
    struct nk_input input;
    struct nk_style style;
    struct nk_buffer memory;
    struct nk_clipboard clip;
    nk_flags last_widget_state;
    enum nk_button_behavior button_behavior;
    float delta_time_seconds;

/* private:
    should only be accessed if you
    know what you are doing */
#ifdef NK_INCLUDE_VERTEX_BUFFER_OUTPUT
    struct nk_draw_list draw_list;
#endif
#ifdef NK_INCLUDE_COMMAND_USERDATA
    nk_handle userdata;
#endif
    /* text editor objects are quite big because of an internal
     * undo/redo stack. Therefore does not make sense to have one for
     * each window for temporary use cases, so I only provide *one* instance
     * for all windows. This works because the content is cleared anyway */
    struct nk_text_edit text_edit;
    /* draw buffer used for overlay drawing operation like cursor */
    struct nk_command_buffer overlay;

    /* windows */
    int build;
    int use_pool;
    struct nk_pool pool;
    struct nk_window *begin;
    struct nk_window *end;
    struct nk_window *active;
    struct nk_window *current;
    struct nk_page_element *freelist;
    unsigned int count;
    unsigned int seq;
};


[Eggy]

Scripter, frankie,

Thanks so much.

Scripter: I agree with you on the 'quick and dirty' and 'high-level' remarks. It is one of the reasons I was so happy to find Pelles. I deinstalled MSVS 2015 out of frustration with all of the tools and interfaces it provides. I come from learning programming in 1978 on a Commodore PET computer with a tape cassette drive and small monitor all-in-one unit.

I did Windows programming years ago, and then left to do mainly linux dev. The alternatives to Win 32 are not that good, but I want to continue to develop my crappy, but fun, cross-platform games, and Win 32 works on Windows only.
I am hoping to use something other than FLTK, or a pure OpenGL solution, but for immediate-mode GUIs I have only found imGui (formerly Dear imGui) and Nuklear.

frankie: Thank you so much for taking the time to work up a sample. It will help me to evaluate it, and to take in your criticisms of it.

I'll let you know where I get with this. I'm in East Java, Indonesia this year, so at +7 GMT, it's time to go to bed! Thanks again!

Rob

[Scripter]

Scripter: I agree with you on the 'quick and dirty' and 'high-level' remarks. It is one of the reasons I was so happy to find Pelles. I deinstalled MSVS 2015 out of frustration with all of the tools and interfaces it provides. I come from learning programming in 1978 on a Commodore PET computer with a tape cassette drive and small monitor all-in-one unit.

Me too ... wrote my first program on an old pdp11 using a ksr33 and punch tape. Got away from it for a while, rejoined the game just when the 8088 machines were coming out, been working in either Pascal or C ever since.

I did Windows programming years ago, and then left to do mainly linux dev. The alternatives to Win 32 are not that good, but I want to continue to develop my crappy, but fun, cross-platform games, and Win 32 works on Windows only.
I am hoping to use something other than FLTK, or a pure OpenGL solution, but for immediate-mode GUIs I have only found imGui (formerly Dear imGui) and Nuklear.

If you are doing cross-platform stuff:

1) My condolences 

2) You can safely ignore my comments. I've always been a "down to the gold" type who likes to talk intimately with my machines.  Of course that's not going to work with cross-platform code...


Good luck on your endevours.

[Eggy]

Scripter,

Good to hear we come from the same dynasty!

Your comments and opinions are valued to me, since I am operating in a vacuum here right now. I too would stay with just one platform or the other, but I run Linux and Windows for work and pleasure, so I am in that world

Also, for game jams, you up your exposure by providing it on many platforms, which is why HTML5 games are so popular there, and Love2D, a Lua-based game framework that runs on everything. There are 3D engines like Godot too, but like you, I want to program close to the machine with the caveat of using a GUI library, since there is no penalty in rendering. I do think the higher-level libs are too much abstraction, and I agree they make it harder than just dropping down and coding it natively. But for sound, graphics, i/o, it is hard to beat SDL2. It is not too far from the ground or gold as you say.

You have inspired me to do a little test. I will create a minimal game with a window, sound and logic:

1. Windows target w/ Pelles C, and the Win32 API for GUI (Wn32 native sound API?? for game dev? Or, do I need something like S?)

2. Linux target w/ GCC, and I should try to use X11 to make it a fair comparison, although I may use Gnome.

If I still have questions and time, I will try and do the same tests above using SDL2 or CSFML for both tests and compare again.

Thanks!

Rob

[Scripter]

Scripter,

Good to hear we come from the same dynasty!

Sometimes I think I've been at this too long. But then some interesting project pops up and grabs my attention and off I go again. 

Some of my pre-PC computers...
http://www.old-computers.com/museum/computer.asp?st=1&c=214
http://www.old-computers.com/museum/computer.asp?st=1&c=204
http://www.old-computers.com/museum/computer.asp?c=210&st=1

Your comments and opinions are valued to me, since I am operating in a vacuum here right now. I too would stay with just one platform or the other, but I run Linux and Windows for work and pleasure, so I am in that world

Edit:  Wine on Linux?

I've been there too.  At one time I was determined to "learn it all". Maybe it's age talking or maybe it's just too much for any one person but someplace along the way I decided to stay strictly with Windows and, despite repeated trials of other compilers, with Pelles C. I still puzzle over whether I'm in a rut or I've simply found the right tool for the work I do...

Also, for game jams, you up your exposure by providing it on many platforms, which is why HTML5 games are so popular there, and Love2D, a Lua-based game framework that runs on everything. There are 3D engines like Godot too, but like you, I want to program close to the machine with the caveat of using a GUI library, since there is no penalty in rendering. I do think the higher-level libs are too much abstraction, and I agree they make it harder than just dropping down and coding it natively. But for sound, graphics, i/o, it is hard to beat SDL2. It is not too far from the ground or gold as you say.

SDL is a better tool than DirectX ... but then my grandkid's etch-a-sketch is better than DirectX.

Over the years, in many hundreds of emails with a friend who works in IT, we have lamented the powerful stupidity of ActiveX, DirectX, COM and other pointlessly complicated inventions that are supposed to make things better while simultaneously frying the brains of otherwise competent programmers. Whatever possessed Microsoft to use OOP in core level functionality is one of the grand mysteries of our time.

You have inspired me to do a little test. I will create a minimal game with a window, sound and logic:

1. Windows target w/ Pelles C, and the Win32 API for GUI (Wn32 native sound API?? for game dev? Or, do I need something like S?)

2. Linux target w/ GCC, and I should try to use X11 to make it a fair comparison, although I may use Gnome.

If I still have questions and time, I will try and do the same tests above using SDL2 or CSFML for both tests and compare again.

If you truly do need/want to issue multi-platform code this will be little more than a side trip but it would be very interesting to see what you come up with. 

My original suggestion that you should equip yourself with the SDK still stands. You actually only need the documentation. Pelles comes with it's own version of the libs and headers and, as you will see in other threads, it does not work at all well with the ones Microsoft provides. So most of what you need is already on your system. But, even if you are using primarily high level libraries for your work there will still be occasions where you will need to delve into the guts of Windows to get what you want. It will be to your advantage to know enough of the SDK and GUI mode programming to be able to do that when necessary.

But I should be honest here and tell you that Pelles C may not be the best tool for the type of coding you are describing. Pelles big strength is in console mode or smaller control/dialog based GUI projects... the kind of stuff I write. I would never consider writing (for example) a multimedia player in Pelles C.  To truly use the OOP constructs needed for graphics and sound in Windows (except at the most primitive levels) you really do need to be on C++. 

You may find this interesting... http://orwelldevcpp.blogspot.ca ... this is a continuation of the old DEVCPP project using GCC and it's derivatives.  I've tried it out, seems ok, but it's not the best tool for what I do so that was only a trial. GCC lacks exception handling --try-except and try-finally-- which is a necessity in the kind of work I've been doing for the past couple of years.

Still, the experience should be very educational and I will be interested to see your results.

[Scripter]

Maybe, but some comments make me think that is not a translation, but just a trial to write Ansi-C from a C++ background...

Ok, that makes sense ... thanks.

[Eggy]

Me too!

This was my first, and I am tempted to buy one in supposed working order.

http://www.old-computers.com/museum/computer.asp?st=1&c=191#ebay

I also owned a Vic-20, Amiga 1000, Amiga 500 and then a slew of PCs. I had an NCR 3125 3086 pen-based tablet computer in 1996!

Edit:  Wine on Linux?

I've been there too.  At one time I was determined to "learn it all". Maybe it's age talking or maybe it's just too much for any one person but someplace along the way I decided to stay strictly with Windows and, despite repeated trials of other compilers, with Pelles C. I still puzzle over whether I'm in a rut or I've simply found the right tool for the work I do...

[Edit]
No, I know when I am in over my head. That is why finding Pelles C was so fortuitous.

I am resolved to stay minimal with languages like C and J. It is the reason I wrote 8-bit chip programs in C and Forth years ago, and thoroughly enjoyed it.

The J programming language reminds me of those early years. You can do so much in the interpreter/REPL - graphics, plots, high-level math all in a very terse syntax. It is the one language that has remained most constant aside from C, and not just as a desktop calculator. Some really serious companies and programmers use it like the ones that use qdb/k.

I am forced to use Python, Lua and JavaScript at times, just because they are the only thing made available to me.
Most of my paid programming background was writing data munging or cleanup programs in the 90s, and some DBA work in the early 2000s. Nowadays, I pretty much code toys for myself to further my personal studies into mathematics, art, music, etc... and have great fun!

I am resolved to master J and stay with C, no C++, too big and unsuitable for my tasks (well, not the games, but for the minimal games, yes). And, I never really bought into the OOP thing. I have put aside Haskell, F#, and others until I make at least 100 more things in J and C. I am now just looking at hooking into J via C and C with J.

My original suggestion that you should equip yourself with the SDK still stands. You actually only need the documentation. Pelles comes with it's own version of the libs and headers and, as you will see in other threads, it does not work at all well with the ones Microsoft provides. So most of what you need is already on your system. But, even if you are using primarily high level libraries for your work there will still be occasions where you will need to delve into the guts of Windows to get what you want. It will be to your advantage to know enough of the SDK and GUI mode programming to be able to do that when necessary.

[Edit]
I have already started on them, thanks! I have to say, though, I now remember why I gave up any Win32 API GUI stuff with C and Windows: I dislike the verbosity and cryptic or non-ideal names for things. As big as some of the other libs are, they use sensible names without all caps and other such obfuscation and aesthetics. It does produce the best Windows on Windows though, and it is just personal taste, not mechanics. It's coming back to me each day...oh, the horror

BTW, stubborn Googling led me to this perfect example of an immediate-mode GUI for what I need.

http://anttweakbar.sourceforge.net/doc/

Development has stopped, but it works wonderfully as is, has plenty of examples to show it with different libs, SDL included. I only have to get SDL2.0 working with it, and just use it and C!
I am having a hard time figuring out where to link, and include things in Pelles C. The fields are there sure, but I am used to command line links, and just relying on <include>s in my source. Since people who do game jams usually bundle everything for distro to ensure everyone can try it to judge it, I am putting the  necessary files in my Pelles C project directory, adding them to the 'Folders' and 'Linker' tabs.

Thanks!

Rob

[Scripter]

No, I know when I am in over my head. That is why finding Pelles C was so fortuitous.

I am resolved to stay minimal with languages like C and J. It is the reason I wrote 8-bit chip programs in C and Forth years ago, and thoroughly enjoyed it.

I mainly ran the BASIC, Turbo BASIC, Turbo Pascal, C route, like probably most people getting into this back then did. Unfortunately, in this day and age programs are not that simple anymore. Now you need manifests, resources, exception handlers, code signers, installers, and on and on if you are to produce anything more than a cute guessing game for your kids.

The J programming language reminds me of those early years. You can do so much in the interpreter/REPL - graphics, plots, high-level math all in a very terse syntax. It is the one language that has remained most constant aside from C, and not just as a desktop calculator. Some really serious companies and programmers use it like the ones that use qdb/k.

I had to look J up ... interesting.

I am forced to use Python, Lua and JavaScript at times, just because they are the only thing made available to me.
Most of my paid programming background was writing data munging or cleanup programs in the 90s, and some DBA work in the early 2000s. Nowadays, I pretty much code toys for myself to further my personal studies into mathematics, art, music, etc... and have great fun!

My "pro" work (which actually subsisted with a service manager's job) was primarily concentrated on diagnostics and simple utilities. This is where I got the "really tiny program" thing from and I think it's actually an interesting area to play in. As one member of a Pascal forum once said after seeing an early version of my FSVerify tool: "You don't just write small programs, you write small small programs". 

I am resolved to master J and stay with C, no C++, too big and unsuitable for my tasks (well, not the games, but for the minimal games, yes). And, I never really bought into the OOP thing. I have put aside Haskell, F#, and others until I make at least 100 more things in J and C. I am now just looking at hooking into J via C and C with J.

I don't even want to guess how many times I've tried C++ and OOP code only to eventually find my way back to the basic languages like C or Pascal. Of course Pascal is now a dead language with almost no worthwhile development happening at all... otherwise I'd still be there. Pascal uses a very C-like syntax but produces much "safer" code since everything is bounds and overflow checked... which C doesn't even know how to do.

My original suggestion that you should equip yourself with the SDK still stands.

I have already started on them, thanks! I have to say, though, I now remember why I gave up any Win32 API GUI stuff with C and Windows: I dislike the verbosity and cryptic or non-ideal names for things. As big as some of the other libs are, they use sensible names without all caps and other such obfuscation and aesthetics. It does produce the best Windows on Windows though, and it is just personal taste, not mechanics. It's coming back to me each day...oh, the horror

Microsoft has a "naming convention" for their SDK code and once you get used to it, it does make sense and it does provide some "instant recognition" to your code.  For example when you see something like WIN32_FIND_DATA you know it's a struct or when you see CopyFile you know it's a function call. and so on..

It just takes some getting used to.

I am having a hard time figuring out where to link, and include things in Pelles C. The fields are there sure, but I am used to command line links, and just relying on <include>s in my source. Since people who do game jams usually bundle everything for distro to ensure everyone can try it to judge it, I am putting the  necessary files in my Pelles C project directory, adding them to the 'Folders' and 'Linker' tabs.

If you install the WSEdit3 addin from the link I gave you, you will see that I've solved that problem for you.  Pelles C includes a define (#define WIN32_DEFAULT_LIBS) that will auto-include the correct libraries when adding headers with #include. When you create projects and workspaces with WSEdit the define is already hooked into your program settings...

Alternatively you can use pragmas in to include individual libraries.  There are two ways to do that...

Code: [Select]

#pragma lib <library name>
or
#pragma comment(lib, <library name>)

Both are described in the help file in the command line tools/pocc section. The first one is Pelles specific the second (ugly) version is more generic.
If you are looking for examples... this is from the top of one of the files in my Renamer project...

Code: [Select]

// the rename algorithm
#include "..\renamer.h"

// include library in search path
#ifdef _WIN64
#pragma comment(lib, "..\\ren64.lib")
#else
#pragma comment(lib, "..\\ren32.lib")
#endif

Also, if you are incorporating third party libs, you can modify your search paths in the Project Settings->Folders tab to include the relevant folders.  This is better than creating dozens of duplicates in your project folders.