tktable-tile-dev — Discussion about tile development

[Tile-dev] Tile dialog box positioning on win32

[Andrew T. <an...@hi...>]

Hi,

I'm using Tile for a project at work, and on the whole it's working out
great. However, I have one issue I'm unable to resolve: the positioning
of dialog boxes on win32. On Linux/FreeBSD/NetBSD/Solaris they seem to
position relatively sanely, but on windows they insist on going to the
upper-left corner of the screen. If I set the dialog's parent to the
empty string to make it non-transient it modifies the position slightly,
it's still at the upper-left but it's indented slightly (about 1 inch)
from the corner of the screen.

I reduced the problem to a short test-case, but I'm not writing tcl/tk
code, I'm using the ruby bindings for tk/tile. Do the dialog boxes
position more correctly using tcl/tk and should I be looking for the
issue in the ruby bindings? I tested with the native tk dialog box and
it worked as expected.

I don't know tcl/tk well enough to write a test-case for this so I can't
check if it's the bindings or not. Can someone give me a sample program
I can test with, or at least confirm this is/isn't a
problem on windows?

Andrew

[Tile-dev] Testing - is this thing on?

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

Test.  Please ignore.

[Tile-dev] ttk::panedwindow - setting sash positions

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

A couple of weeks ago, Paul Mackerras asked on tcl-core
if there was a good way to save and restore the configuration
of a ttk::panedwindow, so that an application could start up
with the same pane sizes that it had last time it was run.
See also bug #1659067, which is about the same problem.

It turns out that there is a way to do so, but not a *good* way --
it's exceedingly tricky to ensure that everything happens in the
right order and at the right time.

Recent changes to the ttk::panedwindow widget should remedy
this somewhat.  The widget now takes -width and -height options:

|   -width
|	If present and greater than zero, specifies the desired width
|	of the widget in pixels. Otherwise, the requested width is
|	determined by the width of the managed windows.
|   -height
|	If present and greater than zero, specifies the desired height
|	of the widget in pixels. Otherwise, the requested height is
|	determined by the height of the managed windows.

In addition, the 'sashpos' method is now considered public and
the documentation has been clarified:

|    _pathname_ sashpos _index_ ?_newpos_?
|	If _newpos_ is specified, sets the position of sash number
|	_index_. May adjust the positions of adjacent sashes to ensure
|	that positions are monotonically increasing. Sash positions are
|	further constrained to be between 0 and the total size of the
|	widget. Returns the new position of sash number _index_.

The "total size" is either the actual panedwindow height
(resp. actual panedwindow width), or the requested -height
(resp. requested -width), depending on which was most recently
changed.

There's also a new [$pw panes] command, which returns the
list of managed panes.  (I forgot to add this initially.)

So to save the panedwindow configuration, an application
can use the following procedure:

(S-1) Call [update], so that any pending geometry requests
      are fully processed.
(S-2) Record [winfo width $pw] and [winfo height $pw]
(S-3) Record [$pw sashpos $i] for 0 <= $i < #panes-1

To restore the configuration:

(R-1) Call [update idletasks] to ensure that there are no
      outstanding geometry requests from slave windows.
(R-2) Call [$pw configure -width $w -height $h], where $w and $h
      are the values recorded in step (S-2).
(R-3) Call [$pw sashpos $i $savedPosition($i)] to restore
      the sash positions.
(R-4) Let the geometry propagation dance do its thing.

The essential part is to set the -width and -height
*before* setting the sash positions.  A full [update]
isn't necessary in step (R-1), but [update idletasks] is:
otherwise GM requests from unmapped slaves will override
the work done in (R-3).

S-[1-3] can be performed any time after the panedwindow is
mapped and before it's destroyed.  Of course, step (S-1) must
_not_ be called inside an event binding; if you want to save
the configuration whenever the widget is resized, schedule S-[2-3]
as an [after idle] callback from a <Configure> binding.

R-[1-4] should be done after creating and managing all
of the panedwindow's descendants, but before the panedwindow
itself is mapped (to avoid "blinking").

