[epiar-devel] Animation Tool

Tue Dec 8 08:59:02 PST 2009

I understand that mentality, and agree with you of course, but this is not one of those cases. The UI won't have bizarre behavior, won't take an abnormally long development time, etc. etc.

In fact, as a rule, I'm against unnecessarily including third party libraries and am still not sure we need PhysicsFS: reading archive formats is a very easy task (libz, for example, literally includes ISO C replacement functions for fopen, fread, fwrite, etc.), and writing the interesting abstraction it gives us would have been a trivial task, and until I get a chance to look over the PhysicsFS branch, that's still preferable in my mind. PhysicsFS does apparently have some kind of caching and optimization practices, but at the cost of being forced to implement any missing archive formats in the PhysicsFS code ourselves (apparently libbz2 isn't supported and 7z support doesn't work?), as well as having to deal with a build system that's remained questionable since we first began using it.

Pick your poison I suppose.

On Dec 8, 2009, at 8:46 AM, Maoserr wrote:

> Well, I'm more concerned about having a UI system that works well rather  
> than favoring any specific one, as long as it works and isn't too  
> different from expected behavior from OS UIs, I'll be fine with it.  One  
> thing I do have to caution is that we don't spend too much time coding  
> stuff that's not critically necessary.  Ostensibly, everything coded from  
> scratch is better suited to our purpose, but sometimes it's better to just  
> slap in a third party library, even if it's not optimal, and replace it  
> later with our own code when the need arise.  In my opinion, it's much  
> easier to abstract third party library interfaces so that it's replaceable  
> in the future than to write the functionality from scratch.
> 
> On Tue, 08 Dec 2009 11:30:16 -0500, Christopher Thielen <chris at epiar.net>  
> wrote:
> 
>> I disagree. Part of the idea behind writing our own UI for Epiar is that  
>> it would benefit both from development in Reipel and development in  
>> Epiar. Ultimately, we could produce a UI that works fast and well, and  
>> has the widgets and organizational complexity we need. After all, if  
>> every other DOS program in 1992 wrote their own UI, I'm sure we're more  
>> than capable. :-)
>> 
>> That said, I'd also like to state that wxWidgets, QT, and GTK+ are, from  
>> my experience, overly complicated and oddly designed (most UIs are).  
>> wxWidgets, in particular, is rather hard to debug should something  
>> actually go wrong after the compile, and it seems awfully silly to have  
>> built a cross platform UI only to add another cross platform UI to the  
>> dependency list.
>> 
>> I also suggest we consider a different name for the Epiar Editor (and  
>> no, 'Epiar Editor' is not an okay name). Epiar Mission Builder is an  
>> alright name. It doesn't have to be an arbitrary name, e.g. Reipel.
>> 
>> My idea for ... well let's just call it Epiar Mission Builder, or EMB  
>> for now, was to have it mainly be a tool for working with the scenarios  
>> (and/or missions) themselves in a graphical manner (if anyone's ever  
>> used the Descent: Freespace-included Editor, that's a pretty close  
>> model), but it would also include a number of smaller built-in  
>> utilities, accessible via the top menu, to do things like work with the  
>> Epiar archive format (which at this point, looks like it won't be the  
>> .eaf but something like .tgz or whatever PhysicsFS supports), or build  
>> .ani files, etc.
>> 
>> EMB (or maybe just EB?) is a task that I wanted to take and start  
>> building for 0.3.0, because that's both a good time to build it (file  
>> formats stabilizing, we'll need it before too long after that, etc.),  
>> and (don't take this the wrong way), but I've already built an Epiar  
>> before, so I'm more interested in this new bit. :-)
>> 
>> - Chris
>> 
>> On Dec 8, 2009, at 6:41 AM, Maoserr wrote:
>> 
>>> I was actually just thinking about writing a log file parser in python.
>>> 
>>> In the future when we go about writing Reipel (or however it's  
>>> pronouned),
>>> I have a few suggestions on how I think this could work
>>> 1) I believe the .ani parser and log file parser could all be part of  
>>> the
>>> Reipel program (the map editor), so we might want to start another
>>> repository for that
>>> 2) There's a few ways we could go about implementing reipel, but I would
>>> suggest we use WxWidgets or QT to implement the GUI rather than using  
>>> SDL
>>> as it seems better suited for an editor program
>>> 3) The Reipel program could accept python modules (like the .ani parser
>>> and log parser) and so we have a uniform interface (of course it  
>>> wouldn't
>>> hurt also if we can just run the python programs standalone.
>>> 
>>> Of course this is not going to happen anytime soon, but just some  
>>> thoughts.
>>> 
>>> On Tue, 08 Dec 2009 02:49:40 -0500, Matthew Zweig <thezweig at gmail.com>
>>> wrote:
>>> 
> <snip>
>>> 
>>> 
>>> _______________________________________________
>>> epiar-devel mailing list
>>> epiar-devel at epiar.net
>>> http://epiar.net/mailman/listinfo/epiar-devel
>> 
>> 
>> _______________________________________________
>> epiar-devel mailing list
>> epiar-devel at epiar.net
>> http://epiar.net/mailman/listinfo/epiar-devel
> 
> 
> _______________________________________________
> epiar-devel mailing list
> epiar-devel at epiar.net
> http://epiar.net/mailman/listinfo/epiar-devel