[ Home | Screenshots | Download | History ]

0.62	t.b.a.	Getting Better!
(I've scrapped the 3-tier junk from 0.61. It was just not the correct direction for this project, and tended to overly complicate things. In this release, the sources are divided up into modules, some of which reside in the Infusion Kernel, some of which reside in dynamically-loadable modules, etc. This will be a very powerful API once I get it hashed out a bit more...) Yet Another Re-Architecture. This one will be the last, I promise. Added support for driver modularization. This means that Infusion can connect to multiple services simultaneously! POP3, SMTP, Citadel/UX, and KAB are the first drivers I've (mostly) implemented. Extreme reworking and refining of the user interface is finally bringing the client up to Usability Par. We're almost to the point where I think an Outlook user could potentially sit down and use it (if it weren't for all of the missing features and empty menu hooks, that is). Added the Infusion Account Wizard to help users make sense out of this new configuration and kernel nastiness.
0.61	2001-09-11	Major Improvements
(Another re-architecture bringing Infusion into more of a 3-tier approach. This has been completely scrapped, as there was too much overhead involved in doing plain things.) Improved DCOP communications layer in infusiond (The Infusion Daemon). Can now obtain folder index and message list Can deliver messages via dcop Can load Sticky Notes via dcop Rewrote DCOP layer in a more KDE-standard way (but the whole object schema for infusiond still needs work...) Improved user interface. Concentrated on making the WndMain::View menu more functional. User Interface now saves the position and visibility of every item in WndMain, hopefully allowing users to customize Infusion to meet their needs a little bit better. Removed KOrganizer code. Am working on incorporating its KParts object... (Not perfect yet) Significantly improved operating speed. Many elements are cached, greatly improving refreshes and other annoying hangs in previous versions. Cleaned up the code somewhat (still needs plenty 'o work...) Added more extensive cache management subsystem, to help Infusion become MUCH more responsive to general navigation. It isn't perfect yet, and it may eat up gobs of memory, but I hope that it eventually proves to make Infusion work better. Tried to make infusiond DCOP interface compatible with as broad a range of 2.x KDE systems as possible. This precluded the use of the "long unsigned int" type (at least, until I figger out what the KDCOP construct for it is... ;) Working on creating a rudimentary Contacts list. This is much harder than it sounds! Zounds! :)
0.60	2001-06-12	Serious Bugfix
Fixed massive memory leaks in the previous release. Slapped mine own hand for writing such sloppy code. (Note that this requires an upgrade of libCxClient to 0.10-RELEASE) Fixed location and slight appearance enhancement of splash screen. Whoopee! Bugfix - Leaky Infusion Daemon. Yuck!
0.59	2001-05-14	Major Changes
Note: This release is very unstable, for various reasons. It (hopefully) will not be indicitive of the final release, but is on par with most Microsoft products. (Kidding, of course!) Added calendaring widgets, courtesy KOrganizer Project. Changed libCxClient API to allow for multiple concurrent connections. Added the "Infusion Daemon", a connection-pool manager which will eventually place a much bigger role than it does now.
0.58	2001-02-18	Bugfixes, API Changes
libCxClient has been split off from the Infusion source tree. It will still be distributed with binary copies of Infusion, but you will need to compile and install it prior to building your own copy of Infusion. Infusion now remembers many things about its state when you exit: Window geometry (position, size) Last active view (Inbox? Tasks?) Status bar/Folder list/Message Pane settings More to come! :) Semi-working task list Fleshed out the interface a lot. This should help you get more of an idea of where I'm going with this application.. Created some bare support for Enterprise Management of Infusion clients. More information will follow on this shortly... I had many problems with core dumping in the development process for this release, which set me back about a week or so. I tracked the problems down to some strange things that I was doing in libCxClient. D'oh! :)
0.57	2001-01-12	Project Renamed
Project is now called 'infusion'. Slight frontend adjustments Added "New User" wizard - Signs user up on Citadel server (currently hard-wired to 'bbs.shadowcom.net') Applied CORRECT autoconf/automake settings to software from another KDE2 program. It isn't perfect, but it does actually build a usable binary (on both FreeBSD and Linux...) Added the ability to retrieve room directories. Will list files in the Messages list. (Sorry, but you can't download anything yet ;)
0.56	?	Major frontend changes
Added icons to lists (make it more 'comfortable' for users). Worked on objuserlist - Need to make it more robust! Backend: Added support for retrieving user listing (CxUsList()) Created a more "Microsoft Outlook" feel. Added a "Notes" view, which resembles a pile of sticky notes. Users will have to create a personal "My Notes" room.... Added the ability to store user passwords locally, BUT NO ATTEMPT IS MADE TO ENCRYPT THE PASSWORD AT ALL! I will work in some sort of Base64 encoding, as per IG's advice, but it's currently NOT there! If you use this feature, make sure that the machine you are on is SECURE, and that you set the perms on ~/.CxClient.rc to be SECURE (0600)! Building the framework for the contact list (writing a vCard parser/contact list manager...) Don't expect THIS to work for a while... ;) Created MessagePane object, which is a prettier way of displaying the inline message-reader. Fixed many bugs.
0.55	?	Serious Changes
(This is the first in a series of many re-architectures) Rearranged code to eliminate the obtuse module loading architecture. It Has Been Decided that it's not necessary, and really complicates things more than they need to be. Things now are based on a shared library structure. Eliminated alternate interfaces. Code can be made available to authors who wish to write another Citadel client using libCxClient.so.. The Only interface available now is KDE2. Implemented Express Message chatting Fixed bug in Composer (inverted options in YesNo) Fixed bug in Reader (hang on message load - QT problem!!)
0.54	?	Some minor reorganization.
[core] Slightly changed the way that CxClient builds. Now, after building, users will find a libCxClient.so in the build directory. This can be moved to /path/to/lib, and the Developer can build applications around it, without using my loader and modularization mechanisms! :) [core] Changed tool.room.Goto() function. Passing it a NULL room name, with a operation parameter of 1, will cause it to goto the next room w/ unread messages. More operations will be added at a later date. [CLASSIC] Added (G)oto support, for all of the citadaelians out there ;) [core] Implemented message posting backend. Had to correct a couple of misinterpretations from session specs. [KDE2] THE MESSAGE COMPOSER WORKS!!! :) [KDE2] Fixed crash problem if message list is clicked, but not clicked on a message. [KDE2] Fixed sort order to sort by date by default [KDE2] Changed message reader class to QTextBrowser. Works much better than KHTMLView. [KDE2] Added "Refresh Messages" button to message reader [KDE2] Set cursor to busy when working.
0.53	?	Minor Bugfixes
Fixed automatic memory leak in ui/gtk/callbacks.c:_mesg() Wrote MAJOR portions of ui/kde. Almost fully functional as a Citadel interface :)
0.52	?	Continuing Implementation
Major goal- Removal of c/s code from UI layer. Added backend functions for Express Messaging Added backend functions for MESG Added backend functions for authentication (now ui-independent) Moved GOTO commands into backend. More code cleanup Removed the "-O2" flag from the production UIgtk.so build-- This wreaked much havoc on Linux systems for some odd reason.... Began implementing the ability for UI modules to manually instruct CxClient to connect to the server, bypassing "normal" control calls. Added more detailed comment documentation to code.
0.51	?	Continuing Implementation
Completed backend message-handling functions, rewrote modules to access via tool.mesg.*(). Reorganized more header files... This is becoming routine for me.. d'oh! (These sort of changes shouldn't affect any modules, just the "core" portion of the client). Message-reading functionality has been fixed! Don't ask.... >:D Rewrote some message-handling stuff to improve the speed of the client (doesn't improve it THAT much, so I'll just blame GTK ;)
0.50	2000-11-14	Extended modularity
- Heavily organized the source files. - Finished most of the "behind-the-scenes" tools, the core CxClient chassis can handle all Citadel communications functions required for a rather basic client. There's still lots of additional work to be done, though! :) - Applied BASIC autoconf rules to the program. Still need some work on portability, tho... - Completed a rudimentary set of UIL and NTL modules, including: [User Interface:Raw] Unadulterated c/s protocol, Barebones sample of what a module looks like. [User Interface:Classic] The Ever-Classic Original Citadel Client (sorta...) [User Interface:Console] Text-mode Communications Tool (think PINE...) [User Interface:GTK] Basic X-Windows client, cool 'nuff for all GNOME lusers. [User Interface:KDE2] My preferrable interface! (I will most likely maintain this module, at least... :) [Network Trans:Null] Doesn't connect to a server. Doesn't do anything but spit stuff out, which you can test your UI with.... [Network Trans:UNIX_SOCKET] The classic way to connect to a Citadel server! - I've planned a couple of more modules, but may not implement due to time constraints (anyone who's willing to is welcome to offer, though!) [User Interface:UNIX_PIPES] Connect to the server using unix pipes. - Some things need to be done: I've got the framework in place for someone to implement, say, a Win32 or OS/2 port. Anyone who's interested can coordinate with me what's involved in doing such (basically, create a ldr_[your-os].c file which handles the dynamic loading of the modules, and you're all set...) - Some things don't quite work right: Most of the UI modules are a little... sparse. My apologies... I've been concentrating on making the backend as robust (and flexible, _AND_ platform-independent...) as possible. Anyone who wishes to take over development of a module is welcome to do so.
0.01	2000-10-15	Initial Release
Initial coding, wrote the modular interfaces necessary to support a client of the type that I envision. Laid out the basic structure of the client.