This should also better support Brian Griffin's use case
(specifying pane sizes as relative fractions of the overall
window size).


--Joe English

  jen...@fl...

[Tile-dev] equal width for vertical tabs

[Patrick H. <he...@gm...>]

Hello,

can anyone give me a hint on how to make vertical tabs have all the same width. From what I thought the option "-mintabwidth" should do the job. But for me it doesn't. I'm wondering if the current implementation allows this at all.

Cheers
Patrick
-- 
Patrick Heck

+61432611842

25 Hampton Street
Brooklyn Park
SA, 5032
Australia

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

Re: [Tile-dev] ttk widget options

[Lynn Q. <qu...@ai...>]

Here are some of the options in question:

labelframe:  -borderwidth not shown in documentation

scrollbar:   -width not shown in documentation

scale:       -width not shown in documentation

button:      -padding not shown in documentation

checkbutton: -padding not shown in documentation

radiobutton: -padding not shown in documentation

menubutton:  -padding not shown in documentation

entry:       -background -foreground -font -text  not shown in documentation



 

Joe English replied:
>  
>  Believe the documentation.
>  
>  The manpages don't faithfully reflect what's actually
>  implemented in all cases (although they should be pretty
>  close -- what discrepancies have you encountered?), but
>  they _do_ reflect what's intended.
>  
>  
>  --Joe English
>  
>    jen...@fl...
>  

Re: [Tile-dev] ttk widget options

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

Lynn Quam wrote:

> I have been developing an extension to the ltk Lisp interface
> to the Tk widgets and I am integrating the Tile widget set.
>
> I am trying to understand what widget configuration options are really
> permitted for the Tile widgets.  The documentation at
> http://tktable.sourceforge.net/tile/doc/ shows a limited set of
> configuration options.  Reading the source code for the ttk widgets
> shows a more extensive set of options.  Is this larger option set
> needed only internally for use by the style machinery?  What am I to
> believe?


Believe the documentation.

The manpages don't faithfully reflect what's actually
implemented in all cases (although they should be pretty
close -- what discrepancies have you encountered?), but
they _do_ reflect what's intended.


--Joe English

  jen...@fl...

[Tile-dev] ttk widget options

[Lynn Q. <qu...@ai...>]

I have been developing an extension to the ltk Lisp interface
to the Tk widgets and I am integrating the Tile widget set.

I am trying to understand what widget configuration options are really
permitted for the Tile widgets.  The documentation at
http://tktable.sourceforge.net/tile/doc/ shows a limited set of
configuration options.  Reading the source code for the ttk widgets
shows a more extensive set of options.  Is this larger option set
needed only internally for use by the style machinery?  What am I to
believe?

Re: [Tile-dev] Writing widgets

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

[I wrote]

> Correct, the widget API is not available in the Tile stubs table.
> However, that just means you can't use stubs -- you can still
> link your extension directly against tile.so/.dylib/.LIB.
> That works just fine on all but the most ancient of Unices.

Or if you want to deploy as a starpack; I forgot about that.
That's another case where stubs are necessary.


--je

Re: [Tile-dev] optimizing display of vertical tabs

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

Patrick Heck wrote:

> Tile supports changing of the tab layout by setting a "-tabposition" for the
> desired layout-style. But although the tabs are packed in the right side afte
> r this, the orientation of the decoration around the tab is still pointing in
>  the wrong direction.
> I propose to use a new style option "-direction" for Tabs to fix this problem
> .
>
> example:
> --------
> style layout TNotebookv {
>    TNotebookv.Tab
> }
> style configure TNotebookv.Tab  -direction w
> style configure TNotebookv -tabposition wn

That's one approach, which should work for the Aqua and XP themes.
For others -- notably pixmap themes, where you can't select different
pictures based on an element option -- you need to have separate
elements and TNotebook[NSEW].Tab layouts for each orientation.
You might need different Pane elements for each orientation
as well (e.g., on Aqua the blue bar should appear on the same
side as the tabs).  There's a handful of other options you
need to tweak as well, depending on whether and how the
the selected tab should expand, padding, margins, etc.

