The Dink Network

Hello good denizens of the Dink Network. I am currently working on Easy DinkC version 2 and I've come to a point where I would like some testers and some feedback. For a little taste of the goods, take a look at a screen shot I just made.

However, there's a little draw back. I develop in Linux, and thus you will probably need Linux to do testing for me. I know there are a few people on here who run Linux all the time or occasionally, so to those of you who do -- I want your help.

How to get the source code is described here. You will need autoconf, automake, GTK+, libglade and GtkSourceView. There may be more stuff, you'll know when you try configuring and compiling.

What I want from you testers are ideas for improvements, feature requrests and patches (If you know how to code C, just make your modifications, create a diff file and send it on over. If your stuff is good enough, I'll even let you join in as an official co-developer!)

You non-testers who are watching this thread: Feel free to give me improvement ideas and feature requests too. Seeing the code and actually running the program will make it easier than just looking at the picture, though, but I'm sure the brightest of you can come up with stuff I can add anyway.

Windows users: There will be no proper release version until I also have this working on Windows. For now, it's simpler to just work on Linux, as it follows POSIX standards and crap, and then just adhere to Windows' strange quirks later. For the moment, though, just enjoy the screen shot. It's a little simple so far, but after all, the only things working are New, Save, Save As, Close and Quit, as well as the About dialog. Expect niftier screen shots as I progress.

Some details that may not be gathered from the screen shot alone:
* Syntax highlighting is real-time
* Bracket matching is enabled (As you can see by the starting bracket of the main function is matched by the end bracket further down)

Sure, I'll play around a bit. But:

(easydinkc:16486): libglade-WARNING **: could not find glade file 'edc.glade'
** (easydinkc:16486): WARNING **: Problem loading the window. Aborting.

I installed a bunch of libglade and libglade-dev packages (including libglade0 and libglade2), yet it still doesn't want to open? I make-installed this thing if that's of any importance.

Hmm. I'll test it. I'll get on it as soon as possible.

You need to run the file from the "src" folder where the edc.glade file is. I haven't configured it far enough that it runs off the installed location, sorry. It's beta after all, heh.

I'll work on getting installation to work properly before I go to work this morning.

You can download it from here, DinkDude. You'll need to compile it yourself. Using Linux, you probably know how that's done, eh?

Will grab it when I'm back from college later today.

The latest revision now supports "make install".

Okay, the program runs now, even though the commandline still complains:
(easydinkc:8391): libglade-WARNING **: could not find glade file 'edc.glade'

The syntax highlighting works very well. I am loving the fact that it colours your text appropiately to the text colour (however, I do not think it should start colouring your text if you do a `1 somewhere else than in the beginning of your string).

Other stuff/ideas:
Undo/redo works well, but could you bind Ctrl+Y to redo too, next to Ctrl+Shift+Z? Same thing basically with tabbing: ctrl+tab as a shotcut key added for that (next to ctrl+alt+PageUp/Down).

Undo/redo can already reside in the Edit menu as they are available features, apparently.

Dragging a file or URL from Nautilus or Firefox results in the program pasting the address as text rather than opening the file. This functionality can, of course, stay for real text that you're dragging over to an application.

When opening a file, I think you should be able to select multiple files to open, or even a tool on the left side of the program that can open and list all scripts from a Dmod. This could be even further improved by telling the configuration dialog where the original Dink is, and always include these default scripts on the left pane too in a different colour to indicate they're unmodified system scripts (like gray). This would make it a LOT easier for a Dmodder to say "I want to edit or overwrite a system script!", open this script in the left pane, modify it and resave it under the current Dmod. The colour of the script in the left pane would then change to a special colour, for example blue, to indicate it's a modified system script.

The font is nice, but could you just use "Mono" as the default? Makes more sense for coding, you should know.

Tabs really are tabs while I like my tabs the size of only two spaces. Could you modify the tab button later on to support "tab display width"?

I'm used to going to the first ACTUAL character in code when pressing Home, instead, it goes to the absolute left, which is usually a tab character. Will you implement this?

I can open the same file multiple times, it'd be more useful if it'd tab-jump to that file instead.

EasyDinkC handles lots of files very well, I have made over 300 files so far and there seems to be no memory and CPU increase at all (some files have some big scripts open, too)! Nice work.

Okay, so the program seems stable, but so far, lacking in some basic features. Will you consider some of my ideas once the basic stuff is out of the way?

Okay, the program runs now, even though the commandline still complains:
(easydinkc:8391): libglade-WARNING **: could not find glade file 'edc.glade'

Aye. I first try loading "./edc.glade" and then the one in the installation location. The first one will
often fail, and thus you get that message. I might fix it, I don't know.

[...]I do not think it should start colouring your text if you do a `1 somewhere else than in the beginning of your string).

Good point. I'll fix that... done!

Undo/redo works well, but could you bind Ctrl+Y to redo too, next to Ctrl+Shift+Z?

I'll see what I can do. I'll save it for later, though.

Same thing basically with tabbing: ctrl+tab as a shotcut key added for that (next to ctrl+alt+PageUp/Down).

Yup. Later. Ctrl+Tab in my window manager switches virtual desktop, though, so it's not a safe shortcut.

Undo/redo can already reside in the Edit menu as they are available features, apparently.

True... if I find a way to programmatically trigger an undo in the control.

Dragging a file or URL from Nautilus or Firefox results in the program pasting the address as text rather than opening the file. This functionality can, of course, stay for real text that you're dragging over to an application.

I'll work on that soon. Thanks for informing me.

When opening a file, I think you should be able to select multiple files to open, or even a tool on the left side of the program that can open and list all scripts from a Dmod. This could be even further improved by telling the configuration dialog where the original Dink is, and always include these default scripts on the left pane too in a different colour to indicate they're unmodified system scripts (like gray). This would make it a LOT easier for a Dmodder to say "I want to edit or overwrite a system script!", open this script in the left pane, modify it and resave it under the current Dmod. The colour of the script in the left pane would then change to a special colour, for example blue, to indicate it's a modified system script.

I'll get to work on opening multiple files. And thanks for the "script library" idea. I'll implement that at some point.

The font is nice, but could you just use "Mono" as the default? Makes more sense for coding, you should know.

Aye. I'll change the default font. The font is going to be choosable later on. I chose "Courier New", though. "Mono" had different width when bold and not bold.

Tabs really are tabs while I like my tabs the size of only two spaces. Could you modify the tab button later on to support "tab display width"?

Yup. Already planned.

I'm used to going to the first ACTUAL character in code when pressing Home, instead, it goes to the absolute left, which is usually a tab character. Will you implement this?

Fixing... done!

I can open the same file multiple times, it'd be more useful if it'd tab-jump to that file instead.

I agree. I'm planning this.

EasyDinkC handles lots of files very well, I have made over 300 files so far and there seems to be no memory and CPU increase at all (some files have some big scripts open, too)! Nice work.

Thanks. Actually, besides my freeing memory where freeing is due, you can thank the makers of GTK and GtkSourceView for it. They code effectively.

Okay, so the program seems stable, but so far, lacking in some basic features. Will you consider some of my ideas once the basic stuff is out of the way?

Most of your ideas are already planned and/or added to my list of things to do now. Thanks for the feedback, I appreciate it.

Screenshot looks nice, but pretty basic still - like notepad except for the colours. Will it look more like v1.4 when done? I can't tell how it works from the screenshot of course, so I'm probably missing something.

I don't have Linux so can't test but I have a question: if you use set_font_color() will the text colour change in Easy DinkC?

Also, I like the highlighting of variables, I presume there's no way for it to know if it's a local or global variable, is there...? It would be nice if it warned if you'd forgotten to 'int' a local, etc.

Sparrowhawk: Indeed it's simple. I've just begun. Almost no code at all in this program. I'm working on changing that, though.

I might do what you say with set_font_color(). I was not really aware of that command, so, no, it doesn't do that yet. I've used the "DINKC Reference v3.1" to gather what functions are legal, and it's not in it, so it's not part of my keyword collection... has the DinkC Reference been updated lately?

About the global variables thing: I'm planning to parse "main.c" for global variables at one point, so I might be able to differentiate between local and global variables at a later time.

I'm also planning a error checker tool, after all, what would a DinkC editor be without one?

DinkC ref. v4.0 comes with Dink v1.08 in the develop folder, it includes all commands new to (or fixed in) v1.08 so it should be quite useful!

A CHM file? Jeez. What ever was the problem with text files?

DaVince: I now support opening multiple files and only opening the same file once.

Actually, the CHM file makes things a lot more structural, and has more explanation/highlighting/tutorials. Besides, there's an excellent CHM viewer for Linux.

I'm aware of that, but that does not cover the fact that extracting data quickly is a lot easier with a text file... there's no grep, sed, awk, cut and similar tools for chm files... with those, I have to extract information manually. THAT is why text files are superior -- they can be manipulated extremely easily.

So magicman, did you ever get around to testing? And DinkDude95, did you get it working?

It be working. So far I can't think of anything other than that the default text colour in say-commands (and family) is yellow. I wish I could write C, though. Looks like an awesome project.

When it comes to feature request, my two most wanted features are D-Mod management and error checking. I saw these two are already planned, so there's no real point in explicitly requesting them again.

Oh, and autocomplete. say_<tab> -> say_stop -> say_stop_<tab> -> say_stop_npc. That'd be cool.

Oh, that reminds me. One of the requests I forgot is to have an autocomplete list pop up when you type a character. You know, Netbeans style. You can then pick your choice from the available selection and press enter or tab to complete the code using that line.

Yeah, that's already planned, DaVince. See the "ideas.txt" file in the "doc" sub-directory.

Pheonix, I haven't got time to test it yet, at the moment I'm on holidays (managed to get Internet access from a library). I'll be back home in about 2 days, so I'll test it then. Oh, and, I don't know how to compile, I'm only a new Linux user. However, my Dad knows alot about Linux, so I'll get him to teach me.

By the way, I have a suggestion, if it's not already implemented, that is (remember, I haven't tested it yet). I suggest a 'pop-out' option. As in, you can press a small button somewhere, and it will close the whole EasyDinkC window, and pop-out with a small Notepad-like window. You know, without all the buttons above and below etc. And in the pop-out, there would be a little button in, say, the bottom right hand corner which un-pops-out.

