LE Redesigning TESsnip

[fireundubh]

I've been working on usability/productivity improvements for TESsnip. I've created this thread to solicit your ideas for future versions of TESsnip. (Also, I've been in contact with Timeslip, who is the original developer, and he's interested in returning to TESsnip development.)

 

You might not understand everything in these lists if you're not familiar with C# and .NET.

 

Thus far, I've implemented the following (minor) improvements:

 

• Implemented keyboard shortcuts: ESC cancels and closes the focused editor window, F5 saves and closes the focused editor window, and F2 toggles Hex Mode.
   
  
• Implemented a status bar with a colored Hex Mode indicator.
   
  
• Added Copy All and Paste All buttons to the Data Editor. These make replacing FULL name records less tedious. Also, the Ctrl+A shortcut still doesn't work, but I didn't bother after adding the buttons.
   
  
• PluginTree is sorted alphabetically, but I'd rather sort child nodes alphabetically instead of the entire tree for performance reasons.
   
  
• FOMM is now Large Address Aware.
   
  
• FOMM now uses .NET Framework 4, instead of .NET Framework 2. (Mostly in preparation for 4.5, which has native ribbon features.)

 

http://i39.tinypic.com/2dm5y06.jpg

 

 

Here are some of the tasks on my wishlist:

 

• Move TESsnip over to WPF as a standalone application.
   
  
• Overhaul the UI with a sophisticated ribbon UI designed in Expression Blend 4.
   
  
• Place plugin nodes in the ribbon a la Quick Styles in Word.
   
  
• Use modeless windows for the main plugin editor form a la Excel. Windows could then be docked, tabbed, or split for comparisons.
   
  
• Integrate the modal data editor, medium record editor, hex editor, group editor, and header editor forms into the main plugin editor form. The modal design is a productivity killer. I'd want the user to spend more time editing data, not opening and closing windows.
   
  
• Add a context menu to the records tree for easy access to common functions.
   
  
• Dynamically determine whether to use Hex Mode. Manual toggle would override that automation.
   
  
• Allow the user to configure keyboard shortcuts.
   
  
• Allow the user to create blank GRUP records.
   
  
• Allow the user to select multiple records.
   
  
• Allow the user to copy, paste, and delete multiple records at once.
   
  
• Allow the user to attach bookmarks, flags, and notes to records.
   
  
• Use LINQ (or another database) to store plugins and records to improve performance and provide other more advanced functionality.
   
  
• Allow the user to export a single record, or multiple records, from LINQ (or another database) to XML, Excel, etc.
   
  
• Load nodes as needed.
   
  
• Load strings as needed.
   
  
• Correct the record structure for Skyrim.
   
  
• Add help documentation for using TESsnip, as well as for creating plugins.

 

There is at least one database engineer working on redeveloping how TESsnip stores, sorts, and displays records. Currently, TESsnip loads entire plugins into memory and loads all of the records into the PluginTree, which is why TESsnip briefly stops responding when you load Skyrim.esm. Overhauling how TESsnip loads and displays plugins is the primary task, and it's out of my hands because it's beyond my skill set. How I hope TESsnip will work is simple: records will be loaded on demand.

 

Other than everything I've listed above, what else would you like to see? Please try to keep your suggestions limited to improving usability/productivity. Also, if you have C# and .NET experience, your help with completing the tasks above would be greatly appreciated.

[Lucubration]

Some of those improvements would be very useful. Multi-select in the record tree is huge, to keep from needing to re-find records in huge branches to copy, for example, a whole set of armor or leveled item records into a new plugin. That, bookmarking, and creating new GRUP nodes are great ideas.

 

One thing I noticed working in TESsnip is that often times when I would select a range of byte values in the hex editor to copy/paste, the editor would get stuck in "shift-selection" mode so that if I continued to move the cursor without the shift key pressed, it would keep selecting new ranges from the original selection start as the cursor moved. This could be fixed by tapping the shift key again. I don't recall if I had originally performed the selection using shift-click or shift-arrow key. Not a huge priority, but something that's happened a time or two.

 

As for loading records, on-demand loading is a good approach. Maybe try a deferred loading scheme that continues to load the rest of non-requested records from a plugin during idle cycles so that there isn't always a brief pause when opening a new branch/group node (only if you try to open them immediately after loading the plugin before it's been fully loaded in the background).

 

Hmm... what about a way to "Open As" on a subrecord, if you know that a subrecord is of a specific type but it doesn't follow the schema well enough to automatically determine it. That way if you ran into (for example) a DESC or MODL subrecord that didn't match the schema, you could try to open it for editing as if it were a string. The updated schema you mentioned would help in most cases, of course.

 

On Linq, I've noticed that it doesn't really improve performance in most cases. The benefits I've mostly observed with Linq is that it makes it easier to design/create a DAL from an engineering standpoint because it lets you automatically generate the DAL based on the database schema. In some cases, it's noticeably less efficient than doing a stored procedure or direct query, but in other cases it's very useful because it helps you track the user's changes and behind-the-scenes generates a complex SQL statement for you. You just have to be careful using it because in many ways, the 'physical' syntax you use when writing a Linq statement can make a tremendous difference in its performance.

 

An example that bit me when I first starting using Linq:

IQueryable<Record> records = DataContext.AllRecords;

...

records.Where(record.Format == RecordFormats.String);

vs.

IEnumerable<Record> records = DataContext.AllRecords;

...

records.Where(record.Format == RecordFormats.String);

 

It looks like a harmless difference in casting, right? But by casting as IEnumerable, you're now loading and iterating all records from the data context to perform your query, so suddenly it may be loading tens of thousands of rows into memory rather than performing the query on your database. Linq is awesome, in the classical sense of "awesome and terrible", lol.

 

Also, Linq isn't really a database as you're referring to it; it's a query language integrated into your programming language. You still have to make a decision about the actual repository behind it.

Edited December 7, 2011 by Lucubration

[cordsnwires]

• Allow the user to create blank GRUP records.
   
  
• Allow the user to select multiple records.
   
  
• Allow the user to copy, paste, and delete multiple records at once.
  

 

Thank you in advance :)

[Shawkab]

I could use some of that stuff in the thus far category right now ;)

 

Please release this lol.