tktable-tile-dev — Discussion about tile development

[Tile-dev] Re: Stubs table

[Donald G P. <dg...@ni...>]

> > TTK_InitStubs(interp) will only succeed if the package

> Before we go anywhere with stubs and API exposure, can
> we agree to use either TTk_* or Ttk_*, but not TTK_*
> (which looks too macro-ish named)?

The tradition here is that Tcl's [load] command insists on the
format

    Ttk_Init()
    
for the relevant Tcl_PackageInitProc, and the other public routines
in an extension follow suit just for sake off consistency.

| Don Porter          Mathematical and Computational Sciences Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

RE: [Tile-dev] Stubs table

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

> TTK_InitStubs(interp) will only succeed if the package

Before we go anywhere with stubs and API exposure, can
we agree to use either TTk_* or Ttk_*, but not TTK_*
(which looks too macro-ish named)?

Jeff

[Tile-dev] Stubs table

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

I'm (finally!) about to check in a stubs table interface
for the tile package.  I'm using a modified version of
the core genStubs.tcl script, which does things a little
bit differently.  I'm hoping this will help avoid some
of the ABI compatibility problems that the core has
run into since the introduction of stubs.

First change: The stub table has two new fields, "epoch"
and "revision".  The revision is simply the number of
entries in the stub table.  The epoch is incrememented
each time there is an incompatible change to the ABI
(typically this will only happen at major releases,
but it can be bumped in between minor releases too
if necessary).

TTK_InitStubs(interp) will only succeed if the package
version satisfies TILE_VERSION (as usual), the epoch number
in the stubs table exactly matches that in ttkDecls.h, and the
revision is greater than or equal the one in ttkDecls.h.

The idea is to decouple the ABI version from the package
version (which is generally considered good practice).
The epoch number provides coarse-grained control and
allows for completely incompatible changes, and the
revision number provides fine-grained control (e.g.,
for when stubs table entries are added in a patch release
or in the CVS HEAD).

Second major change: the second argument to genStubs::declare
is interpreted as a status guard instead of a platform guard.
Possible values for the status field are: "current" (the default),
"deprecated", and "obsolete".  Declarations for deprecated stub
entries are guarded by an #ifdef; declarations for obsolete entries
are not generated at all.  (Definitions are always generated;
the status guard only affects the source API, not the stubs ABI).

The idea here is to provide an easier upgrade path when
entry points are deprecated; dependant packages should
continue to compile with -DTTK_DEPRECATED while the extension
author upgrades the code base to avoid deprecated functions.
Tile will follow the policy that entry points will spend
at least one release in the "deprecated" state before moving
to "obsolete".

There are a few other minor changes (like: no TCL_STORAGE_CLASS
monkey business), but those two are the main ones.


--Joe English

  jen...@fl...

[Tile-dev] RE: Active Tcl Installer

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

Bryan,

The ActiveTcl installer is now using tile, and there are
some issues with tile adapting to Xdefaults, which can be
either home-built or set via wms like KDE.  This is sort
of intentional - tile themes are supposed to set their
own style.  However, I have been talking with Joe about
adapting to just this situation, as it is likely to be a
common one for unix users.

Regards,

Jeff

> -----Original Message-----
> From: Schofield, Bryan (GE Transportation) 

> Hi Jeff, 
> 
> I was just installing Active Tcl 8.4.8 and though I'd drop 
> you a line about the installer. It uses a nice light grey 
> background and assumes the default foreground will be a dark 
> color. On my workstation, I have dark backgrounds with white 
> text. As a result, the installer is light grey with white 
> text, and worse, entry widgets are white with white text. I 
> didn't want to send this to an entire mailing list, so I hope 
> you don't mind I sent it to you directly.
> 
> Thanks and regards.
> 
> -- bryan

Re: [Tile-dev] slightly improved aqua combobox

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

Pat Thoyts wrote:

> | Michael Kirkham wrote:[...]
>
> Quick! Lets make him a developer before he runs away. :)
>
> Pat

I was thinking the same thing myself ...



--Joe

Re: [Tile-dev] slightly improved aqua combobox

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

-----BEGIN PGP SIGNED MESSAGE-----

