|
Post by basica on Apr 23, 2016 18:43:30 GMT 1
Here's a GUI toolkit I just ran across that might be a fit for Bacon. Here's the summary- It can be found here and is called Nuklear basica (I haven't checked this out, so let's hope the name is not an indicator of radioactivity )
|
|
|
Post by Pjot on Apr 23, 2016 19:33:40 GMT 1
Thanks basica, This actually is the zahnrad toolkit, which apparently has a new name. The link also will, as you will see, redirect automatically to 'nuklear'. BR Peter
|
|
|
Post by alexfish on Apr 23, 2016 21:37:55 GMT 1
Hi basica
You are Correct
on some systems
Not shower .. err Sure of the extent of the Fallout.... radio active or not. found one bug in a struct called
tab not good for gcc compilers an shows up in g++
BR Alex
|
|
|
Post by vovchik on Apr 23, 2016 22:10:03 GMT 1
Dear all, I got all the Nuklear stuff to compile and run using all the relevant back-ends (GLUT, GLFW, SDL and Allegro). Do not know what skinning you can do yet, and just starting to look at the code. Our homebrew stuff may be more efficient (and more fun), but have to have a closer look. Could be that the TTF stuff is better than STB, and that could be lifted. Too early to say. With kind regards, vovchik
|
|
|
Post by alexfish on Apr 23, 2016 23:18:14 GMT 1
Hi Vovchik manage to trace the problem on Raspy Funny U should mention fonts , looks like I be getting what Peter & U'r self were getting Here is where the problem be at on the Raspberry RE:: nuklear.h text = buffer; text_len = length; glyph_len = nk_utf_decode(text, unicode, text_len); while (glyph_len) { if (i == index) { *len = glyph_len; break; }
i++; src_len = src_len + glyph_len; glyph_len = nk_utf_decode(text + src_len, unicode, text_len - src_len); } if (i != index) return 0; return buffer + src_len; }
Yet the X11 demo works , that uses the x11 fonts Thing is , the way the Window is done = Pretty Dam Cool:: So now taking a closer look , but do know one of the problems in the GLFW Hints , have changed those Now that cured the initial seg fault , since the Create window is not check , here the original code with hints window = 0 BR Alex
|
|
|
Post by barryk on Jul 3, 2017 14:17:35 GMT 1
Have you guys thought any further about using Nuklear with baCon?
I have encountered it recently. Compiled the simple C example for X11, a window with half a dozen widgets in it. Stripped, it is 157KB, and the deps are libX11, libm, libc, libxcb, libdl, libXau, libXdmcp.
I was wondering how big it would be if compiled statically, against musl or uclibc?
I have been wondering about the possibility of getting a gui app running in the initramfs in my experimental new Easy Linux. It would probably have to talk directly to the framebuffer, which maybe means the appropriate kernel video driver would have to be built in to the kernel, not a module -- or maybe not, for basic framebuffer writing to the screen.
Maybe the tiny X server that goingnuts is working on (see "Xwoaf" in the Puppy Forum), could run in the initramfs.
Just a few wild thoughts!
|
|
|
Post by Pjot on Jul 4, 2017 17:40:36 GMT 1
Thanks barry, We have looked into this before. The strength of this Zahnrad/Nuklear toolkit is also its weakness: the list of drawing commands require a full drawing backend. If you look at the Nuklear code samples, you will see that all drawing and event handling is implemented separately from the GUI. Porting the toolkit would mean really a lot of work, either in case of natively implementing a drawing backend, or in case of implementing a library and the respective imports. The concept inspired me to create my own GUI toolkit based on the canvas include file, this was far less work and a lot more fun Also, vovchik created some really nice skins (for example here), his design talents are very good! BR Peter
|
|
|
Post by barryk on Jul 5, 2017 12:20:12 GMT 1
Great stuff! As I only look at this forum occasionally, I miss out on some great things that are happening. A quick question. I downloaded the two canvas*.bac files, and tried the demo example in your first post here: basic-converter.proboards.com/thread/841/experimental-widgets-canvas# bacon -d temp1 demo1.bac Converting 'canvas-plugin-gui.bac'... 1136 Syntax error: empty EXIT at line 1136 in file 'canvas-plugin-gui.bac'! # Do you know why I am getting that error? Edit:Ditto, same error with vovchik's 'canvas-gui-test-vov1.bac'
|
|
|
Post by vovchik on Jul 5, 2017 13:09:58 GMT 1
Dear Barry,
I encountered that same problem some time ago (because of some improvements/changes in BaCon) and the fix was really easy:
IF GUI_PROPERTIES.widget_ctr < 0 THEN EXIT 1
Just add a 1 after EXIT.
With kind regards, vovchik
|
|
|
Post by barryk on Jul 5, 2017 13:31:54 GMT 1
Vovchik, Thanks, I will give that a go. Note, I am currently using bacon 3.4. Peter, I have just tried your 'canvas-plugin-nanosvg.bac. But, got this: Your example in first post at: basic-converter.proboards.com/thread/815/canvas-plugin-nanosvgThe paths to nanosvg headers are correct. # bacon -d temp1 demo1.bac Converting 'demo1.bac'... done, 2106 lines were processed in 0.101 seconds. Compiling 'demo1.bac'... cc -DNANOSVG_IMPLEMENTATION -DNANOSVGRAST_IMPLEMENTATION -DNANOSVG_ALL_COLOR_KEYWORDS -c demo1.bac.c cc -o demo1 demo1.bac.o -lbacon -lm -ldl Done, program 'demo1' ready. # ./temp1/demo1 ERROR: signal for SEGMENTATION FAULT received - memory invalid or array out of bounds? Try to compile the program with TRAP LOCAL to find the cause. # Note, I successfully compiled and ran 'example1' in the nanosvg source pkg. That verifies my build system is sane. Regards, Barry
|
|
|
Post by barryk on Jul 5, 2017 13:36:56 GMT 1
Vovchik, Thanks very much, yes "EXIT 1" fixed it.
I also tried your 'canvas-gui-test-vov1.bac', that works also!
...and yes, better looking widgets!
Regards, Barry
|
|
|
Post by Pjot on Jul 5, 2017 19:05:57 GMT 1
Great stuff! As I only look at this forum occasionally, I miss out on some great things that are happening. A quick question. I downloaded the two canvas*.bac files, and tried the demo example in your first post here: basic-converter.proboards.com/thread/841/experimental-widgets-canvas# bacon -d temp1 demo1.bac Converting 'canvas-plugin-gui.bac'... 1136 Syntax error: empty EXIT at line 1136 in file 'canvas-plugin-gui.bac'! # Do you know why I am getting that error? Edit:Ditto, same error with vovchik's 'canvas-gui-test-vov1.bac' Hi barry, In the latest BaCon versions, this error does not exist. If you check the source code, you will discover that this error is not in 3.5.4 or any of the 3.5.x series. So, if you get an 'empty EXIT' error, it means you are using an older release of BaCon (< 3.5). Please make sure that you really are using the latest stable version 3.5.4. This also explains your crash with the nanoSVG demo. It must be compiled with a recent BaCon version. Hope this helps, Peter PS: I found that it happens with BaCon 3.4, the EXIT has a regression which is fixed in 3.5.
|
|
|
Post by Pjot on Sept 26, 2018 8:56:18 GMT 1
So I took another look at the Nuklear toolkit and it seem to have matured quite a bit. In newer versions, it is possible to create a drawing backend using drawing primitives as used in the Canvas wrapper (LINE, CIRCLE, SQUARE etc). Next to this, it also appeared to be possible to pass mouse events back to Nuklear using Canvas mouse handling. As a result, we now have access to a full Nuklear GUI in the OpenGL canvas. To compile the demonstration program, the following is required: Some documentation for the Nuklear GUI widgets can be found here, though it does not fully document all possible widgets. The 'nuklear.h' file also contains a lot of useful information. Note that the demonstration program allows dragging the window around, resizing it, minimize/maximize etc. Enjoy! Peter '---------------------------------------------------------------------------------------------
INCLUDE canvas INCLUDE canvas-plugin-nuklear
'---------------------------------------------------------------------------------------------
SUB Show_Gui()
LOCAL op1 = 1, op2 = 0 TYPE static int LOCAL check1 = 1, check2 = 1, property = 0, check = 1 TYPE static int LOCAL value = 0.6f TYPE static float
' Query all mouse events for this window nk_canvas_events(&win)
' Create window with title "Show" at position 100x100 and size 280x280 using some flags IF nk_begin(&win.ctx, "Show", nk_rect(100, 100, 280, 280), NK_WINDOW_BORDER|NK_WINDOW_MOVABLE|NK_WINDOW_SCALABLE|NK_WINDOW_CLOSABLE|NK_WINDOW_TITLE|NK_WINDOW_MINIMIZABLE) THEN
' Menu widget window, 30 = height, 1 menubar nk_menubar_begin(&win.ctx) nk_layout_row_begin(&win.ctx, NK_STATIC, 30, 1) ' Width of menu bar = 100 nk_layout_row_push(&win.ctx, 100) ' Popup where size is max 120x150 IF nk_menu_begin_label(&win.ctx, "File", NK_TEXT_LEFT, nk_vec2(120, 150)) THEN nk_layout_row_dynamic(&win.ctx, 30, 1) IF nk_menu_item_label(&win.ctx, "Open", NK_TEXT_LEFT) THEN PRINT "Open clicked" IF nk_menu_item_label(&win.ctx, "Close", NK_TEXT_LEFT) THEN PRINT "Close clicked" IF nk_menu_item_label(&win.ctx, "Hide", NK_TEXT_LEFT) THEN PRINT "Hide clicked" IF nk_menu_item_label(&win.ctx, "About", NK_TEXT_LEFT) THEN PRINT "About clicked" nk_menu_end(&win.ctx) ENDIF nk_menubar_end(&win.ctx)
' Some space between menu and other widgets, 10 = height, INT_MAX = ignore width, 0 widgets nk_layout_row_static(&win.ctx, 10, INT_MAX, 0)
' Radio buttons, dynamic layout, 30 = height, 2 widgets nk_layout_row_dynamic(&win.ctx, 30, 2) IF nk_radio_label(&win.ctx, "easy", &op1) THEN op1 = 1 op2 = 0 ENDIF IF nk_radio_label(&win.ctx, "hard", &op2) THEN op1 = 0 op2 = 1 ENDIF
' Label and slider, row layout, STATIC = use values for placement, 30 = height, 2 widgets nk_layout_row_begin(&win.ctx, NK_STATIC, 30, 2) DO nk_layout_row_push(&win.ctx, 90) nk_label(&win.ctx, "Volume:", NK_TEXT_LEFT) nk_layout_row_push(&win.ctx, 160) nk_slider_float(&win.ctx, 0, &value, 1.0f, 0.1f) DONE nk_layout_row_end(&win.ctx)
' Value modification widget, dynamic layout, 0 = ignore height, 1 widget nk_layout_row_dynamic(&win.ctx, 0, 1) nk_property_int(&win.ctx, "Compression:", 0, &property, 100, 10, 1)
' Check box, dynamic layout, 0 = ignore height, 2 widgets nk_layout_row_dynamic(&win.ctx, 0, 2) nk_checkbox_label(&win.ctx, "Large", &check1) nk_checkbox_label(&win.ctx, "Little", &check2)
' Buttons, relative layout, DYNAMIC = use percentages for placement, 30 = height, INT_MAX = max widgets nk_layout_space_begin(&win.ctx, NK_DYNAMIC, 30, INT_MAX) nk_layout_space_push(&win.ctx, nk_rect(0.0, 0.0, 0.3, 1.0)) IF nk_button_label(&win.ctx, "Help") THEN PRINT "Help pressed" nk_layout_space_push(&win.ctx, nk_rect(0.7, 0.0, 0.3, 1.0)) IF nk_button_label(&win.ctx, "Exit") THEN nk_canvas_free(&win) QUIT ENDIF ENDIF
nk_end(&win.ctx)
' Verify if there were changes in the GUI, if so clear screen and raw it. IF nk_canvas_changed(&win) THEN INK(100, 100, 100, 255) CLS nk_canvas_render(&win) ENDIF
END SUB
'---------------------------------------------------------------------------------------------
DECLARE win TYPE nuklear_type
' Create a new Nuklear window win = nk_canvas_new()
WINDOW("Nuklear Demonstration", 800, 600)
CALLBACK(20, Show_Gui) WAITKEY
'---------------------------------------------------------------------------------------------
Attachments:
|
|
|
Post by vovchik on Sept 26, 2018 10:51:55 GMT 1
Dear Peter, Thanks. I just compiled the demo and it works fine on my machine (32-bit Mint 18.3). I will try now on my Raspberry PI and see what happens... With kind regards, vovchik UPDATE: Also works fine in the PI.
|
|
|
Post by Pjot on Sept 27, 2018 21:17:08 GMT 1
Thanks vovchik! One thing I see now with this Nuklear toolkit stuff, is how much my font rendering sucked. The relative positions between the letters were completely messed up, as, for example, the 'm' and 'w' always are attached to the next letter. So I took another look at the fonts in Nuklear, but this is a real painful thing to implement, with some very deep OpenGL primitives causing pain in my head. Instead, I investigated the Canvas wrapper Hershey fonts a little bit further. It turns out that their definitions actually contain meta-information about the width of each letter, information which the Canvas wrapper does not use at all?!?! Apparently, I have been sleeping when working on this Anyway, the font rendering now is fixed and really works very good, exactly as it always should have been. The canvas-plugin-nuklear plugin also has an update, mainly an accurate text length calculation, some typedefs related to colors and lists, and setting the correct line width in the drawing backend. Lastly, I extended the demonstration program (screenshot below) with another window, to demonstrate we can use multiple windows simultaneously. Also I added colors, a combobox and a list and found a way to close the whole GUI when the 'X' close button on a window is pressed. As a side note, I learned that the Nuklear toolkit is a so-called Immediate Mode Toolkit which only takes care of (simple) events by implementing widgets as a function. It does not contain state information. This is contrary to Retained Mode Toolkits like GTK or FLTK which keep track of events and state changes. An Immediate Mode toolkit only can work when it is being redrawn frequently (like 60 fps), typically used in a game environment. This is also how the Canvas wrapper works, by setting a callback to a SUB routine which then is called frequently. Usually such redrawing takes a lot of CPU power. Note however that I already added a 'nk_canvas_changed' function to check if the GUI needs to be rendered or not. It is up to the program to decide how to do this. The demo program shows how to use it and does not consume CPU power when there are no changes in the GUI. Here are all updated files: Regards Peter Attachments:
|
|