> As I said this approach is not the most elegant one and also leaves a couple
> of other problems untouched. I'd apprechiate some feedback on how to improve
> and generalize the solution. I belief tile would benefit a lot from a better
> tab support.

It's mostly just a matter of deciding on a standard convention
for style names (e.g., TNotebookv, LeftTabTNotebook, West.TNotebook, ...),
and implementing it in all the themes.

I really do plan on implementing this, honest :-) it's just been hard
to make any progress on Tile lately due to other circumstances.


--Joe English

  jen...@fl...

Re: [Tile-dev] Writing widgets

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

Mats Bengtsson wrote:
> Hi all,
>
> I was thinking of doing a standalone widget from all my chasing arrows patche
> http://sourceforge.net/tracker/index.php?func=detail&aid=1183535&group_id=114
> 64&atid=311464
> but then I read that there is no stub table for this:
> http://tktable.sourceforge.net/tile/WidgetGuide.html
>
> If this is still true what to do?

Correct, the widget API is not available in the Tile stubs table.
However, that just means you can't use stubs -- you can still
link your extension directly against tile.so/.dylib/.LIB.
That works just fine on all but the most ancient of Unices.

For this particular case, you probably don't need a new
widget at all.  Just register a ChaseArrows element in the appropriate
platform themes -- the entry points you need for this are all
in the current public API -- and use a ttk::progressbar widget
with a custom style (which can be done all in Tcl).


--Joe English

  jen...@fl...

[Tile-dev] optimizing display of vertical tabs

[Patrick H. <he...@gm...>]

Hello,

I'm currently working on a project where we need to use vertical tabs alongside with horizontal ones. I've been working on a way to provide a better support for this in tile, but since I'm not a very experienced C programmer my solution is probably not the most elegant one. I'd like to invite others to participate and tell their ideas about the issue.

Tile supports changing of the tab layout by setting a "-tabposition" for the desired layout-style. But although the tabs are packed in the right side after this, the orientation of the decoration around the tab is still pointing in the wrong direction.
I propose to use a new style option "-direction" for Tabs to fix this problem. 

example:
--------
style layout TNotebookv {
   TNotebookv.Tab
}
style configure TNotebookv.Tab  -direction w
style configure TNotebookv -tabposition wn 


To make use of this option it has to be implemented in the theme files. Since I'm using macos I altered macosxTheme.c

first the Element options have to be defined:

typedef struct {
    Tcl_Obj *directionObj;
} TabElement;

static Ttk_ElementOptionSpec TabElementOptions[] = {
    { "-direction", TK_OPTION_ANCHOR,
		Tk_Offset(TabElement,directionObj),"1" },
    {0,0,0,0}
};

then the TabElementDraw function has to be altered to make use of the new option by adding the following lines:

static void TabElementDraw(
    void *clientData, void *elementRecord, Tk_Window tkwin,
    Drawable d, Ttk_Box b, Ttk_State state)
{
// ALTERED CODE
        ThemeTabDirection td = kThemeTabNorth;
	Tk_Anchor direction;
	TabElement *e = elementRecord;
    Tk_GetAnchorFromObj(NULL, e->directionObj, &direction);
	if (direction == TK_ANCHOR_E) {
		td = kThemeTabEast ;
	} else if (direction == TK_ANCHOR_W) {
	    td = kThemeTabWest ;
	} else if (direction == TK_ANCHOR_N || direction == TK_ANCHOR_NW || direction == TK_ANCHOR_NE ) {
		td = kThemeTabNorth ;
	} else { /* TK_ANCHOR_S */
		td = kThemeTabSouth ;
	}
// ALTERED CODE
	Rect bounds = BoxToRect(b);
    bounds.bottom += TAB_OVERLAP;
    BEGIN_DRAWING(d)

// IN THIS COMMAND 'kThemeTabNorth' has been replaced by 'td'    
    DrawThemeTab(
    	&bounds, Ttk_StateTableLookup(TabStyleTable, state), td,
	0/*labelProc*/,0/*userData*/);
    END_DRAWING
}