Joe English wrote:
| Michael Kirkham wrote:
|
|>Having finally gotten my software release out and having a little time to
|>breathe, I thought I'd poke a bit more at tile since I decided not to use
|>it yet.  In my initial experimentation I've slightly improved upon the
|>look of the combobox on Aqua.  Diffs are attached.
|
| Thanks for the patch.
|
| Lacking access to a Mac I haven't been able to test it,
| and -- judging from the fact that the been a typo in
| aquaTheme.c for several months now, none of the other
| main developers have one either :-(.
|
| --Joe English

Quick! Lets make him a developer before he runs away. :)

Pat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQCVAwUBQaUnnWB90JXwhOSJAQFbOAP/duHosTdqlCVCeOhH/ZCwzQOysgHs719z
mUh/C3E7RD958jU1jA6nLI2iLGolRGcyH1jjBn578ZTK7j5xXENU9YgQzF0jQLzS
TCLQN5IWejT3mFZX68ZglL7AAa82ZHFxH8+rJIn4fyT14z3EFxO4q2v9mdIIl5aF
1eNSgqYk0do=
=jF0Z
-----END PGP SIGNATURE-----

Re: [Tile-dev] slightly improved aqua combobox

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

Michael Kirkham wrote:
>
> Having finally gotten my software release out and having a little time to
> breathe, I thought I'd poke a bit more at tile since I decided not to use
> it yet.  In my initial experimentation I've slightly improved upon the
> look of the combobox on Aqua.  Diffs are attached.

Thanks for the patch.

