Menu
▾
▴
tktable-tile-dev
|
From: Joe E. <jen...@fl...> - 2005-07-20 21:24:14
|
New in CVS: [ttk::dialog]. Documentation here:
<URL: http://tktable.sourceforge.net/tile/doc/dialog.html >
Please review.
This is similar to [tk_messageBox], with a few notable differences:
+ [ttk::dialog $dlg ...] constructs the dialog $dlg, maps it,
and returns immediately; [tk_messageDialog ...] blocks until
the dialog is dismissed.
+ [tk_messageDialog] returns the button name to the caller
after dismissing the dialog; [ttk::dialog] passes the button
name to a callback procedure specified by the -command option.
(Rationale: it's easy to build a blocking API on top of a
nonbocking one, but not the other way around. I haven't done
the blocking API yet.)
+ There is no -parent option; instead, [ttk::dialog]s are
made transient for the nearest [toplevel] ancestor widget.
+ [ttk::dialog]s are nonmodal.
+ [ttk::dialog]s use the KDE / Win2K / XP layout style
instead of the older Motif/Windows 3.1/CUA style.
Gnome / Aqua - style button layouts are not (yet) supported.
[ttk::dialog] supports the same set of predefined dialog '-type's [*],
but also allows an arbitrary user-specified list of '-button's
It also provides a "client frame" where the caller can add additional
widgets for further customization. There (will also be) a mechanism
(undocumented, not fully worked out) for defining new '-icon's
or theme/application-specific versions of the built-in ones.
I've been using this interface for a while and am fairly happy
with it; a few things that should probably be changed though:
+ [ttk::dialog]s are "self-destructing" -- when the user
presses a command button, the dialog is destroyed. It
might be preferable to withdraw the window instead.
+ There should be an option to make [ttk::dialog]s modal.
(I don't think this should be the default, though, mostly
because of the all-around evilness of [grab].)
+ Possibly: an option for persistent dialogs, i.e.,
ones that don't automatically dismiss themselves when
a command button is pressed.
Other missing features/possible enhancements are listed in TODO
notes at the top of library/dialog.tcl.
--Joe English
jen...@fl...
[*] Except for '-type abortretryignore', which has been omitted
for obvious reasons.
|
|
From: Brian G. <bgr...@mo...> - 2005-07-20 22:14:56
|
You have to make the destruction determined by the user. The reason is that error checks should be performed before action is completed, if a check fails, the dialog box should stay; reconstructing it would cause unnecessary flashing and additional "failure" dialog boxes are just super annoying or, if used, should be layered on top of the original dialog box anyway. IMO -Brian Joe English wrote: >New in CVS: [ttk::dialog]. Documentation here: > > <URL: http://tktable.sourceforge.net/tile/doc/dialog.html > > >Please review. > >This is similar to [tk_messageBox], with a few notable differences: > > + [ttk::dialog $dlg ...] constructs the dialog $dlg, maps it, > and returns immediately; [tk_messageDialog ...] blocks until > the dialog is dismissed. > > + [tk_messageDialog] returns the button name to the caller > after dismissing the dialog; [ttk::dialog] passes the button > name to a callback procedure specified by the -command option. > >(Rationale: it's easy to build a blocking API on top of a >nonbocking one, but not the other way around. I haven't done >the blocking API yet.) > > + There is no -parent option; instead, [ttk::dialog]s are > made transient for the nearest [toplevel] ancestor widget. > > + [ttk::dialog]s are nonmodal. > > + [ttk::dialog]s use the KDE / Win2K / XP layout style > instead of the older Motif/Windows 3.1/CUA style. > Gnome / Aqua - style button layouts are not (yet) supported. > >[ttk::dialog] supports the same set of predefined dialog '-type's [*], >but also allows an arbitrary user-specified list of '-button's >It also provides a "client frame" where the caller can add additional >widgets for further customization. There (will also be) a mechanism >(undocumented, not fully worked out) for defining new '-icon's >or theme/application-specific versions of the built-in ones. > >I've been using this interface for a while and am fairly happy >with it; a few things that should probably be changed though: > > + [ttk::dialog]s are "self-destructing" -- when the user > presses a command button, the dialog is destroyed. It > might be preferable to withdraw the window instead. > > + There should be an option to make [ttk::dialog]s modal. > (I don't think this should be the default, though, mostly > because of the all-around evilness of [grab].) > > + Possibly: an option for persistent dialogs, i.e., > ones that don't automatically dismiss themselves when > a command button is pressed. > >Other missing features/possible enhancements are listed in TODO >notes at the top of library/dialog.tcl. > > >--Joe English > > jen...@fl... > >[*] Except for '-type abortretryignore', which has been omitted > for obvious reasons. > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >Tktable-tile-dev mailing list >Tkt...@li... >https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev > > > -- # 12th Annual Tcl/Tk Conference: Oct 24-28, 2005, Portland OR # http://www.tcl.tk/community/tcl2005 ------------------------------------------------------------- -- Mentor Graphics Corp. -- -- 8005 SW Boeckman Road 503.685.7000 tel -- -- Wilsonville, OR 97070 USA 503.685.0921 fax -- ------------------------------------------------------------- -- Technical support ............ mailto:su...@mo... -- -- Sales and marketing info ....... mailto:sa...@mo... -- -- Licensing .................... mailto:li...@mo... -- -- Home Page ........................ http://www.model.com -- ------------------------------------------------------------- |
|
From: Damon C. <da...@tc...> - 2005-07-21 01:19:27
|
Also. If you give the user the ability to add widgets in a client frame, maybe they want to do something with them after the user has clicked a button. If I put a combobox inside the client frame, but you destroy the window the minute they hit a button, I may not be able to get the value that was in the combo when they clicked. Yes, I know, I can use a -textvariable on the combobox, but you get the jist. Damon > You have to make the destruction determined by the user. The reason is > that error checks should be performed before action is completed, if a > check fails, the dialog box should stay; reconstructing it would cause > unnecessary flashing and additional "failure" dialog boxes are just > super annoying or, if used, should be layered on top of the original > dialog box anyway. > > IMO > -Brian > > Joe English wrote: > >>New in CVS: [ttk::dialog]. Documentation here: >> >> <URL: http://tktable.sourceforge.net/tile/doc/dialog.html > >> >>Please review. >> >>This is similar to [tk_messageBox], with a few notable differences: >> >> + [ttk::dialog $dlg ...] constructs the dialog $dlg, maps it, >> and returns immediately; [tk_messageDialog ...] blocks until >> the dialog is dismissed. >> >> + [tk_messageDialog] returns the button name to the caller >> after dismissing the dialog; [ttk::dialog] passes the button >> name to a callback procedure specified by the -command option. >> >>(Rationale: it's easy to build a blocking API on top of a >>nonbocking one, but not the other way around. I haven't done >>the blocking API yet.) >> >> + There is no -parent option; instead, [ttk::dialog]s are >> made transient for the nearest [toplevel] ancestor widget. >> >> + [ttk::dialog]s are nonmodal. >> >> + [ttk::dialog]s use the KDE / Win2K / XP layout style >> instead of the older Motif/Windows 3.1/CUA style. >> Gnome / Aqua - style button layouts are not (yet) supported. >> >>[ttk::dialog] supports the same set of predefined dialog '-type's [*], >>but also allows an arbitrary user-specified list of '-button's >>It also provides a "client frame" where the caller can add additional >>widgets for further customization. There (will also be) a mechanism >>(undocumented, not fully worked out) for defining new '-icon's >>or theme/application-specific versions of the built-in ones. >> >>I've been using this interface for a while and am fairly happy >>with it; a few things that should probably be changed though: >> >> + [ttk::dialog]s are "self-destructing" -- when the user >> presses a command button, the dialog is destroyed. It >> might be preferable to withdraw the window instead. >> >> + There should be an option to make [ttk::dialog]s modal. >> (I don't think this should be the default, though, mostly >> because of the all-around evilness of [grab].) >> >> + Possibly: an option for persistent dialogs, i.e., >> ones that don't automatically dismiss themselves when >> a command button is pressed. >> >>Other missing features/possible enhancements are listed in TODO >>notes at the top of library/dialog.tcl. >> >> >>--Joe English >> >> jen...@fl... >> >>[*] Except for '-type abortretryignore', which has been omitted >> for obvious reasons. >> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>from IBM. Find simple to follow Roadmaps, straightforward articles, >>informative Webcasts and more! Get everything you need to get up to >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>_______________________________________________ >>Tktable-tile-dev mailing list >>Tkt...@li... >>https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev >> >> >> > > -- > # 12th Annual Tcl/Tk Conference: Oct 24-28, 2005, Portland OR > # http://www.tcl.tk/community/tcl2005 > ------------------------------------------------------------- > -- Mentor Graphics Corp. -- > -- 8005 SW Boeckman Road 503.685.7000 tel -- > -- Wilsonville, OR 97070 USA 503.685.0921 fax -- > ------------------------------------------------------------- > -- Technical support ............ mailto:su...@mo... -- > -- Sales and marketing info ....... mailto:sa...@mo... -- > -- Licensing .................... mailto:li...@mo... -- > -- Home Page ........................ http://www.model.com -- > ------------------------------------------------------------- > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Tktable-tile-dev mailing list > Tkt...@li... > https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev > |
|
From: Jeff H. <je...@Ac...> - 2005-07-21 03:14:49
|
Damon Courtney wrote: > Also. If you give the user the ability to add widgets in a client > frame, maybe they want to do something with them after the user has > clicked a button. If I put a combobox inside the client frame, but > you destroy the window the minute they hit a button, I may not be able > to get the value that was in the combo when they clicked. Yes, I > know, I can use a -textvariable on the combobox, but you get the jist. But there is a no -textvariable for a text widget, or other more complex client areas. Yes, I've seen this be an issue before - there should be an option to withdraw the dialog without destroying it. Possibly in line with the persistent dialogs mentioned? Also useful as a feature where dialogs would be reused (even maintaining last state). Perhaps all a bit too much for a simple API, but delayed destruction is important. Jef |
|
From: Damon C. <dam...@tc...> - 2005-07-21 13:46:19
|
> But there is a no -textvariable for a text widget, or other
> more complex client areas. Yes, I've seen this be an issue
> before - there should be an option to withdraw the dialog
> without destroying it. Possibly in line with the persistent
> dialogs mentioned? Also useful as a feature where dialogs
> would be reused (even maintaining last state). Perhaps all
> a bit too much for a simple API, but delayed destruction is
> important.
Actually, I'm adding this type of feature to the BWidget Dialogs (and
the new ChooseDirectory widget). I just added a -name option to the
dialogs that would provide a name for the dialog, and they remember
state from the last instance. Example:
ChooseDirectory .d -name OpenImage
That way, even though choosing a directory can be done in many
different places throughout an application, each one remembers its
state. I like this better than a global state because I like to
remember where the user was last when the clicked this particular
dialog.
Damon
|
|
From: Jeff H. <je...@Ac...> - 2005-07-21 18:14:30
|
Damon Courtney wrote: > Actually, I'm adding this type of feature to the BWidget > Dialogs (and the new ChooseDirectory widget). I just added a > -name option to the dialogs that would provide a name for the > dialog, and they remember state from the last instance. Example: > > ChooseDirectory .d -name OpenImage > > That way, even though choosing a directory can be done in > many different places throughout an application, each one > remembers its state. I like this better than a global state > because I like to remember where the user was last when the > clicked this particular dialog. Isn't this redundant to the '.d' name already? If they reuse .d without destroying it, it should keep the info, otherwise they would have another named CD dialog, no? Jeff |
|
From: Damon C. <dam...@tc...> - 2005-07-27 16:27:19
|
> Damon Courtney wrote:
>> Actually, I'm adding this type of feature to the BWidget
>> Dialogs (and the new ChooseDirectory widget). I just added a
>> -name option to the dialogs that would provide a name for the
>> dialog, and they remember state from the last instance. Example:
>>
>> ChooseDirectory .d -name OpenImage
>>
>> That way, even though choosing a directory can be done in
>> many different places throughout an application, each one
>> remembers its state. I like this better than a global state
>> because I like to remember where the user was last when the
>> clicked this particular dialog.
>
> Isn't this redundant to the '.d' name already? If they reuse
> .d without destroying it, it should keep the info, otherwise
> they would have another named CD dialog, no?
Actually, the real purpose of the -name attribute is to make it easier
to create dialogs with a user state. IE:
Yes, No, No to All, Yes to All, Cancel
The user clicks "No to All," and the dialog remembers that based on
the name of the dialog. Then, any subsequent calls to create a dialog
with that name just immediately return a No. Of course, I'm not
exactly sure how to name that dialog.
MessageDlg .m -type yesnonotallyestoallcancel
Just doesn't seem like the right thing to do. 0-]
D
|
|
From: Joe E. <jen...@fl...> - 2005-07-27 21:13:37
|
Damon Courtney wrote: > [...] > Of course, I'm not exactly sure how to name that dialog. > > MessageDlg .m -type yesnonotallyestoallcancel > > Just doesn't seem like the right thing to do. 0-] > Great googly moogly no, that wouldn't be right at all :-) I think the approach taken by [ttk::dialog] is pretty close -- it's not *exactly* the right thing (I don't like the -labels option much), but it's close. In particular, taking an open-ended list of -buttons, and making '-type' a shorthand/compatibility feature that specifies a predefined set of other option/value pairs seems to me like a pretty good way of doing things. Take a look at the the (undocumented) ttk::dialog::stockButton and ttk::dialog::stockDialog procedures for ideas -- and if you can improve on them, let me know :-) --Joe English jen...@fl... |
|
From: Donal K. F. <don...@ma...> - 2005-07-21 07:53:32
|
Jeff Hobbs wrote: > But there is a no -textvariable for a text widget, or other > more complex client areas. Yes, I've seen this be an issue > before - there should be an option to withdraw the dialog > without destroying it. Possibly in line with the persistent > dialogs mentioned? Also useful as a feature where dialogs > would be reused (even maintaining last state). Perhaps all > a bit too much for a simple API, but delayed destruction is > important. Perhaps the right thing to do is to schedule the dialog for deletion upon idle before calling the callback. This gives the callback code all the time it wants to look at the contents of the widgets while arranging for the dialog to go away at the soonest possible opportunity anyway. Donal. |
|
From: Joe E. <jen...@fl...> - 2005-07-23 16:57:06
|
Damon Courtney wrote:
> Also. If you give the user the ability to add widgets in a client
> frame, maybe they want to do something with them after the user has
> clicked a button. If I put a combobox inside the client frame, but
> you destroy the window the minute they hit a button, I may not be able
> to get the value that was in the combo when they clicked. Yes, I
> know, I can use a -textvariable on the combobox, but you get the jist.
Turns out this was misdocumented: the implementation
calls the -command first, then dismisses the dialog.
Manpage updated to reflect this.
Also, in the current implementation the command can use
'return -code break' or 'return -code continue' to prevent
the dialog from being dismissed. I left this undocumented
since I'm not sure if it's a good idea; it seems like a bit
of a hairball. Opinions?
Last but not least: Schelte Bron has contributed a
*really* nice file selection dialog box. It's not
integrated into CVS yet, but you can grab a preview from
my work-in-process repository:
<URL: http://www.flightlab.com/~joe/themebag/fsdialog.tcl >
The dialog is modelled after KDE's file selector (one of
the best ones around, IMO, even better than the standard
Tk file selector). Check it out!
--Joe English
jen...@fl...
|
|
From: Joe E. <jen...@fl...> - 2005-07-23 17:26:44
|
I wrote:
> Last but not least: Schelte Bron has contributed a
> *really* nice file selection dialog box. It's not
> integrated into CVS yet, but you can grab a preview from
> my work-in-process repository:
>
Sorry, should've checked the URL before sending. Make that:
<URL: http://www.flightlab.com/~joe/repos/themebag/fsdialog.tcl >
--Joe English
jen...@fl...
|
|
From: Jeff H. <je...@Ac...> - 2005-07-25 16:36:31
|
> Also, in the current implementation the command can use > 'return -code break' or 'return -code continue' to prevent > the dialog from being dismissed. I left this undocumented > since I'm not sure if it's a good idea; it seems like a bit > of a hairball. Opinions? +1, although I might opt to separate what break and continue mean. Jeff |
|
From: Joe E. <jen...@fl...> - 2005-07-25 17:30:15
|
Jeff Hobbs wrote:
> > Also, in the current implementation the command can use
> > 'return -code break' or 'return -code continue' to prevent
> > the dialog from being dismissed. I left this undocumented
> > since I'm not sure if it's a good idea; it seems like a bit
> > of a hairball. Opinions?
>
> +1, although I might opt to separate what break and continue
> mean.
Agreed. I was thinking of something along these lines
for -command return code interpretations:
TCL_OK --
Default behavior -- dismiss the dialog if '-persistent false',
leave it up if '-persistent true'.
TCL_BREAK --
Always dismiss the dialog (overriding '-persistent true')
TCL_CONTINUE --
Always leave the dialog up (overriding '-persistent false')
TCL_RETURN --
(same as TCL_OK?)
TCL_ERROR --
Return the error result to the caller (normally
the event loop, which will eventually call bgerror).
Not sure what else should happen -- probably ought
to release the grab if '-modal true' was set.
Other --
Return the completion code/result/other return options
to to the caller.
--Joe English
jen...@fl...
|
|
From: Jeff H. <je...@Ac...> - 2005-07-25 17:36:14
|
> Agreed. I was thinking of something along these lines > for -command return code interpretations: > > TCL_OK -- > Default behavior -- dismiss the dialog if '-persistent false', > leave it up if '-persistent true'. > TCL_BREAK -- > Always dismiss the dialog (overriding '-persistent true') > TCL_CONTINUE -- > Always leave the dialog up (overriding '-persistent false') > TCL_RETURN -- > (same as TCL_OK?) The -persistent option to me seems more like "destroy" vs "withdraw", rather than stay up or not. Otherwise, that break and continue differentiation seems ok. > TCL_ERROR -- > Return the error result to the caller (normally > the event loop, which will eventually call bgerror). > Not sure what else should happen -- probably ought > to release the grab if '-modal true' was set. Always ensure the appropriate catch's are in the code to release grab if the user causes an error situation. > Other -- > Return the completion code/result/other return options > to to the caller. Jeff |