Also, instead of having multiple windows open with different .c/.ini files, I suggest tabs, like Firefox.

Hm... I'm a little intrigued by this 'pop-out' thing... Could you elaborate on its purpose? I don't really get what the use would be.

I dunno, bigger viewing space, for people who don't bother with all the little buttons?

All right, I'll add it to the "idea" list. As for the tabs, that's how it already is. You'll see when you try it.

DaVince: In the latest revision, you can now modify the tab width. Just open and close the program, then modify ~/.config/easydinkc.conf to your desires.

I'll get testing soon, Pheonix. Don't worry.

Speaking of which, your idea is under way. That is, the current thing I'm working on is your pop-out idea.

Behold! The world's first DinkC editor with an autocomplete capability has emerged! (Screenshot)

Currently it doesn't really do much, as it's just a test, but it works for the "say" commands currently, because I hard-coded them. However, the dirty work for getting it to show and reduce the available choices as one types is done, now I just have to come up with a clever back end.

My hope is that eventually, it will suggest variables (including global ones!) where they are due and functions where they are due.

Here's also a screenshot of the full window from when the autocompleter is showing from the previous screenshot.

suggesting variables and functions...
Nah, such things in programs always fail.
A good idea would be to make it run the script with set settings, or the entire DMOD.

A good idea would be to make it run the script with set settings, or the entire DMOD.

