tktable-tile-dev — Discussion about tile development

Re: [Tile-dev] Aqua binary

[Csaba N. <csa...@t-...>]

Kevin Walzer wrote:
> Csaba,
> 
> I've compiled it and am using it in a couple of different applications.
> If one proves unavailable through official channels, let me know and
> I'll make my build available.
> 

Kevin,

Many thanks for your help.  All I need is the dylib for Mac OS X Aqua.
I would very much appreciate if you could send me this library.  I have
built myself a version for Linux, but I am still new to the Mac, and
right now I just don't have enough time to set up the developer
environment.

Best regards,
Csaba

-- 
Csaba Nemethi   http://www.nemethi.de   mailto:csa...@t-...

Re: [Tile-dev] Aqua binary

[Kevin W. <sw...@wo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Csaba,

I've compiled it and am using it in a couple of different applications.
If one proves unavailable through official channels, let me know and
I'll make my build available.

Cheers,

Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw...@wo...

Csaba Nemethi wrote:
| Where can I find a tile binary for Mac OS X Aqua, based on the latest
| release 0.6.2 (patched)?  Since the file tile06.dylib in the directory
| Darwin-ppc of tile06.kit found on SourceForge complains that it cannot
| open the library /usr/X11R6/lib/libX11.6.dylib, it seems to be for X11
| on Mac OS X, not for the Aqua environment.
|
| Any pointers are greatly appreciated.
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCb+7VJmdQs+6YVcoRAkcTAJ9AnObDPPoSMhakRSj7YapzLZe0owCdH8+e
N2WsJ87eFQx6daEph3NgB/E=
=YiLt
-----END PGP SIGNATURE-----

[Tile-dev] Aqua binary

[Csaba N. <csa...@t-...>]

Where can I find a tile binary for Mac OS X Aqua, based on the latest
release 0.6.2 (patched)?  Since the file tile06.dylib in the directory
Darwin-ppc of tile06.kit found on SourceForge complains that it cannot
open the library /usr/X11R6/lib/libX11.6.dylib, it seems to be for X11
on Mac OS X, not for the Aqua environment.

Any pointers are greatly appreciated.

-- 
Csaba Nemethi   http://www.nemethi.de   mailto:csa...@t-...

[Tile-dev] chasearrows widget & element for aqua

[Mats B. <ma...@pr...>]

New code for a chasearrows widget on aqua:
http://sourceforge.net/tracker/index.php?func=detail&aid=1183535&group_id=11464&atid=311464

I don't know if their is something similar on Windows.
Mozilla has a similar widget. In any case I could do
something similar as mozillas chasing arrows widget using
the Tk drawing. Opinions?

/Mats

Re: [Tile-dev] Tab panes geom on aqua

[Joe E. <jen...@fl...>]

Mats Bengtsson wrote:

> It seems that the extra padding allocated in PaneElementGeometry()
> in aquaTheme.c
>     *paddingPtr = Ttk_MakePadding(2,8,2,2);
> is not accounted for in NotebookDoLayout().
> [...]

Filed at SourceForge, #1182704.  Will investigate.

    <URL: http://sourceforge.net/support/tracker.php?aid=1182704 >


--Joe English

  jen...@fl...

[Tile-dev] Tab panes geom on aqua

[Mats B. <ma...@pr...>]

It seems that the extra padding allocated in PaneElementGeometry()
in aquaTheme.c
    *paddingPtr = Ttk_MakePadding(2,8,2,2);
is not accounted for in NotebookDoLayout().
The bottom widget in the notebook client area gets clipped
by about 10 pixels which is the pane padding height.
If I comment out the line above the client widgets fit perfectly.

Before: http://www.visit.se/~matben/tile/tilecvs.jpg
After:  http://www.visit.se/~matben/tile/tileNoTabPanePadding.jpg
Script: http://www.visit.se/~matben/tile/TileDialogsPrint.tcl

I have tried to look into the code but don't understand much...

Mats

[Tile-dev] ANNOUNCE: Tile Widget Set release 0.6.2

[Joe E. <jen...@fl...>]

[12 Apr 2005]

ANNOUNCE: Tile Widget Set, version 0.6.2.

~ What is it?

The Tile widget set is an experimental reimplementation
of some of the standard Tk widgets.  The main features are:

    + Native look and feel under Windows (XP, NT, 2K, 98 and 95)
    + Nearly-native look and feel under Mac OSX
    + "Revitalized" look and feel under X11
    + Appearance controlled by a theme engine, providing
      greater flexibility for custom widgets
    + New widgets, including notebook, progressbar, combobox,
      and separator

~ What's New in 0.6

    + Many, many enhancements and bugfixes on Aqua.
      Mac OSX users will definitely want to upgrade!

    + ttk::notebook: Can now selectively disable and/or hide
      individual tabs

    + New ttk::paned container widget, similar to the core panedwindow.

    + New ttk::progressbar widget -- now with documentation!
      NOTE: the API is different from the ttk::progress widget
      (hence the new name).  This will require minor adjustments
      to user code.

    + State-sensitive images for buttons, labels, and other widgets:
      The "-image" option is now a list.  The first element specifies
      the default image, and the remainder is a state map specifying
      alternate images to use when the widget is in different states.

      * * * POTENTIAL INCOMPATIBILITY * * * with previous Tile releases
      and with the core, if you use images with spaces in their names.

    + Now includes stub table support, to make it easier to
      build and install add-on themes written in C.


~ What's Old

The old widget constructor names like "tbutton" etc. will
now issue a warning if used; use "ttk::button" instead.

The "pixmap" element constructor has been removed; if you
haven't switched to using "image", now is the time to do so.

The "ttk::progress" widget is now deprecated; use "ttk::progressbar"
instead.


~ A note on version numbers:

To help distinguish formal releases from CVS snapshots,
the version number returned by [package provide tile]
now includes a patch level, currently 0.6.2.

In future, the patch number will be incremented immediately
before and immediately after making a release.  Thus
odd-numbered subminor versions will indicate a CVS snapshot,
and even-numbered ones will indicate a known release.


~ Availability

The tile widget set is hosted under the tktable project
at SourceForge:

    <URL: http://tktable.sourceforge.net/tile/ >
    <URL: http://sourceforge.net/projects/tktable/ >

Sources are available under the 'tile' module in CVS.
A prebundled tarball is available in the file release area:

    <URL: http://sourceforge.net/project/showfiles.php?group_id=11464 >

Documentation is available here:

    <URL: http://tktable.sourceforge.net/tile/doc/ >


Precompiled libraries for Windows may also be present;
check for availability.


--Joe English

[Tile-dev] New Tk Aqua & Tile application release

[Kevin W. <sw...@wo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For any who are interested, I've released DPGUI--the application suite
that provides a graphical interface to the DarwinPorts package
management system on OS X. The DPGUI applications are written in Tcl/Tk
and make extensive use of the Tile package. I mention this as part of my
interest in using TkAqua and Tile as an environment for developing good
Mac-specific applications (as opposed to porting applications from other
platforms).

The relevant web page is http://www.wordtech-software.com/dpgui.html

Thanks to Daniel Steffen, Jim Ingham, Michael Kirkham, and Joe English
for their fantastic work with TkAqua and Tile Aqua: I hope my
applications are useful showcases for what the tools you develop can do.

- --
Cheers,

Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw...@wo...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCW+jFJmdQs+6YVcoRAhpwAJ4jT/badHINn43If3EDvKn9mjd89ACgiszr
Q18o873NvrXA8c7shDC+ssA=
=BdHw
-----END PGP SIGNATURE-----

[Tile-dev] On version numbers

[Joe E. <jen...@fl...>]

In the past, I've been incrementing the version number
in CVS to "0.N+1" shortly after releasing version "0.N".
This isn't working.

Starting with 0.6 I'm going to try a new approach:
the version number now includes a patchlevel, which
will be incremented immediately before _and_ immediately
after making a release.  0.6 will actually be 0.6.2;
even-numbered patchlevels will indicate an "official"
release, and odd-numbered ones will indicate a random
CVS snapshot.  This should make it easier for application
authors to ensure that they're working with a known
baseline.


--Joe English

  jen...@fl...

Re: [Tile-dev] A few questions

[Michael K. <mi...@mu...>]

On Wed, 30 Mar 2005, Joe English wrote:

> 0.6 was going to be released in early February, but then all
> the Mac users conspired to produce a steady stream of bugfixes
> and enhancements.  This has delayed the release a bit, but
> I think it'll be worth it.  (Note to Michael: please stop
> fixing stuff.)

Awww. :P  At least I think I'm pretty much set unless I decide to switch 
to Tile's paned widget.  Then I might have to do something about Aqua 
styling there. ;)