At last the TabOptions have to be included in the TabElementSpec by replacing 'NullElementOptions' with 'TabElementOptions'

As I said this approach is not the most elegant one and also leaves a couple of other problems untouched. I'd apprechiate some feedback on how to improve and generalize the solution. I belief tile would benefit a lot from a better tab support.

Cheers

Paddy
-- 
Patrick Heck

+61432611842

25 Hampton Street
Brooklyn Park
SA, 5032
Australia

"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

[Tile-dev] Writing widgets

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

Hi all,

I was thinking of doing a standalone widget from all my chasing arrows patches
http://sourceforge.net/tracker/index.php?func=detail&aid=1183535&group_id=11464&atid=311464
but then I read that there is no stub table for this:
http://tktable.sourceforge.net/tile/WidgetGuide.html

If this is still true what to do?
I need it for http://thecoccinella.org/screenshots

/Mats

Re: [Tile-dev] Using ttk::dialog with a 'withdrawn' root window

[Christian S. <chr...@su...>]

Ah! I see. Thanks a lot. 

br. Chr.

Tirsdag den 20. Marts 2007 skrev Will Duquette:
> I'm a Tile newbie myself, but I suspect you need to set the dialog's
> "-parent" option explicitly to "".  Otherwise, it thinks it's transient
> with respect to ".", which isn't visible, and that might prevent it from
> displaying.  For what it's worth.
>
> Will Duquette
>
> On Mar 19, 2007, at 2:08 PM, Christian Surlykke wrote:
> > Hi
> >
> > I'm sorry if this is too newbeish.
> >
> > If I call 'withdraw' on the root window, I cannot make a
> > ttk::dialog show on
> > the screen. This little script shows my problem:
> >
> > <snippet>
> > package require tile
> > wm title . "Root window"
> > toplevel .tl
> > ttk::dialog .dlg -type okcancel
> > wm withdraw .
> > </snippet>
> >
> > With this, the dialog doesn't show.
> >
> > If I comment out the line "wm withdraw .", then the dialog shows
> > ok, but then
> > I have the root window on screen.
> >
> > How can I withdraw the root and show a ttk::dialog?
> >
> > -- Context:
> >
> > I'm trying to write an app, which is to sit as a tray-icon in the
> > system tray
> > and there should be no root window on the screen. When the icon is
> > clicked a
> > pop-up menu appears, and some of the entries in that menu should
> > launch a
> > ttk::dialog.
> > I use tktray1.1 (http://wiki.tcl.tk/5972) which is a toplevel
> > widget, but as
> > the snippet above demonstrates, my problem seems not to be related  to
> > tktray.
> >
> > I'm running tcl8.5a5, tk8.5a5 and tile-0.7.8. It's compiled from
> > sources on
> > debian unstable, and I run the app in KDE 3.5.6
> >
> >
> > -- Disclaimer:
> >
> > I use Tk and Tile from Ruby, and my tcl-skills are in the category
> > just below
> > pathetic. Therefore this mail may be nonsense, in which case I
> > appologize.
> >
> > br. Christian Surlykke
> >
> > ----------------------------------------------------------------------
> > ---
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
> > share your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?
> > page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Tktable-tile-dev mailing list
> > Tkt...@li...
> > https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev

Re: [Tile-dev] Using ttk::dialog with a 'withdrawn' root window

[Damon C. <da...@tc...>]

> I think there are 2 misconceptions here ...
>
> 1. all dialogs should be transient.
>
> No, there are many cases for startup dialogs where you have no parent.
>
> 2. Tk should "best guess" everything.
>
> I think this is an acceptable area to expect the user to provide their 
> own -parent to get the behavior, if desired.
>
> For those reasons, I went with a user-required -parent.

    This is where I thought a little helper proc could come in handy for 
people.  Leave the parent as blank by default but provide an easy way 
for users to get the "best guess" parent.  Meh.  I don't really care.  
I'll write my code to do my thing.  I'm just trying to help the other 
guy out. 0-]

