Yay. Worked on it a bit more. Per the linebreak support I mentioned last time, I think I'll just have a property or some such that will set the newline character(s) in regards to exporting/importing the text. The internal newline character will continue to be '\n'.
GUI features are aiming to emulate VS's. So it has the gutter area for icons, the line numbers, the thin colored bar, and the collapse area. The collapse area and the line numbers can be completely "in house", so no relying on external code or supporting "plugins" for them. The gutter area will probably have EventHandlers for mouse clicks, and possibly hovers as well, so it will rely on externals, too. It would probably make sense for the gutter "plugin" to be built into the Lexer, as that is the only way it'll be able to change the syntax highlighting if needs be(at least right now.) I suppose I could have a default gutter "plugin" that did the standard breakpoint thing...
The other possibly-not-totally-first-party GUI feature is the thin colored bar. I've never found out what the 'technical' term for that is, or if I did, I've forgotten it. I think benryves called his MarkDirty or somesuch. The only thing I recall having seen it ever do is just turn yellow when a line has been edited, green when the edited line has been saved, and possibly red if the line has an error. So I'm currently debating between keeping it in house and having a method to be called whenever the text is saved/committed/whatever that will turn the yellow lines green, or just having it be external. Heck, I should just have an option for the inhouse green/yellow to be toggled and allow for other classes to change the color of the line. It'd probably, again, be tied in either with the Lexer or Library classes. Yay on-the-fly-decision-making.
In order to allow for split viewing as well as another feature(mentioned in the next paragraph), I've seperated the "common" variables of the code editor from the "view specific" ones, and created a CodeView class that will be seperate from the rnfnCodeLite class. Now rnfnCodeLite can be considered the parent of one or more CodeViews. As for the actual split implementing, I'm again debating(any feedback on any of my self-debates in this journal is more than welcome). VSExpress only allows for horizontal splitting of the code editor, and only one split at that. I'm torn between that, and allowing each CodeView to be turned into a container for two more CodeViews of either horizontal or vertical nature(not both). The parent CodeView would not be drawn in this case, but act as the host for the two subs. The downside to this is that it can get messy fast and I don't really see any major need for it. Particularly considering the next feature...
Ever since I'd started working on this editor, however long ago that has been, I'd wanted to do something with that deadspace square stuck in the bottom right corner between the horizontal scrollbar and vertical scrollbar. It is empty and has no use, except on occasion it gets used as a resize handle, but that wouldn't work well in the case of an editor control. I'd thought about just having a window pop up that allowed the user to change preferences, but conversations on #gamedev(mainly with benryves, again) showed some potential problems with this. I've since decided upon another use for it, however. An icon/button(whichever looks best in that little square) will be placed there that will open up a form that contains the code editor in it. This way, you can edit the code in the actual control that is part of the running application as well as have a seperate window(s) with the same code. Changes of course would be across all of the displays.
The benefit of this being that you can have a small window that you can code in while, say, looking at code on the interwebs, without the 'bulk' of the rest of the application getting in the way. When I'd discussed it with benryves, he mentioned it'd be a good idea for it to be a modal window(over top of the others; I just use the less technical term of "stickiefied"). I might end up doing that, but it seems to force the user into having to use it only in modal form. What I might end up doing is, instead of having the same button in the scrollbar deadspace on the modal window's control, have another more-different looking button that toggles whether the modal window is in fact modal or not. If I want to get really fancy, and this idea just occured to me so I've not had a chance to think it through to problems, is also allow the button to be 'dragged' off, and whatever window, if any, you 'drop' it on, the window will become 'attached' to that window. So instead of being overtop everything, it'll just be overtop that one window and pulled up with that one window. Then again, that'd probably be insanely difficult to implement.
Of course, I've managed to think up of some more stuff I'd like to do/implement/whatever that I'll probably forget about and/or never actually do.
GDnet Journal Viewer Thingy
Inspired a bit by Daerax's Journal Comment thingy, I've toyed with the idea of making a custom Journal reader for GDnet. You'd have your favourites/bookmarks off to the side, and an option to check on the most recent journals. Based on your bookmarked journals, it'd check ever so often for journal updates(maybe once an hour?) and comment updates(every 20-30 minutes?), both of which you could read and reply to from within the application. Of course, most people will probably think this is somewhat stupid. Regardless, since there is rumour of the site being redone some time, I'll probably wait till it is redone in case either the format is majorly changed or something is implemented about being notified when someone comments in your journal. wink wink nudge nudge
TiddlyWiki Documentation Exporter
I don't think TiddlyWiki gets enough praise/use. It seems to have quite a bit of potential for, in the very least, small teams. If I ever get around to it, I think it'd be nice to build a library for writing a TiddlyWiki based off of articles or whatnot. Once having gotten that done, I might add onto the library with a code documenter.
Microsoft Document Explorer Replacement?
In line with documentation programs, I'd thought about this awhile back. Microsoft Document Explorer does seem somewhat useful, but it seems to be mostly for Microsoft. Quick Google searches indicate that it isn't redistributable. The "unofficial" viewers that I saw explicetly stated source code wouldn't be available *and* it wouldn't work with just the .NET Framework SDK installed, which leads me to presume it won't be used by non-.NET proggers. So perhaps a competitor is in order(if you know of any, please tell me; I haven't been able to find any, really).
It'd have to have improvements over Microsoft's Document Explorer, becoming a bit modern. I was thinking along the lines of wiki-izing it(and removing its dependancy on IE, perhaps) while retaining the search, index, how-do-I, and contents to some degree. Mostly just the search and index. Now, by wiki-izing it, that may raise the concern that 'critical' and relevant data can be overwritten accidentally, which would be *bad* unless some form of revision was kept in the file format, too. So it'd probably be the original help page couldn't be edited, but you could add your own 'notes' or paragraphs to the main page or the individual sections of a page. This would allow things to be personalized, whether for comments on the stupidity of a requirement to the marking of a specs error.
As long as I'm spouting(no pun intended(maybe)) out these wacky ideas(which, if you like, please, feel free to use!), here is another one. Steam's popularity as a digital distribution program got me to thinking about whether or not there was a need for a 'free' digital distributor for freeware/shareware/demoware and possibly commercialware, too. Instead of having a central server(s), it'd be use a form of RSS/XML. Links could be posted to it from websites or from an installed game/application. Or, when a game/application was installed, it could register the link with Geyser(the name of the program), which would then non invasively ask the user, next time they're looking at Geyser, if they would like to use Geyser with that link. If so, it'd be added with the rest of the links.
These links, always updated, would allow updates, mods, new games to be announced(again, non-invasively) in the program. On occasion, they might suggest a similiar site's link, which could be accepted or rejected. The persons providing the links would have to host the content on their own servers, of course, with possibly a 'key' to prevent others from hotlinking if they so desire. Non-commercialware could be directly downloaded via Geyser, but to start out with, commercialware would redirect to the appropriate page for the user to buy the software.
Thanks for reading! And any feedback is always welcome. :]
Thrice blasted spelling errors! I'm going to have to start using FireFox instead of Opera to write these entries.