Unfortunately, it looks like that little circular button you see e.g. 
between the left and right panes in Finder windows, that corresponds to a 
sash in Tk paned widget speak, seems to be neigher drawable through themes 
nor a system icon somewhere, but is pretty tied directly to some high 
level HI stuff or something.  So this might require just drawing one as an 
image.  I don't mind that so much, but it should probably have an alpha 
channel and you can't currently do alpha through the GetColor format, so 
you can't create images with alpha through Tcl scripts unless you use an 
extension like TkPNG (which is partly why I wrote it).

Other than that, it's just the line width thing.  That was apparently 
"fixed" in the core-8-4 branch of Tk by setting the default line width to 
1 in the XLib emulation layer, but I don't know if that was the right 
thing to have been done so I don't know if it'll stay.  (Don't know what 
consequences that might have for GCs outside of Tk_GetColor() and their 
uses.)

> Right now there's one outstanding showstopper bug (#1151526),
> and a couple almost-ready patches; as long as nothing else
> comes up in the next few days, 0.6 will be out Real Soon Now.

*whistles innocently*

--
Michael Kirkham
www.muonics.com

Re: [Tile-dev] new OS X "Tab View" control

[Joe E. <jen...@fl...>]

Jeff Hobbs wrote:

> Someone pointed out that the Tile tab notebook isn't "10.3" compliant,
> as defined here:
>
> http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuide
> l
> ines/XHIGControls/chapter_10_section_7.html#//apple_ref/doc/uid/TP30000359/TP
> X
> REF105
>
> Any thoughts on whether that should be used?


