Use destructor instead

• setTimeout/setInterval callback (if uitimer gets merged)

Some elements are missing

examples/grid.js (0_1_0)

var grid = new libui.UiGrid();
grid.padded = true;
grid.append(new libui.UiLabel('name'), 0, 0, 2, 1, 0, 0, 0, 1);
grid.append(new libui.UiLabel('surname'), 0, 1, 2, 1, 0, 0, 0, 1);
grid.append(new libui.UiLabel('age'), 0, 2, 2, 1, 0, 0, 0, 1);

grid.append(name, 2, 0, 2, 1, 0, 0, 0, 1);
grid.append(surname, 2, 1, 2, 1, 0, 0, 0, 1);
grid.append(age, 2, 2, 2, 1, 0, 0, 0, 1);

grid.append(JSONData, 4, 0, 1, 3, 1, 0, 1, 0);

Corresponding issue: kusti8/proton-native#55

This messages are generated by trying to append to a multiline textbox after the window that contains it has been closed:

At least it not segfault, but it could be cool to silence all that warnings.

Whenever I run libui-node it throws an error:

module.js:568
  return process.dlopen(module, path._makeLong(filename));
                 ^

Error: libui.so.0: cannot open shared object file: No such file or directory
    at Error (native)
    at Object.Module._extensions..node (module.js:568:18)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)
    at Module.require (module.js:468:17)
    at require (internal/module.js:20:19)

My directory structure looks like:

libui-node/
   examples/
      core-api.js
   libui/
     build/
        libui.so
        libui.so.0

I can't run any of the examples without copying the libui.so* files to my library folder. I had no errors with compiling. Ubuntu Linux 16.04

Continue discussion from here: #74 (comment)

Tried running the control-gallery example on OS X which works without issues, but attempting to run it on Windows 7 results in an error:

module.js:568
  return process.dlopen(module, path._makeLong(filename));
                 ^

Error: The specified module could not be found.
\\?\node_modules\libui-node\build\Release\nbind.node
    at Error (native)
    at Object.Module._extensions..node (module.js:568:18)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)
    at Module.require (module.js:468:17)
    at require (internal/module.js:20:19)
    at initNode (node_modules\libui-node\node_modules\nind\dist\nbind.js:162:15)
    at node_modules\libui-node\node_modules\nbind\dist\bind.js:130:13
    at findCompiledModule (node_modules\libui-node\nodemodules\nbind\dist\nbind.js:94:13)

EDIT: Found the problem. It's having issues finding libui.dll and copying the file from node_modules/libui-node to the root of the script fixed it and it now works fine. Don't know if there's any better solution to this...

• Might take some work
• Maybe wait a bit in case there are api changes?

Example: https://github.com/andlabs/libui/blob/master/examples/drawtext/main.c

After being appended there's no way to remove an item from a combobox. EditableCombobox has this issue as well.

There is no Widget like Image Components.

I am having an interesting error. On windows 10 under node 8.9.3 (I've also tried 6.9.2) if I npm install on a project that uses libui-node everything compiles correctly, but then when I go to run I get:

node .
module.js:597
  return process.dlopen(module, path._makeLong(filename));
                 ^

Error: The specified module could not be found.
\\?\C:\Users\sam\Desktop\bitfort-client\node_modules\libui-node\build\Release\nbind.node
    at Error (native)
    at Object.Module._extensions..node (module.js:597:18)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at initNode (C:\Users\sam\Desktop\bitfort-client\node_modules\nbind\dist\nbind.js:162:15)
    at C:\Users\sam\Desktop\bitfort-client\node_modules\nbind\dist\nbind.js:130:13
    at findCompiledModule (C:\Users\sam\Desktop\bitfort-client\node_modules\nbind\dist\nbind.js:94:13)
    at find (C:\Users\sam\Desktop\bitfort-client\node_modules\nbind\dist\nbind.js:108:13)
    at Object.init (C:\Users\sam\Desktop\bitfort-client\node_modules\nbind\dist\nbind.js:119:5)
    at Object.<anonymous> (C:\Users\sam\Desktop\bitfort-client\node_modules\libui-node\index.js:3:21)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)

Interestingly, if I move node_modules/libui-node/build/Release/nbind.node to node_modules/libui-node/, it will run correctly, however then I get problems when I try to export this with pkg (e.g. complaints about the file nbind.node not self-registering as a module). What is the proper way to fix this @parro-it?

Thanks!!

During last week there were some news on projects related to libui-node, so I want to write here some status update about the project.

These news are:

• proton-native is a project similar to react-libui that is trendy on github in the last days.

• @andlabs publish a new alpha3.5 release of libui that solve the Enter bug.

So, during next weeks I'll work to publish a new (long due) libui-node version, to support thsi new release and fix some long outstanding bug.

Next version will include:

• support for alpha3.5 libui version (This will involve updating my PR on libui automated CI builds).
• fixes to #46
• UIImage bindings
• bump nbind version from 0.2.1 to 0.3.13 #48
• Reverted event loop for macOS to previous single-threaded alghoritm #50

This is needed by quit menu items

