Proposed ttk::dialog callback change

[Kevin Partin]

Currently when the user presses a button on a ttk::dialog widget, the
widget is destroyed regardless of which button was invoked, and the
return status of the callback command.

In terms of user feedback and interaction with the dialog widget,
wouldn't it be better if the command where executed before the dialog
widget is destroyed? The dialog widget could check the return status of
the command, and if it was zero, destroy the dialog. This way the
programmer has some control over when the dialog is destroyed.

To accomplish this task now, I don't specify a '-command' option when I
create the dialog, and configure the dialog button commands after the
dialog is created.

Just a thought. I don't know if this topic has been previously
discussed.
--
Kevin Partin
Applied Structural Dynamics, Inc.
[phone]


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Tktable-tile-dev mailing list
Tktable-tile-dev@...
https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev

[Jeff Hobbs]

Kevin Partin wrote:

> Currently when the user presses a button on a ttk::dialog widget, the
> widget is destroyed regardless of which button was invoked, and the
> return status of the callback command.
>
> In terms of user feedback and interaction with the dialog widget,
> wouldn't it be better if the command where executed before the dialog
> widget is destroyed? The dialog widget could check the return status of
> the command, and if it was zero, destroy the dialog. This way the
> programmer has some control over when the dialog is destroyed.
>
> To accomplish this task now, I don't specify a '-command' option when I
> create the dialog, and configure the dialog button commands after the
> dialog is created.
>
> Just a thought. I don't know if this topic has been previously
> discussed.

I agree, but this and other points is why ttk::dialog is not in 8.5
core.  You can look at widget::dialog for ideas on how to handle the
richer possible interactions with a dialog.  It is more of a replacement
for a general dialog shell, whereas ttk::dialog tries to be a richer
tk_dialog.

Jeff

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Tktable-tile-dev mailing list
Tktable-tile-dev@...
https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev

[Joe English-2]

Kevin Partin wrote:

> Currently when the user presses a button on a ttk::dialog widget, the
> widget is destroyed regardless of which button was invoked, and the
> return status of the callback command.
>
> In terms of user feedback and interaction with the dialog widget,
> wouldn't it be better if the command where executed before the dialog
> widget is destroyed? The dialog widget could check the return status of
> the command, and if it was zero, destroy the dialog. This way the
> programmer has some control over when the dialog is destroyed.

The dialog will stay posted if the -command script returns
a TCL_BREAK or TCL_CONTINUE return code.  Does that do
what you want?


--Joe English

  jenglish@...

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Tktable-tile-dev mailing list
Tktable-tile-dev@...
https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev

[Kevin Partin]

Yes, that will do nicely. Thanks for the post.

Kevin

On Sat, 2007-12-01 at 10:12 -0800, Joe English wrote:

> Kevin Partin wrote:
>
> > Currently when the user presses a button on a ttk::dialog widget, the
> > widget is destroyed regardless of which button was invoked, and the
> > return status of the callback command.
> >
> > In terms of user feedback and interaction with the dialog widget,
> > wouldn't it be better if the command where executed before the dialog
> > widget is destroyed? The dialog widget could check the return status of
> > the command, and if it was zero, destroy the dialog. This way the
> > programmer has some control over when the dialog is destroyed.
>
> The dialog will stay posted if the -command script returns
> a TCL_BREAK or TCL_CONTINUE return code.  Does that do
> what you want?
>
>
> --Joe English
>
>   jenglish@...
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Tktable-tile-dev mailing list
> Tktable-tile-dev@...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev

--
Kevin Partin
Applied Structural Dynamics, Inc.
[phone]


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Tktable-tile-dev mailing list
Tktable-tile-dev@...
https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev

[Christian Surlykke]

Hi

I'm running tcl8.5b3, tk8.5b3, tile-0.7.8 and tileqt0.4b1, compiled from
sources.

If I do:

  package require Tk
  package require tile
  package require "tile::theme::tileqt"

I get:

  couldn't load
file "/usr/local/lib/tileqt0.4/libtileqt0.4.so": /usr/local/lib/tileqt0.4/libtileqt0.4.so:
undefined symbol: Ttk_RegisterElement

But if I do:

  package require tile
  package require Tk
  package require "tile::theme::tileqt"

It works ok.

Is this a bug or intentional?

(It's a bit of a problem for me because I use Tk from Ruby, and Ruby seems to
load Tk before tile)

thanks

Christian Surlykke
   

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Tktable-tile-dev mailing list
Tktable-tile-dev@...
https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev

[Joe English-2]

Christian Surlykke wrote:

>
> I'm running tcl8.5b3, tk8.5b3, tile-0.7.8 and tileqt0.4b1, compiled from
> sources.
>
> If I do:
>
>   package require Tk
>   package require tile
>   package require "tile::theme::tileqt"
>
> I get:
>
>   couldn't load
> file "/usr/local/lib/tileqt0.4/libtileqt0.4.so": /usr/local/lib/tileqt0.4/libtileqt0.4.so:
> undefined symbol: Ttk_RegisterElement

The Tcl API and C ABI for third-party themes
suffered a number of incompatible changes from
Tile 0.7.8 when it was integrated into the core.

>From the error message, it would appear that your copy
of Tile-QT was compiled without -DUSE_TTK_STUBS.
Try adding that, and compile against Tk 8.5 headers
instead of Tile 0.7.8 headers.

I'm sorry I don't have any further suggestions.
This aspect of TIP#248 was not well thought out.


--Joe English

  jenglish@...

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Tktable-tile-dev mailing list
Tktable-tile-dev@...
https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev

[Christian Surlykke]

Tried compiling with -DUSE_TTK_STUBS and against ttk headers, but it made no
difference. (I could compile tileqt without tile, but 'package require
tile::theme::tileqt' still gives same error.)

I'll revert to (Tcl/Tk)8.5a5 for now and try to raise the issue with the Ruby
people.

Thanks for your time.

Chr.
 
Lørdag den 15. December 2007 skrev Joe English:

> Christian Surlykke wrote:
> > I'm running tcl8.5b3, tk8.5b3, tile-0.7.8 and tileqt0.4b1, compiled from
> > sources.
> >
> > If I do:
> >
> >   package require Tk
> >   package require tile
> >   package require "tile::theme::tileqt"
> >
> > I get:
> >
> >   couldn't load
> > file "/usr/local/lib/tileqt0.4/libtileqt0.4.so":
> > /usr/local/lib/tileqt0.4/libtileqt0.4.so: undefined symbol:
> > Ttk_RegisterElement
>
> The Tcl API and C ABI for third-party themes
> suffered a number of incompatible changes from
> Tile 0.7.8 when it was integrated into the core.
>
> >From the error message, it would appear that your copy
>
> of Tile-QT was compiled without -DUSE_TTK_STUBS.
> Try adding that, and compile against Tk 8.5 headers
> instead of Tile 0.7.8 headers.
>
> I'm sorry I don't have any further suggestions.
> This aspect of TIP#248 was not well thought out.
>
>
> --Joe English
>
>   jenglish@...
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplac
>e _______________________________________________
> Tktable-tile-dev mailing list
> Tktable-tile-dev@...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Tktable-tile-dev mailing list
Tktable-tile-dev@...
https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev