[Scummvm-devel] Splitting common/util.h -> engines/util.h, maybe splitting common

[Johannes Schickel]

> You see, my personal vision is that common/ should contain:
> * glue code between backends and frontends (such as FSNode, error/warning,
> Archive, ...)
> * generic data structures (Array, List, HashMap, ... but
> also Rational, Rect, ...)
> * algorithms
> * code that can be used by backends, engines, GUI, base, such as the XML
> parser, zlib wrapper, ...
> 

I agree that we should have glue code, data structures and algorithms in 
common/.

> Everything else is a bit dubious, in my eyes at least. If it is used by
> several main level "directories", then it may have some justification in
> there, but should be carefully reviewed.
> 
> Now look at common/util.h. These days it contains tons of stuff -- and most
> of it is only interesting for engines (and on some cases for the GUI /
> command  line code). I am talking about things like platform & language
> keys, render modes and GUI options.
> 

Personally I think we should keep at least keep the language enum in common/, 
since it is also used for the translation code etc.

We could move the platform code to engine/, but not sure whether that is worth 
the effort. Seeing how often we add new platforms to the enum, I don't think 
it's a big reason to move it to a new engines/util.h.

Minor bits: I also would say we should move hexdump from utils.h to one of the 
debug realted output functionality headers. Since it seems to be primilary 
used for debugging purposes.

> Going beyond this, there is now quite some more code in common/ which I
> wonder about:
> 
> (1) dcl.* -> used only by engines/
> (2) serializer.h -> used only by engines/ -- and by its unit tests
> (3) macresman.* -> used by engines/ plus common/quicktime.cpp
> (4) winexe*  -> used by engines/ and graphics/ (for Windows cursor/font
> support) (5) quicktime.* -> used only by audio/ (though I guess the plan
> is to use it from video/ eventually, too?)
> 
> 
> For 1 & 2, they seem to clearly belong into engines/ , unless I am missing
> something.
> 

The serializer could really be moved to engines/ yes.

> Then there are 3 and 4, both are about accessing files in a certain
> "encoding". So is  5, quicktime.cpp. So is common/iff_container.* (which I
> did not list because so many main level dirs use it).
> 
> These are all files that are of interest for multiple modules, but *only*
> for frontend modules. They all are about certain decoding certain (file)
> formats. They are relatively generic for that. Maybe it's time for another
> module? Either a top-level one ("formats/" ? "decoders/" ? ), or one below
> common/ ("common/formats/" ? "common/decoders" ?) ?
> 

So let for a moment consider that we would have a special directory for those 
"archive" file formats like the Mac resource fork code or the Win32 executable 
code. Having them in formats/ might make sense. But why do we only have 
archive/bundle file formats there then? Shouldn't we move the audio file format 
code, video file format and/or graphics file format code there then too? The 
name would suggest we handle all kind of file formats there then.

> Note that more stuff could be put in there, if viewed from this angle: E.g.
> the XML parser, the config-file.* code, even unarj.* and unzip.* (the
> latter is, like the XML parser, also used by backend code).
> 

Well if we had a formats/ directory then this sounds sensible.


In fact I would also suggest we move all the read/write stream code to a new 
subdir of common too. We have quite a few files for it now and it could help in 
cleaning up the common/ dir a little. We 

// Johannes