[CrackMonkey] [mailman-owner@zork.net: CrackMonkey Subscribe Notification]

[Michael Jennings]

On Monday, 31 July 2000, at 21:51:31 (+0100),
Paul J Collins wrote:

> Who needs sissy alpha-blended file windows with l33t anti-aliased
> TrueType fonts?

I'd much rather have that than a bunch of Windows Explorer wanna-bes
like gmc, kfm, and Nautilus.

I find the typebuffer feature alone makes EFM far more useable than
any other file manager I've encountered.

> Well, GNOME has its place.

Agreed.

> Have you seen E's nasty confguration language?  I'm sorry, but
> all-caps commands, each prefixed by two underlines, is an indicator
> of serious braindamage.

Actually, this is 100% incorrect.  E's configuration language is
actually composed of numbers.  What you're referring to are the config
files before they get pre-processed by epp (a slightly modified cpp).
Thus, you can make E's config language anything you want it to be just
by writing cpp-style macros.

And the underlines have the same purpose they do in C headers and
libraries:  to avoid namespace collisions.  The all-caps is due to the
standard of cpp macros having all-caps names.

On Monday, 31 July 2000, at 13:50:45 (-0700),
Alex Feinberg wrote:

> Yes, why do they use such CPU intensive code? Amiga Workbench, under
> which EFM is modeled (as told by some of the developers) ran on 50
> Mhz, if not slower, machines.

The interface is modelled after WorkBench, but the capabilities are
not limited to what WB could do.  WB did not due 24-bit color
multi-layer alpha-blending and anti-aliased TTF rendering.  EFM takes
advantage of the fact that most people use newer desktop machines with
more RAM and more power in both the CPU and the graphics card.  People
who are still clunking along on old 486/66 machines are probably not
the kind of people who would want to use EFM.

> Dumbest idea I've ever seen. Why use a structure like a database,
> which provides much un-needed overlay, when in fact such a thing
> could be acomplished in a text file -- that would require less code,
> less libraries to link with (gdbm I believe is what EFM asks for)
> and it would be human readable.

This is also not true.  Databases were chosen for one simple reason:
speed of random access to data.  No text file can come close to the
speed of a binary database.

So the choice was made to use GDBM databases.  Unfortunately, GDBM has
major endianness issues, so we've since switched over to NDBM.

People have always complained about how configuring E almost always
involved editing text config files by hand.  By using binary
databases, we not only gain the speed advantage, but we also have
forced ourselves to create GUI tools for doing all the configuration
for EFM/E 0.17.  Take a look at the Bit Editor, EFM Prefs, EFM DB
Edit, and the other GUI tools that come with EFM to see what I mean.

> Of course, databases are needed for many other things, but not if
> there's a much simpler way to implement what's needed.

"Simpler" is in the eye of the beholder, apparently.  Personally, I
don't care what the backend is as long as there are sufficient tools
to manipulate the data to whatever level of granularity I choose.  For
the in-depth hackers, e_db_ed works great.  EFM DB Edit will provide a
GUI equivalent to e_db_ed.  And at the high level, EFM Prefs allows
you to customize all the EFM options from a GUI.  Much simpler than
editing text configs, at least for most people.

> I do not wish to insult enlightenment hackers, I just argue that
> they are going about implementation of their ideas on a completely
> wrong way.

Hopefully an understanding of our reasons will help resolve any
confusion you might have as to the merits of our approach. :-)

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej at eterm.org>
Software Engineer, VA Linux Systems       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "I know that through it all the hardest part of love is letting go,
  But there's a greater Love that holds us."
                                    -- Michael W. Smith, "Pray for Me"