
AndroWish: Tcl/Tk on Android - networked
http://www.androwish.org/index.html/home
======
lnanek2
Kind of sad the UI wasn't fixed. TCL/TK looked old and archaic a decade ago on
desktop machines, and still looks really bad here:
[http://www.androwish.org/index.html/wiki?name=Example+Script...](http://www.androwish.org/index.html/wiki?name=Example+Scripts)

It is old Sun technology that Sun abandoned to work only on Java and if you
are familiar with how bad and ugly the original Java UIs were (AWT, Applets,
etc.) you already know what it looks like.

To match modern Android UIs they have to rip out a lot of chrome and needless
borders and decoration and make the whole thing a lot cleaner, then redo
everything to try to follow a consistent design grid of touchable items.
Android designs follow a 48dp grid (dp being a pixel that scales with screen
density) to keep things consistent and the right size to touch. In the
screenshots above you often see things like inconsistent spacing and tiny
microscopic checkboxes (which are not even consistent checkboxes with the rest
of Android so increase user friction).

~~~
oblio
They did fix the tech with TTK/Tile. The thing is, the default themes for it
are decent, but they're still far from what Qt does. And even Qt isn't
perfect.

Here's how things look with Tile:
[http://tktable.sourceforge.net/tile/](http://tktable.sourceforge.net/tile/)
(click Screenshots on the left).

~~~
luckydude
This:

[http://www.mcvoy.com/lm/bitmover/lm/gui/gui.html](http://www.mcvoy.com/lm/bitmover/lm/gui/gui.html)

is done with Tk. It's possible to make it look semi decent and not that hard.
We should have picked some better fonts.

------
davidw
I made Hecl work on Android, but it has kind of languished, unfortunately:

[http://www.hecl.org/](http://www.hecl.org/)

------
72deluxe
Nice to see Fossil SCM being used as the website host. Thanks SQLite creator!

~~~
bch
...and former TCT (Tcl Core Team) member.

(This is drh (Richard Hipp) for those that don't know off the top of their
head who the principal of SQLite is...
[http://en.wikipedia.org/wiki/D._Richard_Hipp](http://en.wikipedia.org/wiki/D._Richard_Hipp))

------
amelius
John Ousterhout is a professor who really did some amazing programming back in
the 90s! Can't think of many people coming close in terms of productivity.

~~~
easytiger
INteresting:

[http://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy](http://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy)

Ousterhout's dichotomy is computer scientist John Ousterhout's claim[1] that
high-level programming languages tend to fall into two groups, each with
distinct properties and uses: system programming languages and scripting
languages

------
lafar6502
Fossil.. it deserves more attention than it has now. Maybe Git is more
powerful, but Fossil is a pearl of software engineering

------
hardwaresofton
I realize I am raining on the parade a little bit but,

As a person who has worked with TCL, I would hate to see it anywhere other
than where I have run into it before (IC design). It is an almost-lisp that
has way too many idiosyncrasies and bad quirks.

~~~
luckydude
Yeah, agreed, and we still use it so we made a little C like language that
compiles to tcl byte codes. Makes coding there far far more pleasant (for me
at least).

[http://www.mcvoy.com/lm/L/L.html](http://www.mcvoy.com/lm/L/L.html)

~~~
hardwaresofton
Excuse me for asking, but are you doing IC?

If not, what is tying you to TCL? legacy software? Also, why not just
interface away from TCL?

I'm trying not to be too negative on TCL, but it's just not worth the trouble.
Now, if someone built a lisp on top of tcl, I might use it, but things like
having a { in the comments or spacing out opening {s for a loop is a
ridiculous problem for a parser to fall down on (with a non-intuitive error
message to boot).

Also, you guys are throwing away the good (lispy) parts of tcl by having a C
like language (the syntactic consistency, meta-programming by creating
variables dynamically,etc)... Also, I bet people have to do some "training" to
get up to speed on which parts of the C-like language are which, which
generally leads to

Not to sound arrogant, but if I was working with you guys, my first 20% time
project would be to convert whatever it was that was tying us to TCL to
something else, unless it was super duper impossible (like it was in IC). It's
just a productivity killer, in my experience.

~~~
luckydude
Sorry, didn't see this until now. We do cross platform gui apps in L/Tk for
our source management system. We're pretty small so doing native apps for
Windows/Mac/Linux is a lot more work than doing it once. Yeah, the hassle of
making them look good is true but not as true as people claim it is (see my
other post above).

We looked at Qt and I didn't want to bite of C++ on all our ancient platforms
we support.

I'm a C kinda guy, I like looking at things and understanding it quickly (when
going into new code I tend to read the .h files and find the structure
definitions, that tells me a lot). Most scripting languages don't have structs
(they use a hash instead which means you never really know what is in there
unless you find every single assignment to it and memorize all the keys).

~~~
hardwaresofton
Hey thanks for the reply, was very curious what you were using it for...

So, this is pretty crazy, but why not try a small rewrite of some non-trivial
functionality in Go? Other than being a language hipster (which I admit I am a
little bit), I point to these reasons:

1\. Go's ease of cross-compilation is outstanding, so much so that everything
else I think of (java, python, C/C++) are not as easy

[http://dave.cheney.net/2012/09/08/an-introduction-to-
cross-c...](http://dave.cheney.net/2012/09/08/an-introduction-to-cross-
compilation-with-go)

2\. Go is trying to be used in a "systems language" context, so it's
relatively quick

3\. It's not C++, and is relatively safer

If you're with me till now, then you've realized the real problem with
something like Go for this is the GUI library -- unfortunately there are not
enough that have been around long enough to be as stable/trusted as TCL/TK....
so that's a bit of a problem.

You could also make the UI to your app a website, rather than a GUI
application?

\-------------- OR --------------

What about a your-app-is-a-website type framework like TideSDK?

[http://www.tidesdk.org/](http://www.tidesdk.org/)

You can encapsulate and separate your engine code (which is doing the heavy
listing), and just have the client be something that sits on top of it.

Sorry, these solutions are quite pie-in-the-sky and I'm sure that you guys are
focusing on getting things done (for which L/Tk is perfectly fine), but if you
guys are small, I think you might have the agility to move onto a different
solution, and I can't help but suggest these things, because I think working
on a TCL/TK stack might get things done, but you're gaining experience in a
technology that is thoroughly antiquated... So yes, you'll get things done,
and you guys will do a great job, but at the end of the day, when it comes
time to move to something else, not a lot of the knowledge you gained will be
useful?

~~~
luckydude
So moving to anything is a pile of work, we have 10 different guis in L/Tk:

    
    
      bk citool - graphical check-in tool
      bk csettool - graphical changeset browser
      bk difftool - graphical differences viewer
      bk fm3tool - three-way merge tool
      bk fmtool - side-by-side merge tool
      bk helptool - graphical front-end to the help system
      bk renametool - graphical tool for finding renames
      bk revtool - graphical history browser
      bk setuptool - graphical front-end to the setup command  
      bk explorer - file/repo/branch explorer
    

which is about 26,000 lines of code.

We're trying to relaunch the company, we've never done any marketing, just
coasted on the rep we got from having the Linux kernel use us for a while.
Rewriting all the guis is a big task - we need to focus on stuff that will
make money or the whole thing will be a moot point :)

And we're gonna open source L pretty soon here so maybe that will breath a
little life into the tcl/tk ecosystem (and maybe not, I have no way of
knowing). L is pretty pleasant, it has replaced perl as my goto scripting
language. I'd love it if gcc had an L dialect.

------
zerr
It is somewhat confusing whether this is a wishlist or done-list :)

~~~
sigzero
You are probably joking but...wish it the "gui" executable for Tcl.