The tile notebook ought to use that form, but the
Appearance Manager API doesn't seem to provide
any way to draw it.  The missing piece is the
"segmented control" gizmo.


--Joe English

  jen...@fl...

[Tile-dev] new OS X "Tab View" control

[Jeff H. <je...@Ac...>]

Someone pointed out that the Tile tab notebook isn't "10.3" compliant,
as defined here:

http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIG=
uidel
ines/XHIGControls/chapter_10_section_7.html#//apple_ref/doc/uid/TP3000035=
9/TPX
REF105

Any thoughts on whether that should be used?

Jeff

Re: [Tile-dev] A few questions

[Joe E. <jen...@fl...>]

Csaba Nemethi worte:

> [...] I don't quite understand why tile
> colors might fail to work as the value of the "-background" option for
> a Tk core widget.

The tile widgets use an auxilliary database for color names,
which extends the Tk color name database.  Right now this is
mainly used for Windows system colors, but it may be extended
in the future to allow arbitrary user- or theme-defined symbolic
color names.

Right now the only visible difference is that on Windows,
things like "SystemButtonFace" mean "the current system button
face color" for Tile widgets, and "the system button face color
at the time the program started" for core widgets.  These
will normally be the same, unless the user has switched color
schemes while the program is running.

Something similar will probably be implemented under X11,
in which case the theme-defined Tile widget color names 
won't even be recognized by core widgets.


--Joe

Re: [Tile-dev] A few questions

[Csaba N. <csa...@t-...>]

Joe English wrote:
> 
> For colors, beware that Tile widgets use an auxilliary database
> for color names, so even if you could find out what color is
> being used for (say) the ttk::frame background, there's no guarantee
> it will work as the -background for a core frame widget.
> 
> That said, solving the tile vs core widget color clash is a
> high-priority issue, right up there with The Background Problem.
> More on that later.

Thanks for the prompt reply, Joe.  I don't quite understand why tile
colors might fail to work as the value of the "-background" option for
a Tk core widget.  Maybe an example would clarify this (if you don't
mind).

Best regards,
Csaba

-- 
Csaba Nemethi   http://www.nemethi.de   mailto:csa...@t-...

Re: [Tile-dev] A few questions

[Joe E. <jen...@fl...>]

Csaba Nemethi wrote:
>
> 1. Is a spinbox widget planned for some future tile release?  IMHO, this
>     would be important, because mixing tile entry and combobox widgets
>     with Tk core spinboxes doesn't look very nice.  The latest CVS
>     sources don't seem to contain anything related to spinboxes.

One is planned, but not in the immediate future.
Probably in the next 3-4 months. 

