Now that Tile is at 0.7.5 and all 'compatbility options' have been removed, it is impossible to convert many applications to use Tile with the simple recipe of "namespace import -force ttk::*" and a bit of manual tweaking (this was reasonably possible with Tile < 0.7). In fact even Tk's built in dialogs will throw errors all over the place with such an approach. This page is here to help (hopefully!).
I believe the first lesson in migration is a mental one. Tile is designed to be different. Tk was designed so that everything "just works", but Tile is designed so that you have to follow a strict path to achieve your platform-native look. This means that obvious things you may have learned from Tk are just wrong now. For example:
Eg1: What font does this label have?
Tk: set font [$label cget -font] ; set size [font measure $font $text]
Ttk: error no such option '-font'...
or
Eg2: This widget's a bit cramped, let me give it some more space: $widget configure -borderwidth 4
Ttk: error no such option '-borderwidth'
So you have to recognise that your entire approach will have to be different to cope with Tile. It would have been pretty easy to code Tile deal with most standard options just like Tk does, but the developers appear to have made a conscious decision not to do anything like that. (Note that this page does not attempt to justify why the Tile developers rejected the idea of allowing configuration options to actually work and forced the programmer down the path of using styles for absolutely everything.)
Note: currently most of the answers here are empty. Tile's documentation wasn't too helpful, so I'm hoping that one of the Tile developers might step in with some answers.
Here are some common issues in migrating to Tile, together with their resolutions:
1) Tk's dialogs manually adjust buttons with, for example, '$button configure -relief sunken'. Tile has no '-relief' option. How can a dialog's code programmatically press a button with Tile?
Answer: ...
2) Labels, checkbuttons etc all have a variety of wrapping options so text can wrap across multiple lines. How can this effect be achieved with Tile? How can I create a Tile checkbutton widget that has wrapped text?
Answer: ...
3) Tk's menubuttons have a '-indicatoron' option. How is this handled in Tile?
Answer: ...
4) I want a red label with a large font to warn a user about something important, but there isn't a -font or -foreground option. How is this done with Tile?
Answer: Create a unique style in every theme for your big red warning label.
4b) The answer to question 4 is a lot of work for just a big red warning label. Isn't there an easier way?
Answer: Use the standard Tk widgets.
5) I want Tile widgets in Tk dialogs.
Answer: Rewrite the dialogs or use [insert name here]'s rewrite of the Tk dialogs.
6) I need to find out what font a widget is using so I can both display its name and calculate whether the widget will need several lines to fit a given textual string. How can I determine the widget's font?
Answer: ... I don't think you can. Redesign your code completely so it doesn't need to know.
7) My application is cross-platform. I'd like it to run if Tile is or is not available. How should I takes advantage of Tile when Tile is available, but works just fine when Tile isn't? Given the dramatically different design philosophy (e.g. of something as simple as the 'red label' above), it seems I'm just going to need to have a lot of different tile and non-tile branches in the code.
Answer: ... I think you need a lot of branches in your code and will have to write 2 versions of a lot of gui stuff. In one branch you configure the -style of tile widgets and in another branch you'll configure the various options of Tk's widgets. Of course you can factor some of this stuff into common procs, but you still need a lot of branches and a vast amount of work.
SRIV I hope i'm wrong, but, due to lack of -options, I feel that tile widgets will be useless for building megawidgets. I do understand the goal of creating a native look and feel, which it does nicely.
George Peter Staplin I feel the pain. I was excited about Tile for a while. I converted several applications to use it. Then I upgraded to tile07.kit and found that most of my applications broke. They were unusable... So, I have removed Tile from all but 1 application -- the Whim window manager. Even there we now have what I consider unnecessary branches that are just tile-specific code. We no longer have the themed dialogs, because every dialog must now be rewritten. After the initial disappointment of Tile 07.x I talked with Joe English and unfortunately he isn't interested in changing things, and now with Tile going into the core it will probably go unused by all but the new apps, or those that pay to have applications converted.
Vince I'm really struggling to update Alphatk to use the latest Tile. In fact I'm beginning to agree with what you write George - Tile just isn't suited to updating complex applications. It demands such a different approach that it's only good if that approach is incorporated into the design from the beginning.
SRIV If you use it such that the OS controls the theme, then you get native looking apps cross platform with little effort. But since you can't predict what the users set theme will look like, you can't really predict what your app will look like, especially when you make megawigets.