I have a Tk UI which when executed on different linux machine comes up with different UI. I checked tcl version is 8.6 for both platforms.
The UI looks like this.
invoke method : tclsh script name.tcl
I wanted to use 1st one as its more graphical and fonts are readable.
Can you point me to check what is the difference in the tcl version installed on machine B. I assume Tk package could be different, but i dont know how to check.
I think tk still uses good ol'resource databases for X11, which may be different on each platform. Check xrdb(1) for this. Also read ttk::intro(n) and ttk::style(n) to read about ttk widget styles.
System wide defaults go to
/usr/lib/X11/app-defaults/∗ Client resource specifications.
or similar (check /etc/X11 and /usr/share).
In your home directory there may be .Xdefaults for user specific defaults.
But the fonts are selected through fontconfig, which has other default directories. Check /etc/fonts.
Related
My tcl platform(osVersion) is v6.2
% puts $tcl_platform(osVersion)
6.2
How to downgrade tcl_platform(osVersion) to v6.1?
Thank you.
I try to find activetcl v8.5 on internet but the old version all links are invalid...
That value, which describes the version of the operating system that is running the script, is read out of a platform-specific location in your OS during the initialisation of an interpreter (technically, it is copied from data determined during startup of the first Tcl interpreter in a process, where that data is held in a location invisible to you). It is then free to be read or altered by your code... with whatever consequences that may entail.
Permanently changing that value is done by changing what OS is installed. That's totally out of scope for what an ordinary user script can do!
Tcl's implementation mostly doesn't use the OS version. It cares far more about whether API capabilities are exposed to it, and those are almost always at the more granular level of general platform (or transparently adapted around).
Note: this is not a dupe of this or this other question. Read on: this question is specific to the Code-Sharing template.
I am doing some pretty basic experiments with NativeScript, Angular and the code sharing templates (see: #nativescript/schematics).
Now I am doing some exploration / poc work on how different "build configuration" are supported by the framework. To be clear, I am searching for a simple -and hopefully official- way to have the application use a different version of a specific file (let's call it configuration.ts) based on the current platform (web/ios/android) and environment (development/production/staging?).
Doing the first part is obviously trivial - after all that is the prime purpose of the code sharing schematics. So, different versions of the same file are identified by different extensions. This page explain things pretty simply.
What I don't get as easily is if the framework/template supports any similar convention-based rule that can be used to switch between debug/release (or even better development/staging/production) versions of a file. Think for example of a config.ts file that contains different parameters based on the environment.
I have done some research in the topic, but I was unable to find a conclusive answer:
the old and now retired documentation for the appbuilder platform mentions a (.debug. and .release.) naming convention for files. I don't think this work anymore.
other sources mention passing parameters during the call to tns build / tns run and then fetching them via webpack env variable... See here. This may work, but seems oddly convoluted
third option that gets mentioned is to use hooks to customize the build (or use a plugin that should do the same)
lastly, for some odd reason, the #nativescript/schematics seems to generate a default project that contains two files called environment.ts and environment.prod.ts. I suspect those only work for the web version of the project (read: ng serve) - I wasn't able to get the mobile compiler to recognize files that end with debug.ts, prod.ts or release.ts
While it may be possible that what I am trying to do isn't just supported (yet?), the general confusion an dissenting opinions on the matter make me think I may be missing something.. somewhere.
In case this IS somehow supported, I also wonder how it may integrate with the NativeScript Sidekick app that is often suggested as a tool to ease the build/run process of NativeScript applications (there is no way to specify additional parameters for the tns commands that the Sidekick automates, the only options available are switching between debug/release mode), but this is probably better to be left for another question.
Environment files are not yet supported, passing environment variables from build command could be the viable solution for now.
But of course, you may write your own schematics if you like immediate support for environment files.
I did not look into sharing environment files between web and mobile yet - I do like Manoj's suggestion regarding modifying the schematics, but I'll have to cross that bridge when I get there I guess. I might have an answer to your second question regarding Sidekick. The latest version does support "Webpack" build option which seems to pass the --bundle parameter to tns. The caveat is that this option seems to be more sensitive to typescript errors, even relatively benign ones, so you have to be careful and make sure to fix them all prior to building. In my case I had to lock the version of #types/jasmine in package.json to "2.8.6" in order to avoid some incompatibility between that and the version of typescript that Sidekick's cloud solution is using. Another hint is to check "Clean Build" after npm dependency changes are made. Good luck!
I am creating a kbskit for my tcl executable application as follows on Suse :
./kbs.tcl -builddir=85 -r -mk-bi -bi="itcl3.4 itk3.4 iwidgets4.0.2 img1.4.1" install kbskit8.5
cp 85/bin/kbsmk8.5-bi kbsmk8.5-bi-run
./kbsmk8.5-bi sdx.kit wrap sim -runtime kbsmk8.5-bi-run
The application will be used on several flavours of linux like Redhat,Ubuntu etc. I am trying my best to test it myself under many combinations. Neverthless, i would be like to know someone thinks this would/wouldn’t work seamlessly across different platforms since I wont be able to cover all combinations exhaustively.
A Linux/x86 kbskit is at least reasonable to run on that collection of platforms. Unfortunately, the only way to be sure is to try. It should work, but if your script refers to files in a particular location and another platform (or deployment!) puts them elsewhere, then things will fail. The other thing that might go wrong is if there are significant incompatibilities in the small number of system libraries that Tcl uses, especially the C library; I do not know whether such problems exist, but I suspect they're not a major problem in practice.
You can try using the platform package (a standard part of Tcl since at least 8.5) to report what platform you're dealing with. That's the usual level of granularity you need to pay attention to.
package require platform
puts [platform::identify]
Are there any particular things to think about when building and installing (globally) a new version of Tcl from source, besides relinking /usr/local/bin/tclsh and wish to the new versions?
I know that the interpreter executables tclsh and wish are installed with different names, but what about the include and library files? When I build eggdrop, will it link with the latest version? How about the man pages - are the old ones overwritten by the new ones?
The usual approach for this case is to configure the build so that it's installed under a single directory (the Windows approach), say, under /opt/tcltk/8.6. You're then guaranteed against clashes with other versions and deinstallation is a matter of running rm -rf on that single directory. This approach has its downsides though:
You'll have to link (some) installed third-party Tcl libraries under your new hierarchy. This is because Tcl derives the set of paths to look for libraries from its own location.
/opt/tcltk/8.6/bin won't be listed in $PATH.
With certain OSes, another (possibly more sensible) approach is to do a "backport", that is, to take the source package of the required Tcl/Tk version and make it build for the installed version of the OS; then install the resulting packages in a normal way. On systems where various versions of Tcl/Tk are co-installable (for instance, Debian and its derivatives), this possibly provides the most sensible solution.
As to manual pages in the latter case, in Debian, they just end up being packaged in a separate package, installation of which is not required; so you just select one of the available documentation packages and install it.
In terms of having multiple versions present, this is a normal thing to do (do this by setting the --prefix option to configure when building) and has been so for quite a while. You'll probably want to avoid having multiple patchlevels of a single version if you can, but having, say, 8.4, 8.5 and 8.6 co-installed is entirely OK. You'll want to have the different installations in different directories too, and you're right about linking the unversioned tclsh name to the one you want normally (though I just use the versioned executable name instead).
The only way to have the manpages coexist nicely is to have them installed in separate directory trees and to update the MANPATH environment variable to point to the right one (unless you've got a man executable that will take paths to manpages directly — some do, some don't — and that is hardly as convenient). If you can bear being online, we've got official HTML builds of the documentation hosted at http://www.tcl.tk/man/ which includes all significant versions going back quite a long way.
I am in the process of building interactive front-ends to a
distributed application which to date has been used to run workloads
that had a batch-job like structures and needed no UI at all. The application is mostly written in Perl and C and runs on a mix of Unix and Windows machines, but I think this isn't relevant to the UI.
The first such frontend is going have a command-line user interface --
currently, I envision something similar to the CLIs of the Procurve
switches and Cisco routers that I have worked with.
Like modern network gear CLIs, commands are going to resemble
simple sentences, (i.e. show vlans ports 1-4) and the CLI will
have some implicit state, much in the way that Unix shells and
cmd.exe in Windows have environment variables and current working
directories. Moreover, I'd like to implement great tab completion that
is aware of the application's state as much as possible and I want to be able to do that with as
little application-specific code as possible.
The low-level functionality (terminal I/O) seems easy to implement on
top of GNU Readline or similar libraries, but that's only where the
real fun starts. So far I have looked at the Perl modules
Term::Shell
and
Term::ShellUI,
but I'm not convinced that I want to use either of them. I am still
considering rolling my own solution and at the moment I am primarily looking for
inspiration.
Can you recommend any application or library, regardless of
implementation language, that implements a good CLI from which I can
borrow ideas?
I suggest you take a look at the philosophy underlying Microsoft PowerShell. From the idea of piping typed objects between commands to the consistency of its commands and argument syntax, I think it can be a source of inspiration.
You could try having a look at libcli :
"Libcli provides a shared library for
including a Cisco-like command-line
interface into other software."
http://code.google.com/p/libcli/
BTW - I forgot to mention that it is GNU Lesser GPL and actually used by Cisco in some products.
As for your last sentence/question, I'm particularly fond of zsh completion and line editing (zle).