Lacking access to a Mac I haven't been able to test it, 
and -- judging from the fact that the been a typo in 
aquaTheme.c for several months now, none of the other
main developers have one either :-(.



--Joe English

  jen...@fl...

[Tile-dev] labelframe on aqua

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

On aqua the labelframe doesn't look right, as the text of the label sits 
on top of the border for the frame rather than being above it (a likely 
known issue since it's mentioned on the Wiki page at 
http://mini.net/tcl/12565).

At any rate, while a real fix should likely take into account the size 
of the font, I found a simple fix to be to insert into GroupElementDraw():

Index: macosx/aquaTheme.c
===================================================================
RCS file: /cvsroot/tktable/tile/macosx/aquaTheme.c,v
retrieving revision 1.13
diff -r1.13 aquaTheme.c
287a288
> 	bounds.top += 8;


--
Michael Kirkham
www.muonics.com

[Tile-dev] slightly improved aqua combobox

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

Having finally gotten my software release out and having a little time to 
breathe, I thought I'd poke a bit more at tile since I decided not to use 
it yet.  In my initial experimentation I've slightly improved upon the 
look of the combobox on Aqua.  Diffs are attached.

It looks more like the real aqua combobox in that it has a blue glassy 
button, although it's still a little off.  The native one is rounded on 
the right and square on the left, and the arrow is a little smaller.

For the former, I suspect the way they may draw it is the button is 
actually outside the bounding box of the entry but the entry overlaps it 
slightly.  Alternately, its possible that it's a special button that the 
appearance manager just doesn't give an interface for. :-/ But the reason 
I suspect it's the entry box overlapping the button rather than vise versa 
is when it has focus you can see a little bit of blue highlight between 
the button and the entry along with the highlight that surrounds the whole 
thing.

For the latter, I'm not sure what the deal is - the next size lower arrow 
drawn with the current method is smaller than the one in the native 
combobox.  Oh well.

Btw, there's a missing ) in one of the layout specs that's also pointed to 
in this diff.

--
Michael Kirkham
www.muonics.com

Re: [Tile-dev] Building Tile for ActiveTcl

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

-----BEGIN PGP SIGNED MESSAGE-----

Joe English wrote:
| Sorry, my mistake: it's not $::tile_library anymore, it's
$::tile::library.
| This should do the trick:
|
| 	package ifneeded tile 0.5 "
| 	    namespace eval tile { variable library $dir } ;
| 	    load [file join $dir tile[info sharedlibext]]
| 	"
|
| (note that the ifneeded script is ""-quoted, not {}-quoted).
|
|
|>but setting env(TILE_LIBRARY),
|>as is done in the starkit pkgIndex.tcl, seems to work.  But I had a
devil of
|>a time getting the starkit to play nicely with ActiveTcl, which includes
|>tile0.3.  I finally realized that the pkgIndex.tcl files set
|>env(TILE_LIBRARY) *outside* of the package ifneeded script.
|
|
| Uh oh.
|
| Pat, could you fix this?

Will do.

Pat.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQCVAwUBQYmUu2B90JXwhOSJAQF2ygP/dM7GJkqD7hoA5twqLBuwhZspgpuadEVy
X/Md8b/AtNjgcsuuCa4HawrnrOWj+uix2E+uHtxzAv36qJjXj9FVGiPI0Eder5WX
rMDKbQzBVCzncvf+HYwGdegGIdT6AfwffJYSKsKBpZilVn47zvKxerYy8vsbbddK
DU2CV8Nymi4=
=b6DS
-----END PGP SIGNATURE-----

[Tile-dev] Thanks for the starkit

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

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

Thank you for putting together the starkit at Sourceforge with OS X
libraries for Tile.

I spent a lot of time trying to build them, but building against TkAqua
is quite complex, and I kept getting errors that I couldn't work
through. But this solves all my problems! So, thanks again.

Terrific work on the new release! I can't wait to play with it in the
application I'm developing. I'm hopeful that TkDarwinPorts will be a
powerful example of what one can do with Tile--that's part of its
purpose.


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

iD8DBQFBiSFQJmdQs+6YVcoRAk+BAJ0fwvNnAAAyWFAHVilNCsmFhKiRxQCdEnTe
ZRXlFVnnr1gJBNenUbYWD7I=
=q9hH
-----END PGP SIGNATURE-----

Re: [Tile-dev] Building Tile for ActiveTcl

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

Techentin, Robert W. wrote:

> Joe English wrote:
> > An alternate approach: compile with "-DNO_PRIVATE_HEADERS"
> > and link against libtk8.4.so (as well as libtkstub8.4.a).
> > The build system in the "generic" subdirectory does this
> > by default, or just hack the Makefile by hand.
> >
> > This _might_ not work on HP-UX, since dynamic linking
> > reportedly works differently there, but it's worked for
> > me on all the platforms I've tried.
>
> Thanks for the help, Joe.  The generic build works on HP-UX 11.0, once I
> changed the compile and link flags for the native compilers.

Could you file a patch at SourceForge (or just email the patched
Makefile to me directly) so I can back-port the required changes
into the autoconf machinery?

[...]
> > This is bug #695441 "tcl_findLibrary does not look in
> > $::auto_path". Probably the best way to fix it is to hack
> > pkgIndex.tcl to set $::tile_library before loading the extension:
> >  [...]
>
> Setting ::tile_library didn't seem to work,

Sorry, my mistake: it's not $::tile_library anymore, it's $::tile::library.
This should do the trick:

	package ifneeded tile 0.5 "
	    namespace eval tile { variable library $dir } ;
	    load [file join $dir tile[info sharedlibext]]
	"

(note that the ifneeded script is ""-quoted, not {}-quoted).

> but setting env(TILE_LIBRARY),
> as is done in the starkit pkgIndex.tcl, seems to work.  But I had a devil of
> a time getting the starkit to play nicely with ActiveTcl, which includes
> tile0.3.  I finally realized that the pkgIndex.tcl files set
> env(TILE_LIBRARY) *outside* of the package ifneeded script.

Uh oh.

Pat, could you fix this?


--Joe English

  jen...@fl...

[Tile-dev] How to import my tileqt tile theme in the tile CVS space?

[George P. <pe...@ii...>]

Hi all,

As  some of you already know, I have written a prototype of a tk-tile-qt
theme, named 'tileqt'. Its a C/C++ Tcl package that adds a new theme in tile
(named again 'tileqt') which draws widgets with the current KDE/Qt theme the
KDE desktop uses. This is not done through pixmaps as some tile themes do,
but by using the Qt style engine directly.

Currently, supported widgets are all buttons, scrollbar, combobox, notebook,
entry & label frame widgets. Sliders aren't (and probably will never 
work due to
the bad Qt implementation of this widget). Progressbars are also supported,
but the visuals depend on the theme in use (not all themes support vertical
progressbars :-))