Damon

Re: [Tile-dev] Using ttk::dialog with a 'withdrawn' root window

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

Damon Courtney wrote:
>     Well, but most all dialogs should be transient to something.  That's 
> just the way a dialog should be.  At the very least, we could provide a 
> helper proc to get the "best guess" transient parent.  I typically do 
> something like this:
> 
> proc ttk::parentWindow { {toplevel .} } {
>     return [lindex [wm stackingorder $toplevel] end]
> }
> 
> ttk::dialog -parent [ttk::parentWindow]

I think there are 2 misconceptions here ...

1. all dialogs should be transient.

No, there are many cases for startup dialogs where you have no parent.

2. Tk should "best guess" everything.

I think this is an acceptable area to expect the user to provide their 
own -parent to get the behavior, if desired.

For those reasons, I went with a user-required -parent.

Jeff

Re: [Tile-dev] Using ttk::dialog with a 'withdrawn' root window

[Damon C. <da...@tc...>]

> Er ... actually, I haven't had my morning coffee yet.  No +1 to Joe's 
> suggestion.  How about -parent "" by default, and let the user specify 
> it?  This is more in tune with how core widgets work.  This is also what 
> I did with tklib's widget::dialog (which, IMO, should replace all of the 
> above eventually ;) ).
>   

    Well, but most all dialogs should be transient to something.  That's 
just the way a dialog should be.  At the very least, we could provide a 
helper proc to get the "best guess" transient parent.  I typically do 
something like this:

proc ttk::parentWindow { {toplevel .} } {
    return [lindex [wm stackingorder $toplevel] end]
}

ttk::dialog -parent [ttk::parentWindow]


    Or some such nonsense. 0-]

Damon

Re: [Tile-dev] Using ttk::dialog with a 'withdrawn' root window

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

Damon Courtney wrote:
>> This appears to be a common pitfall with [ttk::dialog] --
>> you're not the first to run into this.  I was considering
>> changing things so that [ttk::dialog]s that are direct
>> children of "." are nontransient by default -- what do
>> others think?
> 
>     Do what BWidgets does.  If the parent is "." and that window is 
> withdrawn, make the window non-transient.  Or, considering that dialogs 
> are drawn immediately (in BWidgets they are created but not drawn until 
> "$w draw" is called), if ANY parent window is not visible, make the 
> dialog non-transient.  One would usually assume that if you're using 
> ttk::dialog that you want it to appear immediately no matter what the 
> parent is.

Er ... actually, I haven't had my morning coffee yet.  No +1 to Joe's 
suggestion.  How about -parent "" by default, and let the user specify 
it?  This is more in tune with how core widgets work.  This is also what 
I did with tklib's widget::dialog (which, IMO, should replace all of the 
above eventually ;) ).

Jeff

Re: [Tile-dev] Using ttk::dialog with a 'withdrawn' root window

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

Joe English wrote:
> This appears to be a common pitfall with [ttk::dialog] --
> you're not the first to run into this.  I was considering
> changing things so that [ttk::dialog]s that are direct
> children of "." are nontransient by default -- what do
> others think?

+1

Jeff

Re: [Tile-dev] Using ttk::dialog with a 'withdrawn' root window

[Damon C. <da...@tc...>]

> This appears to be a common pitfall with [ttk::dialog] --
> you're not the first to run into this.  I was considering
> changing things so that [ttk::dialog]s that are direct
> children of "." are nontransient by default -- what do
> others think?
>   

    Do what BWidgets does.  If the parent is "." and that window is 
withdrawn, make the window non-transient.  Or, considering that dialogs 
are drawn immediately (in BWidgets they are created but not drawn until 
"$w draw" is called), if ANY parent window is not visible, make the 
dialog non-transient.  One would usually assume that if you're using 
ttk::dialog that you want it to appear immediately no matter what the 
parent is.

Damon

Re: [Tile-dev] Using ttk::dialog with a 'withdrawn' root window

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