I drafted some pages to document libui-node usage:

https://github.com/parro-it/libui-node/tree/master/docs

It would be beautiful to get feedback / suggestions / correction by the community...

Installing nbind-based packages on Windows currently requires Visual Studio and Python, just like most other native binary Node.js addons. There's now a plan to change this.

nbind should eventually come bundled with a precompiled minimal binary addon for all Node.js versions, for communicating with a special entry point in shared libraries. It will then be possible to pass a flag to node-gyp and compile the project into a single .dll, .so or .dylib with such an entry point, and put them in the npm package. In practice only the following should be required:

• 32-bit .dll for Windows
• 64-bit .dll for Windows
• 64-bit .dylib for OS X

Linux users can probably get node-gyp working anyway.

libui-node would still be compiled and installed exactly as now, but if that fails, it could use a precompiled .dll or .dylib as a fallback. When in use, the fallback will introduce a tiny performance penalty for each call.

I'm also investigating running the C++ code in another thread to avoid having to poll UI events, but that won't happen at least until next year.

I plan to follow this roadmap to implement new features and improvement, please comment:

Beta 1 - 0.1.0

• - Complete documentation - UiArea
• - Complete documentation - UiGrid
• - Complete documentation - Menus
• - Memory managament

Beta 2 - 0.2.0

• - Implement UiTable
• - Implement various enums
• - Bump nbind to 0.3.0: nullable arguments, enhanced type checking, fixed callbacks arguments

Beta 3 - 0.3.0

• - Precompile binaries with node-pregyp and publish them to github
• - Application packager - probably in its own repo

Hey Andrea, let's stick with your repo here since you got npm and Travis set up already.

Will integrate some of my code into the code base by next week. :) Think it would be better if the window function is structured like this:

const window = new libui.Window({
  title: 'Cool',
  width: 700,
  height: 700,
  hasMenu: true,
  margined: false,
  onClosing: (err) => {
    console.log('exited')
  },
});

And also integrate some of my menu code:

const menu = new libui.Menu('File', [
  {
    label: 'Open',
    type: 'item',
    onClick: () => {
      const filepath = window.openFile();
      if (!filepath) {
        window.msgBox('No file selected', "Don't be alarmed");
        return;
      }
      window.msgBox('File selected', filepath);
    }
  },
  {
    label: 'Save',
    type: 'item',
    onClick: () => {
      const filepath = window.saveFile();
      if (!filepath) {
        window.msgBox('No file selected', "Don't be alarmed");
        return;
      }
      window.msgBox('File selected', filepath);
    },
  },
  {
    type: 'about',
    onClick: () => {
      console.log('about');
    },
  },
  {
    type: 'check',
    label: 'Check this',
    onClick: () => {
      console.log('check');
    },
  },
  {
    type: 'preferences',
    onClick: () => {
      console.log('preferences');
    },
  },
]);

My long term plan is to use libui-node and make React components out of it. So others can create desktop apps with React.

I succeeded to get your UIArea example up and running in my Windows Environment.

Unfortunately there is no rectangle. Inserting some "console.log's I can see, that neither the 'draw'- nor the 'mouseEvent' method of the handeler object is invoked.

Would love to work with that cool piece.

Upstream issue

Maybe I'm missing something: cloned the repo, npm i, npm start and I get an nsexception error. Tried to do a standalone hello world, but the same happened - I'm on OSX, Sierra, will give it a try on Arch too. Do I have to install something else, or is my node version unsupported?

szkurdi ~/Projects/sandbox/libui-node $ npm start

> [email protected] start /Users/szkurdi/Projects/sandbox/libui-node
> node examples/control-gallery.js

2016-11-20 20:29:38.703 node[6245:111927] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'nextEventMatchingMask should only be called from the Main Thread!'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fffd538048b __exceptionPreprocess + 171
	1   libobjc.A.dylib                     0x00007fffe9ae2cad objc_exception_throw + 48
	2   AppKit                              0x00007fffd369350c -[NSApplication(NSEvent) shouldBeTreatedAsInkEvent:] + 0
	3   nbind.node                          0x00000001043bd801 _Z10pollEventsPv + 273
	4   libsystem_pthread.dylib             0x00007fffea5d8aab _pthread_body + 180
	5   libsystem_pthread.dylib             0x00007fffea5d89f7 _pthread_body + 0
	6   libsystem_pthread.dylib             0x00007fffea5d8221 thread_start + 13
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Abort trap: 6
szkurdi ~/Projects/sandbox/libui-node $ node --version
v7.1.0
szkurdi ~/Projects/sandbox/libui-node $ uname -a
Darwin Szabolcss-Air 16.1.0 Darwin Kernel Version 16.1.0: Thu Oct 13 21:26:57 PDT 2016; root:xnu-3789.21.3~60/RELEASE_X86_64 x86_64

Edit: yes, it works fine on Arch :)

moved from discussion #66

Currently there's no way to change a Window's title, size, or if it has a menu without creating a new one.