I saw the announcement about the pixmap (or image) themes on the list,
but I am not sure if my code qualifies for that space, as it is announced to
contain "tcl" packages. Does this mean tcl-only?

Also, if my package should be placed there, who is responsible for adding
it? (I assume a user with cvs write permissions is needed, isn't it?)

Regards,
George

RE: [Tile-dev] Building Tile for ActiveTcl

[Techentin, R. W. <tec...@ma...>]

Joe English wrote:

> An alternate approach: compile with "-DNO_PRIVATE_HEADERS"
> and link against libtk8.4.so (as well as libtkstub8.4.a).
> The build system in the "generic" subdirectory does this 
> by default, or just hack the Makefile by hand.
> 
> This _might_ not work on HP-UX, since dynamic linking 
> reportedly works differently there, but it's worked for 
> me on all the platforms I've tried.

Thanks for the help, Joe.  The generic build works on HP-UX 11.0, once I
changed the compile and link flags for the native compilers.  I see that the
starkit version, tile05.kit, includes a little support for HP-UX in
pkgIndex.tcl.  So I stuffed HP-UX-hppa/tile05.sl into lib/tile0.5, and the
kit seems to work nicely on HP-UX.  :-)


> This is bug #695441 "tcl_findLibrary does not look in 
> $::auto_path". Probably the best way to fix it is to hack 
> pkgIndex.tcl to set $::tile_library before loading the extension:
> 
> |package ifneeded tile 0.5 \
> |    "set ::tile_library $dir ; load [file join $dir tile[info 
> |sharedlibext]]]"
> 
> Alternately, you can set the environment variable
> $TILE_LIBRARY to point to the install directory.

Setting ::tile_library didn't seem to work, but setting env(TILE_LIBRARY),
as is done in the starkit pkgIndex.tcl, seems to work.  But I had a devil of
a time getting the starkit to play nicely with ActiveTcl, which includes
tile0.3.  I finally realized that the pkgIndex.tcl files set
env(TILE_LIBRARY) *outside* of the package ifneeded script.  So
env(TILE_LIBRARY) may change depending on which version is in the auto_path
first.  I would suggest making pkgIndex.tcl work like this:

  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
      package ifneeded tile 0.5 "
        [list set ::env(TILE_LIBRARY) $dir]
        [list load [file join $dir $platform tile05[info
sharedlibextension]]]"
  } else {
      return
  }

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/ 

[Tile-dev] ANNOUNCE: Tile Widget Set, version 0.5

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

[31 Oct 2004]

ANNOUNCE: Tile Widget Set, version 0.5.

~ 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
    + "Revitalized" look and feel under X11
    + Native look and feel under Mac OSX
    + Appearance controlled by a theme engine, providing
      greater flexibility for custom widgets
    + New widgets, including notebook, progressbar, combobox,
      and separator

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

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

The ActiveTcl and TclTkAquaBI distributions both include CVS snapshots
of the Tile project.  Tile 0.4 corresponds to the version included
in the 8.4.7 release of those packages.

~ What's new in 0.5:

    New namespace: Use "ttk::button" instead of "tbutton" or "tile::button".
    This is the recommended way to access the Tile widgets from now on.

    "pixmap" element constructor replaced by "image"; see image.n.
    User-defined pixmap themes will need to be updated.

    [package require tile] automatically selects the appropriate theme
    depending on platform.

    Default theme on X11 is now a simple, streamlined look.
    Motif look moved to the "classic" theme.

    New ttk::separator widget, for use in dialog boxes and toolbars.

    New treeview widget (alpha-quality).

    Changed fallback rules so custom styles are easier to define.

    Combobox has a -postcommand option.

    Labelframe has an -underline option and supports mnemonic activation.

    Labels now support -justify and -wraplength.

    More improvements to look and feel (esp. notebook and combobox widgets).
    Look and feel on Windows (XP and classic) is now almost completely
    indistinguishable from native widgets.

[Tile-dev] New tile themes repository.

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

-----BEGIN PGP SIGNED MESSAGE-----

We have created a second cvs tree to host contributed themes for use
with tile. This is to clear such things from the primary source tree but
~ to permit the themes code to be managed with CVS.

The new tree is tile-themes and is accessed at
~ CVSROOT=:pserver:ano...@cv...:/cvsroot/tktable
~ cvs co tile-themes