Christian Surlykke wrote:
>
> I'm sorry if this is too newbeish.
>
> If I call 'withdraw' on the root window, I cannot make a ttk::dialog show on
> the screen. This little script shows my problem:
>
> <snippet>
> package require tile
> wm title . "Root window"
> toplevel .tl
> ttk::dialog .dlg -type okcancel
> wm withdraw .
> </snippet>

Here's what's happening:

By default, [ttk::dialog] windows set [wm transient $dialog $parent],
where $parent is the nearest toplevel ancestor of $dialog --
in this case, ".tl" will be a transient child of ".".

Under most window managers, transient windows are only visible
when their parent is mapped.  Since "." is withdrawn, its
transient children will also be hidden.

You can override this with [ttk::dialog .tl -parent {}].

 * * *

This appears to be a common pitfall with [ttk::dialog] --
you're not the first to run into this.  I was considering
changing things so that [ttk::dialog]s that are direct
children of "." are nontransient by default -- what do
others think?


--Joe English

  jen...@fl...

Re: [Tile-dev] Using ttk::dialog with a 'withdrawn' root window

[Will D. <Wil...@jp...>]

I'm a Tile newbie myself, but I suspect you need to set the dialog's
"-parent" option explicitly to "".  Otherwise, it thinks it's transient
with respect to ".", which isn't visible, and that might prevent it from
displaying.  For what it's worth.

Will Duquette


On Mar 19, 2007, at 2:08 PM, Christian Surlykke wrote:

