[[Note: This is not a well-structured page, as I'm just dropping this all in here so it doesn't get lost and forgotten. It can be made to look nice later by someone with better aesthetic sensibilities.]] [Larry Smith]: check out [weeDesk]. Last update: 2008-05-30 (see bottom). ---- On comp.lang.tcl, Victor Wagner wrote: Now, I'm suggesting a technical challenge for people who want to get Tcl into headlines of computer-related news: Write a desktop environment in Tcl. If it is properly done, we'll get something uncomparable with [Windows], [KDE], and [MacOS] - an easily extensible desktop environment, where user has powerful scripting language at his disposal. With Tcl introspecting capabilities it is even possible to write RAD tools which would allow to do nontrivial scripting by drag and drop, and resort to typing commands in to enhance drag-n-dropped prototype. So we should write fully scriptable suite of components, which would allow GUI user to extend and tune his environment even simpler than a command-line [Unix] user can tune his environment using [shell]/[perl]/[tcl] scripts, aliases and such. We already has almost all necessary components - web browser (BrowseX), spreadsheet (Abacus), window manager (tkwm) etc, etc. We also have ways to integrate traditional [Unix] tools into our graphic apps (expect) All which is needed is to write proper integration framework. It is sufficient to run all the components of desktop in single nonthreaded process. [MacOS] did this for decades, and most users were satisfied. No [CORBA] would provide anything similar by flexibility to interface, Tcl extension mechanism is providing. But of course, [CORBA] should be supported to communicate with foreign apps. But we also have powerful means of interprocess communication (Tk [send]) which allows communication even between programs running on different machines, as long as they are on same display (which is proper desktop approach, I think). So project may be finished with fewer man-months than it is already invested into [KDE] or [GNOME]. ---- What we have: * Web Browser: [BrowseX] [http://www.BrowseX.com/] * Spreadsheet: [Abacus] [http://www-cad.eecs.berkeley.edu/HomePages/aml/abacus/abacus.html] * Window Managers: [Tkwm], Panache [http://www.xmission.com/~georgeps/panache/] * Text Editor: [Tcl Editors] * Text Editor: David McClamrock's WISH [Supernotepad]: http://www.geocities.com/pa_mcclamrock/ see -> supernotepad.tar.gz *** * Text Editor: [vim] is an obvious candidate. [emacs] and others also support Tcl, to varying extents. * Larry Smith's Tcl Tools [http://www.smith-house.org:8000/open.html] * Miscellaneous tools and toys: People reading this are requested to add any "little things" they know of to the list. Calculator tool, digital and analog clocks, what-have-you... [aqtools] has all sorts of desktop adds - editors, help systems, abbreviation managers, visual more, preference editors, etc. * Larry Virden's TCL FAQ has an application list here: [http://www.purl.org/NET/Tcl-FAQ/part4.html] (many of which are actually wiki pages here on this site) * [TkDesk] [http://tkdesk.sourceforge.net/] * [TkWorld] http://www.tkworld.org/ *** [D. McC]: I've also written a very simple program launcher, WISH Command Center, available here: http://www.geocities.com/pa_mcclamrock/ see ->wishcom.tar.gz *** '''What we need:''' * volunteer to head the project. * A list of what's needed. I would like to see a desktop development framework provide: 1. Cross Platform support! The desktop works on the various platforms where Tk works. 1. IntraApplication communication - some kind of easy to use framework so applications are ready to talk to one another with minimal effort by the developer. 1. InterApplication communication - some mechanism for applications not developed specifically for the desktop to be included in the fun. 1. InterPlatform communication - the ability to talk to apps running on other platforms. This provides enterprise extendibility. * A list of things that might fit things we need. * A list of things we'll need to write ourselves. * volunteers to work on the projects. * the projects. ---- Anselm Lingnau said: It's true that there are lots of pieces around. However a »desktop environment« to rival the likes of KDE would probably require more consistency between the individual pieces, not only as far as the »look and feel« is concerned, but also for smooth interoperability. It would be nice to have an »application framework« that would make it easy to generate the skeleton of a »desktop-ready« Tk program. Right now there is quite a lot of drudgery required to set a program up with a menu bar, »help« menu, toolbar et cetera (»drudgery« from the point of view of a Tcl programmer -- it is still a lot more straightforward than with other toolkits). It would be nice to be able to say something like package require tkapp set menu { File { command &New [list newCmd] command {&Open ...} [list openCmd] command &Save [list saveCmd] command {S&ave As ...} [list saveCmd -ask] - command &Quit [list quitCmd] } Edit { ... } } set toolbar [list [tkapp::tbicon new] newCmd [tkapp::tbicon open] openCmd ... ] set about { Foobar 1.0 by J. Random Hacker See http://www.foobar.org/ } tkapp::create -name "foobar" -title "Foobar" -icon foobar.xbm \ -menu $menu -toolbar $toolbar -about $about \ -manual [file join [file dirname [info script]] doc] where the »tkapp::create« procedure does all the work of installing the top-level menu, toolbar, »About« dialog and link to documentation viewer, reads the resource file(s), sets the main window title and so on. This would go a long way towards enabling a common look-and-feel for Tk »desktop« programs, since suitable definitions could be pulled in without making extra work for the application programmer. It would even be possible to make use of, say, existing KDE preferences files to find out about global settings for fonts etc., the way Ktk does this. In any case, the »tkapp::create« procedure could also try to do the right thing on other platforms such as KDE, GNOME or Windows. ---- One thing to consider is the [Visual Tcl] (vtcl) (http://vtcl.sourceforge.net/) framework - does it (or could it) provide some of the facilities mentioned above? ---- One feature often provided in a desktop environment is a file manager. One I have used on a variety of systems is [X-Files] [http://www.hut.fi/u/mkivinie/X-Files/]. I have not seen any signs of recent development (like this century), but I used the version 1.43 on a variety of systems. There is also [FileRunner] [http://www.cd.chalmers.se/~hch/filerunner.html], but I have never used it. David S. Cargo (25 Sep 2002) [GPS]: When I first started using Linux (Redhat 5.2) FileRunner was great. It has a lot of features, and of course is written in Tcl/Tk. It's fairly easy to modify too. I haven't used it in years, because I now use terminals for almost everything in Unix, but I still recommend it. [D. McC] I agree. I've used FileRunner since 1999. It's the fastest and most comprehensible file manager I've seen on any operating system. ---- Does a brand new desktop environment need built - one that works cross platform? Or is it more important to work on integrating Tk/Tcl better into the existing desktops, given that right now people complain about the behavior and look of tcl/tk on [gnome], [kde], MacOS X, Windows XP, etc.? ---- There is no way that we can compete in this space. The number of committers to Gnome and KDE is probably larger by an order of magnitude than to Tcl, Tk and the projects that comprise the "activestate distribution". The most sensible thing is, as the above comment states, to try and integrate with existing environments in order to take advantage of the huge amount of work they have done. ---- '''2004-08-28''' [SRIV] I dissagree. The RAD nature of tcl empowers the developer to create powerful apps in 1/10 the time. Other than having to play catch-up with other desktop environments, a tcl desktop would have a significant advantage. By utilizing the "app framework" methodology, integrated apps could be easily created or converted from old apps. This project has a lot of potential and should not be discounted so easily. I can imagine a tcl desktop stored on a [USB] keydrive that runs on top of any windows/linux window manager, which gives a unified set of apps and functionality. Try that with KDE or Gnome! ---- '''2005-03-02''' [Rildo Pragana] I think it is very viable to have a tcl desktop (with the help of a small extension). I'm still doing some experiments, but you can already see what my experiments have led me to, at http://pragana.net/ and grab a starkit of it for Linux. It will feature a file manager, taskbar, desktop, fancy root menu, and (not yet started) a window manager. The source of the small C extension is also inside the starkit, so use "sdx" to access it, or the included file manager (browse into the virtual directory with the name of the executable). ---- '''2008-05-30''' TclTk-D or '''TkD''' : I have (been) challenged writing an tcl application (since 2003 mainly for privavte use),which should be a standalone desktop-environment. Try it!(but may be buggy) at: http://members.jcom.home.ne.jp/tcltk-d/ (TclTkdWrap.exe 1,985Kbytes 2008/5/30 for Windows only) * No complexed installing operation. Just execute it. * Simple and unique window style,without ugly frills. * Based on standard Tcl/Tk(8.16),and wrapped by Tkwrap of [WinTclTk]. * Web and/or Multimedia contents can be handled by [optcl]. ''[escargo] 30 May 2008'' - I ran into a problem: ====== wrong # args: should be "Retreive file ?pg? ?mode?" wrong # args: should be "Retreive file ?pg? ?mode?" while executing "Retreive C:/Documents and Settings/David Cargo/My Documents/My Downloads" (menu invoke) ====== At a guess, a file name with spaces isn't being properly handled by menu invoke. ----- Yes,It shoud be put in some Simple path,like C:/Programs/Tcl, E:/TclTk in usb,... ---- * [WISH Command Center and WISH Mini-Console] ---- !!!!!! %| [Category GUI] | [Category Desktop] |% !!!!!!