snowkit / linc_dialogs

http://snowkit.github.io/linc/ Haxe @:native bindings for Open, Folder, and Save dialogs

linc/dialogs

Haxe @:native bindings for Folder, Open and Save dialogs across Windows, Mac and Linux (GTK 3+)

This is a linc library.

---

This library works with the Haxe cpp target only.

---

Install

haxelib git linc_dialogs https://github.com/snowkit/linc_dialogs.git

Supported platforms

• Mac
• Linux (GTK 3)
• Windows

Example usage

notes: - some platforms, when there is no Main Window, have focus issues with cli - cancelled or failed dialogs return a blank string, test for it

import dialogs.Dialogs;

class Test {

    static function main() {

      var result =
        Dialogs.open('Load image',
            [
                { ext:'gif', desc:'GIF image' },
                { ext:'png', desc:'PNG image' }
            ]
        );

      trace("Open result: "+result);

      result = Dialogs.save('Save text file',
            { ext:'txt', desc:'Text file' }
      );

      trace("Save result: "+result);

      result = Dialogs.folder('Select a random folder');

      trace("Folder result: "+result);

    }
} 

linc_dialogs's Issues

Windows open/save filters have "true" in the description strings

Request: Pre-populate save with suggested filename

I've seen save file dialogs that have a pre-populated value for the filename. GTK seems to support this:

https://developer.gnome.org/gtk3/stable/GtkFileChooserDialog.html
https://developer.gnome.org/gtk3/stable/GtkFileChooser.html#gtk-file-chooser-set-current-name

I presume the others do also.

windows test, haxe build/hxml doesn't launch (Haxe build issue? env?)

haxe build.hxml correctly builds the .exe file in the ./cpp output folder, but it doesn't automatically launch the app like on the other platforms. However, the output .exe exists and can be run manually.

Crashes when optional filters argument(s) are omitted

Ensure it gracefully handles optional haxe arguments being null on the cpp side

Apps become unresponsive (appear frozen) when a dialog is up

It's understandable that an app would not be interactive while a dialog is up, but the apps I've tested (hxScout, snow basic testcase) become, while the dialog is open, unresponsive is such a way that it produces undesirable results.

On linux, the window becomes gray and dark (like when a runaway process is no longer responding to the OS.) On windows, it's worse such that the app window gets painted over by the dialog.

It's not an absolute blocker, because the app does come back once the dialog is closed. But it does look bad.

snow basic test on linux (note dark app behind dialog):

hxScout on linux:

hxScout on windows (especially bad, the dialog graphics are drawn over the hxScout window):

Unable to compile on mac

haxe 3.4.0
hxcpp 3.4.49
lime 3.7.2
openfl 4.7.3
linc_dialogs up to date with master

OSX El Capitan (10.11.4)
XCode 7.3

Compiler invocation:

haxelib run lime test mac

Output:

Link: ApplicationMain
Undefined symbols for architecture x86_64:
  "linc::dialogs::open(String, Array<Dynamic>)", referenced from:
      ui::InstrumentPanel_obj::onPressOpen() in 0d936921_InstrumentPanel.o
  "linc::dialogs::save(String, Dynamic)", referenced from:
      ui::InstrumentPanel_obj::onPressSaveAs() in 0d936921_InstrumentPanel.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I've recently upgraded haxe, hxcpp, lime, basically everything I have at the top of that list to most recent version. Somewhere along the way, linc_dialogs stopped compiling for me on mac. I haven't tried upgrading OSX to Sierra yet because that potentially affects other things for me, but if it's likely to work I'll do it.

Dialogs.open() changes cwd on some platforms

I don't know if this is a bug on OpenFL or on linc_dialogs, but basically:

1. Open a file with Dialogs.open() (you must actually select a file, not hit "cancel")
2. Try to load a bitmap data with Assets.getBitmapData

It will always be null.

Here's some repro code, a modified version of OpenFL's DisplayingABitmap demo:

package;


import dialogs.Dialogs;
import lime.app.Application;
import openfl.Assets;
import openfl.display.Bitmap;
import openfl.display.Sprite;
import openfl.system.System;


class Main extends Sprite {

    public function new () {

        super();

        var str = Dialogs.open("title");

        trace("file = " + str);

        var bmpData = Assets.getBitmapData ("assets/openfl.png");

        trace("bmpData = " + bmpData);

        var bitmap = new Bitmap (bmpData);
        addChild (bitmap);

        bitmap.x = (stage.stageWidth - bitmap.width) / 2;
        bitmap.y = (stage.stageHeight - bitmap.height) / 2;

    }


}

If you select "cancel", the image loads. If you select a file (any file) it will not load and the trace will similarly indicate that bmpData is null.

I wouldn't normally expect linc_dialogs to interfere with OpenFL's asset system like this, so that's why I'm not quite sure where the bug originates. I figured I'd start here because if I swap linc_dialogs with systools, the problem goes away.

(also, to be clear the error occurs with the latest versions of Lime & OpenFL, and using the next codebase, not legacy)

Windows folder select output is "true"

The return of folder() is String "true":

Dialogs.save crashes without a desc

seems like trying to open a save dialog without a desc for your filetype causes an errorless crash,

Nico