Updated 2014-03-28 18:28:18 by eds

The ten commandments to keep your hands off AndroWish

  1. looks ugly, like stuff from the 90's (you're invited to design a ttk theme for it to look somewhat less anachronistic)
  2. behaves not exactly like Tcl/Tk on the desktop (due to that pixel density war on mobile equipment)
  3. has not reached maturity in years (and will take another century)
  4. will never look native on Android (although nativity in terms of look is quite relative)
  5. invites developers to combine it with unwanted ads (in the sense of free software)
  6. 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!)
  7. will run for 74 minutes at most (not proved, but couldn't resist, since the 35 year old CD played not longer)
  8. was a hack by a single individual not backed up by a conference or a consortium
  9. (the most compelling point) was not designed from ground up to be something totally new
  10. 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 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?