The Aquativo, WinXP-Blue and kroc themes have been moved from the tile
tree into the new tree and I have imported updated versions of the
keramik and plastik pixmap themes that were posted to comp.lang.tcl by
Googie some time ago.

All the themes in tile-themes are tcl packages and can be installed as
any other tcl package. The 'tile::availableThemes' procedure will list
the core themes plus any installed themes and the utility procedure
'tile::setTheme themename' will deal with the necessary package requires
~ and set the theme. The tkchat app currently uses this scheme, as does
the tile demo.

Any new themes are welcome, but new themes should use the 'image'
element engine as we intend to remove the 'pixmap' engine in tile 0.6.
Once the tile API has stabilized we should have a tile or ttk stubs
interface and new themes using the tile C API can be added.

Pat Thoyts.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQCVAwUBQYOD0WB90JXwhOSJAQFamgP9GU8gbF0NaevKm5289QBJ0skolpn0+tAC
Q5ywqRNi+HJaJDBudNXnbZXE468jp/HhdiG+O0EEYJDmlE7l1KmIMn+/ba7K3Gv4
SR95H4CmRSvkHUVsv4u3VRxZTFIwGY9a3xS3RaXIhR2blJOxR5a63VQF948Q18Ai
4foclVhIBGs=
=fGCM
-----END PGP SIGNATURE-----

Re: [Tile-dev] Questions about new theme development...

[Georgios P. <pe...@ii...>]

----- Original Message ----- 
From: "Joe English" <jen...@fl...>
To: <tkt...@li...>
Sent: Friday, October 29, 2004 3:00 AM
Subject: Re: [Tile-dev] Questions about new theme development...


>
> George Petasis wrote:
>
>> I have made some first steps into building a new tile theme
>> (see http://www.iit.demokritos.gr/~petasis/screenshot.png [...]
>
> Once again: wow!
>
>> but I am having some problems on how
>> to implement some widget elements.
>>
>> First of all, for changing the background of the text label
>> of a labelframe, I have to reimplement the Labelframe.text
>> element. And of course I don't want to mess up with text at all.
>> But why this widget element has a special background?
>> I have implemented a generic "background" element, and seems
>> to be used by all widgets, except from the labelframe with its
>> text. Is there a solution for this?
>
> The "Labelframe.text" element defined in tkElements.c
> is exactly the same as the default "text" element except
> that it erases the background area first.  If you can
> find some way to extract KDE's background color and get
> that into a Tcl script, you should be able to use the
> built-in Labelframe.text element and do something like:
>
>    style default Labelframe -background [kde::backgroundColor]
>
> in the theme definition.

Of course something I haven't thought of :-) However,
it still doesn't solve all the problems, as the Qt style may
use a pixmap for the background. I think a better solution
is to export a function that will handle text drawing?
(Perhaps it will be needed by other themes).
Or since labelframe is the only widget that needs to draw
a backround, break its text element in two subelements,
a background & a text?

>
>
>> The second important problem that I have is theming the scrollbar
>> widget. In my theme, I take the current unix KDE/Qt theme that the
>> desktop uses, and draw the widgets. But at this point, I don't know
>> what the organisation of the scrollbar will be. I.e. in the above
>> screenshot the scrollbar seems fine (visually), but the elements that
>> comprise it are not in place, as I use the default layout for scrollbars.
>> On the other hand, Qt has 6 (!) scrollbar elements, but no layout
>> information
>> at all. Any theme that has override the style.drawComplexControl()
>> may have placed the various pieces in various places.
>
>
> The Aqua theme on Mac OSX has the exact same problem --
> instead of entry points to draw each piece of a scrollbar,
> there's a DrawThemeTrack() function that draws the whole
> thing.  I don't know how to solve the problem there, either :-(.

Well Qt does the exact same thing for almost all widgets :-)
Check/Radio buttons, comboboxes, scrollbars, etc.
Thus, in my code I have made some assumptions, i.e. that the
combobox arrow will always be on the right side of the widget.
If a Qt style comes out that changes that, comboboxes will be
as problematic as scrollbars :-)

>
> It will almost certainly require a change to the theme engine
> and scrollbar widget internals to handle this correctly;
> we need to add another level of indirection (somewhere)
> to support this sort of thing.
>
> Is your source code available?
>

