Menu
▾
▴
tktable-tile-dev — Discussion about tile development
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(88) |
Oct
(30) |
Nov
(10) |
Dec
(12) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(31) |
Feb
(37) |
Mar
(39) |
Apr
(10) |
May
(3) |
Jun
(6) |
Jul
(23) |
Aug
(47) |
Sep
(55) |
Oct
(8) |
Nov
(6) |
Dec
|
| 2006 |
Jan
(21) |
Feb
(8) |
Mar
(17) |
Apr
(8) |
May
(26) |
Jun
(19) |
Jul
(11) |
Aug
(4) |
Sep
(17) |
Oct
(40) |
Nov
(71) |
Dec
(3) |
| 2007 |
Jan
(5) |
Feb
(7) |
Mar
(11) |
Apr
(6) |
May
(3) |
Jun
(4) |
Jul
(7) |
Aug
(1) |
Sep
|
Oct
(26) |
Nov
(12) |
Dec
(9) |
| 2008 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
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 |
|
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 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: Mats B. <mat...@ho...> - 2005-07-25 08:13:46
|
When building a C++ widget I had to change generic/widget.h from:
struct WidgetSpec_
{
....
enum { WIDGET_SPEC_END } sentinel; /* to help the compiler catch errors
*/
};
to:
typedef enum { WIDGET_SPEC_END } SentinelEnum; /* to help the compiler
catch errors */
struct WidgetSpec_
{
....
SentinelEnum sentinel; /* to help the compiler catch errors */
};
since in C++ WIDGET_SPEC_END gets "hidden" inside the struct due to
the more limited scope.
Mats
_________________________________________________________________
Hitta rätt på nätet med MSN Search http://search.msn.se/
|
|
From: Mats B. <mat...@ho...> - 2005-07-25 08:12:00
|
At http://sourceforge.net/tracker/index.php?func=detail&aid=1183535&group_id=11464&atid=311464 there are now four (4) different ways of drawing a chasing arrows element: 1) native aqua (patch tile-chasingarrows.patch ) 2) GDI+ for Win32 (patch chasearrowsXP.cpp) 3) generic Tk drawing which makes a rotating bar (patch ChasingArrowsElemBar.c ) 4) generic Tk drawing which makes a rotating circle of dots (patch aquaTheme.c; pick relevant element ) I would value the usefulness of these also in this order where applicable. Mozilla/Firefox also has a similar widget which shows itself also if not running using the "background" color of the ovals. Personally I don't like that behaviour since it just clutters the UI with nonrelevant parts. 3) and 4) can perhaps also be improved to fit particular themes. Opinions? Perhaps some kind of decision could be made... Mats _________________________________________________________________ Nyhet! Hotmail direkt i Mobilen! http://mobile.msn.com/ |
|
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: 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: 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-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: 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: 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. <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: 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: 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: Joe E. <jen...@fl...> - 2005-07-20 16:00:12
|
Mats Bengtsson wrote:
>
> I've run into two problems which I don't understand:
>
> 1) Setting ttk::entry font using
> style default Small.TEntry -font {Helvetica 8}
> pack [ttk::entry .e -style Small.TEntry]
> doesn't work. Using an explicit -font switch do work.
> This is different from most other tile widgets probably since
> they use a 'label' element which TEntry doesn't.
Known problem (see #1211387).
Hm... looking at it again, this doesn't seem too hard to fix.
Will up the priority.
> 2) Setting ttk::notebook tab fonts using (?)
> style default Small.TNotebook.Tab -font {Helvetica 8}
> style default Small.Tab -font {Helvetica 8}
> pack [ttk::notebook .nb -style Small.TNotebook.Tab]
> .nb add [ttk::label .nb.l -text Hej -padding 20] -text Hej
Also a known problem (see #1168548) -- basically,
custom styles for the "complex" widgets [ttk::notebook],
[ttk::treeview], and [ttk::paned] don't work at all,
since the widgets use hardcoded layout names for the subparts.
--Joe English
jen...@fl...
|
|
From: Mats B. <ma...@pr...> - 2005-07-20 14:11:50
|
I've run into two problems which I don't understand:
1) Setting ttk::entry font using
style default Small.TEntry -font {Helvetica 8}
pack [ttk::entry .e -style Small.TEntry]
doesn't work. Using an explicit -font switch do work.
This is different from most other tile widgets probably since
they use a 'label' element which TEntry doesn't.
2) Setting ttk::notebook tab fonts using (?)
style default Small.TNotebook.Tab -font {Helvetica 8}
style default Small.Tab -font {Helvetica 8}
pack [ttk::notebook .nb -style Small.TNotebook.Tab]
.nb add [ttk::label .nb.l -text Hej -padding 20] -text Hej
Tested on Aqua (1 also on XP)
/Mats
|
|
From: Mats B. <ma...@pr...> - 2005-06-19 13:19:32
|
I think it still a patch only. The problem is that I need to come up with something for the other platforms as well, and there is no "native" solution for this. I wrote two suggestions (think there are patches for both): 1) native tk drawing mimicing OSX, but that isn't optimal without antialiasing. The best looking I can get for 16x16 widget are 1x1 pixel dots for the radial lines of the aqua version. 2) similar but using the flat gdiplus lib from WinXP. It has antialiasing and ought to look ok, but I did this "in blindo" before I had got myself an XP box. I will look into this, and a few other tile things, as soon as I get a new version of Coccinella released. Kevin Walzer wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Did the Mac "chasing arrows" widget that was discussed on the list a > couple of months ago (developed by Mats) ever make it into a Tile > release? I haven't seen it documented anywhere (except in various > patches at SF, which I'm not sure have been applied or not). > > I'm also curious to know if this widget looks like the current Mac/Aqua > spinner widget, or is the literal "arrows" image that was on the classic > Mac OS. > It is Aqua native. /Mats |
|
From: Mats B. <ma...@pr...> - 2005-06-19 13:11:46
|
I think it still a patch only. The problem is that I need to come up with something for the other platforms as well, and there is no "native" solution for this. I wrote two suggestions (think there are patches for both): 1) native tk drawing mimicing OSX, but that isn't optimal without antialiasing. The best looking I can get for 16x16 widget are 1x1 pixel dots for the radial lines of the aqua version. 2) similar but using the flat gdiplus lib from WinXP. It has antialiasing and ought to look ok, but I did this "in blindo" before I had got myself an XP box. I will look into this, and a few other tile things, as soon as I get a new version of Coccinella released. Kevin Walzer wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Did the Mac "chasing arrows" widget that was discussed on the list a > couple of months ago (developed by Mats) ever make it into a Tile > release? I haven't seen it documented anywhere (except in various > patches at SF, which I'm not sure have been applied or not). > > I'm also curious to know if this widget looks like the current Mac/Aqua > spinner widget, or is the literal "arrows" image that was on the classic > Mac OS. > It is Aqua native. /Mats |
|
From: Kevin W. <sw...@wo...> - 2005-06-17 23:20:15
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Did the Mac "chasing arrows" widget that was discussed on the list a couple of months ago (developed by Mats) ever make it into a Tile release? I haven't seen it documented anywhere (except in various patches at SF, which I'm not sure have been applied or not). I'm also curious to know if this widget looks like the current Mac/Aqua spinner widget, or is the literal "arrows" image that was on the classic Mac OS. - -- Cheers, Kevin Walzer, PhD WordTech Software--Open Source Applications and Packages for OS X http://www.wordtech-software.com http://www.kevin-walzer.com http://www.smallbizmac.com. mailto:sw...@wo... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCs1qqJmdQs+6YVcoRAswAAJ4gjp18XoaunOu4//0ebws1el6ifQCggX0t IVj0XoVreeCiEyqw3zmQMkg= =uySq -----END PGP SIGNATURE----- |
|
From: Mark G. <du...@ya...> - 2005-06-14 11:51:05
|
I have comboboxes packed in resizable windows (a spreadsheet cell) and would like to make use of the -width option of the listbox widget to force the listbox to be a certain size regardless of the current width of the combobox as defined by the cell. Is there a way to do that besides altering combobox.tcl? Thanks --------------------------------- Yahoo! Mail Stay connected, organized, and protected. Take the tour |
|
From: <aku...@sh...> - 2005-06-14 04:47:42
|
Submission of Summaries
Tcl/Tk 2005 will be held in Portland, Oregon USA from October 24 -
October 28. The program committee asks all people using and developing
with Tcl/Tk and extensions to submit papers and proposals for
presentations at this conference. Past conferences have seen
submissions covering a wide variety of topics including and not
limited to:
* Scientific and engineering applications
* Industrial controls
* Distributed applications and Network Managment
* Object oriented extensions to Tcl/Tk
* New widgets for Tk
* Simulation and application steering with Tcl/Tk
* Tcl/Tk-Centric operating environments
* Tcl/Tk on small and embedded devices
* Medical applications and visualization
* Use of different programming paradigms in Tcl/Tk and proposals
for new directions.
* New areas of exploration for the Tcl/Tk language
The submissions should consist of an abstract of about 100 words and a
summary of maximum two pages. Omit extraneous or redundant
information. Length is not a direct factor in judging the quality of
the submission.
Send submissions as plain text to <tcl2005 AT tcl.tk> no later than
July 1, 2005. Authors of accepted abstracts will have until September
15, 2005 to submit their final paper for the inclusion in the
conference proceedings. The proceedings will be made available on
CD-ROM, so extra materials like code samples are welcome.
The authors will have 20-25 minutes to present the paper at the
conference.
The program committee will review and evaluate papers according to the
following criteria:
* Quantity and quality of novel content
* Relevance and interest to the Tcl/Tk community
* Suitability of content for presentation at the conference
Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.
Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.
Papers accompanied by non-disclosure agreement forms will be returned
to the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.
The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.
Other Forms of Participation
The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.
Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis
starting in August, 2005. Specific instructions for reserving WIP and
BOF time slots will be provided in the registration information
available in June 2005. Some WIP and BOF time slots will be held open
for on-site reservation, so we encourage all attendees with
interesting work in progress to consider presenting that work at the
conference. Registration Information
More information on the conference will be available in April 2005 at
the conference Web site and published on various Tcl/Tk-related
information channels.
To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list.
Conference Committee
Brian Griffin Mentor Graphics Facilities Coordination
Clif Flynt Noumena Corp General Chair, Website Admin
Ron Fox NSCL MSU Program Chair
Arjen Markus WL Delft Hydraulics
Cyndy Lilagan Eolas Corp
Gerald Lester HMS Software
Donal Fellows University of Manchester
Jeffrey Hobbs ActiveState Corp
Steve Landers Digital Smarties
Kevin Kenny GE Global Research Center
Ken Jones Avia Training
Sheila Miguez mVerify
Larry Virden Tcl FAQ Maintainer
Andreas Kupries ActiveState Corp
Contact Information <tcl2005 AT tcl.tk>
--
Sincerely,
Andreas Kupries <aku...@sh...>
<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------
|
|
From: Damon C. <dam...@tc...> - 2005-06-03 16:14:07
|
All,
Are we planning on keeping the colors array around? I'm just
wondering if it's something I can use reliably. I currently am for
lack of a better choice, but I don't necessarily think it's a bad
idea. I even had to go through and add a colors array for the XP
theme so that my code would work properly. If we're going to keep the
colors array around, shouldn't we at least flesh out the rest of the
themes that are lacking it?
Damon
|
|
From: <ro...@po...> - 2005-05-31 11:39:28
|
Detlef Groth asked me to announce here, that his dgHelpBrowser now includes the tile 0.6.2 documentation. The dgHelpBrowser application is an advanced help viewer. For more information about dgHelpBrowser see http://mini.net/tcl/dgHelpBrowser rolf -- Im Urlaub / On vacation: 2005-07-28 - 2005-08-12. |
|
From: Joe E. <jen...@fl...> - 2005-05-25 19:34:08
|
Techentin, Robert W. wrote: > I would like to deploy a starkit application with both BLT and Tile, > particularly on Windows, [...] > Unfortunately, dqkit (and even other older tclkits) can't load > tile06.kit because pkgIndex.tcl insists on Tcl 8.4.6 or higher. [...] The problem that the tile06.kit's pkgIndex.tcl script is trying to avoid is: the theme engine calls a Tk private routine that wasn't added to the private stubs table until Tk 8.4.6. So if you compile Tile against post-8.4.6 private headers, and load it into a pre-8.4.6 interp, it will crash. Other possibilities are: (1) Compile with -DNO_PRIVATE_HEADERS (see tkTheme.c). Then tile.dll will declare and call the offending function directly instead of going through the stubs table. This may cause a runtime linker error, depending on the platform and how the core was built. (2) Compile against pre-8.4.6 headers. This will have basically the same effect as (1), plus you'll get a compiler warning. (3) Build tile --enable-static and link libtile.a / TILE.LIB into the Big Wish / starkit runtime / whatever. Tile_Init() supports the usual tcl_findLibrary conventions for locating its init script. > Tinkering around a bit, I find that I can actually load tile06.kit's > tile06.dll into dqkit if I can get past the pkgIndex.tcl limitations. > [...] > I haven't done extensive testing, but the demos still runs, so I presume > that all the widgets work. Is this reasonable, or a bad idea? If it doesn't die with a runtime linker error, and doesn't crash when you create and map a widget, you should be OK. --Joe English jen...@fl... |
|
From: Techentin, R. W. <tec...@ma...> - 2005-05-25 16:23:49
|
I would like to deploy a starkit application with both BLT and Tile, particularly on Windows, where starkit/starpack is a big distribution win, and I can get the XP native theme. But BLT is not a "well behaved" stubs-enabled extension. So I can't just drop its library into a starkit. Instead I have to resort to a specially built bloated tclkit that includes BLT. One such beast is dqkit from http://sourceforge.net/projects/dqsoftware/. Unfortunately, dqkit (and even other older tclkits) can't load tile06.kit because pkgIndex.tcl insists on Tcl 8.4.6 or higher. And rebuilding a huge beast like dqkit looks hard. Tile's docs seem to indicate that you can build it against pre-8.5 Tcl without stubs. So I downloaded Tcl and Tk 8.4.5 (matching dqkit's versions), fired up MSYS/MingW, and built Tcl, Tk, and Tile. Configure and make went smoothly, but the resulting library doesn't know about xpnative theme. Something about uxtheme.h, which I don't have. Tinkering around a bit, I find that I can actually load tile06.kit's tile06.dll into dqkit if I can get past the pkgIndex.tcl limitations. Is tile06.kit really limited to tclkit's 8.4.6 and higher? Or is this pkgIndex.tcl logic left over from something else? Just for reference, tile.kit comes with this logic in pkgIndex.tcl: if {![package vsatisfies [package provide Tcl] 8.4]} { return } if {[package vsatisfies [package provide Tcl] 8.5] || [package vsatisfies [info patchlevel] 8.4.6]} { # use the stubs linked version set ::env(TILE_LIBRARY) $dir package ifneeded tile 0.6 \ [list load [file join $dir $platform tile06[info sharedlibextension]]] } else { return } But this logic, similar to that created by building Tile from source, seems to suffice, and seems to work. if {![package vsatisfies [package provide Tcl] 8.4]} { return } package ifneeded tile 0.6.2 \ [list load [file join $dir $platform tile06[info sharedlibextension]] tile] I haven't done extensive testing, but the demos still runs, so I presume that all the widgets work. Is this reasonable, or a bad idea? Thanks, Bob -- Bob Techentin tec...@ma... Mayo Foundation (507) 538-5495 200 First St. SW FAX (507) 284-9171 Rochester MN, 55901 USA http://www.mayo.edu/sppdg/ |
5 messages has been excluded from this view by a project administrator.
