AndroWish: Tcl/Tk on Android(androwish.org)
androwish.org
AndroWish: Tcl/Tk on Android
http://www.androwish.org/index.html/home
23 comments
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/ (click Screenshots on the left).
Here's how things look with Tile: http://tktable.sourceforge.net/tile/ (click Screenshots on the left).
This:
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.
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.
"the default themes for it are decent"
Not on Linux. One of the long-time criticisms of Tcl was its Windows-centric development.
Not on Linux. One of the long-time criticisms of Tcl was its Windows-centric development.
> It is old Sun technology that Sun abandoned to work only on Java
Not exactly true. Tcl/Tk was not invented at Sun, although Sun did fund its development for a few years by employing its author John Ousterhout.
But, I agree with you that the UI look is outdated, and needs some touching up. Every time this issue is brought up, the Tcl folks point to the "new" theming capabilities that were added in v8.5 (or perhaps v8.4?). I haven't looked at theming in Tcl to make an opinion.
Not exactly true. Tcl/Tk was not invented at Sun, although Sun did fund its development for a few years by employing its author John Ousterhout.
But, I agree with you that the UI look is outdated, and needs some touching up. Every time this issue is brought up, the Tcl folks point to the "new" theming capabilities that were added in v8.5 (or perhaps v8.4?). I haven't looked at theming in Tcl to make an opinion.
Tk looked outdated 20 years ago when I first used it on BSD-derived SunOS boxes.
I made Hecl work on Android, but it has kind of languished, unfortunately:
http://www.hecl.org/
http://www.hecl.org/
Nice to see Fossil SCM being used as the website host. Thanks SQLite creator!
...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)
(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)
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.
INteresting:
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
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
Recently, he and a grad student at Stanford came up with the most exciting consensus protocol people have seen in a decade or more, Raft.
Fossil.. it deserves more attention than it has now. Maybe Git is more powerful, but Fossil is a pearl of software engineering
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.
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.
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
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.
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.
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).
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).
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...
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/
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?
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...
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/
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?
So moving to anything is a pile of work, we have 10 different guis in L/Tk:
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.
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
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.
In ASIC design (that's what the commenter probably refers to when mentioning IC), just like in the more widespread FPGA world: many of the proprietary expensive tools are exposing their functionality as aTCL scripting engine. While the graphical tools hide this to some extent, as soon as you go for automation, which is unavoidable for complex work, you'll find yourself to write scripts in the TCL language.
Oh -- I am the original commenter (haha), I was just trying to not assume that they were working in IC design. what you've said is absolutely true -- just wanted to see if that was the case
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).