If you have any good ideas for how this widget ought 
to work and what features it should have, post them here;
it'll be a good starting point.

(My main goal in adding a spinbox is not so much for the
sake of having a spinbox, but rather to figure out what
kind of megawidget facilities are needed to make it easy
to build things _like_ spinboxes.)


> 2. What is the current state of the implementation of introspection
>     capabilities in tile?

Not Yet Implemented.  It's on the TODO list but keeps
getting pushed back.  This probably won't make it into 0.6.

> But even more
>     important would be for me to have a way to retrieve the *real*
>     default and current font and colors of some tile widgets (for
>     example, ttk::label).  Again, I couldn't find anything new related
>     to introspection in the current CVS sources.


For fonts, Tile always [*] uses the TIP#148-inspired symbolic font
names defined library/fonts.tcl.  Applications can and should use
those as well.

[*] Except for the "classic" theme.

For colors, beware that Tile widgets use an auxilliary database
for color names, so even if you could find out what color is
being used for (say) the ttk::frame background, there's no guarantee
it will work as the -background for a core frame widget.

That said, solving the tile vs core widget color clash is a
high-priority issue, right up there with The Background Problem.
More on that later.


> 3. Any approximate schedule time for the next tile release?  (Please
>     don't hate me for this question! :-))

0.6 was going to be released in early February, but then all
the Mac users conspired to produce a steady stream of bugfixes
and enhancements.  This has delayed the release a bit, but
I think it'll be worth it.  (Note to Michael: please stop
fixing stuff.)

Right now there's one outstanding showstopper bug (#1151526),
and a couple almost-ready patches; as long as nothing else
comes up in the next few days, 0.6 will be out Real Soon Now.


--Joe English

  jen...@fl...

[Tile-dev] A few questions

[Csaba N. <csa...@t-...>]

I have a few questions to the tile Developer Team:

1. Is a spinbox widget planned for some future tile release?  IMHO, this
    would be important, because mixing tile entry and combobox widgets
    with Tk core spinboxes doesn't look very nice.  The latest CVS
    sources don't seem to contain anything related to spinboxes.

2. What is the current state of the implementation of introspection
    capabilities in tile?  For example, both "tile theme use alt" and
    "tile::setTheme alt" can be used for setting the current theme, but
    the variable "tile::currentTheme" is only set by the second method,
    and "tile theme use" doesn't yet work as stated in the documentation
    (i.e., it cannot be used to query the current theme).  But even more
    important would be for me to have a way to retrieve the *real*
    default and current font and colors of some tile widgets (for
    example, ttk::label).  Again, I couldn't find anything new related
    to introspection in the current CVS sources.

