Y HALO THAR

It would seem that I'd fallen off the face of JournalWorld for a bit. Or maybe I just broke through its space-time continuum. We may never know.

In regards to any actual progress I may or may not have made on my rnfnCodeLite project, I must say not much. I don't think I've worked on it, really, for almost a month and a half. :[ Yay procrastination.

So in order to get myself familiar once more with my code, and because there are areas that needed rethinking/reworking/rewhatevering, I saved copies of the code elsewhere and am writing it from scratch. The good news is that it won't take nearly as long as it did originally to write since I already have it(along with printed copies of the three main bodies) to look/copy from. The bad news is that feature creep may creep in, and I'm already trying to rewrite everything. :/ Fortunately, if I do get tired of it and want to start over, I *did* remember to make a commit to the SVN on the project's GoogleCode...thing before starting over. Go me.

A few main areas that I'm wanting to change are as follows:

Firstly, I'd originaly been writing it with the idea in my mind that I might allow third-party extensions and plugins to be made for it outside of the syntax/intellisense "plugin" system, if it can be called a plugin system. I'm sure I was doing it wrong, plus there were events being fired all over the place and events not being fired where I'm sure there should be. So I've decided to ditch the whole plugin thing. In order to make it lite and fast, any features/'extensions' would be worked in directly with the code. If someone really wanted a custom feature bad enough, the code would be available for them to download and alter(like that's a good idea!)

Secondly, in my previous post long long ago(possibly somewhere on the other side of JournalWorld's continuum), benryves had made a comment about wanting to draw a little box around text and I'd responded by stating I'd thrown in a way for custom drawing to be done. I KINDA LIED. All I had done was added a delegate that could be set and would receive the Graphics and boundary for the text to be done. Nothing else was added in the code to handle this. Seeing as all my code had relied on solely text being in the data for the syntax, this would screw everything up. Prior to the delegate, each SyntaxNode node had variable for the text, the fore color and the back color(background). So "foobarbiz" with bar colored differently than "foo" or "biz" would be split into "foo"-"bar"-"biz" in a LinkedList data structure(one of these was in each TextNode which was, subsequently, thrown in its own LinkedList under Text) along with their associated colors. I had intended on adding options for certain common intellisense drawings such as dashed lines, jagged lines, a box, a dashed box, underlined, italics, bold, weblink, etc., all along with their own colors. These 'enhancements' would have been contained within the Rectangle bounds of the string in question, so any and all width concerns would have been based solely on the text. The entirety of the text contained within the various SyntaxNodes of a TextNode was kept in a seperate StringBuilder in its entirety, which, when changed, would reparse the whole line(might have-been/will-be changed as a flag so multiple edits can be done between renderings without being parsed between each edit), creating a new LinkedList for the DrawLine function to in turn parse and render onto the screen where appropriate. Throwing the delegate in there means that I would have to have some manner of calculating the drawn area seperately and calculating the width of each SyntaxNode seperately, regardless of whether it is custom data or a string(I've toyed with adding icons, which might not cause the same problem since I would draw them as a square, with a width/height of the Font property's height), causing more calculations. In addition the the extra work, I would also not be able to properly use TextRender.MeasureText's results as they would probably be incorrect due to the fact that I would have access to the Graphics of the control itself withing either SyntaxNode or a wrapper class I considered writing, Syntax. I might just throw it out and try to offer as many common drawing features as possible.

Now, after that long flippin' a** paragraph(I apologize to the grammar sensitive), on to number thirdly. Wait, I'm not sure I've gotten far enough in my rewrite for there to be a thirdly... If there were, I'd probably say... that dratted text selection thing I never got to. I think putting that off is why I haven't worked on this thing in forever. :/ Meh. Maybe I should just yank out the event firings, the custom drawing, and keep the rest of the code, and go ahead and get text selection working. Except, if I *were* to take out the event firings, that leads us to my fourthly...

Fourthly(and here I wasn't sure if I even had a thirdly), the undo/redo engine. It was going to depend on the event firings, although I'm tempted to just incorporate it directly into the Text class, so whenever the text *is* edited(all of the string manipulating/editing is done, of course, through Text), it would just be all *voila!* and whatnot. Except then I wouldn't know what event(copy/paste/cut/backspace/delete/whateverelse) was the reason for this undo action. :/ Unless, of course, I were to make Text access the clipboard in place of the control, so the control would call, say, CopyFromClipBoardToLine(23)(No, I don't actually write my functions like that. At least, not usually.) and Text would actually know it was a Copy event and could tell the Undo/Redo engine that... Hmmmm... >_> I might have to start using this journal more often to get these ideas.

So that's basically it for the rnfnCodeLite project right now. I hope to work on it more this evening once I finish this horrificily long journal entry(making up for all this lost time!)(and no, it isn't quite done, either!)

Pakiz was just a quick thing I did one day so I actually had a finished project to my name that I hadn't written when I was 18 or under. :D It just allows for you to alter the Accessed/Written/Created time of a file. The only 'problem' that I've noticed so far is that when you alter any of the three, other than the Accessed time, the Accessed time itself is changed to whenever you changed the other two. Probably something I should change, if I thought anyone would ever use the program(though I did put some actual work into designing the GUI, believe it or not.)

I have been tossing around the idea, and have already worked on it to some extremely small degree, of a task/idea management program, called Mnemosyne's Tablet(Clicky for those who don't know who Mnemosyne is.) Instead of displaying tasks/ideas as a list or other linear structure, I was thinking along the lines of having the actual program divided into two seperate "halves". Really three areas shared between two controls(e.g., when the mouse was over or had been over one side, that side expanded to take up 2/3's of the program's client area, while the other side shrunk to 1/3, and vice versa). The right side would contain the actual data of a task/idea. I hadn't actually decided as to what the data would be, but I was debating between either plain text and a wiki type setup. Plain text would probably be easiest/least-problematic, but the wiki type setup would allow more types of data to be shown(but then I'd feel the need to include all non-web data(images,files,etc) in the task's file). The left side would be the actual task/idea layout area. It'd basically be an open space with the tasks position in there(I was planning on going for a cloud/elliptical border around the task/idea names). These could be dragged around on the space to allow for a certain order, should the user choose, that their eye would place some importance too(say for a game project, artistic types to one side, programming types to the other). Lines would be drawn between the tasks/ideas depending on the dependency of the tasks. And so on and so force. Clicking on a task/idea would bring up its data on the rightside pane. Double clicking would cause the control to zoom in, as it were, from the general plane to the plane of the task in question. This would allow multiple levels of tasks/ideas. On the top most plane, you could have basic tasks such as "Finish rnfnCodeLite" and "Advertise for rnfnCodeLite". Zooming in on "Finish rnfnCodeLite"(possibly being shown at 45% completion) would reveal the tasks for it. Say one of them were "Undo/Redo engine". Double clicking that(taking us to, basically, "root"/"Finish rnfnCodeLite"/"Undo/Redo engine") would reveal the various tasks that were required for this task. Not sure if I'll ever finish it, as the only reason I started was the delay of capnmidnight's management software(cause, you know, he just has to have a life outside of coding)'s release. Not sure if the idea is even a good one.

I was going to rant and rant about something I talked about in #gamedev today, OSes, their current state, the 'need' for a new one, and the things it would/should/could do and implement to be a better OS, but I think this is a long enough entry for one day(hope I don't break any size restrictions[disturbed]), and it'll give me something to talk about tomorrow, so I don't wait eons between my posts.