MG would love to see support for the vfs package, a requirement for loading starkits.
chw the vfs package is now included starting with the "James Joyce" edition (2014-01-13).
MG Brilliant, thanks for the quick response.
MG Follow-up: I installed the newer version of AndroWish in the emulator, did a
package require starkit
which worked (1.3.3). I then tried to source my starkit, but that failed with the error
can't find package vfs::mkcl
while executing
"package require vfs::mkcl"
(procedure "::vfs::mk4::Mount" line 4)
invoked from within
"::vfs::mk4::Mount /storage/sdcard/Download/starkit.kit /storage/sdcard/Download/starkit.kit -readonly"
("eval" body line 1)
invoke from within
"eval [list ::vfs::${driver}::Mount $self $self} $args"chw so there's something missing in the CVS version of vfs. Can you please point me to where I can fetch a complete vfs source archive including the required stuff for starkits? There must also be some C code which needs to be adapted for Android which I didn't find on the web, either.
MG It looks like it tries to load vfs::mkcl as a fallback when the Mk4tcl package isn't available. I can't actually find any info about vfs::mkcl, but it seems Mk4tcl can be obtained from [L1 ]
chw 2014-01-18: hopefully fixed with the "Amphetamine" edition which includes the read-only tclkit vqtcl module.
MG 99%! It errors out when trying to cd to a directory in a starkit (complains it's not a directory, while under other OSes you can CD into the file structure of a starkit without a problem). Curiously, though, it has created images with image create photo -file ... which are located inside the starkit. Anyway, I removed the cd and it loaded the starkit, which seems to be running perfectly. Thank you :)
chw 2014-01-21: when I try this on /storage/sdcard0/clock.kit
package require vfs::mkcl vfs::mkcl::Mount /storage/sdcard0/clock.kit /mystarkit
it is possible to cd into the mounted startkit on /mystarkit, to glob, and to open files.
ramsan I would like to see a short tutorial in how to compile a simple tcl package that contains c/c++ code
chw unfortunately unsupported as a standalone piece since everything is built as a whole and finally packaged into an APK. So your best option is to fetch the complete source, add your tcl package containing native code to the .../jni subdirectory of the source tree, pick one of the Android.mk makefiles from the many ported extensions, adapt it to your package, add an appropriate pkgIndex.tcl to the .../assets subdirectory, and build the beast using Android NDK/SDK and "ant". A short recipe is in Tcl/Tk on android poll.
ramsan But then ... I cannot offer the package to other users. In my specific case, I have RamDebugger running ok on Androwish. But some parts of this program are made in c++ to instrument and colorize files faster. How can I create the dynamic library for this code in order for RamDebugger to run properly?
chw 2014-01-21: glimpsed over RamDebugger-source8.1.zip and saw many DLLs and shared libraries but no source code. As stated above, you should fetch the AndroWish sources, put your sources of those DLLs/shared libraries below the .../jni subdirectory and create appropriate Android.mk makefiles. Finally, you might want to call your application "RamDebugger": you have to subclass from tk.tcl.wish.AndroWish (an empty class body should do) in order to give the application another package/class name. That java stuff is below the .../src subdirectory. Adapt the AndroidManifest.xml to that package/class name and change the resources in .../res (strings, icons) to your needs. That should give you your RamDebugger APK at the end.
ramsan 2014-01-22: You are describing how to create an application only for myself. But this is not the objective. The objective is to create a package, an editor and debugger, that can be used by any user of androwish. (NOTE: the source code is at: scripts/RamDebuggerInstrumenter.cc). You can access the fossil source code at: [L2 ]
chw 2014-01-23: then package RamDebugger into a starkit. I'm afraid, however, that for the shared libraries you have to carry out the above mentioned steps (get AndroWish sources, Android NDK, put C/C++ sources below .../jni, create Android.mk, use ndk-build to generate shared libraries). Another point to watch out for is that AndroWish builds for ARM and x86 processors, i.e. there are two versions of each shared library which you have to put into the starkit. And the package specific Tcl load command must use $tcl_platform(machine) to find out which library to load (I've never tested loading native code from a starkit, BTW).
PO would like to have an Android theme and the possibility to simulate right clicks (if possible).
jima 2014-01-14
As asked for in the Tcler's Chat:
Do you know if/how a script can be started with AndroWish instead of starting it with an interactive console and a tk default window?
This question has also arised in comp.lang.tcl:
https://groups.google.com/forum/#!topic/comp.lang.tcl/m9A6bWKPi_8
chw that is were the "borg" command comes into play as mentioned in AndroWish:
borg shortcut add <name-of-shortcut> <file-to-be-sourced> <png-icon-as-base64-string>
The last parameter can be left out in which case Aladdin's magic device is shown. However, YMMV depending on Android version. On my 4.x devices it worked but the opposite (borg shortcut delete) did not. The <file-to-be-sourced> must be given as an absolute path and it must be readable by the user id under which the AndroWish package has been registered by the Android installer.
ed.s - 2014-02-12 02:24:31
1.BTL/RBC, please! I would love even a partial implementation - specifically, graph, if this is easier than a full implementation.
2.I am assuming things like complex/fourier can be simply included, as they are completely self contained and require no hardware access, is this right? Still, is there a place one can place such common tools? On Linux it would be /usr/share/tcl or something similar, could we have a /storage/sdcard0/AndroWish take up the same role? This would also be a good place to contain .androwishrc, to be executed at startup, if present (default font sizes, etc.). User scripts would also be placed there, and I would also write a little script that looks through this space, finds all file.tcl (and the matching file.png, if available) and create buttons associated with launching each of these (Borg shortcut ...).
Superlinux - 2014-02-26 06:08:47 There should be a way to check whether AndroWish is installed after I made my HelloTclTk package. If it's not installed, I should be able to grab it from Google Play store. Whenever chw wants, I can let him upload AndroWish releases on my Google Developer Console account by sending me the signed released package.
In HelloTclTk.java file, the following override of OnCreate(Bundle savedInstanceState) method can be added as a checkpoint. this is not Tcl. this is purely in Java.
PackageManager pm = getPackageManager();
List<ResolveInfo> activityList = pm.queryIntentActivities(shareIntent, 0);
boolean AndroWish_is_installed=false;
for (final ResolveInfo app : activityList) {
if ((app.activityInfo.name).contains("wish")) {
AndroWish_is_installed=true;
break;
}
}
if (!AndroWish_is_installed){
/*don't forget to define in strings.xml the value "@string/You_Must_Install_AndroWish" ,
just to display the same meaning in as many languages as possible.
*/
Toast.makeText(TableOfContents.this,R.string.You_Must_Install_AndroWish, Toast.LENGTH_LONG).show();
//Let's assume that the Androwish package name is the following string
String package_name="tk.tcl.wish";
//This will open the Play Store app to the following link
Uri marketuriString = Uri.parse("market://details?id=" + package_name);
// "market://details?id=tk.tcl.wish"
Intent intent = new Intent(Intent.ACTION_VIEW, marketuriString);
startActivity(intent);
}chw 2014-02-27: good idea. The library stuff (also in Java) which is inherited by the HelloTclTk class has a static initializer which already might have detected the absence of vital native shared libraries (since it was not able to load them). Therefore code to deal with prompting the user for AndroWish installation belongs in that library, not in the APP template. But implementing that stuff is low priority on my list, since there are more problematic open ends left.
chw 2014-03-03: this is partly solved in the Pioneer 10 edition.
bmidy - 2014-02-26 08:45:09
Hi, very nice work!!
I d like to get Tix support and also BLT like another one asked.
Thanks
chw 2014-02-26: I can see benefits of having BLT for data visualization but what gives Tix when there are ttk, treeview, tktable, tklib etc. all available and ready to use?
bmidy - 2014-02-27: Hi, I d like to get Tix as I used it a lots in many of my projects, I d like to port to android.
pbb - 2014-02-27 11:01:12
I would like to have gnocl (Tcl/GTK+ bindings) package included in AndroWish. Mainly for its text widget, which can do BIDI type rendering for Sanskrit script using the Devanagari font.
chw 2014-02-27: postponed until a stable GTK port is available for Android. Better give me a pointer to a fribidi or ICU/ubidi patch for the Tk text widget.
bmidy - 2014-02-27 14:17:29
Hi, I also wanted to use your great Androwish to open serial port using a OTG USB adapter with an USB-serial adapter. so the serial port is available as /dev/ttyUSB0 but I could not use the "fconfigure -mode" command. Is there a reason ? a workaround to open serial port.
Thanks
chw 2014-02-27: probably a permission issue. Android APPs normally aren't allowed to open character devices. Since about Android 4.0 there's support for USB device access from Java code, see the pointer to the usb-serial github project above. The downside is that the entire device driver seems to require to be written in Java. Adding the usb-serial is on my wish list, but has very low priority.
bmidy - 2014-02-27 15:52:36
Also another thing that would be interesting: As I m using a SG Note 3 I get a 1920x1080 resolution which is good but all looks like very small. So it will be nice if it would be possible to have the possibility to zoom/pinch on the screen, but without additional code, I mean if it could be built-in in the "Tk/X" implementation. I do not know If my explanation is good enough, I hope.
chw 2014-03-03: in the Pioneer 10 edition fonts are now chosen based on pixel density. It should be readable on full HD displays now.
bmidy - 2014-02-27 17:10:50
Also another things that would be usefull: Associate .tcl file with the AndroWish app, so that the Androwish start and load the .tcl file. So it would be very easy to test our scripts.
chw 2014-03-02: already implemented by android.intent.action.VIEW for file URLs with any pattern and by android.intent.action.SEND for MIME type application/x-tcl. YMMV depending on Android's launcher and/or file manager.
Superlinux - 2014-03-02 09:10:20
Hi. How can I force the virtual keyboard to be only numeric, or to make the keyboard help me in typing Internet addresses ..etc?
chw 2014-03-02: This is not supported by the underlying libSDL 2.0.1 infrastructure. What about asking for this feature on http://www.libsdl.org ? Update: seems to be controllable by a simple integer mask, will try to add this in the "sdltk textinput" command.
chw 2014-03-03: in the Pioneer 10 edition that mask is added to the "sdltk textinput" command. However, the standard event bindings don't use this feature.
Superlinux - 2014-03-04 10:53:22
Well A reminder here to everyone, if you updated to AndroWish runtime "Pioneer 10 edition, 2014-03-03", then remember to update the java library of file name "tcltkapplib.jar" that comes in the HelloTclTk skeleton project. Just re-Download the HelloTclTk skeleton project from here . Unpack the HelloTclTk.zip. From the unpacking locate and copy and replace "tcltkapplib.jar" to your own project library folder named "libs".
Superlinux - 2014-03-05 14:23:45
Regarding the keyboard input type, how about making a quick command like this:
array set entry_vs_input_type { entry1_window_path entry1_input_type entry2_window_path entry2_input_type entry3_window_path entry3_input_type ... ... }
sdltk entry_input_types $entry_vs_input_typeAnd this command is used at the bottom of the script after the last defined entry. And has automatic bind <Focus> for all entries in the array.
eds - 2014-03-07 00:30:23
A very simple request: could we have another env variable under AndroWish that would tell unambiguosly that we are under Android?
On my desktop: set env(MACHTYPE) yields: i686-suse-linux
Under AndroWish it is not defined. It would be very handy to test for something like this, to make AndroWish-specific changes.
chw 2014-03-07: MACHTYPE is bash specific. Run tclsh from tcsh and you get i686. Newer AndroWishes support this construct
set android 0
catch {set android [sdltk android]}to safely find out if you're running on Android.
eds - 2014-03-07 00:43:13
A very useful feature:
BUT: it seems to override not just the defaults, but also the explicitly controlled font sizes, which messes up a picture, made with labels of a very particular size, as these labels now grow and start overlapping and make a mess of things. Pre-Edison editions worked just fine on an unedited script from Linux.
If I edit the script to scale back from 10 to 6 point font, the labels on the picture are back to normal, but if I run the same script under Linux or windows, they are way too small. Sounds like I need a system-dependent switch, or a "Auto-scale fonts" should be a selectable option under AndroWish.
chw 2014-03-07: positive font sizes are now scaled to real world points (as on UN*X/Windows/MacOSX). Negative font sizes are pixel based. If you want to control your layout on pixel basis, use negative numbers. See the Tk documentation of the font command, and play with tk scaling (which I've never tested with AndroWish).
GCS 2014-03-13
It would be nice to have events associated with the Menu and Back buttons, and the Volume Up/Down keys. Apologies if they are already there and I missed them.
PS I am really curious about the development of AndroWish--is it just a hobby, or part of your work? Do you have specific project(s) in mind? ...? Anyhow, I am very very happy you are doing it.
chw 2014-03-15: at least the Back button is mapped as keycode 270 and starting with "The Ides of March" edition as keysym Break. The volume keys aren't exposed by SDL but consumed by the system. Unfortunately I have no device with a Menu key. If you can test the Menu key with this code snippet
bind all <Key> { puts "keycode=%k keysym=%K" }a later AndroWish could provide a mapping to an X11 keysym. PS: yes, I have some commercial projects based on Tcl/Tk which I hope to port to the Android platform someday.
GCS 2014-03-15: Here is the output from hitting the Back and Menu buttons:
keycode=270 keysym=Break keycode=118 keysym=App
So it seems what I need is already there! BTW, my plan is use these events to cycle through the open windows, since my SQLite GUI can have several open, and I know of no other convenient navigation mechanism.
Thanks for your prompt response.
chw 2014-03-15: Right now, I've learned that the Menu key disappeared in Android >= 4.0 (or was it 3.0 already). Thus, I suggest only to use the Back button, if you want to ensure, that your program can be operated on all devices. Maybe some years into the future (Android 8.1 comes to mind) even the Back button will have been eliminated (and those smart little things read-ahead our minds directly using DWIWM technology ;-)
hkoba 2014-03-21
Hi. Today, I wrote a minimum patch to enable CJK input via textinput. It worked for me(but not enough tested). Anyway, without this, current AndroWish get corrupted string from input method. So, please include this into next release!
chw 2014-03-22: thank you, hkoba-san. Your patch will go into the next edition. Did you find out the purpose of the SDL_TEXTEDITING event? Is that used for CJK input?
hkoba - 2014-03-22 07:44:36
hkoba: Thank you chw! If I understood correctly, SDL_TEXTEDITING is sent by input method to inform application about current(and possible) translation result. When user hits RETURN, it became final result and application will receive it via SDL_TEXTINPUT. For more information, see SDL tutorial . From 2...4 is TEXTEDITING, 5 is TEXTINPUT, I think.
So, expected (future, perfect) behavior is "previewing such potential result as overlay on the spot of final destination".
chw 2014-03-22: I see, however (as far as I was able to type in Japanese or Korean symbols which are unreadable for me) even the Android contacts app does not use the "on the spot" preview, but instead there's a preview/selection area above the on-screen keyboard. OTOH, the SDL library supports the SDL_TEXTEDITING event on the Android platform. Would it make sense to synthesize a text selection (Entry and Text widgets) of the inserted text by SDL_TEXTEDITING so that the later commit by SDL_TEXTINPUT would first erase the SDL_TEXTEDITING selection and then replace it by its own string?
hkoba - 2014-03-23 02:41:53
hkoba: To see "on the spot" preview, you may need to change settings of input method. Under correct settings, you can see the preview in Android contact too. See these photos .
For about "synthesized text selection", I'm not sure it is good way but if is not visible from Tk widget tree(like wish console), it may be a possible solution. Actually, I'm bit curious about how other SDL apps implement this. There would be some recommended way (for SDL or Android), I guess. So, IMHO, before implementing "synthesized text selection", we would better search other examples.
chw 2014-03-23: again, I see, thank you hkoba-san. That is not quite exactly what my ASUS phablet displays when I select one of those languages I can't speak and read, but they present the preview of text input above the on-screen keybord as on your photos. So I think our best option for now is to add your patch and see how other languages (neither mine nor yours) go with AndroWish. (Poor me at school last century. Only to become another brick in the wall. Should have learned more languages many years ago :(
hkoba 2014-03-24: I agreed with your above option and thank you for including my patch. If you find problems about applying my patch, please let me know. For about another SDL exampl, I searched "SDL_TEXTEDITING" deeply on github code search yesterday, but I could find only one real use . And I'm not sure this is good example or not. (For about reading many languages, same applies to me;-) You might notice my english is strange, especially about tense. I should learn them more)
escargo 2014-04-05: It would be nice if the commands like borg were a bit more self-documenting, so that if you are experimenting with a small device where it's not practical to be looking at the documentation at the same instant, you could do something like borg ? or borg help to access subcommand summaries. APN The rest of Tcl does not have this feature (if you discount the informative error messages) so not clear why this particular command should.
escargo From my point of view, the lack of built-in documentation in the rest of Tcl is a misfeature in the rest of Tcl. While you can interactively force some of the informative error messages to be output, having useful messages come out when you request them would be far better.
Certainly it's possible to ignore this feature request; I just think it would be helpful to be able to get any command to provide some useful information when you might not have access to real documentation (because of either no access or no room to run an application to display the info.
RS 2014-04-07 Some self-documentation could be done as often in Tcl:
% info wrong # args: should be "info subcommand ?argument ...?" % info sub# unknown or ambiguous subcommand "sub#": must be args, body, cmdcount, commands, complete, default, exists, frame, functions, globals, hostname, level, library, loaded, locals, nameofexecutable, patchlevel, procs, script, sharedlibextension, tclversion, or vars % info args wrong # args: should be "info args procname" %
ET - 2014-04-15 06:01:07
At the risk of stating the obvious,
For example, all my windows systems run a socket listener that can eval whatever is sent to it This lets me mail code such as,
package require twapi ; twapi::suspend_system -state standby -force true
to remotely put a windows computer into standby. (Don't freak, this is just for my private home lan. Security by obscurity)
On Windows, or ubuntu, this is trivial to do. I'd like to do this from my samsung tablet.
So, it seems to me that all that is really required is to wrap up that helloTclTk example so it can source a text file instead of the animation it does now.
chw 2014-04-15: please don't expect AndroWish in an app store any time soon since I still regularly manage to break some binary interfaces which will make it a support nightmare when/if other packages rely on it. Putting it on Google Play or something else is on my to-do list but has low priority. You don't need ant etc. just download and install the AndroWish-debug.apk on your device (after temporarily activating development mode).
Regarding running Tcl scripts, there's the borg shortcut ... command which allows you to make an icon on the Android desktop. Technically, this is identical to wish URI-of-Tcl-script. Your other proposal is implementable by adding some Tcl to your .wishrc.
With the current (Leonhard Euler) edition, dropbear is included allowing for SSH and SFTP access on the behalf of the AndroWish package. See my example of a .wishrc on the AndroWish page.
Another possibility to remotely start an arbitrary Android activity (can be a Tcl script) is now using SSH and the am command on Android:
# start an interactive AndroWish am start -n tk.tcl.wish/.AndroWish # start the widget demo am start -n tk.tcl.wish/.AndroWishLauncher -d file:///assets/sdl2tk8.6/demos/widget -a android.content.intent.VIEW
The latter is technically equivalent what the borg shortcut places on the Android desktop. Yes, I agree with you, that this is much more to type than a simple wish widget on a normal UN*X or Windows machine, but currently I know of no other method.
ET - 2014-04-15 11:59:20
Someone once said to me, if it's truly that easy, then you should be able to tell my dog how to do it. Joking aside, the absence of a short complete step by step installation guide in a nice pretty box at the top of the main androwish page is kinda telling here.
It seems the goal, for now at least, is to provide a framework so app developers can write apps for android using the androwish base. That is a worthy goal, but if it were me, I'd reverse my priorities.
There's likely many more end users who might want to write a few handy scripts for themself. That's me - I only just bought my first tablet computer a week ago and It's frustrating not to have tools like tcl/tk that are normally at my fingertips.
But oh that app store! That's what sold me. To me, this is as important to user friendliness as the GUI was to the command line. I still shiver every time I have to install something on my windows computers. But any idiot with a phone knows what an app is. And they love how you buy them - like buying a song on itunes, only easier.
So dreaming ahead to a play store app, ... if .wishrc is to tcl like .bashrc is to bash then a line like this would suffice.
if [file exists $startupFile] {source $startupFile}All you'd need to do was explain where this file is and how to edit it. Maybe a little default startup script that brings up a screen with a handful of buttons to launch the other sample scripts. Something very simple to get people started. Think to the user, not the developer here.
There's no reason why there can't be an Androwish lite as well as developer versions. I think a lite version is within reach. Wouldn't you just love to see the app pop up in the store saying 1,000,000 downloads. Think of what that would do for our favorite computer language.
chw 2014-04-15 14:38:07: to somewhat quote Leonard (Bones) McCoy (not Euler): I'm a developer and not a marketroid. Really. If you have a nice startup script (btw $HOME/.wishrc is the path name of that startup script as in a normal interactive wish on UN*X or Windows) what about publishing it here on the wiki? And, yes, that file is really in the same place as on UN*X or Windows, see AndroWish: Documentation for the environment variables.
Although I've spent many days (and nights) now on developing it further, I still don't have the feeling that it is ready for prime time yet, despite the many millions of smartphone and tablet users awaiting it eagerly. Please, be a little patient.