Yes and no :-) No in the sense that you can't
download them from anywhere. But for anybody feeling
adventurus, running linux/KDE 3.x, and willing to
change somewhat the makefile for some hardcoded
Qt/KDE include/lib paths, I can email directly
a gzipped tarball. In any case, and despite the level
I will finally manage to achieve writting this theme,
I will post my sources somewhere (i.e. in the tile SF patch area?),
as perhaps they will be also usefull to others (and always
under BSD). In any case, do you want to send you a copy of
my sources? I haven't managed to theme all widgets,
only buttons* & combobox...
And even for these widgets, some alignment problems still
remain when background pixmaps are used, which I am not sure
if they can be resolved under tile. I have to somehow allign the
background pixmap tile, and I need to know the position of the
window in its toplevel. I have the tkwin for each element, but still
haven't looked into this at all :-)

George 

Re: [Tile-dev] Questions about new theme development...

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

George Petasis wrote:

> I have made some first steps into building a new tile theme
> (see http://www.iit.demokritos.gr/~petasis/screenshot.png [...]

Once again: wow!

> but I am having some problems on how
> to implement some widget elements.
>
> First of all, for changing the background of the text label
> of a labelframe, I have to reimplement the Labelframe.text
> element. And of course I don't want to mess up with text at all.
> But why this widget element has a special background?
> I have implemented a generic "background" element, and seems
> to be used by all widgets, except from the labelframe with its
> text. Is there a solution for this?

The "Labelframe.text" element defined in tkElements.c
is exactly the same as the default "text" element except
that it erases the background area first.  If you can
find some way to extract KDE's background color and get
that into a Tcl script, you should be able to use the
built-in Labelframe.text element and do something like:

    style default Labelframe -background [kde::backgroundColor]

in the theme definition.


> The second important problem that I have is theming the scrollbar
> widget. In my theme, I take the current unix KDE/Qt theme that the
> desktop uses, and draw the widgets. But at this point, I don't know
> what the organisation of the scrollbar will be. I.e. in the above
> screenshot the scrollbar seems fine (visually), but the elements that
> comprise it are not in place, as I use the default layout for scrollbars.
> On the other hand, Qt has 6 (!) scrollbar elements, but no layout
> information
> at all. Any theme that has override the style.drawComplexControl()
> may have placed the various pieces in various places.


The Aqua theme on Mac OSX has the exact same problem --
instead of entry points to draw each piece of a scrollbar,
there's a DrawThemeTrack() function that draws the whole
thing.  I don't know how to solve the problem there, either :-(.

It will almost certainly require a change to the theme engine
and scrollbar widget internals to handle this correctly;
we need to add another level of indirection (somewhere)
to support this sort of thing.

Is your source code available?


--Joe English

  jen...@fl...

[Tile-dev] Questions about new theme development...

[George P. <pe...@ii...>]

Dear list,

I have made some first steps into building a new tile theme
(see http://www.iit.demokritos.gr/~petasis/screenshot.png
http://www.iit.demokritos.gr/~petasis/screenshot.jpeg),
but I am having some problems on how
to implement some widget elements.

First of all, for changing the background of the text label
of a labelframe, I have to reimplement the Labelframe.text
element. And of course I don't want to mess up with text at all.
But why this widget element has a special background?
I have implemented a generic "background" element, and seems
to be used by all widgets, except from the labelframe with its
text. Is there a solution for this?

The second important problem that I have is theming the scrollbar
widget. In my theme, I take the current unix KDE/Qt theme that the
desktop uses, and draw the widgets. But at this point, I don't know
what the organisation of the scrollbar will be. I.e. in the above
screenshot the scrollbar seems fine (visually), but the elements that
comprise it are not in place, as I use the default layout for scrollbars.
On the other hand, Qt has 6 (!) scrollbar elements, but no layout 
information
at all. Any theme that has override the style.drawComplexControl()
may have placed the various pieces in various places.
(I suppose I will have to query the rectangle of each piece and
compare them to form the proper layout.)
How is the correct way to adress this issue?
I suppose one way would be to have some predefined
layouts for some known Qt styles and decide upon their name.
Also, to somehow pass the rectangle information for each element
at the tcl, and resolve/define the layout from a tcl proc.
Or finally, define a very complex layout that can capture almost
all possible layouts, and set the dimentions of the unused elements to
zero. Is this supported under tile? Can I force an element to have zero
width for example? Is there a "preferable" approach?

(Actually all Qt scrollbar layouts I have seen, either have 2 arrow
buttons - placed on the same side or the two opposite sides of
the widget - or three buttons, like the tile step theme...)

Regards,
George

Re: [Tile-dev] Building Tile for ActiveTcl

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

Techentin, Robert W.  wrote:

> I tried to compile tile with --with-tcl and --with-tk pointing to the
> ActiveTcl installation, and it didn't work because tkInt.h just isn't there.

An alternate approach: compile with "-DNO_PRIVATE_HEADERS"
and link against libtk8.4.so (as well as libtkstub8.4.a).
The build system in the "generic" subdirectory does this by 
default, or just hack the Makefile by hand.

This _might_ not work on HP-UX, since dynamic linking
reportedly works differently there, but it's worked for me
on all the platforms I've tried.

> No problem, because I can download and build Tcl, Tk, and Tile all in
> parallel, just like you're supposed to do.  But once I've created the
> tile0.5 library and added it to my auto_path, I cannot use it from
> ActiveTcl.  It complains that it can't find a usable tile.tcl, starting in
> ActiveTcl's lib directory, and then moving on to /usr/lib and /lib.  It
> appears that tile0.5 wants to be in the same library directory as tcl8.4 and
> tk8.4.


This is bug #695441 "tcl_findLibrary does not look in $::auto_path".
Probably the best way to fix it is to hack pkgIndex.tcl to
set $::tile_library before loading the extension:

|package ifneeded tile 0.5 \
|    "set ::tile_library $dir ; load [file join $dir tile[info sharedlibext]]]"


I might just set things up to always do this
(OTOH, that'll break other stuff, so maybe not...)

Alternately, you can set the environment variable
$TILE_LIBRARY to point to the install directory.



--Joe English

  jen...@fl...

[Tile-dev] Building Tile for ActiveTcl

[Techentin, R. W. <tec...@ma...>]

I'd like to start using Tile widgets in my new applications.  (The Tcl
Conference got me all excited!)  We're presently running ActiveTcl
8.4.6.something, which includes tile0.3.  I easily downloaded and installed
tile0.4 for Windows.  But I'm having a little trouble getting it built for
Unix.

Like many Unix users, I've got a sysadmin down the hall who takes care of
hundreds of systems.  I was able to get ActiveTcl installed for HP-UX and
Linux, but its installed by root, and I don't have access.  (Which is
probably a good thing.)

I tried to compile tile with --with-tcl and --with-tk pointing to the
ActiveTcl installation, and it didn't work because tkInt.h just isn't there.
No problem, because I can download and build Tcl, Tk, and Tile all in
parallel, just like you're supposed to do.  But once I've created the
tile0.5 library and added it to my auto_path, I cannot use it from
ActiveTcl.  It complains that it can't find a usable tile.tcl, starting in
ActiveTcl's lib directory, and then moving on to /usr/lib and /lib.  It
appears that tile0.5 wants to be in the same library directory as tcl8.4 and
tk8.4.

Is there a way to build tile for ActiveTcl (or against ActiveTcl, for that
matter)?  Or do I have to make a sysadmin request to get a library installed
in the system directories?

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/ 

[Tile-dev] (no subject)

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

George Petasis wrote:

> I have managed to write my first themed widget
> (although is a plain button only :-)).
> However, one point still remains unclear.
> If I inherit my theme from the classic theme in TTK_CreateTheme,
> my drawing code (element in general) is not called, so I get the
> label on a gray background. If I don't use any parent theme,
> (i.e. placing NULL as the last parameter of the TTK_CreateTheme),
> everything works as expected. I am not sure I have understood
> why is this happening.

