A forum for discussing the optimal selection of built-in applications for inclusion in the [weedesk] environment. ---- [Larry Smith] suggested the following (listed here so we can start fleshing them out): * [weeEdit] is used for all text editing * [weeCalc] is the spreadsheet * [weePage] is a page layout app - takes text from weeEdit files and allows you to insert them into a web page - there would be no "weeWord", just weeEdit and weePage, which together serve the same purpose using [HTML] as an internal file format. * [weeBrowse] * [weeMail] * [weeProg] (an IDE/debugger/compiler for developing scripts) * [weeData] (the database) * [weeChat] * [weeWeb] httpd I'll ([MDD]) add: * [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. * [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. * [weePre] - A presentation graphics/drawing package, perhaps based upon enhancements to Impress [http://www.ntlug.org/~ccox/impress/] * [weeDate] - PIM-oriented calendar appt. db * [weeIM] - a Jabber-compatible 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] * [weeOutline] - this would just be [tkoutline], adapted to whatever standard configuration the weeDesk project settles upon. (''I do so much of my work in programs like TkOutline, I just couldn't do without the same when working in weeSpace - [MDD]'') Additional suggestions: * [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. ---- [NEM] '''18Jan04''' A few comments. Firstly, are these intended to be new apps written from the ground up, or are you planning to use existing solutions (with maybe some minor modifications)? For instance, while weeWeb could be a fun project for someone, [tclhttpd] is already a very good webserver, which should probably be reused. Similarly for the others, there are probably decent existing Tcl/Tk implementations of most of these apps already out there. Secondly, a particular point on weePage. I'm not entirely sure what you are describing here. It seems that you would take plain text from weeEdit and add styling to it by encasing it in html. Would this be html+[CSS], or just html (with tables, font tags and other ugliness)? Finally, the name wee''Page'' is slightly confusing. It implies (to me) a page layout program (i.e., for printed output), whereas html has no concept of ''pages'' in the sense of A4 etc. So, it needs to be clarified what the usage of "page" is in this context - a webpage, or an actual page. If actual pages is being suggested (like a traditional word processor), then I would suggest going with a different format than html ([Postscript]? [RTF]?). [MDD] '''18Jan04''' Adapting existing solutions certainly seems the best way to go, where possible. [Larry Smith] '''19Jan04''' Adapting existing code should be the rule, but consistancy of user experience is crucial, so most of the existing programs would likely need to be modified. Also, some apps are way overkill, not appropriately ''''wee''''. We might want to recode some to simplify. (WeeEdit may be a case in point, none of the ones I've looked at seem aimed precisely at the kind of demographic I envision, which would be much like nedit.) ---- [RJ] '''18Jan04''' Something that appears missing from almost every UNIX platform - a Macro recorder and playback for automating tasks. An example would be bringing up an app, clicking on a button or two, entering some data from the keyboard, then clicking a button and closing the app. Should be application independant. Basically, record the mouse and keyboard events to a file, then replay them whenever the file is played back. Is this do-able? [Larry Smith] '''19-Jan-04''' Absolutely. [TKReplay] is probably the best start here. If we keep the system tcl-centric, we won't have to go to the event-level with [android] - which is good because android just '''won't''' run on Windows. [SRIV] '''18Jan04''' So far it seems everyone is on the same track here. I have many small apps that I could rework to fit this schema, most were designed for Linux/Win/Arm when extensions are involved. I want to mention [Mark G. Saye]'s [Pocket Tcl Environment] project on Sourceforge as a precursor to this discussion. Tcl/tk has never had a big following on the Linux iPaq, so Mark's efforts, and mine, have been single-handed projects, But, when we start talking Desktop/Handheld/Windows/Linux/PPC I think there will be more interest. I program in tcl/tk specifically to get cross-platform capabilities. It may be interesting to see a 5-line web browser that uses [tcom] to launch IE in Windows, but it has no real value outside the small realm of Windows. (In case you missed it, that was a rant.) [Larry Smith] I see where you are coming from, and I totally agree. I would like weeDesk to take its role as the basic common denominator for all knowledge workers on all platforms seriously. To run in tiny environments (which by rights anything calling itself "wee" should), it needs to be lightweight, and use as little screen real-estate as possible. [SRIV] '''18Jan04''' Inter Process Communication. Could each app include comm so that apps can exchange data via some networked messages? I thinking of something simple. Comm can be sourced into an app and not used by it, but, external apps could access data in it. Perhaps the send command will suffice, now that Windows support is here. [Larry Smith] Graceful, integral, IPC is something that will surely be needed. [Tequila] seems a good choice, simple and lightweight, ideal for use in a wee environment. [jcw] - FWIW (i.e., in the "toot my own horn category"): if the world is Tcl, then to me [Tequila] remains as before a viable option (with or without MK backing store). Haven't done much with it lately, but Tequila seamlessly bridges comms from within a single interp to across machines via sockets. The model is "shared global arrays", i.e. nothing new to learn. ''[MDD] - Agreed, wholeheartedly! Tequila is still the easiest way I've found to do data synchronization across the net. Also, [dp_RPC] could provide a lightweight rpc capability'' [Larry Smith] Yup. [MGS] '''18Jan04''' Wow. A mention of "Pocket Tcl"! Thought I'd better respond ... The [Pocket Tcl Environment] project has been dead for a long time. In fact, I had hoped to have its replacement(s), [eWidgets Toolkit] and [Mogul] released by now, but alas not yet. Things have slowed down considerably, but I am keen to pick things up again as soon as time permits. Actually, I see a lot of crossover between what's being discussed here and my plans for [Mogul]. Maybe I should try and describe some of the components of Mogul. Unfortunately time is really tight right now as I'm busy with a big PHP website project. [Larry Smith] I have hoping to see this project revitalize Pocket Tcl. I want to be able to run this environment on my Linux, Windows and Palm. [NEM] '''18Jan04''' By the way, I have been planning for a while to write an xml/html editor based loosely on editors like XMLMind[http://www.xmlmind.com/xmleditor/]. It would basically allow a word-processor--like editing environment for xml documents (e.g. xhtml or docbook), using the text widget to display/edit. It would be possible to assign text widget tags to xml-tags so that different tags could have different visual styles. I might also make it understand a subset of [CSS] for specifying this visual design. This may tie in with weeEdit/weePage. I'll hopefully have some code in the next week or so, and I'll make a wiki page when I do. This combined with the stardom xml-tree view could be quite a nice authoring environment. [Larry Smith] You have precisely the idea. [NEM] '''19Jan04''' I've actually started work on an editor that should be a bit more powerful than this. I'm using a Model-View-Controller design. It's being written in [snit] at the moment. Each file type (distinguished using a mime-type like notation) has a document model associated with it (implemented as a snit type) which supports some basic methods (creating, saving, searching for a string etc). Then there are views, which operate on particular document types. The application itself is just a wrapper which connects documents to views and provides menus, dialogs, key bindings etc. I'll sketch out the details at [ArTcl] (which is the name I've given to the project which this is intended to become part of). [SRIV] '''20Jan04''' I just tried tequila and I have to say it put an evil smirk on my face. Well done [JCW]! I can't think of any reason why we would need to actually exec code on a remote interp if we have a shared bundle of global vars to toss around. Im interested in how we will layout the shared vars to accomplish tasks in a uniform fashion. After a plan is agreed on, let's all pick an app to throw into the pot. In the mean time, we can further discuss the window management features and functionality. As an example, let's say I add tequila to my calulator app, and share its result var globally. How would we like the apps to exchange data? [Drag and Drop]? ^c & ^v ? Obviously we need to pick a mouse/key transfer mechanism to initiate the move or create a permanent link-up. Any thoughts? ---- [schlenk] For the weeMail app, i think [IMAP] would more or less be a requirment if this is going to be a portable desktop, but there isn't a pure tcl imap implementation yet.Any volunteers to do such a package? ''See http://expect.nist.gov/tkbiff/ - it appears to do IMAP in plain Tcl...'' tkbiff does a subset of imap, only the very basics. ---- [AM] For the "Young programmers' project" I have elaborated code from Will Duquette with a similar yet more restricted goal in mind. Some of that could be used here - or better still: I could use one or two applications from this forum. One thing I have achieved - elaborating again somebody else's code, here on the Wiki - is a smooth printing of text files. ---- 06oct04 [jcw] - To try and crank the handle on all these wee* pages ([weeDesk], [weeApps], [weeEdit], etc) and get some neurons firing again, it would be nice to have a good project name to do everything under. Was thinking along the lines of "weestar" or "starweed" or something, but I'm hoping some native English speakers will join in to make sure the name has the right connotations. No big deal. 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 interpeter 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. ''It all just needs a name/handle to get started. GooWee? Heh :)'' ---- [Category Community]