#7919 closed bug (notabug)

Opened November 28, 2011 06:24PM UTC

Closed November 28, 2011 06:36PM UTC

Last modified November 29, 2011 08:25PM UTC

Dialogs which are not draggable do not have their titlebar properly styled.

Reported by: benjamin.neau Owned by:
Priority: minor Milestone: 1.9.0
Component: ui.dialog Version: 1.8.16
Keywords: Cc:
Blocked by: Blocking:
Description

Indeed, if you set up a dialog which is not draggable with some code like:

$("<div>test</div>").dialog({ title: "Test dialog", draggable: false });

And then, when you mouse over the dialog title, the cursor is a "text" cursor, whereas you cannot select the dialog title text.

Not being able to select the dialog title text is obviously the right behavior.

But the dialog titlebar should have a "default" cursor when it is not draggable, and a "move" cursor when it is draggable.

Attachments (0)
Change History (5)

Changed November 28, 2011 06:36PM UTC by scottgonzalez comment:1

resolution: → invalid
status: new → closed

Actually, not being able to select the text is kind of bad and that behavior is planned to be removed (see #7756).

Changed November 29, 2011 05:21PM UTC by benjamin.neau comment:2

Scott, with all due respect, I do not understand why not being able to select a dialog window title is "kind of bad". Perhaps, you're thinking of a UI system which I'm not thinking of, but I do not remember ever seeing a window management system in which dialog windows titles were selectable.

Of course, your decision is final, but an explanation would be helpful in enlightening me.

Thanks for your time and consideration.

Changed November 29, 2011 07:18PM UTC by scottgonzalez comment:3

Do you have an example of a desktop non-movable dialog?

Changed November 29, 2011 08:21PM UTC by benjamin.neau comment:4

_comment0: Actually I do: maximized dialogs are not movable on Windows system Pre-Seven. \ \ Granted, "dialog" does not offer restore/maximize functionality as of now. \ \ But in my company, we extended ui.dialog in a "window" widget (it adds: icon, icon menu, minimize/maximize/restore and can integrate with a "desktop" widget) in which having maximized dialogs, and therefore non-movable dialogs makes sense. \ \ I now understand non-movable dialogs are not really useful for e.g. web sites and that they only make sense in a window management scenario (e.g. web desktop). \ \ As always, you are right. \ But understand 'things' is always less frustrating than simply accepting them. \ \ Thank you, Scott, for demonstrating the patience needed to help me rest my mind on this case. → 1322598117052299

Actually I do: maximized dialogs are not movable on Windows system Pre-Seven.

Granted, "dialog" does not offer restore/maximize functionality as of now.

But in my company, we extended ui.dialog in a "window" widget (it adds: icon, icon menu, minimize/maximize/restore and can integrate with a "desktop" widget) in which having maximized dialogs, and therefore non-movable dialogs makes sense.

I now understand non-movable dialogs are not really useful for e.g. web sites and that they only make sense in a window management scenario (e.g. web desktop).

As always, you are right.

But understanding 'things' is always less frustrating than simply accepting them.

Thank you, Scott, for demonstrating the patience needed to help me rest my mind on this case.

Edit: Grammar.

Changed November 29, 2011 08:25PM UTC by scottgonzalez comment:5

No problem, I'm sure you can build the functionality you want into your window extension. If you need any help, just ask on the forum or IRC.