It's hard to say for sure without seeing your code, but:
the "classic" theme registers a different button layout,
maybe that's causing a conflict?


> Also, a side-effect of my attempt to create a themed widget, is that
> a partial link with Qt/KDE is feasible, at least in making the widgets
> look "similar" (apart from the fonts/font colours). In my test
> I used qApp->style().drawControl() to draw a button. The results
> in the attached image :-)


Wow :-)  I'm impressed!


> PS: A very important notice is that tkTheme.c is badly missing
> handing for C++ compilers (
> #ifdef __cplusplus
> extern "C" {
> #endif ...)

Fixed now...



--Joe English

  jen...@fl...

Re: [Tile-dev] Progress bar

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

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

Thanks to everyone for their help with my questions about the progress
bar. I've synthesized everything and am adopting it for the application
I'm developing (based almost entirely on Tile!). I've documented what
I'm doing, plus added some nice eye candy, at the wiki:

http://wiki.tcl.tk/12786

Additions, comments welcome there. Thanks!

Kevin


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

iD8DBQFBfnzwJmdQs+6YVcoRArd1AJwK9pse8yACCvK5fKT10/zH5Dv/XgCePMvC
dPjz5eYoha08T1Rs9FyOzZA=
=5CCy
-----END PGP SIGNATURE-----

Re: [Tile-dev] Progress bar

[Donal K. F. <don...@ma...>]

Brian Griffin wrote:
> Consider this testcase:
>    every 250 {Update .p 10}
>    every 250 {Update .p 10}

FWIW, I considered that test case and decided against doing anything
about it. It has the hallmark of code that is actually fairly unlikely
to occur in practice except in situations that are already a bug
irrespective of the effects of this code. Running the identical script
twice is going to lead to unexpected behaviour anyway.

You can of course go for a full solution that implements ids a bit like
[after] does (which allows for a fully controllable behaviour), but the
code to do this is rather much longer than I felt like writing and is
probably overkill too. :^D (It might be a candidate for adding to the
Wiki or tcllib if it isn't already there.)

Donal.

[Tile-dev] Re: Question about Tile...

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

[Cc: ed to tktable-tile-dev, since this is of general interest ]

Georgios Petasis wrote:
>
> I want to ask a question regarding writting a new theme.
> Lets suppose that I want to write a new button widget. I want to
> have a custom background, border & focus ring (well, no focus ring
> at all actually).

Buttons are actually pretty complicated, since there
are so many different ways to put them together.

For a pixmap theme, you probably want to use something
like the following:

    style layout TButton {
	Button.button -children {
	    Button.focus -children {
		Button.padding -children {
		    Button.label } } } }

This is what the XP theme uses.

The "focus", "padding", and "label" elements can be inherited
from the parent theme, and you only need to define the
"Button.button" element.  There should be different
images for the "active", "pressed", and "alternate" states
(TTK_STATE_ALTERNATE is set when the widget is the default
button).  If you use different images to indicate focus as well,
then leave the "Button.focus" element out (this is what the
Aqua theme does).

> I have tried to read the tile sources, and what remains unclear to
> me is the exact elements that I need to provide. For example,
> I saw that there is an element called "background", but it doesn't
> get redefined by lets say the clam button.

This has changed between 0.4 and 0.5.  In 0.5, the background
element is automatically included in all layouts.  The theme
engine will probably need to treat the background element
specially at some point (see earlier message on "The Background
Problem"); you probably shouldn't redefine it.

> ???
> I can see for example that in the classic theme, the following layout
> is defined:
>
> TTK_BEGIN_LAYOUT(ButtonLayout)
>     TTK_GROUP("Button.highlight", TTK_FILL_BOTH,
>         TTK_GROUP("Button.border", TTK_FILL_BOTH|TTK_BORDER,
>      TTK_GROUP("Button.padding", TTK_FILL_BOTH,
>          TTK_NODE("Button.label", TTK_FILL_BOTH))))
> TTK_END_LAYOUT
>
> This means that Button.label also supports the display of the image?
> The background/focus elements are not used ?

The classic theme uses the outer highlight ring as
a focus indicator, and the default ring is built into
the "Button.border" element.  It's more conventional
to use a dashed focus ring inside the border, as in:

    style layout TButton {
	Button.border -children {
	    Button.focus -children {
		Button.padding -children {
		    Button.label } } } }

The "label" element is a combination of "text" and "image"
elements; it handles the "-compound" and "-anchor" widget options.


--Joe English

  jen...@fl...