new dialogs

[ray]

I want to propose a new system/API/framework whatever for the dialogs. Of course it's div-based, because it's modern, quicker, looks better and avoids the problems that the old popups always have (only recently #1166,#1157,#1115).

It supports both modal and modeless (floating and panel) dialogs.

You can try it out here, code is located in svn in branches/new-dialogs/. Try double-clicking on Stylist's panel heading :)

I think I'd like to have it already in this release, what do you think?

Of course there still has to go some work into converting all the plugins...

[wymsy]

It looks good. I had been thinking we needed a solution like this for just the reasons you give. I think it would be great to include this in the next release, but I think we need to continue to support the existing plugins during a transition period as well, for those who might choose to keep the popup windows for whatever reason, or for those (like me) who have written their own special plugins for their applications and will need time to rewrite them before switching. Perhaps put the new ones in a separate directory? Or change the names somehow? Or make it configurable (this would probably be messy)?

[ray]

Custom plugins using the old method are no problem, the old dialog.js can be loaded side by side.
If someone prefered popups instead of divs, one could add the option to use popups using the new API, should be not to hard to implement (would be similar to popupwin.js as used by TableOperations).

[gogo]

Looks good.

When I wrote the initial inline dialog stuff (for Linker) I always intended that we would eventually have other dialog types around that same API (inline like Linker, fake-window like this new one, popup's, and of course panels) and that if somebody wanted to use a particular dialog type, it'd simply be a matter of setting a config variable.

Would be good to get ImageManager and ExtendedFileManager? switched to using the Dialog api, I'm thinking these are probably the most used popup-plugins currently.

[gogo]

Should add, that before it goes into trunk it should be tested in the various browsers (Gecko, IE, Safari and Opera), and in both Quirks/Standards modes in IE especially.

[guest]

Provided sample, works very well in Firefox 2, Safari 3.1 but does not work in Opera at all because Xinha is disabled! and does not respond. In IE it also works but it has two issues. 1.gray background does not convert the whole page, it only covers Xinha horizontally. 2.dialog movement is limited, so when user moves dialog fast it stops following cursor so user have to drag it again and move it slowly.

-- Sina Salek

[douglas]

I'm working on converting the various plugins with Nicholas, r1015 is the UnFormat? plugin

[douglas]

r1016 Handles the BackgroundImage? plugin

[guest]

Patch for the Abbreviation plugin to use the new dialog system

[guest]

Patch for the FindReplace plugin to use the new dialog system

[guest]

What's the current status with the new-dialogs branch, i.e., what's keeping this from being merged into trunk? (Aside from the many plugins that still need to be updated.)

-nicholasbs

[guest]

I can't speak for the developers, but I for one am still finding issues with the new dialogue system. For example, if you are editing text inside a <div></div> container in IE7, a diagonally striped frame is placed around the div block: unfortunately, this frame stays in front of many of the new-style dialogues when they are invoked, partially obscuring them. E.g., Insert/Modify Link, Insert/Modify Image and Insert Table. In these cases, the frame goes away when you click in one of the text fields on the dialogue. However, in the case of Page Cleaner, it's impossible to make the frame disappear, and the dialogue box remains behind the frame.
As an aside, I do wonder how necessary it is to grey-out the page when invoking a dialogue box. If a dialogue has recognizable borders and shading, it should stand out on its own account. No other application does this greying-out (with the exception of Vista's clunky User Account Control system...), and it's possible that it'll be disconcerting to everyday users. Could the greying-out be made optional?
--Geoffrey K

[gogo]

Diagonally striped frame? That sounds odd. Could you post a screenshot please.

[guest]

Patch for the TableOperations plugin to only use the new dialogs (it previously used a popup for the merge cells dialog)

[guest]

Added new 'centered' option for dialogs. When true, causes dialogs to be centered on the screen. (Ideally, there should really be a global config option to set where dialogs are positioned for consistency.)

[guest]

Could the greying-out be made optional?

Geoffrey, I believe what you're looking for is already possible. The graying-out only occurs when opening a modal dialog, as by definition a modal dialog means the other "windows" (e.g., the Xinha editor) are inaccessible. You can make a dialog modeless by setting modal to false when you create the dialog. For example,

this.dialog = new Xinha.Dialog(editor, html, 'MyPlugin', null,{'modal':false});   

However, I don't think this is ideal. I think there should be a global configuration option for settings like this and where dialogs are placed when they are first opened. Otherwise things will quickly become inconsistent.

-Nicholas

[guest]

Patch to allow global overrides of dialog options (resizable, closable, modal, and centered)

[guest]

I just wrote a quick patch to allow dialog options to be set on a global level. If you want to make sure all dialogs are (or are not) modal, centered, resizable, or closable, you can now do so in your Xinha config file:

   xinha_config.dialogOptions = { 'centered' : true,
                                  'closable' : true,
                                  'resizable' : false,
                                  'modal' : true};

Geoffrey, let me know if this is what you were looking for.

-Nicholas

[nicholasbs]

r1017 includes the new 'resizable' and 'centered' options, as well as the support for global options from the attachment:ticket:1176:XinhaDialogOptions.patch.

[nicholasbs]

r1021 finishes converting the TableOperations plugin to the new system using attachment:ticket:1176:TableOperationsPlugin.patch

[guest]

Shows the striped line surrounding a div block when editing in IE

[guest]

Shows the problem caused for the new dialogue boxes by the div frame

[guest]

Replying to gogo:

Diagonally striped frame? That sounds odd. Could you post a screenshot please.

I've added two screenshots. The first shows the striped line that surrounds div blocks (only when editing inside a div block). The second shows the problem this causes for the new dialogue system. If I click in the "Caption" field of the dialogue displayed here, the striped line goes away (completely), and the dialogue moves to the foreground. Clicking on the dialogue box or even dragging it around isn't enough to do this: I have to click in a text field to make the frame disappear.
--GeoffreyK

[guest]

Replying to Nicholas:

I just wrote a quick patch to allow dialog options to be set on a global level .... Geoffrey, let me know if this is what you were looking for. -Nicholas

Thank you very much indeed Nicholas. I think it's great to have these options configurable. I can't test the modeless option because it's currently disabled as incomplete, but will look forward to trying it when read. --GeoffreyK

[ray]

I created a new ticket #1268 targeting the "striped frame" issue

[ray]

I don't think you can simply switch between a dialog being modal or modeless. It is the sole decision of the plugin author which type is appropriate. I suppose the problems mentioned in ticket #1264 arise out of trying to make a modal dialog modeless. If the grey background is not desired it is a matter of style and could be actually made optional, but I think it is useful to focus the user's attention and make clear that no interaction with the editor is possible at this moment

[ray]

rev [1023]: removed global config option for modality

[ray]

rev [1026]: added global config options for centering, greyout, and close on escape to Xinha.Config.prototype

xinha_config.dialogOptions =
  { 
    'centered' : true, //true: dialog is shown in the center the screen, false dialog is shown near the clicked toolbar button
    'greyout':true, //true: when showing modal dialogs, the page behind the dialoge is greyed-out
    'closeOnEscape':true
  };

'closable' and 'resizable' as described above is still honoured, but I think this, too, should be up to the author

[nicholasbs]

r1037 applies AbbreviationPlugin?.patch with some code cleanup/bug fixes.

[douglas]

r1044 Merges the new dialogs branch to trunk. Not all plugins have been updated, but those that haven't continue to work under the old system.

[ray]

Well, I have to say I feel a bit excited :)

[guest]

In the current trunk (r1153), the new dialogs used by linker (and other plugins) only work in IE in Quirks mode. For more details, see: http://www.xinha.org/punbb/viewtopic.php?id=1875

[guest]

Additional info: It is not sufficient to set config.browserQuirksMode to true. The containing page must specify the loose.dtd in its doctype. Lacking the quirks mode doctype, the new dialogs are invisible in IE 7.

[douglas]

I'd like to clarify that the problem is in quirksmode, and that they work fine in standard mode. If you read the forum post and check the doc strings you'll see. As such, any fixes should look to correcting the problem in quirks mode.

[guest]

To help clarify: I tried leaving the DOCTYPE string set to this: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> and then setting quirksMode on via the editor config. Changing the editor config had no effect. Only placing the full DOCTYPE in the containing page caused things to start working.

[ray]

This is the same as #1376 and is fixed in [1155]

[ray]

Everyone, please open a new ticket if you find a problem with the dialogs.