Uh, sorry, I did not understand any of that. Would you care to explain better?

suggesting variables and functions...
Nah, such things in programs always fail.
May I ask... How? Being able to quickly type your variables because you made them earlier on is quite useful, especially if you tend to forget names for some variables. Plus, when project mode comes here, it'll pop up a list of all the global variables too, making things even more easy.

It'd be a good idea either to run a script, given the values of variables, graphics, midi's and such, or to run the DMOD as a whole.

A computer is very unlikely to be able to guess the function the user wants to use.
Suggesting variables is a good idea for romp's, but after a certain number of variables, it would become quite annoying.

To start with, variables could be annotated variables with a type. Technically, they're all integers, but their semantics can be different. For example, something like this:

int &sound = playsound(arguments here)
sp_hitpoints(&sound,5);

isn't going to make sense. &sound will be a "Sound number", while sp_hitpoints expects an "Active sprite number". This will also prevent errors like the following to be made:

editor_seq(&current_sprite,5);

What's wrong? &current_sprite is an "Active sprite number", while editor_seq expects an "Editor sprite number".

And of course, you can go wild with these variable types. "Frame number"s and "Sequence number"s come to mind. The program could even check if a certain "Frame number" variable ever exceeds 50, and give a warning based on that.

Suggesting functions is just like it's shown in the screenshot, but not hardcoded as it's now, and with every function, not just the say family.

