jIRC Resource Center
1/6/04
The new script loader API is in place and being used by jIRC. I've logged 14 changes today alone. Sheesh I've been coding like a mad man. I hope to exhaust my todo list tonight or tommorow. Then I will release another beta. While that beta is out I'll continue work on the scripting documentation.
Getting closer. Expect a new beta tommorow sometime.
1/5/04
Well made some good progress today. Whipped through my todo list implementing various small things like /run and such. Right now I started work on what is going to be a big API change for sleep. I'm working on a script loader class that acts as a central point for loading scripts and in/out processing bridges.
I've also been doing some work on the sleep console. Right now its looking like these new API's are designed well enough that the sleep console will integrate directly into the script environment for an app and can be used to manipulate it. Assuming the application author takes proper advantage of the script loader. jIRC will use the script loader API but I don't intend to integrate the sleep console into jIRC. Once I'm sure the sleep code is stable I will then proceed to integrate this new stuff into jIRC.
The cool thing is bridges will be able to tell if they have been loaded into a shared environment or not. If they have they won't be loaded again. This will save on memory and script loading time. This will also split up the sleep API a little bit making it somewhat more logical and easier to follow. So all around this is a good change to make. Albeit one I was planning on making later but ah who cares.
1/4/04
Oops. Missed my update from last night. I fixed bugs and did lots of work on the default script. I also put some work into the background dialog so its a little bit more obvious what you can/can't do.
I have a small list of enhancements to push forward with. I'm going to be doing that. :)
18 documented bug fixes/enhancements made so far. Thats not to bad. Definetly a long ways toward a better user experience.
Bug List currently:
closing tab needs to shift menubar focus to current context
remove concurrent modification exceptions
localizing a $var in foreach doesn't work, find out why
1/3/04
Little bits of documentation work. My main work today has been bug fixing. Which is good. Its kind of like polishing the client up. I spent 3 hours tweaking the dimensions of the icons used in the mdi windows and the switchbar buttons. Trying to get something that looks good on Windows without mesing with OS X or the java look and feel.
I'll continue my bug hunt until I exhaust my todo list. Then I'll probably zip another beta with the fixed bugs and continue writing documentation.
I've been writing small scripts as well to try and catch bugs in the scripting language. I hate to say it but I caught a few to many today and thats what led me to start fixing bugs so aggressively. I might start writing an XDCC script to really give the system a workout.
Even once jIRC is released as a public release, I will do at least a bug fix release later on. I'm not the kind of programmer who likes to leave something with known bugs circulating around for long.
One good sign though. As I've been coding I haven't felt a strong desire to add new features. Which is good. That means the project is pretty much winding down and I will actually finish it. I've got two weeks as of today of "disposable" time. Time I can use to get this thing finished.
1/2/04
I just noticed below that I wrote "righting" instead of writing documentation. Goes to show what burn out mode coding will do to you. I'm still "writing" documentation. *snooze*.
1/31/04
My next few days shall go towards righting documentation. Ta
- Added date related functions, formatDate(), parseDate, timeStamp(),
and timeDateStamp(long)
- Added colormap manipulation API's
- added a loadFont function for loading a ttf font file into the java
virtual machine. It will then be selectable from the options dialog.
The scripter can set the font as well by looking up the format in
jirc.properties and calling setProperty("client.font", "the font format")
- fixed a text display bug related to scrolling occuring with popup
menus being present
- two command line options -settings "directory", to specify what
directory to use as the settings directory, and -lnf "some.class.name"
to specify a look and feel on the command line
1/30/04
Good progress today as well. I now have the majority of API's I feel are necessary in place. I will add some date related API's as well though. From there I will worry about expanding the scripting organically (i.e. if someone asks for it, I'll add it). I'm going to spend some time modifying the build scripts to create packages. Once I have this thing packaged reasonably well I will release a beta. Expect a beta on Sunday. While the beta is out I'll write documentation, fix bugs, and add very small scripting features. Don't expect new client features. We are *very* close now.
Its friday so I'm going to go and have some semblence of a social life. In any case my progress for today is as follows:
- added a DCC_REQUEST set, same thing as CTCP_REQUEST except for DCC's
- fixed error messages for connecting DCC's, they are now fired correctly.
- fixed the DCC status/error sets for sends/receives. The sets/events are:
Prefix: RECEIVE_ or SEND_
Postfix: FAILED, COMPLETE, START
- changed some of the DCC API's adding getDCCFileName and getDCCFilePath
- added scalar casting functions: double(), int(), and long() - forces scalar to
be represented as any of those...
- fixed bug with refreshWindow() always default to status window
- added local('$x $y $z') to declare scalars as local variables
- altered the way locals are handled, no longer automatically removes value from global
space...
- unbroke nick completing channel commands like /do, /v, /kb etc..
- /hop and /cycle now work with +k'd channels
- added Process I/O to sleep (the i/o framework I have freaking rocks!@)
- added an eval() function to evaluate and execute code on the fly..
- added a interface for file system API's
- added API's for showFileDialog() and showDirectoryDialog()
1/29/04
Good progress today. I would have liked to have gotten more done but this is decent for a days work. Theres always tommorow I guess.
- added a clear(@array) function that clears the passed in array
- oops, unbroke use of && in if statements and added regression tests
for the same type of problem in the future.
- Line number information is now passed to predicate checks so use of
a non-existent predicate can be pointed out
- made some changes to add(@array, "data"), you can now specify an
index as the 3rd parameter i.e. add(@array, "sluts", 3).
- added $pt variable for ctcp PING replies...
- send ctcp and send notic echos now go to the same place as ctcp
replies and notices, depending on how you have things configured
- unjacked actions within queries (it had the word ACTION being echoed
as well...)
- scripted USER_MODE set...
- unbroke dcc chat, I'm surprised it wasn't broke before with what was
wrong..
- Unbroke/improved the logic for resolving/handling local info.
- Most popup menu hooks now have event data associated with them,
background, menubar, and tab menus do not have a $0-. Query
windows, Channel windows, nicklist, Status window do though.
(Status window isn't anything worth getting excited about)
- fixed problem with nicklist popups dieing when a channel window is
reused (i.e. I join channel, leave somehow, then join again without
closing channel window).
- /exit now uses the global quit hook, so a quit message is sent and
all that when exiting view /exit.
- Changed behavior of window closing in SDI. When a window is closed
the window to the left of it in the switchbar becomes active.
Pretty cool!
- fixed bug with /QUIT, it wasn't sending parameters to the server
correctly.
1/28/04
Good progress today. Added a remove() function that works for arrays and hashes in sleep. I also implemented the DCC related functions. I've been doing some work scripting the menus for the client. So far I'm happy with how they are turning out. I'm doing pretty good with scripted dynamic menus.
I had one issue I just realized I don't need to solve. Say I script a cool menu snippet but want to use it in more than one place. I was going to create new language keywords and everything. I just realized I could throw the menu snippet into a subroutine and call the subroutine where ever I'd like the menu snippet to be. Hows that for cool. Sometimes being the designer of my own language is dangerous. To much time spent thinking of what I can add to solve problems rather than using what I've already got.
So progress is really solid. I feel that adding code to interface with the file system and get file attribution information is important. So I might do that tommorow. I'm happy with how the client is shaping up though. Also /reload got quite a workout today. Works flawlessly so far. Definetly a good thing.
1/27/04 - part 2
DId some work adding more functions. Added a usable for file/socket i/o. Wrote in bridges for creating and managing timers. Added bridges for interfacing with the config system. I also added a rand() function to the math stuff.
Good progress today.
I want to get the DCC operators in place and add in the dialog stuff. Once those are done I'll do some work on the default script. Once the default script is more solidified I'll actually release a beta.
While the beta is out I'll expand the scripting repetoire organically i.e. if someone asks for something I'll add it. I'll fix bugs during that time and work on documentation. Maybe even add some of my easter eggs.
From there we should be close to a release.
1/27/04
Sorry, I've been out of town for the past 3 weeks or so. Thats how it goes. In any case I've been working on sleep i/o facilities lately. I'm working on making sockets and files use the same API so things will be reasonably consistent. I hope I can make it work. We'll see.
I'm making good progress though. Like right now I have a really simple raw irc client coded. I can send stuff to the irc server off of input from the console and I can read shit from the irc server. This is significant because I can do all of this at once from a simple script (using callback functions for the reads). Heres the code:
$socket = connect("irc.blessed.net", 6667);
println($socket, "USER a b c :d");
println($socket, "NICK butang");
sub onread
{
println(getConsole(), "Server: " . $1);
@temp = split(" ", $1);
if (@temp[0] eq "PING")
{
println($0, "PONG " . @temp[1]);
}
}
sub oninput
{
println($socket, $1);
println(getConsole(), "Me: " . $1);
}
read($socket, &onread); # on read from socket...
read(getConsole(), ); # console input y0, getConsole()
# returns the IO handle for STDIN/OUT
1/8/04 - 6am
Now my error checking is *real* slick. If an exception happens while a script is processing the interpreter catches it. Prints the stack trace to the console and fires off the exception description as a runtime warning. Whats really cool is that this runtime warning also contains the script line number where the exception occured. This will make it a lot easier to debug problems in the future as well.
I've been going through and implementing all the necessary built in functions. Once I'm done implementing this stuff, then its on to fixing bugs and writing documentation. I'll probably release a beta before I start in on a massive bug hunt.
1/7/04
Sleep is back in place. Since I've got my error checking stuff in place I've decided to get back to working on the client and working towards a release. Its mostly scripting related stuff now coupled with bug fixes. Almost there I guess.
1/5/04 - Another 3am update
This is worth writing about. The code generator *is* in place. So we're rockin in that respect. I spent some time chasing down a problem with predicates.
My predicate parser wasn't breaking down tokens properly. I was getting pissed because I kept following the code and going in circles (much like the computer was doing following a never ending recursion). For the life of me I couldn't figure out what was supposed to happen. I copied the code from my old parser and modified it to use the new data structures I wrote. So it should have worked okay. Then I discovered the problem. I have a method that is supposed to regroup predicates, well that method never gets used in the old parser codebase. It existed but didn't get used. I was using it and it was creating a never ending recursive situation for me. I axed that method and used a generic regrouper method and then everything was peachy keen.
I also started an important package requirement for the sleep language. I wrote a perl script to run a bunch of scripts in a directory and compare there output to output from the same scripts from a time when I knew they actually worked. This way I can quickly test changes to sleep to make sure the library is working as it should. Pretty important to have if I want anyone to take it seriously.
I'm going to continue parser testing and brainstorming runtime debugging options.
1/5/04
Still working on the code generator. I've got everything compiling. Now its a matter of debugging everything and making sure I didn't break anything. I'll probably be done with all of this by the end of the week at the very lastest.
1/3/04
Shoot me for wanting to commit to another big open source project. jIRC from its roots was meant to be a "hackers" irc client, even though its written in java. I've been shooting for the hADES/bX feel/attitude ever since I started writing it. I was also trying to counter balance this with some of mIRC's ease of use. Having a niche audience is all well and good so long as your targetting what your audience uses. Well it seems many people I know have moved to SILC (Secure Internet Live Conferencing).
The reason I'm putting so much time into a "hackers" irc client. I'm trying to give back to that community. I want something that is useful as well though. SILC isn't a script kiddie toy and as such I wouldn't mind hacking out something that is SILC compatible.
I've really toyed with the idea of using jIRC's codebase to make a SILC client. However reading the protocol drafts I've been so far unable to figure out the damned protocol. However today I discovered a public domain java silc library for use as a base for a java silc client. I plan to release jIRC as an irc client first but when I've got jIRC out the door I'm going to take a look at the silc library. I may be able to pull it off.
Anyways you probably want to know jIRC's progress. I'm working on the scripting language parser pipeline still. My focus is making it possible to pass around tokens that contain a code snippet and a line number indicating where in the script file the token is.
Progress is good. I'm picking up on errors much better than before but I'm not done yet. I'm happy with the way it is turning out though. So far much better than I originally thought.
Error: Mismatched Parentheses - missing close paren at line 5
if (3 * (4 / sluts())
^
1/2/03
How do you eat an entire elephant? Cut him into small peices. I'm coming down with something I don't necessarily expect to get a lot of work done tonight. I have the great task of rewriting sleep's parser setup. Basically what I have now doesn't propagate line number information for each code snippet. This makes error reporting incredibly difficult. I haven't had a problem with this as I can usually spot syntax errors quickly but I'm sure other people using sleep would like the error reporting. I estimate this to take 3-4 days if I work fast. Ideally I'd like to release jIRC on the 14th. Wether that happens or not remains to be seen.
1/1/03
Lots of work done tonight.
- Fixed DCC (I broke it)
- Modified Control-O behavior (resets everything but the color since we don't have anything to reset it to)
- A default quit message is sent when exiting the client
- Added switchbar options including position (top, bottom), enable/disable, and activity highlight color... a dialog to edit all this is included as well (my dialog creator kit rules!)
- autoreconnect has been fixed (made smarter/better etc.)
- Added sets for IRC_CONNECT, IRC_DISCONNECT, IRC_RECONNECT
- fixed a bug with local host resolve via server method, basically if you hit the dialog to do it several times each time it would register a temporary chat listener saying "hey lookup my local info".
So yeah good progress. Now to start over on a whole new leaf. Script error reporting. This will be mostly work with the sleep API. I'm going to use exceptions to communicate parser errors and I'm going to use an event/listener model to communicate script runtime warnings.
12/31/03
Happy new years everyone. I've been watching the server logs. I know people read this thing every day (some even come back). So anyways thanks for your interest. I won't be coding tonight though since its new years even. However:
My new years resolution... be more of a prima-donna. My other new years resolution... finish this freaking irc client. :)
We're almost there... really.
12/30/03
Wrote in some of the OS X specific stuff. I had a frustrating problem with MRJAppBuilder only to learn my bundled jar file wasn't working because I needed to upgrade my development tools and use Jar Builder. Blah...
jIRC on OS X
I'm debating wether or not to include Mac OS X specific UI tweaks i.e. the icons in the switchbar buttons look like shit. I might install 10.3 first to see if Apples updates to java fix that problem.
12/29/03 - technically 12/30/03 at 4am
Did some more work tonight. Implemented a -pass option to /server for server password support. Finally implemented the use of your alt nick if you try to connect and the server says your nick is in use. I also added an ignore feature. Its very basic: you add a mask like *!*@*.aol.com and it just simply ignores all messages (public/private), notices, actions, ctcps, replies, dcc's, etc. from the matching hosts. Some dude on irc was annoying me so I'm testing the feature out on him.
I've also made a change to the options dialog, using a JTree instead of a JList for navigating available options. I discussed it with someone and he disagreed with the idea of using a JTree. After implementing it I think it separates the options better and makes the list easier to navigate. So I'm happy with the change.
Tommorow I'm going to dilly dally with some more options, adding options for the switchbar position and the swithcbar activity highlight color (some people just don't like red). My goal isn't option overkill however I think a little bit of flexibility is okay. I may work on Mac OS X specific stuff tommorow as well. Then beyond that it will be time to start on the scripting stuff. All the scripting stuff will be a lot of coding however it goes quick. So progress is pretty solid thus far.
12/29/03
Let us capture the moment, shall we. I'm almost done with jIRC. Almost there. I just crossed off two huge milestones:
- config dialogs / help dialogs
- tie options into the dialogs
These two are not 100% done (I might add something) however for what I've got they are done. All the options in the options dialog are now implemented. Including ident which I did tonight. I also made the setup dialog connect button use the configured port and use ssl if that is enabled or not.
This is huge. Some work on the scripting language, some scripted features, and some documentation then we have a releaseable irc client. I'm very excited about this as I've been promising this client to the world for a long time now and it is almost there. :)
12/28/03
Tied the option dialog results for notify list manager and the script manager into the client. So this stuff all works well and good.
I've decided that for my scripted sets I'm going to try to consolidate them down a little. Instead of having a set for every single possible echo I'm going to try to generalize them a little bit, like DCC_ERROR instead of SEND_FAILED, RECEIVE_ERROR, RESUME_ERROR etc..
I've encountered some kind of bug with my implementation of scritped aliases or sleep. If a script uses "return;" within an alias it causes other code that is running to freak out big time. The language recovers after a minute or so but something is seriously wrong. I don't have much in the way of debugging sleep in place yet. I should be able to get past this one. I'm going to take a swing at it tommorow. To be honest though bugs within sleep always scare me. :(
I've also made a little design decision. I have a ton of built in commands. I'm going to make it so none of the built in commands echo anything. If someone wants to have some echo going along with an alias they can redefine it as an alias and use call("/ $+ $0-", "built-in"); I'll script some alias echos this way like /notify by itself. I'm also going to do /dcc this way as well.
I don't have a long list of changes like yesterday but tonights progress was pretty good as well.
Update: found the bug. I first isolated it by trying to produce the same results with a subroutine instead of an alias. I couldn't. I even went so far as to move the code over exactly to a subroutine and make the alias call the subroutine. It worked fine when I did this. So whats the difference between how my aliases run code and how a subroutine runs code. Subroutines clear the return flag after they are done executing. Aliases weren't doing that. That was kind of a problem. I'm noticing all of my other bridges use SleepUtils.runCode() to execute a block and that clears the return value for them. Probably what I should have done all along with my aliases. Damned!@ When I actually package and document sleep i'm going to have to make the API's really idiot proof and really make clear what developers should and shouldn't call.
It looks like I foresaw this exact problem. The javadoc for SleepUtils.runCode() states it is the safe way to run code because of the return value clearing thing. Hehe :)
12/27/03
Made a lot of progress tonight... so much progress that I'm calling it a night early. However some of the shit I've implemented/done tonight:
- implemented local info lookup using 3 methods, the user can input an ip address, the ip address can be obtained from the operating system, or the ip address can be resolved from the irc server.
- reworked the dcc data structure code and made it better and easier to get what I want. This carries over to making /dcc accept and /dcc close work as intended.
- rearranged the dialogs a little bit, created an external programs one and moved the open files with option over there.
- fixed save problem with the options dialog
- added a control in the UI Options to set the color for the editbox.
- did some work on the statusbar: it is now thinner, the option to change the number of statusbars is now implemented (but not really setable yet), and if the statusbar is set to 0 lines it will appear as a 1 pixel line to separate the editbox from the text display.
- implemented the ui option for switching the client font; everything seems to be resetting correctly. Unfortunately my custom components do not work perfectly with all fonts. Most normal fonts don't seem to have a problem however some do (i.e. VT100). I may investigate this further later but for now I consider it safe enough to go into the first release with.
- made the help, about, and option dialogs non-modal.
So in summary, good progress for a day. Next on the agenda will be tieing in the notify and script loading options. I'll then have to decide wether I want to work on the scripting or continue digressing and implement the identd and notify features. Progress is good though.
12/25/03
Just a quick update. I did a lot of my "planned" work on the dcc stuff. I added sets for RESUME_REQUEST, SEND_RESUME_REQUEST, RESUME_SUCCEESS, and RESUME_FAILED.
Once all the DCC stuff is in place I'll start tieing the other options in. Beyond making the options work I have to do some work on the scripting stuff but we're much closer to a complete client.
12/22/03
Did some more work on the dcc options. Interestingly enough I've more or less implemented all of them. Now for a little bitching and then some on the spot design work.
The current DCC data structures don't do jack for me. They do not fit the needs of the client and as such may need to be reworked. In fact I'm not satisfied with the external aspect of the dcc architecture (the internal aspect is pretty good though).
By external I mean notifications to the client that dcc stuff has occured, sets currently in place for the dcc stuff, dcc related echos etc... I feel the implemented range of dcc commands is weak as well, and the data structure for getting at the active/inactive dcc's is totally inadequate. I'm going to sit down with a notebook tonight and see if I can figure out a better architecture for some of this stuff. I *should* just call it good but I want something better than what I've got.
As for implementing options for the dialogs I've created here is where I'm at:
- setup dialog is mostly rocking, port and ssl options need to be used when clicking the connect button
- ident isn't implemented yet so the notify dialog is useless right now
- notify dialog settings need to be carried over to the notify system itself
- script manager settings need to be used
- the UI option for setting the client font needs to be used
Thats pretty good considering setup options are mostly implemented ,auto window options are 100%, irc options are 100%, window images, and UI options are implemented as well. So we're doing good in that respect.
The main two things standing between now and a complete client is implementing all of the options in the config dialogs *and* some work on the scripting language.
12/20/03
Minor dialog work today, mainly dcc dialogs for graphically prompting the user that a dcc request has been made. I don't plan to put to much effort into this as I consider dialogs to be lame for this type of program.
12/18/03
Minor bug fixes today. Scripted in clickable URL's (yes, scripted... hows that for a capable client).
on click
{
if (left($item, 7) eq "http://")
{
openCommand($item);
}
}
My next two focuses are going to be the DCC stuff and error reporting within the scripting. At dinner tonight I was having a conversation with a friend about the "feel" of a project. Yesterday jIRC crossed that magical line where it is now starting to feel like a complete work coming together. This means it will be done soon and I will have something that I'm happy with. :) Yay for ~5 years of work on an irc client (several rewrites of course, plus a social life, several jobs, and pursuit of several other interests).
12/17/03
More solid progress today. I fixed the setWindowTitle() problem causing an occasional deadlock. Coded up auto /window options. Implemented the shit in the irc options dialog to echo certain types of events in the active window. Definetly making progress.
12/16/03 - 2
Made some solid progress today. Implemented the Help dialog and worked on the about dialog.
I even managed to get a few easter eggs in place. I have one more important (to me) easter egg
to implement and then I'll just continue finishing stuff up. Progress is good though.
12/16/03
Last night I did some miscellaneous bug fixing and today I packaged the client together. Beleive it or not packaging is kind of a big deal. I had to do some work to make sure all of the resources were accessible within the .jar file but also accessible if they changed and ended up being saved in the users ~/.jIRC directory. Everything seems fine now.
If you want a copy of what I submitted to my professor for the independent study let me know. I'm having the feeling that I won't actually be betaing the first public release. I'm shooting for all or nothing as far as getting a release out the door. What I will do though is when I release I'll keep the first release on the down low and then I'll start development on an update right away. The update will go through a normal beta process and once that is done I'll actually post that to freshmeat.net and make some effort to get it out there.
12/11/03
Did some work on the default script. Worked on fixing some problems with the window related scripting stuff. More or less I'm just hacking away trying to figure out solidly what direction I'm going to take with regards to the balance between hard coding and scripting.
12/10/03
Made some good progress tonight:
- Finished the server setup dialog. Huge!!!! It works reasonably well too.
- Added SSL support for connecting to irc servers. Took some research but I pulled it off.
- Added a special set of escapes to parsed literals in jIRC's interfacing with sleep. I added \b for bold, \c for color, \u for underline, \r for reverse, and \o for cancel. Basically not having an editor geared towards writing jIRC scripts makes it hard to put those irc formatting characters into a script. I decided to get around that inconvienence. So like
echo("Hello \bice cream\b"); will be like "Hello ice cream";
Pretty useful :)
12/9/03
Almost done with this stupid server editing dialog. Lame. Lame. Lame. Unfortunately its one of the first things people notice/interact with in the client. Plus its important to make it easy to find a common list of servers.
I'll have that done tommorow and then I'll press on with getting more coding. Blah blah blah.
I'm thinking of putting a beta out on Tuesday as that is the utlimatum day for me to actually package and deliver something resembling an irc client. I'm on it.
12/6/03
Not much to write. I've been working on the server list editor dialog thingy. Not fun. I am not a fan of writing UI's. Very repetitive, finicky, boring, frustrating, and uninteresting work. Still a required feature of any irc client. Another big problem is this feature is one of those takes more time than its worth features. Like in one day I managed to implement the single document interface option. In three I can't finish one half of one lousy dialog. Lame. So you may be wondering whats up, heres the deal...
- I will not be finishing jIRC before the term is over. I just don't have time to hit my "vision" of a solid IRC client. I can do it. I will do it. Time is just not on my side. Having a social life at times and passing classes does occasionally take priority.
- I am receiving credit for writing this. 1 college credit because I can't afford to pay for more. As such I do have to deliver something. I have a lot to deliver but now I need to prioritize on the features for the next week.
- Once I deliver some version to my teacher I will simultaneously release a beta and reactive the jIRC beta tester website. I will then continue the beta process. Hopefully from that I'll have a completed product within a few months. Hopefully.
Features for Delivered jIRC
- Completed Server Dialog thing
- Make jIRC tie into as many of the dialog options as possible.
- Help Dialog
- Updated documentation
- Scripted menus (default stuff mostly)
- Ident Daemon
- if time - string manipulation functions in sleep
- Deployable via double clicking on a jar file or java -jar jerk.jar. Nothing else to setup.
Dialogs I don't finish the "features" for should be disabled. For example I didn't get around to implementing auto /window. As such I should remove that dialog for the turned in version and beta process until there implemented.
So that is whats going on.
12/4/03
Making a Java app look and feel right on Mac OS X is a pain in the ass. Really. I think its cool that my Java app can be so well integrated into MacOS but holy shit Apple has a lot of crap you have to do to make that happen. Worse yet they even have API's using there classes that they want you to use to hook into there default created menubar menu. I'm kind of pissed about that because I want something that will compile on any platform. I'm also pissed because in order to get a dock icon and such I'll have to distribute jIRC as a .app package which is Mac OS X specific. I of course plan to distribute jIRC as a .jar file but it looks like I'll have to make a separate Mac OS X specific distribution as well. I think that is stupid. If I had to do that for every platform I wanted jIRC to run on I'd just be screwed.
On the bright side I modified Jakiechan's jIRC logo a little bit with some software until 3am last night and ended up with a dock icon for jIRC. You can't tell much but it has been aquafied a little bit. This is to make jIRC fit in better with Mac OS X when I finally figure out how I'm going to do this integration without killing the crossplatformness of the app.
12/3/03
Tonight has been hugely positive for jIRC development:
- I managed to do a clean compile (deleted all of the classes and recompiled). This is good news as this step can sometimes result in problems.
- I have implemented a single document interface option, jIRC is by default (and just its nature) a MDI client. MDI meaning multiple document interface. SDI is a more natural fit for Mac OS X and I'm sure some users will prefer it over MDI. mIRC is an MDI client, X-chat is an SDI client to kind of put it in perspective.
12/2/03
Did some tweaking to the dialog I worked on yesterday. Made no progress otherwise though. Tsk. On the bright side I had an idea and I'm going to try to implement it. Basically I have an idea of how I can alter the architecture of my window management code such that the code depends on the parent container of the window for window management. This would allow for me to use different containers for windows i.e. a JFrame, a JDesktopPane or even a JPanel with a card layout manager. I think so anyways. Its kind of a drastic change but limited to a few files. What I'm going to do is backup all my code and just have at it and hope it works. We'll see. If I get so far though as the ability to do an MDI interface and a single document interface then I'll consider myself golden. The MDI really bugs me on Mac OS X. I think its cool in X windows or even in Windows itself but on OS X it just does not feel right. So that is whats going on.
I also managed to start brainstorming on some of the final scripting API's I plan to implement. Onward closer to a release.
12/1/03
Managed to get an important dialog out of the way. Window image configuration! The GUI isn't ultra pretty but it works. I had to fit a lot of configuration options in a small space so I went with some tabs. Each tab contains 1 or 2 controls. I'm going to spend some time and see if I can make it so when something can't be done for say configuring the window (i.e. can't be made transparent) then the option will go away. Otherwise though the UI was made with the dialog creator kit. I'm managing to build some good flexibility into it. Looks like when the time comes I'll be able to do some pretty slick dialogs for various jIRC options. Unfortunately I'm on a 3 week crunch to finish this thing though. Screenshot of the image config dialog below:
To consider the dialogs milestone done I have to complete the following:
- help dialog
- irc options dialog
- setup dialog (nickname, altnick, realname, edit servers connect etc.)
- local info
- cancel options dialog restores settings as they were before.
If I continue neglecting school I can have all of this done by Wednesday or Thursday night. I may throw in some other UI options just for the fun of it. If I can swing it maybe a SDI interface instead of an MDI one and disable the menubar.
SDI would be easy to do... all I'd have to do is create a different class to manage the windows, something other than ClientDesktop. This might be an important option to add as MDI doesn't feel right on a Mac at all. Since I use a mac taking a mac into account is kind of important.
The setup dialog will be a big chunk of work. I'll try to knock that one off tommorow.
11/29/03 - Take II
I think I know how I can finish jIRC to some level of satisfaction (for myself). If I ship the client with a default script (and options) that make it resemble mIRC - I can have a complete client with mininimal muss and fuss in the tight time frame I've got. Part of what makes the client cool though is the default script/options I was creating but I personally don't care about the look so much anymore and I don't have an eye for solid aesthetics. I'm sure some scripter will make some sort of cool looking theme to replace whatever crap I ship anyways. With this in mind I may be able to pull off a completed client on time.
11/29/03
Well yeah. I haven't updated in a few days. I'm still working on the dialog creator kit. The bright side is that the bottom up approach is absolutely wonderful. So far the dialogs are what I want. A consistent interface that looks pretty decent. For example one of my DCC dialogs the code looks like this:
public void setupDialog()
{
addBlankSpace();
addBlankSpace();
addSelectInput("dcc.onsend", 0,
new String[] { "Ask", "Auto Accept", "Ignore" },
"On Send Request: ", 'S', 75);
addSelectInput("dcc.exists", 0,
new String[] { "Ask", "Overwrite", "Resume", "Ignore" },
" If file exists: ", 'I', 75);
addBlankSpace();
addSelectInput("dcc.onchat", 0,
new String[] { "Ask", "Auto Accept", "Ignore" },
"On Chat Request: ", 'C', 75);
addBlankSpace();
DGroup temp = addDialogGroup(new DGroup("DCC Ports", 50)
{
public void setupDialog()
{
addStringInput("dcc.low" , "4000", " First: ", 'f', 60);
addStringInput("dcc.high", "5000", " Last: ", 'l', 60);
}
});
}
Pretty solid in my oppinion. Really easy to customize the dialogs and change them around. Not to mention adding new ones. That makes me happy. :) Alright back to work.
11/25/03
Oops. I didn't log what I did last night. Besides playing a 6 hour game of Galactic Battlegrounds (I <3 RTS) I did the design work on the dialog creator kit. Basically I'm doing a bottom up approach to writing my dialogs. Bottom up meaning I'm designing an easy to work with abstraction for creating my dialogs. This should hopefully allow for a consistent interface and save me some major development time. That is the plan anyways. I did start writing the code its looking like that part won't be a short job. I'll slog through it. This week is starting to look tight on wether or not I'm going to hit my milestones (this is *not* a good week to fall behind because none of them get any easier).
11/24/03
Finished off the gui <-> script bridges. I've done very little testing but it appears to work so far. I don't feel like I included everything or designed my API's particuarly well but at least they are there. *shrug*. I'll see if I can make some progress on the DCK tonight.
11/22/03
Did a lot of work on the GUI <-> Script bridges. I still have some window management stuff left to do to complete this milestone. Probably another good hour on this one yet.
Tommorow I'm going to work on what I call the dialog creator kit. Some code basically that will make it much easier for me to create dialogs. I've done most of the design work already so it should just be a matter of hacking it out.
11/16/03
Did some work on the default script and fixed bugs as they occured. I'm definetly not going to hit my milestones this week or next week. I've been pretty damned sick for the past week (still not over it) and during that time I've been mostly unable to work. Next week I have a physics exam which will take up my time for a good portion of the week. I still have to release in 5 weeks though.
I've refactored the milestones again. Unfortunately I had to remove some of the features that would have gone into the first release. These include a DCC "dialog", SSL Sockets, and desktop windows. I'll add them in if I get time before releasing. Otherwise they will make it into a follow up release.
Once I do a public release I plan to do a follow up release that addresses problems people pointed out in the first release. So just because I'm not doing something before the first public release doesn't mean I don't plan to do it.
11/12/03
No progress today however I removed a debug statement from my text stuff which helped out my perceived performance when scrolling up and down. So I'm happy about that. Still suspicious of the text performance but a little releived.
11/11/03
Finished up my work on sleep for this week. Stayed up all night doing it. This is a pretty key milestone as the scripting language is at the core of the whole client. So what exactly did I do staying up all night? More than you might think...
- Tested the hash stuff... its working a-okay (and damned fast as well).
- Wrote wrapper classes to make it 1000x easier to take program data structures and make them accessible in the scripting environment. It's all a matter of SleepUtils.getArrayWrapper(Set instance) or SleepUtils.getHashWrapper(Map instance). This will help me quite a bit and it should help developers who choose to use sleep in there apps in the future. The other cool thing is the wrapper classes have very little overhead compared to creating a copy of the data structure I wanted to make available with all scalar values. This is huge! Now operations like getOps(#channel) won't be expensive. Likewise using size(getOps(#channel)) won't be an issue either. I'm very happy about this.
- I actually added some built in operator precedence. +, -, and . take highest precedence now. This is so arithmetic expressions done in Sleep (without good parentheses) actually evaluate in the same way as they would in other languages. Enjoy.
- Made a small predicate change. you can now do if ($x) { } or if (myFunction()) { } as a test case. The way it works is any 0, "", or null value means false. Anything else means true. A big convienence for coding. Enjoy that one as well.
- I tested out my increment hack optimization. It was a factor of two increase however I had to do an empty loop with 2 million iterations to get good numbers. For the lack of flexibility the optimization would cost me I figured its not worth it. Things are pretty quick as is.
Getting some of this stuff worked out is pretty important to finishing jIRC (and releasing Sleep). I'm sick as a dog right now and dead tired. However I think the progress I made tonight was very well worth it.
I just noticed I keep saying enjoy this or enjoy that. I suppose you won't be enjoying nothing until I actually release something. My bad. Well when its released enjoy.
11/10/03
I've been reworking the way sleep handles variables. I've got my interfaces defined and everything seems to be working so far. I changed the implementation of foreach to (supposedly) have less overhead using a java Iterator.
I've got the array and hash implementation done as interfaces so I can change the under lying implementation (or wrap an existing data structure with low time cost). That was the important part of all of this. I still have yet to test the hash stuff though (to make sure it works).
My biggest concern with reworking the interface was the possibility of making sleep take a performance hit. That would be a bad thing. The good news. I tested the old code (and some possible array implementations in the new code) and overall we have a small performance improvement. The really good news: the new code fixes some old problems and the new code is cleaner. I may also be able to do some optimizations to $x++ and $x-- so they have less overhead. Overall these changes are a win-win for sleep.
Test Results:
|Push/Pop |Random Access|Iterator
-----------+---------+-------------+---------
Stack | 12460ms | 12942ms | 12385ms
LinkedList | 12989ms | 49201ms | 12703ms
ArrayList | 14201ms | 13308ms | 12970ms
Old Code | 14402ms | 14541ms | 16076ms
The iterator test is basically just a test of using foreach on an array containing 20,000 elements. Random Access is a test of going through an array of 20,000 elements accessing each element with @scalar[index].
Those two tests also have the overhead of calling add() on the 20,000 elements. Push/Pop is a test of pushing 20,000 elements onto an array and popping the same 20,000 elements back off. The string 20,000 elements in the test are printed out to the console as well so that adds quite a bit of overhead. The stack implementation without printing to the console takes 1368ms. So looping performance seems good.
I expected ArrayList to have the best performance of all of the data structures. Stack appears to be the reigning champion.
It took me awhile to get everything setup for testing the old codebase for a comparison. Hope you appreciate it.
One other change I want to make. I want to somehow add operator precedence to the parser. I personally use parantheses when doing any math in a program but others probably don't so this is kind of necessary. I hope to be done modifying the sleep library itself by the end of the day tommorow.
11/9/03
Alright. Background options code is in place and I am very happy with the functionality. I'm happy with the code and the design of the code (the way it fits together) isn't perfect. However it works very well and its very fast (images are stored in video memory when possible, transforms and such are done once and reused as long as possible).
I've even got a wide array of options. These include the ability to center an image (with a solid color in the non filled spaces), smart stretching of an image, fill (which just stretches the image to the width and height of the target area), and tile. The normal stuff. Now for the kicker. Any of these options can be done relative to the object (a window, statusbar, or MDI desktop background) or relative to the desktop so everything aligns right.
The other options in place include just using the default color for the look and feel (desktop and statusbar). Using a solid color for a fill. Also the statusbars can be transparent with a specified tint.
So yes, the background code is in place and it is awesome. I'm going to try to do some miscellaneous work tonight. If I get anything done I'll post it here.
One other worthwhile change. When a user says something and is no longer idle (and only when there is a change in there idle status) the listbox for the channel they said something in is now forced to repaint. This way the listbox will be reasonably up to date with who is idle and who is not.
11/8/03
Working on the code for background options. Trying to figure out any other backgrounds options I might want to add as well. Currently we have backgrounds for the MDI desktop, the windows themselves, and options for the statusbar.
Statusbar: default for component, solid color, transparency tinted with a solid color, image, image w/ a solid color tint (maybe)
MDI Desktop: default, solid color, image
Window: solid color, image, image w/ a solid color tint
Image arrangements include two types of tiling at the moment. Trying to decide on others.
11/7/03
Implemented popup menu hooks up the freaking wazoo. I can only think of one place where they are missing and I never intended to put them in this one place to begin with (although if Sun adds the proper hooks for me and it seems possible I'd consider it). Basically I'd like to have a menu for the icon of an internal frame and for the switchbar buttons. However Sun doesn't provide an obvious hook for me to provide this kind of functionality w/i the JInternalFrame. It's not important enough to add to the switchbar buttons alone. I might investigate this for some future version of jIRC though.
I finished the two menu related milestones. Each time a menu click occurs the variable $command is set with the text of the clicked menu. I have a $snick variable for the selected nickname (for listbox popups). Everything else should be well covered through other options already in place or to be added later.
I have menu hooks for the following:
menubar - the top level menubar
nicklist - the nicklist within a channel
channel - channel popups
query - user query popups
chat - dcc chat popups
status - popups for the status window when no query is set, otherwise the appropriate menus are used
input - popups for the text field (so cut, copy, paste etc. can be scripted by default)
background - the background of the MDI desktop for the jIRC windows
tab - popups for the server connection tab (now these can be right clicked on with stuff).
Why did I go so nuts on making all of the menu stuff scriptable? The simple answer is coding popups in Java by hand is very cumbersome, repetitive, and boring. Not to mention error proned, inflexible, unexciting, and just a slow worthless process. This is one thing that it makes sense to script. I'm going to make a script called like menus.irc that will contain the standard menu stuff like cut, copy, paste and all of that. This file will be separate from the default script and will stay loaded unless someone chooses to unload it. This provides a quick way for me to edit the menus and tweak the overall user experience.
Personally I think any application would benefit from using an embedded scripting language to speed up development of this kind of stuff in the application. Just a thought :) Although it would have to be a big app to have the benefits of providing bridges to some of the application functionality outweigh the time it takes to integrate the language and develop the bridges.
11/6/03
Made some good progress today. I have most of the menubar and popup code setup. I had a really frustrating problem with my mouse listeners but got around it. Apparently the lowest component in the component hierarchy gets the mouse events. Once it is dispatching mouse events to its listeners other components in the hierarchy won't receive the events. Kind of frustrating but I got around it.
Still left before I call the menubar and popup milestones complete:
- have some way when a script is loaded / unloaded that the menubar is refreshed
- make a menu item pass a variable to the code it is executing. Probably will do something like $description which contains the text of the menu that was clicked on. This is for menu items added in a loop.
- get the listbox popups working and make sure $snick contains the primary selected nickname.
- I don't know how I'm going to handle the other selected nicknames yet other than a function like getSelectedNicks() that returns an array of the selected nicknames.
I should be able to get all of that done tommorow. Any other coding I do will be towards the background milestone. I should be able to hit my milestones this week but unfortunately I don't expect to get ahead at all. Next weeks milestones are going to be a tough hit so I was hoping to get to that point. Ah well.
Also if your curious what I did about the problem with the menu bridge and the long assed line of code. I opted to keep things as they are. It won't really hurt anything and once its done I won't be touching the code so :P
Screenshot
I haven't done any work on the default script other than to get the basics in. Thats why there is no color. Next week I'll be working on the default script so hopefully we'll get something better looking than that. However you can see that my rewrite is starting to size up to be just like the original code base that I abandoned.
11/4/03
((UserHandler)SessionManager getGlobalCapabilities() getActiveSession() getCapabilities() getDataStructure("commands")) processCommand(code);
(.'s replaced with spaces so it wordwraps)
An absolute abuse of object oriented programming and the API's I've provided myself. Unfortunately the menu bridge I've designed is isolated from the capabilities object. I'd have to restructure how my bridges are instantiated and how they receive data to make the above code be a simpler call.
I could just make the menu bridge a second class bridge in which case this wouldn't be a problem. The menu bridge is the last primary bridge I have to add as well so there are no unanticipated other problems to deal with.
The above code is the only bad spot in my menu code and its only used for the scripter convienence function of:
addItem("menu description", "/command to execute when menu is clicked");
Of course it would be just as easy to do this (and the code underlying it is cleaner):
item "menu description"
{
call("/command to execute when menu is clicked");
}
My 4 options consist of:
1. remove the addItem function - its not really needed anyways
2. keep things as is, if it ain't broke, don't fix it
3. move the menu bridge to the rero.client.whatever package and make it a second class bridge (which doesn't feel right) - being a second class or primary bridge doesn't affect performance or anything its just an organization of code issue.
4. redesign the API's for how primary bridges are instantiated
I'm leaning towards 3 as that would (possibly) give me the ability to make the menu bridge install the top level menubar itself rather than relying on outside code to update the menubar when a change occurs (i.e. a script is loaded).
I'm working on menus right now, can't you tell?
11/3/03
Implemented key bindings and fixed some bugs. So now people can script key bindings, kind of fun. An example would be this:
bind Ctrl+N { call("/newserver"); }
The above code creates a key binding to Control and N being pressed at the same time. When that happens the code above creates a new server instance. The bindings work anywhere within jIRC and the binding is executed from the loaded script(s) of the currently active server.
1 milestone for this week down already (and its only Monday).
Started work on the scriptable menubar code which will carry over very nicely to the popup code when I'm ready to implement that.
11/2/03
Managed to write the config system today. I haven't really tested it but it has been written. Speaking of which I haven't integrated it into anything either. Although as I choose to add options I'll be able to do it. I've managed to hit my milestones for this week and do some thinking ahead work for week 12 type stuff. Next week is key bindings and menus galore.
In case anyone is curious jIRC is looking more and more like the old codebase. The client is pretty usable now (albeit no dialogs or config options yet). After next week I expect the UI is going to look exactly the same. After week 13 the default script will be in place in which case its going to look like a complete client (at least in screenshots).
10/31/03
Spent some time designing the way scalars will work in sleep. This isn't a jIRC change per se but sleep (scripting language) is a huge part of jIRC so any change to it affects jIRC. Basically I'm trying to make it so array and hashtable containers in sleep are an interface. This way I can bridge other data structures with interface code instead of having to do an expensive conversion from one data structure to another (sleep-friendly) every time the user requests something in the language. I'm also trying to fix some long standing problems with the way I handle arithmetic. I'm a little nervous though because this is a big change and I don't know what it will yield for performance.
I'm thinking all non-object values (strings, longs, ints, and doubles) will be passed around as copies. Every time they are assigned somewhere a copy of the original will be assigned. For objects including hashes and scalars I'm thinking I will pass these around by reference.
I'm also putting some thought into making normal scalars ($variables) have list like behaviors and be able to be treated as lists. i.e. each $scalar could have another scalar linked to it (which in turn could have another scalar linked to it). Then I'd provide like different commands like head(), rest(), tail(), first() etc... and many other lisp favorites. Something I'm thinking about anyways. Lists are powerful and fast and damned it, I like them. This is something I'm thinking about though so stayed tuned. It may or may not happen.
10/30/03
Finished implementing the irc related scripting features. Enough to call the milestone done. The scary thing is I haven't tested any of it. Just coded a shit ton. Its now almost 8pm and I think I'm done writing code for tonight.
All I've gotta do yet this week is implement the user preferences code. This should be pretty easy. Hopefully I'll get ahead and start some other milestone this weekend. Maybe not though, its halloween weekend and I might just be partying alot. Hehe. CIAO
10/29/03
Starting work on the irc related scripting stuff. I've posted a list of irc related functions and the style of naming for built in functions. Please check it out and offer feedback if you have any. Thanks.
