Why AndroWish was a bad idea
The ten commandments to keep your hands off AndroWish
- looks ugly, like stuff from the 90's (you're invited to design a ttk theme for it to look somewhat less anachronistic)
- behaves not exactly like Tcl/Tk on the desktop (due to that pixel density war on mobile equipment)
- has not reached maturity in years (and will take another century)
- will never look native on Android (although nativity in terms of look is quite relative)
- invites developers to combine it with unwanted ads (in the sense of free software)
- follows not that hyped HTML5/CSS/JavaScript/WebGL/Canvas/Websocket/*whatever* inventions of W3C (which in modern times does not require to learn one programming idiom, but at least three, holy progress!)
- will run for 74 minutes at most (not proved, but couldn't resist, since the 35 year old CD played not longer)
- was a hack by a single individual not backed up by a conference or a consortium
- (the most compelling point) was not designed from ground up to be something totally new
- born out of pragmatism to be as portable as possible with oldish software which has been invented years ago in order to not re-invent the wheel.
pdt I could be a bit picky with ttk, e.g. under Linux scrollbar buttons don't look great, treeview defaults to bold column titles. Under Windows, notebook tabs don't look as good as under Linux. I'm sure I could come up with some other minor points as well. But I don't think there's too much wrong really with how ttk looks.
The Linux tk file dialag leaves a lot to be desired. But I don't like the native Windows file dialog either. It's great if you like native, but what's native isn't always particularly good. I don't like the Microsoft ribbon much, and I don't like tool buttons in window title bars ...
Am I sounding grumpy? :) I won't start on Gnome3.
For cross-platform apps, attempting to look native is something I personally wouldn't go for. What I would go for is the app just must not be visually offensive.
I haven't used it in a while, but Synplify Pro always looked ugly to me, with its quite strong gradient shading on its toolbars and buttons.
tk under Linux looks bad. I used to write quite a bit of Java, and it's fairly easy to write an ugly Swing GUI as well, although with a bit of effort you can make them look just fine. Xilinx Vivado looks OK, I _think_ that's Swing ...
If ttk on Android can look as good as it does on Linux/Windows, great!
chw here's a snapshot made from a 7 inch tablet with 1024x600 resolution running TkSQLite which is ttk based.
Not that bad at all, I hope.
nobelke chw, again, your efforts should be praised! Don't be put off by negative comments. You provide us with a batteries included solution even with a nice interface to the android eco-system. What ever do you want more! Which other scripting solution gives us this write once run everywhere feeling. As you see on which devices it all works it's amazing. A TTk theme special for android would be nice. Here we need some graphical designers who can pop in.
APN nobelke, it was chw himself who wrote those comments so not likely he will be put off :-)
pdt Yes, looks good. I don't have an Android tablet, but I think I'm going to have to get one. I haven't treated myself to much in the way of gadgets recently, so it's now at the top of my shopping list :)
eds - 2014-03-26 23:01:42
Well, where do I begin?
The bulk of the comments seems to be about the look and not the functionality, so in a word - who cares!? Looks good to me: 
AndroWish provides an amazingly low-overhead way to program Android devices. It leverages an existing code base that actually DOES something, and not just LOOKS a certain way. The said code runs without modifications (more or less, some tweaks made for readability made it necessary to resize some of the fonts I had used back DOWN in size, for Android only).
if { $tcl_platform(platform)=="unix" } {
if {[catch {exec sdltk android}]} { ;# Linux
set defaultfont "Arial"; set defaultsize 10
}
} else { ;# Android
set defaultfont "Arial"; set defaultsize 6
}
} else { ;# Windows
set defaultfont "Arial"; set defaultsize 8
}The fact that it was made by a single individual, who actually cares, listens and responds to user traffic, is a strength not a weakness. This is the only way to run a successful project. Once it matures, you can form a committee and start evolving a new "standard".
> I completely agree with this view. Even more: there is e.g. growing consensus among scientists, that even brainstorm sessions are not that productive as is common sense. The single code creator who creates code in a "flow" state is indeed quite very productive (RJM 201709).
I can teach a classroom full of novices to achieve something meaningful in a single lecture. It's a blessing, removing the overhead of multiple user interfaces on multiple platforms.
The above list seems contrived. I think, chw is just fishing for compliments ;-)
chw 2014-03-27: bull's eye, eds! Thanks. In your code snippet the exec sdltk android is wrong. It would use Arial 6 on all UN*Xen. The photo is nice. What application is it? And on which device with which screen resolution did you shoot it.
eds - 2014-03-27 23:06:49
The code may well be a bit off, I was quoting from memory... it's hard to cut and paste and do regular things on Android.
Actually, what would be the best way to test for Android vs. other Unix flavours? Setting all to the same size does NOT work, labels scale very badly and mess up our beautiful simulation graphics (where they cannot scale!), I can show examples.
The application is picl, "a compiler/loader for PiCLab board written in tcl/tk" that I use in teaching some of my classes, for example:
http://www.physics.brocku.ca/Courses/2P32/lab-manual/pic-assembler.pdf
It's a tool that is a combination compiler/ide/emulator/control device for a home-grown digital Electronics lab platform, called PiCLab. If anyone is interested, I can post links, though they are under a bit of a password-protection at the moment, as there are some materials in the course pages that are under copyright; picl is freely available, but it really does require the development board itself to make full use of it, even if it works happily without one.
The platform is a Cintiq Companion Hybrid, a 13" pad, that I use to teach and to prepare class notes, as well as a general large-size notepad - my eyesight is not as good as it used to be, so I cannot meaningfully deal with 4-5" screens.
Jorge - 2014-03-28 02:51:50
I am interested, please post the links. Thanks.
chw 2014-03-28: Me too. Thanks for the info. Regarding cut & paste I've tried my best to provide what infrastructure is available on Android. Some of my findings and patches were integrated into SDL but the really important part is still a private patch in AndroWish. If you connect a Bluetooth mouse to your real kooool full HD equipment, selection with the mouse for cut and paste might be not that bad.
Scaling all that stuff is PITA for me. In the very beginning I believed that I should follow the single pixel truth: it should look always equally the same regardless of pixel density. Pixel for pixel on all displays of the universe. Although that is getting a huge universally expanding problem (most likely induced by some bang) if pixel densities start at about 75-100 DPI (for monitors, be it LCD or anachronistic CRT) and go up now to 530 DPI (for high end smartphones) with no end in sight. My hapless hope was to find a middle ground but as I see from your application I'm still far off. And I'm afraid we're all off with our ancient thinking in pixels. Since pixel density seems to be somewhat infinite (regardless of our limited human eye sensors) I see (rather limited, low res, of course) some arguments of Why AndroWish was a bad idea confirmed.
BTW: what is the result of borg displaymetrics on your Cintiq Companion?
eds - 2014-03-28 18:17:10
I will make something about picl available shortly, want to create a short write-up explaining what it is.
On Cintiq Hybrid: density 1.0 densitydpi 160 width 1920 height 1032 xdpi 166.444 ydpi 166.255 scaleddensity 1.0
You cannot possibly anticipate the use of the pixel density in all devices. Imagine a high-dpi small physical size device that gets used in a "slide projector" that gets it scaled up to feet on the wall. The same size/pixel density in your handheld would require a microscope to view. You cannot anticipate which it is from the raw pixel density data.
Now, chw, don't throw the baby out with the bathwater!! The fact that we have not yet found an intelligent way of dealing with the many available screen sizes and pixel densities **by default** does not mean the application itself is "not worth it", that's just plain silly. Perhaps the interim solution is to leave it in the hands of the user?
From the screenshot I posted you can see that picl works actually quite well on Cintiq. It's when I try the same script on a Nexus 7 that the auto-scaled label fonts get messed up. Notice how I am being very careful saying "label fonts" all the time. The fonts inside the canvas can be nicely controlled (increase/decrease font size works just fine), it's the fonts of the window frame itself (and these are the ones that get used by the "label" in tcl) that do not respond to +/- requests which scale things inside the canvas.
Here's my "radical" proposal: add a font/size selector for the AndroWish shell labels/menus, like an additional "Settings" menu. You could have a radio button for "Auto" or a selector of a specific font/size that the user can make and that will be remembered in the .androwishrc in the working directory (where the .tcl source is, so it may be different for different scripts, for example).
Unless I am simply not doing the font request properly for my labels? Excerpts:
set defaultfont "Arial"; set defaultsize 6 font configure TkDefaultFont -family $defaultfont -size $defaultsize font configure TkTextFont -family $defaultfont -size $defaultsize font configure TkFixedFont -family $defaultfont -size $defaultsize font configure TkHeadingFont -family $defaultfont -size $defaultsize font configure TkCaptionFont -family $defaultfont -size $defaultsize font configure TkTooltipFont -family $defaultfont -size $defaultsize font configure TkIconFont -family $defaultfont -size $defaultsize font configure TkMenuFont -family $defaultfont -size $defaultsize font create pf -family $defaultfont -size $defaultsize label .pic.f.c.w -width 8 -relief groove -justify center -textvariable P_pic_W -font pf .pic.f.c create window 360 90 -window .pic.f.c.w; set P_pic_W "W=00"
The "-font pf" part is ignored and the label font/size is set to the same font/size employed by the labels within the frame of "Console"; all other fields do seem to obey the font size instructions, so perhaps it's just the TkMenuFont that is being overridden by AndroWish? Or am I forgetting to set some other TkXyzFont? If it's a "feature" of AndroWish, perhaps this could be bypassed **if** the TkMenuFont (or whatever it is that controls it) is defined within, as the user is clearly trying to control it?
eds - 2017-04-11 15:18:21
My apologies, I completely forgot the promised links: description , picl.tcl , picl-install.tcl (installation script, with a nice logo, assumes you made a /sdcard/tcl/ and keep all your .tcl files there). May require gnuplot on the platform, for Android, assumes Gnuplot Viewer .
The above description is of both hardware and software, written by the primary author of the application, Phil (a lab demonstrator in the Department of Physics). The application has been 13 years in development and is mature and stable.
MDD: I’m particularly excited about the potential AndroWish provides in the area of education. I’ve worked with SEH over the last year to create an enhanced version (adding code signing, Firebase support, and web integration) of the AndroWish package, called NovaTcl, that I intend to build upon to create an environment for teaching kids to code. I don’t care too much about the old look-and-feel of Tcl, since teaching coding concepts is the main objective. Over time, the look-and-feel issues will likely improve. My plan is to leverage the simplicity of the language, and the low-cost of Android devices, to put together a reasonably-complete curriculum covering the various fundamentals of coding and application design, one that even poorly-funded schools can integrate into their curricula with minimal resource requirements. I’ve released a preview version of the package in the Google Play Store (search for NovaTcl), and plan to add an integrated editing environment with interactive lessons, and other tools, by the end of the year. I’ve started putting together a web site for the project, as well,[L1 ] but it is not even close to complete. This is basically a side-project for me, but hopefully I can get some schools to try it out next year. It is only through the amazing work that chw did with AndroWish that this project has become even remotely feasible.
RJM 2017-9-10: I installed novatcl now. What makes me happy is that it A) is available in google play, without complaining about unknown source of app (and hence, forces the user to change a security detail in the settings) and B) executes existing Tcl code as if Androwish be installed.
As such, I can share small Tcl applications with other people without difficulties. Asking them to install a 23 MB app from google play is OK. There are some Ideas in my mind to present some nice apps to Android devices, in kiosk mode.
HaO2022-03-08: To have a good look and feel, the themes AWDark and AWLight may be used. They are scalable, so the issues with different screen resolutions may be solved. There are other hints on the Tips and Tricks page. The file dialog is an open issue for me. Unfortunately, great fsdialog 2 does not fly, as the root folder is not readable at all.