And it'd be nice to have additional info in the list of suggestions, using these types, like:
say_stop(string[199], active sprite number)
say_xy(string[199], x-coord, y-coord)
say_stop_xy(string[199], x-coord, y-coord)
say_stop_npc(string[199], active sprite number)

But I guess this wouldn't be too difficult once the backend is set up.

The variable count in most D-Mod projects is rather low: after typing a few characters of a variable name, the list of possible variables has a manageable size and the user can select the desired variable from the list. The computer doesn't have to guess the variable, it simply has to show the possible variables.

A computer is very unlikely to be able to guess the function the user wants to use.

Never used a proper programming tool, I guess. Most programs list the available functions/variables/methods that start with the one to three letters you typed. Then you can press enter or tab to let it fill you in. It's a mighty useful feature, and a lot of programming IDEs actually have such a feature.

I've made quite a bit of progress lately, a huge part of the autocompletion is done, although that doesn't mean there isn't a lot left.

Another little nifty thing I managed today was to get the program running in Windows XP. That's a good sign, it means that it is very likely that I'll have a Windows version for those of you who run that OS, which probably are most of you.

It crashes in Windows from time to time though, but that's something I'll handle when the time has come to release a non-preview version of the program, i.e. when it's at v2.0.

For those of you eager to have a go, and have enough technical know-how, the source repository (see original post) now has a file describing roughly how you make it run in Windows. I say "roughly" because I forgot to write it down as I was messing around, and thus I just wrote down afterwards what I did, which might lack a few key points.

"release a non-preview version of the program, i.e. when it's at v2.0."

Finished products are usually marked as v1.0, not v2.0... Are you sure you want to use the versioning in such a, well, unusual way? V2.0 would only indicate it's mostly rewritten or a LOT has been added since the original release version, after all...

What do you suggest? The last released EDC version was 1.4. Should this be 1.5 or something? It's not like this continues the 1.x line, exactly. This is a completely new, written from scratch EDC. Thus, I feel it is a v2.0 when it's done.

Oh yeah, how could I have forgotten the original? Duh.

You could do it like this, maybe, because it's a complete rewrite and turning out to be quite different so far: EDC 2 v1.0

Yes, I was actually contemplating that versioning scheme, and since somebody else (i.e. you) also suggested it, I might go with it instead. That way I'm able to do pre-1.0 releases also. After all, releasing versions 1.8 as a "pre-release" version just doesn't seem right.

Pheonix, I'm having trouble running it on Linux, so I'll just have to wait till you get release a Windows version. Or, I'll see what you said about doign it myself.

Er, getting it to run in Windows is harder than getting it to run in Linux, heh. And what's the trouble you're having?

Not sure, my Dad's working on it. Something about autoconf something-or-other. I think that's the word. Maybe if he gets the tiem he'll get it working. I dunno.

By the way, how's the pop-out thing going?

The pop-out thing was implemented on the 12th of January. Done and working. Here's how it looks before "pop-out", here's how it looks after pop-out. I haven't myself figured out what this thing would be useful for... But if anybody wants a feature, I'll add it if I can.

The correct order of compilation is "./bootstrap", "./configure", "make". If none of that fails, you'll have a working executable in the "src" folder. Also, you need to make sure the libraries I mentioned in the first post are all installed, else configure will fail.

I'm pretty sure all the libraries are installed. I dunno, I'll continue to look into it, then.

sry for brnging back from grave, but any1 know if theres any progress in dis project plz?

Oh, I thought this was happening NOW...I always miss the date.

Still, it was very interesting read. But too sad that it did not get finished.

Phoenix is still working on this.