It's a possibility, but it would require changing/adding a lot to LGM. First off, I'd have to force LGM to do an operating system check (which it currently doesn't have to do). Then, I'd have to add several different entries in the preferences.properties file for each operating system.

I've also noticed that Java has a java.awt.Desktop.edit(File) which can be used to launch the editor associated with the file as per the user's operating system. This may be a solution. Of course, you'd still use the Preferences.properties (or any overriding method) to override the default system editor - especially useful if the system doesn't have a default editor, or if you'd like to use a different editor for GM games than whatever the system default is (e.g. your system editor is something fancy for large-scale graphics, like GIMP, but when working with GM, you'd like to use something more pixel-oriented, like Paint[.net]/Pinta/KolourPaint.
There is a slight issue that this method returns instantly and returns void, making it hard to tell when it's done, etc., but this is not much different from our currently exec() method, which we simply resolve by wrapping it into a file monitor which we've written (listens for changes to the file specified).

Edit: Unfortunately, apparently Linux (or at least Ubuntu) doesn't define any system editors, so Desktop.edit always fails on Ubuntu...

Looking over your list of suggested tutorials, those things would be best on the Wiki, and I see no reason to prevent someone (like yourself, or any interested party) from writing them up now.

Paint.NET is Windows-only, ruling it out as a candidate for "de facto". In the past, we tried to use an image editor that most computers already had installed. This turned out to be Gimp. However, Ubuntu's removal of Gimp in default installs (not to mention, its incredible difficulty to use for simple tasks) has given us reason to seek a replacement. In the meantime, the default is still Gimp. If you have it installed, it will be used as your sprite and background editor.

Pinta may be a good option. I haven't heard of it before, but looking at the screenshots, it seems to be everything I wanted from JEIE. My biggest concern is its dependency on Gtk#, which may cause Windows users to disapprove.

I should also mention that this location can be changed in LGM's preferences - the same place you change the external sprite/background/sound editors.

Fede-lasse: Looks like a good starting point. Let's try to get our other ideas more concrete.

And, I thought you could tell by my specs that it won't be as horribly gay as GM8 in a number of ways, including keyboard accessibility.

LateralGM has a preferences.properties file which stores all the default external editors.
More information on how to change this value is documented in our wiki:
http://enigma-dev.org/docs/Wiki/Overriding_settings

We have been frequently chewing on the idea of a built-in sprite editor, but it seems like a lot of a hastle when an external editor works just fine, and instead of spending time building a sprite editor, we can instead spend that valuable time on more useful features in LGM, like fixing bugs, or getting it to fully support everything that GM8 introduced.

There was a side-project started ages ago for a built-in sprite editor, which we were building from the ground up, called JEIE (Java Easy Image Editor), but after developing some of the basics of it, and not getting any help, I paused development on it so I could focus on LateralGM again.

http://enigma-dev.org/forums/index.php?board=7.0
Tips, Tutorials, and Examples forum.

./lib

Which should translate to: In the same directory as LGM itself, please create a folder named "lib", and place your libs inside it.

1) Yes.
a) Now
b) Now
c) Now
d) Now
e) Soon (if not now)
f) Not planned
g) Not planned (Game is in C++, not Java)
f) Yes. We're currently considering Solaris.

2) It's already there. To select which platform to compile for, go to Enigma Settings (should be in the tree), and click on the API tab. Please notice that you need to have a C++ compiler capable of compiling for the intended platform.

3) Libs are already supported, as they are completely UI-side (LGM). In fact, we even have our own lib format called LGL. Extensions are not fully supported at this time, but we're working on it (should be mostly if not entirely UI-side). DLLs are already supported.

4) There are plans to create our own format, however it will NOT be proprietary (we were thinking zip text-based), and I don't expect it to happen anytime terribly soon. If it happens, we will do our best to make it backwards compatible with GM (meaning that you should be able to open a .LGM/ENIGMA file and save it as a .GMK/GM6), and it is guaranteed to be fully frontwards compatible with GM (you will be able to open a .GMK/GM6 and save in our special format).


Also, you should consider joining the IRC, where most development chat happens. irc.freenode.net #enigma-dev

You may make suggestions for the GUI here. However, if you think it may be a bug or something that should probably be in LGM anyways (rather than just an idea), consider posting it on the LGM Mantis: http://sourceforge.net/apps/mantisbt/lateralgm

I don't really like that idea because what does it mean to search an individual Sprite or Background? Because they would essentially be selectable.

That gives me the idea to also apply an "Object" scope for searching as well, which would be the default when the user presses Ctrl+F with an object in focus, rather than a script.
We'll need some more brainstorming on how to search an object, or possibly multiple objects, kinda like Retro mentioned above.

I think I could make another Event Tree which would have checkboxes next to each of the events, and would show only the events that the object has. Question is, where would I put said tree?

I'm looking to implement a somewhat competent Find/Replace feature into LGM. I'd like some input on what options you think would be good, how to lay it out, etc.

Fields:
* There will be a text field for Find
** There will be an option for regex (anybody think wildcard would be necessary?)
* There will be a text field for Replace
** This will accept regex backreferences if the Find is a regex.
* There will be separate buttons for Find, Replace Once, and Replace All.
* There will be options for search scope:
** The current script
** Another open script
** 1 All scripts
** 2 Resource names
** 3 All DND Action Arguments
** Any combination of 1, 2, and 3. (gui suggestions on how to present these options appreciated)

Functionality:
Upon pressing Ctrl+F anywhere in LGM, this dialog will appear. If it was pressed from within a script, it will be scoped for that script by default. Otherwise, it will be a global search (some combination of 1, 2, and 3 - suggestions for a default scope appreciated)
Initially, the Search textfield will have focus, and will be populated with the contents of the [clipboard | current cursor selection]. Pressing the tab key will switch focus to the Replace textfield immediately.
Pressing enter while the search textfield is in focus, and no input was given to the replace textfield, will only perform a Find.
Pressing enter with the replace textfield in focus and with text will perform a Replace Once. Holding down a certain (as of yet undetermined) key will perform a Replace All.

Ideas:
Some sort of tree structure for displaying results of performing search on global scope. Maybe even flatten single-child parent nodes (e.g. only one sprite was found, so display Sprites/spr_name, compared to Sprites/ \n \t spr_name. This example use branch/leaf, but the same would be applied to branch/branch as well).
Although it might be difficult to implement, a way to undo a full find/replace, in case it turns out badly.

Concerns:
How would focus traversal work for options? Right now it goes: Find Text > Replace Text > Find Button > Replace Once > Replace All

Global Searching should also take into account Room Creation and Instance Creation Codes.



If anybody wants to draw up the way they think it should be laid out, that'd be awesome.

I kinda like Lime Green on Black.
Or lime green on red :-p

I've commited r678, which includes all the LGM bugfixes I mentioned, plus the new TargetHandler system I've been working on which will hopefully mean that the Options Panel shit is done now.