> Hi
>
> I'm sorry if this is too newbeish.
>
> If I call 'withdraw' on the root window, I cannot make a  
> ttk::dialog show on
> the screen. This little script shows my problem:
>
> <snippet>
> package require tile
> wm title . "Root window"
> toplevel .tl
> ttk::dialog .dlg -type okcancel
> wm withdraw .
> </snippet>
>
> With this, the dialog doesn't show.
>
> If I comment out the line "wm withdraw .", then the dialog shows  
> ok, but then
> I have the root window on screen.
>
> How can I withdraw the root and show a ttk::dialog?
>
> -- Context:
>
> I'm trying to write an app, which is to sit as a tray-icon in the  
> system tray
> and there should be no root window on the screen. When the icon is  
> clicked a
> pop-up menu appears, and some of the entries in that menu should  
> launch a
> ttk::dialog.
> I use tktray1.1 (http://wiki.tcl.tk/5972) which is a toplevel  
> widget, but as
> the snippet above demonstrates, my problem seems not to be related  to
> tktray.
>
> I'm running tcl8.5a5, tk8.5a5 and tile-0.7.8. It's compiled from  
> sources on
> debian unstable, and I run the app in KDE 3.5.6
>
>
> -- Disclaimer:
>
> I use Tk and Tile from Ruby, and my tcl-skills are in the category  
> just below
> pathetic. Therefore this mail may be nonsense, in which case I  
> appologize.
>
> br. Christian Surlykke
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev

[Tile-dev] Using ttk::dialog with a 'withdrawn' root window

[Christian S. <chr...@su...>]

Hi 

I'm sorry if this is too newbeish.

If I call 'withdraw' on the root window, I cannot make a ttk::dialog show on 
the screen. This little script shows my problem:

<snippet>
package require tile
wm title . "Root window"
toplevel .tl 
ttk::dialog .dlg -type okcancel
wm withdraw .
</snippet>

With this, the dialog doesn't show.

If I comment out the line "wm withdraw .", then the dialog shows ok, but then 
I have the root window on screen.

How can I withdraw the root and show a ttk::dialog?

-- Context:

I'm trying to write an app, which is to sit as a tray-icon in the system tray 
and there should be no root window on the screen. When the icon is clicked a 
pop-up menu appears, and some of the entries in that menu should launch a 
ttk::dialog. 
I use tktray1.1 (http://wiki.tcl.tk/5972) which is a toplevel widget, but as 
the snippet above demonstrates, my problem seems not to be related  to 
tktray.

I'm running tcl8.5a5, tk8.5a5 and tile-0.7.8. It's compiled from sources on 
debian unstable, and I run the app in KDE 3.5.6
 

-- Disclaimer:

I use Tk and Tile from Ruby, and my tcl-skills are in the category just below 
pathetic. Therefore this mail may be nonsense, in which case I appologize.

br. Christian Surlykke

Re: [Tile-dev] tile.kit questions - Success

[Casey A. <ca...@sa...>]

Ok, I managed to get it to ./configure and compile correctly. However, 
not without more problems. i didn't realize I had to have and keep 
the Tcl/Tk sources after compiling/installing. And because I had 
installed Tcl and Tk via the FreeBSD ports systems, the sources were 
no longer there.

Therefore in my naive assumption, I didn't expect Tcl/Tk was 
a "compile-time" dependency of Tile. Of course, hindsight tells me it 
was obvious. I just wasn't thinking clearly. :)

After some detective work, and downloading the sources directly from 
sf.net, and editing the [tcl|tk]Config.sh files, I managed to get 
Tile compiled.

My offer still stands to offer the FreeBSD files for the tile.kit for 
the next release, or whenever.

Thanks!

- Casey

On Wed February 28 2007 10:25, you wrote:
> Casey Ackels wrote:
> > I tried both Jeff's and Joe's versions.
> >
> > When i try ./configure, i get these errors:
> > checking for correct TEA configuration... ok (TEA 3.5)
> > checking for Tcl configuration... configure: WARNING: Can't find
> > Tcl configuration definitions
> >
> > However, there is a Port of Tile, and that has compiled
> > successfully. Any tips on getting the standard SF.net source
> > distribution to compile?
>
> What is different in the "Port of Tile"?  I think all you need to
> do is have the right --prefix or --with-tcl --with-tk lines in you
> configure call.
>
> Jeff

Re: [Tile-dev] tile.kit questions

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

Casey Ackels wrote:
> I tried both Jeff's and Joe's versions.
> 
> When i try ./configure, i get these errors:
> checking for correct TEA configuration... ok (TEA 3.5)
> checking for Tcl configuration... configure: WARNING: Can't find Tcl 
> configuration definitions
> 
> However, there is a Port of Tile, and that has compiled successfully. 
> Any tips on getting the standard SF.net source distribution to 
> compile?

What is different in the "Port of Tile"?  I think all you need to do is have
the right --prefix or --with-tcl --with-tk lines in you configure call.

Jeff

Re: [Tile-dev] tile.kit questions

[Casey A. <ca...@sa...>]

Ok, i've tried to compile Tile from the source package from 
SourceForge. And i am unable to successfully compile it.

I tried both Jeff's and Joe's versions.

When i try ./configure, i get these errors:
checking for correct TEA configuration... ok (TEA 3.5)
checking for Tcl configuration... configure: WARNING: Can't find Tcl 
configuration definitions


However, there is a Port of Tile, and that has compiled successfully. 
Any tips on getting the standard SF.net source distribution to 
compile?

I certainly wouldn't mind either offering an account on my machine to 
compile Tile releases, or doing it myself.


On Mon February 26 2007 10:12, you wrote:
> Casey Ackels wrote:
> > platforms (windows, linux, freebsd).
>
> 	...
>
> > So, I unwrapped the tile.kit and /FreeBSD-x86/ doesn't exist. Is
> > this a mistake or is there no FreeBSD support in tile.kit?
>
> Whoever built tile.kit probably did not have access to a FreeBSD
> machine.  One just needs to extend the existing kit with the right
> binaries.
>
> > And if FreeBSD isn't supported, what would it take to get it
> > supported? If its a simple recompilation, i would be more than
> > willing to do it, provided I had instructional help (I am new to
> > this).
>
> Yes, it's a simple recompilation.  You would need to grab the
> appropriate sources (ideally the same as the kit uses, for
> consistency with the runtime tcl files), and just do the usual
> configure/make on it.  It's the install that has to be
> hand-twiddled to get into the kit correctly.
>
> Jeff