Re: [E-devel] Epplets vs plugins

[Christian K. <kre...@in...>]

Hi,


*hug* :) This email contained everything I felt needed to be said for a
long time. Thanks :)

"Carsten Haitzler (The Rasterman)" wrote:
> 
> now we can ask - do we make external epplets C or ferite? or both? do we now
> just have 1 external epplet hanlder (if its ferite) that timeslices (or even
> uses threads) - or do we run 1 ferite epplet interpreter per external epplet?
> what kind of mecanims do we use to do this... what will the external api be? it
> needs to leave a slittle work for the eppelt author as possible and do things
> quickyl and magically for them...

I think on the one hand it should be really easy to put together the
layout of an (external) epplet. That was the case for e16 epplets, it
was simple. At the same time I think that coding the rest of an epplet
(the actual features it provides) is not any easier than any other
(small) application, especially because of the flexibility that they
need. Therefore I'd use ferite exclusively for the e17 plugins (it'll be
great for that) and stick with C for the epplets.
 
> i think it's time for a .e_iconbar directory containing a bits file for a layout
> of not just icons for the iconbar on a desktop - but layout of where file icons
> go (for files int he dir) where epplets et laid out - and al the other things we
> plan on putting on a desktop or file view...

Yes! Yay! A mechanism to provide an *integrated* layout mechanism for
everything needed in a view, say a bunch of icons to have around for
apps/files commonly needed in that directory (I guess that was the
original idea of the iconbar), epplets, a status line (size of the
directory etc). Very nice.

Cheers,
Christian. 
-- 
________________________________________________________________________
                                                    http://www.whoop.org