os-js / osjs-dialogs Goto Github PK

For instance: When selecting the fore- or background color buttons in the writer application, one is presented with the three sliders, a color graph and a textbox underneath it.

The color can only be updated by clicking on the sliders or the graph, but not by changing the value inside the textbox.

As of now you can only select files in the "file" dialog. Needs to support an option for this.

Hi,
Continued widget development(os-js/osjs-widgets#9), i faced new problem.
I kept a paramter as widget custom options.
measurment: 'netdata.apps.cpu.X'
Due to changing this custom option value I used choice dialog, but I don't know how should I use my parameter value as choice dialog default value.

createMeasurmentDialog() {
    this.core.make('osjs/dialog', 'choice', {
      title: 'Measurment',
      message: 'Select Measurment',
      //TODO: make this list via grafana service
      choices: {
        'netdata.apps.cpu.X': 'netdata.apps.cpu.X',
        'netdata.statsd_timer_swift.object_server.put.timing.events': 'netdata.statsd_timer_swift.object_server.put.timing.events'
      },
    }, (btn, value) => {
      if (btn === 'ok') {
        this.options.measurment = value;
        this.render();
        this.saveSettings();
      }
    });
  }

Currently the PromptDialog only accepts one value. There should be an array that can be submitted in the "value" field, and then the done() callback function can do a loop through the results.

ex:

    core.make('osjs/dialog', 'prompt', {
      message: `Type in your name:`,
      value: ['First Name', 'Last Name'] 
    }, done(value => {...}

Right now the file dialog does not warn of overwrites.

Is it possible to use window event in a dialog?
For example defining on close or destroy event for a dialog.

why is this line like this?

shouldn't it just be?

buttons: {
  ok: !!this.args.filename
}

Currently whenever the save dialog box is opened with filetype: 'directory' the OK button is enabled. Which may be wrong.

I am using the below code for creating and acting on a Save Dialog in OSjs.

    core.make('osjs/dialog', 'file', {type: 'save', title: "Save As"},  {parent: win, attributes: {modal: true}}, (status, file, event) => {
      if (status === "ok") {
        if (!file.path.endsWith(".wf"))
          file.path += ".wf";
        basic.emit('save-file', file);
      }
    });

And the resulting Dialog:

At this point, I would expect clicking the Cancel button to trigger a callback with status = 'cancel' and file = null. However the Cancel button callback doesn't trigger until Filename is populated with some text.

There also appears to be an error handler that triggers if the text equals an existing filename, even if the Cancel button was pressed and not the OK button, example below:

Pressing No returns to the Save Dialog, and pressing Yes on the Confirm window closes the Save Dialog and sends the status = 'cancel' callback.

I believe expected behavior is to not display the Confirm dialog when Cancel is pressed and to simply close the Save Dialog while sending the 'cancel' callback, regardless of whether any text is input in the Filename field.

Thanks Anders, you're the man.

Hi.
I think there is a bug when I close the save-as dialog by close button (not by cancel button). If the filename textbox has some value, the confirm dialog for overwriting is triggered by pressing close button!
For example It happenes in your textpad application.

hi @andersevenrud .
When the server crashes or down, we receive a disconnection notification in all browsers.

But when the internet is interrupted, Chrome browser does not receive this notification, but we receive this notification in other browsers.

This is due to the arguments being swapped in: https://github.com/os-js/osjs-dialogs/blob/master/src/dialog.js#L153

By default the color dialog only changes the hex of the textbox once the user has let go of the slider, not showing them a preview as they drag. On my implementation I have merged onchange into oninput so the hex is updated as the user slides, so they know what the color looks like before they release.

I could make a quick PR for this if you are interested, but I don't know if you prefer the current behavior as opposed to the behavior that I mentioned.