Updated 2015-09-02 17:53:45 by pooryorick ▲

Larry Smith weeapps - or perhaps @apps?

A forum for discussing the optimal selection of built-in applications for inclusion in the weedesk environment.

Larry Smith 12/31/04 - I have tidied this page into a rough spec for the initial suite of weeapps I'd like to see WeeDesk have. I have removed some attributions when I "adopted" the suggestions into the spec - I did this to make it easier to read and the contributors know who they are (and they will, I am sure, appear in the "about" boxes for the various weeapps). But everyone should remember - this is a group effort. Feel free to dig in.

If you want to discuss any of the following, put attributions in, I will re-edit and consolidate this page from time to time. If you wish the conversation to remain forever, put it on a separate page and link to it.

The objectives here are:

  • one program, one job - MSWord is an example of an app that has grown wildly out of control until it has been buried under so many bells and whistles it is nearly impossible to use it for basic editing - the original job it was intended for. In fact, it has strayed so far that MS has actually begun to bundle little apps like Notepad and Paint with the OS because their primary tools are total overkill for the typical user. Word itself is no longer really capable of just editing an ascii file.
  • easily extensible - Tcl should be visible and accessible in any app to extend it or script it. Since the whole weedesk idea is aimed at your basic, non-expert user who may never have programmed before, it is important to make Tcl more orthogonal and refine away some of the cruft it has picked up through history. See Tcl/2.

The following is the basic target list for needed weeapps:

  • weeFile - a really easy-to-use file manager, maybe something that looks like the Windows Explorer, or Konqueror in local file mgmt mode, but without all the excess baggage.
  • weeDraw
  • [weeOutline] - essentially tkoutline
  • weeEdit is used for all text editing
  • weeSpread is the spreadsheet
  • weeCalc is the desktop calculator
  • [weePage] is a page layout app - takes text from weeEdit files and allows you to insert them into a printable page - there would be no "weeWord", just weeEdit and weePage, which together serve the same purpose. This app would likely use HTML as an internal file format allowing the document (sans paging) to appear on the web effortlessly.
  • [weeCard] A HyperCard-like app providing a simple way for people to create new, specialized apps for their own use (and to extend and add value to weedesk.
  • [weeBrowse]
  • [weeMail]
  • [weeProg] (an IDE/debugger/compiler for developing scripts)
  • [weeData] (the database)
  • [weeChat] Chat client (not to be confused by this weeChat http://weechat.flashtux.org/)
  • weeWeb A small httpd server that can be added to scripts to present a webstyle interface
  • [weeBase] - A simple plug-in-your-own backend (Metakit, sqlite, ODBC) database manager. What I'm thinking of here is something in the spirit of the old PC File of the late '80s, but where you can just menu-select which DB engine you want it to use. The initial target would be Metakit.
  • [weePaint] and weeDraw Drawing packages, perhaps based upon enhancements to Impress [1]. Output is intended for weePage to produce presentations.
  • [weeDate] - PIM-oriented calendar appt. db
  • [weePhone] - PIM-style phonebook
  • [weeMsg] - IM client
  • [weeRSS] - A simple RSS viewer/archiver
  • [weeVNC] - an SSL-enabled VNC client/server combo
  • [weeFTP] - an FTP client (that would seamlessly integrate with weeVNC, of course)
  • [weeTerm] - a Telnet client/tkcon combo
  • weeSpool - a universal print spooler that all weeapps can print to, perhaps implemented as a Tcl servlet on weeWeb
  • [weeComms] - a set of network comm services to provide data synchronization Tequila, RPCs dp_RPC, etc.
  • [weeRecorder] - a session macro recorder, to provide the ability to record and play back streams of user events for any weedesk session. This starts out as a tool for regression testing, but it should also serve the user as a means of adding macros to the system for any function the wish to add.

and, finally, the most important weeapp of them all ;)

  • [weeSolitaire]

A few others it would be nice to think about, but which are not part of the 1st cut:

  • weeRogue - multiplayer?
  • weeBurn - CDs/DVDs
  • weePlay - mp3s/ogg/etc
  • weeTV - TV player
  • weeCam - digital camera tool
  • weePDF - PDF viewer
  • weeScan - scanner tool
  • weeMix - sound source and volume

In generally these will be new apps written from the ground up, but they will crib shamelessly from pre-existing tcl apps. The overall design objectives are:

  • small is good (most functionality for least lines)
  • 90% solutions - these are light-duty apps that provide the smallest, most heavily-used subset of the features of their prototypes. Features that everyone will use every day are in. Features used once in a blue moon by a left-handed baboon in heat with an abcessed wisdom tooth are out. These apps should never, ever have to shorten menus to hide complex functionality. The tiny minority of people who need such features should use OpenOffice, or whatever.
  • Consistent user interface is crucial.
  • web-based delivery - packages providing applications or libraries should be available via the web and weeapps should not attempt to use packages that cannot be found this way. The method used to access these packages/apps/libs should check signatures. (Isn't there a new algorithm out that allows checking sigs without needing a signing authority?) We are dealing here with portable executable content - without some real thought we could be adding Windows major headaches to Linux.
  • miserly with screen real estate.
  • weeapps may also make use of signed extension packages that can be safely loaded from web sources. These will be loadable into the basic execution environment along with the weeapps themselves.

Tools already "out there" that will be crucial:

  • Tequila seems a good choice, simple and lightweight, ideal for use in a wee environment.
  • dp_RPC lightweight rpc capability

Notes:

The idea is to try and come up with a clean loosely-coupled structure between a presentation layer (window manager) and individual apps. Light enough to easily tie into numerous small single-file scripts. After all, there is an immense choice of those on this wiki already. Basically, an application ("weelet"?) asks for a top-level-ish window, and gets a Tk frame back with which it can do anything. Whether all apps run in a single interpreter or not, whether there is threading, whether there are networked sessions (or TkVNC) - all that is none of the apps concern. A very simple set of alternate commands could be used to run such apps in a classical Tk toplevel window, i.e. outside the weedesk system. It may be an idea to latch onto Tile as well, now that it is starting to really fly.

Another point to bring into the mix is embedding. There are a number of TCL apps that perform functions that would be useful to have as a function of a much larger application. This has brought to mind an API for embedding applications. Much like starkits look at the way they are invoked to determine what initialization is performed, so would a [weeApp]. To make this easy there needs to be a simple way for the application to know what toplevel to use to contruct it's main window. As well as the allow embedding application to access appropriate data from the embedded app.

The following is 1st cut at this:

  • Every WeeApp defines an "app-command" (think "object command").
  • To run that as an application, evaluate the app-command with subcommand application.
  • To use it as a service, use other subcommands of the app-command.
  • There might be some standard commands for things like getting a list of the services provided.
  • The WeeApp returns the name of its app-command when sourced (return value of source). If a WeeApp is reentrant, then sourcing it again may return early after merely creating a new app-command.

Category Community