• Documentation (#69)

• More enums: https://github.com/andlabs/libui/blob/51f72abba84e3941deba1c8f699046a48d1f7fb9/ui.h#L356-L383)

  • uiDrawBrushType
  • uiDrawLineCap
  • uiDrawLineJoin
  • uiDrawFillMode

• Modifiers, uiExtKey https://github.com/andlabs/libui/blob/d53ab65589e126bb9bf40c99d67ca1d94bbff738/ui.h#L997

• DrawStrokeParams: Dashed

• Gradient

  • fix std::vector<BrushGradientStop> DrawBrush::getStops

• this isn't exposed to JS:

  libui-node/src/UiArea/UiAreaMouseEvent.cc

  Lines 29 to 31 in ae067f5

  	int UiAreaMouseEvent::getUp() {
  	return e->Up;
  	}

• b is never freed:

  libui-node/src/UiArea/DrawBrush.cc

  Line 7 in 36c278f

  b = new uiDrawBrush();

• sp is never freed:

  libui-node/src/UiArea/DrawStrokeParams.cc

  Line 8 in 36c278f

  sp = new uiDrawStrokeParams();

• leak:

  libui-node/src/UiArea/UiAreaKeyEvent.cc

  Lines 10 to 15 in 445e395

  	char *UiAreaKeyEvent::getKey() {
  	char *k = new char[2];
  	k[0] = e->Key;
  	k[1] = '\0';
  	return k;
  	}

Node lacks a lot of tools for getting information about the screen, so there's a few things I think would work great with libui-node:

• Monitors: getting the amount of monitors and their individual sizes
• Size: get width/height of screen

May need to update your readme....

• I needed to manually download the sub-module, not sure why but git wouldn't pull it
• needs making clear you need node v6
• perhaps note you can install cmake with homebrew on mac brew install cmake
• After all that, the gui still didn't appear on mac...? (running npm start)

Love to see this working so any feedback would be nice, thanks.

I just merged Windows branch into master.

From now on, libui-node support Windows OS too!

After many attempts using various methods, I finally implemented the event loop using a simple libuv timer.

Linux and macOS got a better event loop implementation, with a background blocking thread that check for any pending GUI event and when there are one or more, it run a callback in main js thread that dispatch all events.

It appear that on Windows we have no way to check for the presence of pending events on other threads, so I revert to checking them in main thread, once every 100 ms.

Anyway, CPU usage appear to be lower than 1% on my machine. So at least by now, I choose to go on with this implementation. Maybe we can find a better way in future.

Please test it and report any issue you'll find, thanks!

While spelunking yoga source code, I found I nice way to avoid listing every source file in binding.gyp:

<!@(ls -1 sources/yoga/*.cpp)

I think we could simplify the file using the same command, but I have to study which command on windows replace ls -1

Is there a way to do this?

First of all: This binding works and looks amazing. I am especially excited about your idea of a React-like interface (see sindresorhus/project-ideas#72), I would even plan to try it out on my own.

Anyway, when running the histogram example, I noticed that the node process uses 100% of one of my cores which is pretty intense for a simple window without interacting with it. It seems that your startLoop implementation consumes a lot of CPU time due to its recursive invokation. I replaced the call to startLoop, in the example, with the direct binding to uiMain and it still worked perfectly with much less consumption:

    mainwin.show();

    //libui.startLoop();
    libui.Ui.main();
}

Now, since I am not very familiar with libui, I was wondering what the differences between your startLoop and the uiMain approach are and why one would choose startLoop.

Currently there is missing documentation about:

• Area component
• Dialogs
• Grid component
• Add meaningful code example in VerticalBox, Horizontalbox, Group
• Menus
• Color
• move Point/Size from Area.md to a more central place
• in the readme:

Each libui widget implementation is written in it's own C++ file in src folder.

I just use setInterval to update a label for counting, but it can't refresh unless the mouse moves on the window.

Is this project still alive?

I haven't started creating my own programs with this library, but I've tried the examples and run in to a major disappointment. The Control Gallery example and the Core Api example both take a really long time to start (over a minute!). Is this a bug in the examples, the library or am I doing something wrong?

node version: v6.3.1
hardware: i5, 8GB of RAM

like title.
I wish it could implement NSOpenPanel on macOS, or other component on Windows...

I don't get any menu items other than "node" when I run any of the examples.

Currently children are a bit weird. There's setChild and append, which belong to different UI items. I'm suggesting common methods called setChildren, addChild, appendChild, and removeChild that belongs in Window, Group, RadioButtions, Vertical/Horizontal Box, and others.

setChildren would accept an array of children, overwriting any current children. For UI items like Window/Group that only accept one child, it would throw an error if there's more than one child in the array.

addChild would basically do what append does. For UI items like Window/Group this would throw an error if it already has a child.

appendChild would accept a child and an index. Pushes children after it to a higher index. For UI items like Window/Group this would throw an error if it already has a child.

removeChild would remove a child at the specified index. Index defaults to 0. For UI items like Window/Group this would throw an error if the index is not 0.

Any thoughts? After working with this library for a few hours it seems like there's currently too many ways to handle children and this is just one suggestion for unifying them.

Upstream issue