Slaad's Programming Stuff

So I just figured I'd post a bit more in the way of proof that I am working on Snoopy. This time it is the all new, all singing, all dancing BuddyView. And along with it the better-laying-out BBMPView. The BuddyView, like the MSGGView requests views from Snoopy to do stuff for it (In this case a view to handle Bitmaps). The BuddyView allows a user to import, export, add and delete a buddy icon for a Person. So now... a picture.

BuddyView: Because it'd be boring to type a thousand words to describe all your friends...

I worked on Snoopy a bit today and yesterday. And as a result I present three new plugins and two improved ones. I need to go through and do some rework on the older plugins. But it's something the end user will be unlikely to notice (It's to do with laying out the plugins when they are drawn). And now in the tradition of this site... pictures...

MSGView, PointView, RectView and a reworked GeneriView

Here we can see the better-laying-out GeneriView (All the attributes above IM:ChatSettings). The MSGView (IM:ChatSettings) asks for a plugin to display its internal data from Snoopy. In this case it has been given a RectView for the windowrect member and a PointView for the inputdivider member. Moving along...

Pretty!

And here we see my artistic side (Hah!) coming out. Or at least some colours. This is for the RGBC attribute. I'm sure I could come up with something witty if I were so inclined, honest!

If you read the previous Snoopy entry you'll see that I've been working on the repeating schedule stuff. Part of this is a field schedule:interval which is stored as a string but needs to represent a casual date. So, something like "10 seconds" or "next friday" would be valid. Something like "Wang time" would not. I whipped up a new plugin - the IntervalView which gives the user graphical feed back on the validity of their input. Which you can see in the next two images...

10 seconds; Good!

Snoopy: Because it's never time for wang!

So, there you have it. I'm not sure if I need to add a similiar thing to the normal TimeView because it changes your input to the date your casual input represents.

So I've been working on Snoopy a bit. Actually, that's not strictly true. I've been working on a background application I'll bundle as part of Snoopy. This app will be responsible for repeated scheduling. What's that? Repeated scheduling? Yup. It's rather powerful as well. I've added 4 more "public" attributes to my scheduling filetype; schedule:repeatStart, schedule:repeatEnd, schedule:interval and schedule:repeatLimit. There's also a schedule:repeatCount, but you shouldn't play with that. schedule:repeatStart / schedule:repeatEnd determine the period of time the event should repeat for. schedule:interval is the frequency of the event and schedule:repeatLimit can be set to a number if you want to repeat X times, rather than for a date period.

An example, if you will. Lets say my neighbor has gone away for the week and wishes me to feed her cat at 6pm for the next week. I'd set up a Snoopy Scheduled event with a schedule:repeatStart of today and a schedule:repeatEnd for "next week" (Snoopy will convert this into a proper time). I'd then set the schedule:interval to be "6pm" - again, internally this is converted to work out the next time the event is due. I could also set the schedule:repeatCount to 7, as they're only gone for a week. Now after each 6pm + the event length each day the event would get rescheduled for the next day. Cool, huh?

Oh, there was one other thing... oh, yeah, it can also be used to launch programs. So you could set up an event that zips up your email and burns it to CD every week.

So today I did a fair bit of work on Snoopy. This included moving the Template settings into individual files. The reason I did this? Well, I figure that developers may wish to distribute a Snoopy template for a filetype their app uses, and now they can. I plan to do this with The Snoopy Scheduling System.

Other changes include the FileListView being able to drag 'n' drop export correctly. I also wrote two little utilities; IMParticipants and EmailParticipants. These are part of The Snoopy Scheduling System and allow you to IM and Email all participants for a schedule. Works as a Tracker addon, too.

I've also began fixing the BuddyIconView which is used to display IM Kit Buddy Icons.

Annnnd now for a picture. This is actually from some work a while back, but it's the new fixed up IMConView. It allows you to add an IM connection to a user nice and easily. It grabs the list of protocols installed from the im_server.

IMConView: Allowing me to be more schizophrenic than ever!

Yeah, so, I mean, I meant to have a release out shortly. But I'm a horrible person and a liar, it seems.

ie. I've been busy with Uni. I plan to devote today to Snoopy. Honest, Mum!

So, I've been working on Snoopy, again. It seems the vast majority of work for each release is not in Snoopy itself, but in the prefs. I seem the recall the same thing happening with EMouse. Why can't you damned users be content with text files? I kid, I kid.

Anyhow, the next release will see two modifications to AttributeView. First of all, Snoopy Prefs will look for BView *setup_view(BMessage *preferences). This function can return a BView to allow the user to configure the plugin. Most plugins shouldn't need this. Some will. The TimeView plugin is the only one that uses this so far, because I know not everyone likes their dates in ISO format. The second thing it'll look for is status_t get_plugin_info(BMessage *info). The developer of a plugin can fill the BMessage with information hand crafted by small elves, er, I mean... information pertaining to the plugin. The information all my plugins include is; author name, email and URL and a brief description. But you could put whatever you want in there, from your shoe size, to the day of the week the user will see best results on (Hopefully days ending in y).

Snoopy Preflet: Because pictures are tradition

So, looks like I'm going to have to expand the Template system. At the moment it matches solely on name, which should be right for most of cases. However I'd like the Template system to, at least optionally, always display controls for all attributes, even if they don't exist. Currently I do a search of the attributes for one matching the name given in the Template. If I find one, I read it and get a view from the attribute's type / name combo. However, if the attribute doesn't exist, I only have the name. Which is not always going to be sufficient for finding the right plugin to display the attribute.

As a result, Templates are going to require the storing of type, as well. I'm unsure of how I like this. As it stands, I think that the system for entering Templates is already too complex. Having to enter an attribute type may be the straw that breaks the proverbial camel's back. Perhaps if I do a find-as-you-type feature that completes the attribute name and type as you enter it, it may be more intuitive? Thoughts are, indeed, welcome.

So I've been working on a set of attributes, and their associated plugins, for the purpose of a scheduling system. I've added a percentage, file list and a date/time addon. The results can be seen somewhere in this news post, if you look very carefully.

Snoopy Plugins: Because I want to take over the world

I just now got an email from Dave of Waldo Web Design, who, a while ago, I asked for an icon for Snoopy. Well, I now have one. I find it rather cute, personally.

Snoopy Icon: Because it looks purdy!