3. Any approximate schedule time for the next tile release?  (Please
    don't hate me for this question! :-))

Best regards,
Csaba

-- 
Csaba Nemethi   http://www.nemethi.de   mailto:csa...@t-...

[Tile-dev] Tcl/Tk 2005 First Call for papers

[<aku...@sh...>]

Tcl/Tk 2005 First Call for papers.
===================================

Tcl/Tk 2005 will be held in Portland, Oregon USA in late October or
early November.  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


At this point we are requesting submissions of:

   * Abstracts of papers for oral presentation.
   * Proposals for short courses to be taught the day prior to the conference.
   * Proposals for other presentations/discussions.
   * Proposals to present tutorial sessions.

Please send abstracts and proposals to tcl2005 (at) nscl (dot) 
msu (dot) edu

Important target dates:
=======================
 July  1, 2005    - Abstracts and proposals due.
 July 31, 2005    - Notification to authors.
 Sep  15, 2005    - Author materials due.

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.

The authors of oral presentations 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.

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.



Program Committee:
==================
 Donal  Fellows       University of Manchester
 Clif   Flynt         Noumena Corp.
 Ron    Fox           NSCL Michigan State University
 Jeff   Hobbs         ActiveState Corp.
 Steve  Landers       Digital Smarties
 Gerald Lester        HMS Software
 Cyndy  Lilagan       Eolas Technologies Inc.
 Arjen  Markus        WL | Delft Hydraulics

--
Sincerely,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

RE: [Tile-dev] Feature Request: combobox text field mousewheel binding

[Jeff H. <je...@Ac...>]

> The convention on X11 (which Tk follows) is that mousewheel=20
> events are delivered to the window under the mouse pointer,=20
> not the one with keyboard focus.
>=20
> With this model, comboboxes are less likely to be=20
> accidentally mousewheeled; OTOH, it also makes combobox=20
> mousewheel bindings somewhat less useful.
>=20
> I thought there was talk of making Tk on Windows work the
> same way (i.e., mousewheel events follow pointer instead
> of focus) -- what became of that?

http://www.tcl.tk/cgi-bin/tct/tip/171.html

"Instead of requiring a widget to have [focus] to receive MouseWheel =
events,
the new proposal operates with MouseWheel as a global binding. When =
fired, it
first does a safety check to prevent double-firing if an existing =
MouseWheel
binding is on the widget. It then finds the widget which the mouse if =
over and
uses that as the target for the scrolling event. If that widget doesn't =
exist
(usually meaning that it returned {} indicating we are outside the Tk =
app),
then use the widget which has the actual [focus]."

So this proposal doesn't avoid all the Combobox focus issues,
but it will avoid the most common ones.

> Implementation question: should the selected item "wrap=20
> around" when scrolled with the mousewheel, or should=20
> scrolling up (resp down) stop at the first (resp last) item?

Hmmm, I haven't seen wrapping done with mousewheel scrolling.
The mousewheel is an adjunct to the scrollbar, and scrollbars
don't wrap.


Jeff

Re: [Tile-dev] Feature Request: combobox text field mousewheel binding

[Joe E. <jen...@fl...>]

Brian Griffin wrote:
> I guess my point is M$ can get things wrong also.  Just because they do
> something some way doesn't make it a standard.

+1.  Windows gets a lot of things right, but not everything.
If Tk can do better, it should.

That said, I'm not sure where this particular feature falls 
on the right thing/wrong thing spectrum (my home machine has a 
trackball, no mousewheel, so I'm a little bit in the dark here ... :-)

The convention on X11 (which Tk follows) is that mousewheel 
events are delivered to the window under the mouse pointer, 
not the one with keyboard focus.

With this model, comboboxes are less likely to be accidentally
mousewheeled; OTOH, it also makes combobox mousewheel bindings
somewhat less useful.

I thought there was talk of making Tk on Windows work the
same way (i.e., mousewheel events follow pointer instead
of focus) -- what became of that?

Implementation question: should the selected item "wrap around"
when scrolled with the mousewheel, or should scrolling up
(resp down) stop at the first (resp last) item?


--Joe English

  jen...@fl...

Re: [Tile-dev] Feature Request: combobox text field mousewheel binding

[Brian G. <bgr...@mo...>]

Jeff Hobbs wrote:

>>>>>Another feature which IMHO should be part of tile.
>>>>>When the text field has the focus, moving the mouse wheel should 
>>>>>change
>>>>>the selection. Windows XP combos work this way.
>>>>>
>>>>>          
>>>>>
>>>>Not always a good thing. I have a number of people raising a
>>>>bug on our bugzilla installation that an accidental slip of 
>>>>the mouse wheel in the wrong place can cause mail to be sent 
>>>>to everyone.
>>>>        
>>>>
>>>misfeature or not, it is dangerous to go against standards.
>>>      
>>>
>>Standard or no, I think this is just plain broken.  I can't tell you how 
>>many times a day I mouse wheel over a different panel only to have some 
>>combo box scroll instead because that is where the focus is.  If the 
>>pointer was over the combo box, it would be one thing, but the pointer 
>>is often on the other side of the screen as are my eyes.
>>    
>>
>
>I will have to disagree on the misfeature, as I have used it
>myself intentionally, as well as having been caught by it.
>However, you have to look at the design of the widget to see
>that the mousewheel behavior is 100% appropriate.  It is the
>same as a 1-line listbox, and you would want to take away
>mousewheel from a listbox, would you?
>  
>

No, but M$ really needs to fix the Mouse Wheel/Pointer problem. 

I guess my point is M$ can get things wrong also.  Just because they do 
something some way doesn't make it a standard.

-Brian

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

RE: [Tile-dev] Feature Request: combobox text field mousewheel binding

[Jeff H. <je...@Ac...>]

> >>>Another feature which IMHO should be part of tile.
> >>>When the text field has the focus, moving the mouse wheel should 
> >>>change
> >>>the selection. Windows XP combos work this way.
> >>>
> >>Not always a good thing. I have a number of people raising a
> >>bug on our bugzilla installation that an accidental slip of 
> >>the mouse wheel in the wrong place can cause mail to be sent 
> >>to everyone.
> >
> >misfeature or not, it is dangerous to go against standards.
> 
> Standard or no, I think this is just plain broken.  I can't tell you how 
> many times a day I mouse wheel over a different panel only to have some 
> combo box scroll instead because that is where the focus is.  If the 
> pointer was over the combo box, it would be one thing, but the pointer 
> is often on the other side of the screen as are my eyes.

I will have to disagree on the misfeature, as I have used it
myself intentionally, as well as having been caught by it.
However, you have to look at the design of the widget to see
that the mousewheel behavior is 100% appropriate.  It is the
same as a 1-line listbox, and you would want to take away
mousewheel from a listbox, would you?

Jeff

Re: [Tile-dev] Feature Request: combobox text field mousewheel binding

[Brian G. <bgr...@mo...>]

Jeff Hobbs wrote:

>>>Another feature which IMHO should be part of tile.
>>>When the text field has the focus, moving the mouse wheel should change 
>>>the selection. Windows XP combos work this way.
>>>      
>>>
>>Not always a good thing. I have a number of people raising a 
>>bug on our bugzilla installation that an accidental slip of 
>>the mouse wheel in the wrong place can cause mail to be sent 
>>to everyone.
>>    
>>
>
>misfeature or not, it is dangerous to go against standards.
>  
>

Standard or no, I think this is just plain broken.  I can't tell you how 
many times a day I mouse wheel over a different panel only to have some 
combo box scroll instead because that is where the focus is.  If the 
pointer was over the combo box, it would be one thing, but the pointer 
is often on the other side of the screen as are my eyes.

This is really more of a problem with the mouse scroll/pointer then the 
combo box on Windows, but the combination just makes the feature a 
problem rather than a convenience.

-Brian

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

RE: [Tile-dev] Feature Request: combobox text field mousewheel binding

[Jeff H. <je...@Ac...>]

> >Another feature which IMHO should be part of tile.
> >When the text field has the focus, moving the mouse wheel should change 
> >the selection. Windows XP combos work this way.
> 
> Not always a good thing. I have a number of people raising a 
> bug on our bugzilla installation that an accidental slip of 
> the mouse wheel in the wrong place can cause mail to be sent 
> to everyone.

misfeature or not, it is dangerous to go against standards.

Jeff

Re: [Tile-dev] Feature Request: combobox text field mousewheel binding

[Pat T. <pat...@us...>]

Mark Garvey <du...@ya...> writes:

>Another feature which IMHO should be part of tile.
>When the text field has the focus, moving the mouse wheel should change the selection. Windows XP combos work this way.

Not always a good thing. I have a number of people raising a bug on
our bugzilla installation that an accidental slip of the mouse wheel
in the wrong place can cause mail to be sent to everyone.

I wonder if this 'feature' is the cause of some of the more famous
internet e-mail disasters :/


-- 
Pat Thoyts          http://www.zsplat.freeserve.co.uk/resume.html
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD

Re: [Tile-dev] treeview column widths...

[Brett S. <bre...@ya...>]

--- Joe English <jen...@fl...> wrote:
> 
> Bryan Oakley wrote:
> 
> > My first attempt at creating a treeview results in
> a columns that stop
> > short of filling the entire width of the widget.
> Is there a way to
> > configure a particular column to stretch to fill
> the width, or do I have
> > to do the math myself and set each column
> individually?
> 
> I really don't like the current column-sizing
> behavior,
> but am not entirely sure how to make it do the Right
> Thing.
> 
> I've been using a utility routine that takes a
> treeview widget,
> a dictionary of weights, and an overall width, and
> configures
> each display column to have width proportional to
> its weight.
> This has worked OK for the use cases I've
> encountered, but
> still doesn't feel quite right.
> 
> Another option is to use -minsize, -weight, and
> (possibly) -uniform
> options as in [grid columnconfigure].
> 
> When I get a chance I'll check in some Tcl code
> implementing
> different sizing behaviors for people to play with;
> once we
> figure out what the right approach is we can bake it
> in.
> 

You may want to look at how tktable does this as
well...seems reasonable...might need a little tweeking
for the treeview...

--brett