Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#1176 closed enhancement (fixed)

new dialogs

Reported by: ray Owned by:
Priority: normal Milestone: 0.96
Component: User Interface Version: trunk
Severity: normal Keywords:
Cc:

Description

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...

Attachments (7)

AbbreviationPlugin.patch (10.1 KB) - added by guest 9 years ago.
Patch for the Abbreviation plugin to use the new dialog system
FindReplacePlugin.patch (21.8 KB) - added by guest 9 years ago.
Patch for the FindReplace plugin to use the new dialog system
TableOperationsPlugin.patch (3.7 KB) - added by guest 9 years ago.
Patch for the TableOperations plugin to only use the new dialogs (it previously used a popup for the merge cells dialog)
CenterDialogs.patch (851 bytes) - added by guest 9 years ago.
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.)
XinhaDialogOptions.patch (3.1 KB) - added by guest 9 years ago.
Patch to allow global overrides of dialog options (resizable, closable, modal, and centered)
Div_striped_line.jpg (132.8 KB) - added by guest 9 years ago.
Shows the striped line surrounding a div block when editing in IE
Div_dialogue_problem.jpg (85.5 KB) - added by guest 9 years ago.
Shows the problem caused for the new dialogue boxes by the div frame

Download all attachments as: .zip

Change History (37)

comment:1 Changed 9 years ago by 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)?

comment:2 Changed 9 years ago by 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).

comment:3 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by 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

comment:6 Changed 9 years ago by ray

  • Milestone changed from 0.95 to 0.96

comment:7 Changed 9 years ago by douglas

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

comment:8 Changed 9 years ago by douglas

r1016 Handles the BackgroundImage? plugin

Changed 9 years ago by guest

Patch for the Abbreviation plugin to use the new dialog system

Changed 9 years ago by guest

Patch for the FindReplace plugin to use the new dialog system

comment:9 Changed 9 years ago by 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

comment:10 follow-up: Changed 9 years ago by 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

comment:11 follow-up: Changed 9 years ago by gogo

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

Changed 9 years ago by guest

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

Changed 9 years ago by 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.)

comment:12 follow-up: Changed 9 years ago by 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

Changed 9 years ago by guest

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

comment:13 follow-up: Changed 9 years ago by 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

comment:14 Changed 9 years ago by nicholasbs

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

comment:15 Changed 9 years ago by nicholasbs

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

Changed 9 years ago by guest

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

Changed 9 years ago by guest

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

comment:16 in reply to: ↑ 11 Changed 9 years ago by 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

comment:17 in reply to: ↑ 13 Changed 9 years ago by 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

comment:18 in reply to: ↑ 10 Changed 9 years ago by ray

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

comment:19 in reply to: ↑ 12 ; follow-up: Changed 9 years ago by 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

comment:20 in reply to: ↑ 19 Changed 9 years ago by ray

rev [1023]: removed global config option for modality

comment:21 Changed 9 years ago by 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

comment:22 Changed 9 years ago by nicholasbs

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

comment:23 Changed 8 years ago by douglas

  • Resolution set to fixed
  • Status changed from new to closed

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.

comment:24 Changed 8 years ago by ray

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

comment:25 Changed 8 years ago by guest

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

comment:26 Changed 8 years ago by 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.

comment:27 Changed 8 years ago by 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.

comment:28 Changed 8 years ago by guest

To help clarify: I tried leaving the DOCTYPE string set to this:
<!DOCTYPE HTML PUBLIC "-W3CDTD HTML 4.01 TransitionalEN">
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.

comment:29 Changed 8 years ago by ray

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:30 Changed 8 years ago by ray

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

Note: See TracTickets for help on using tickets.