Enlightenment

> Yet another lib? Is this one really necessary?
> I looked a bit at this one and I don't really see the use.
> What's the main purpose - that will save the programmer time?

An obvious use I can see for this is epplets :) (just a guess, I may be
wrong). Epplets generally have limited visual space, and they roughly
all have the same display/input handling needs. So such an api is (imho)
ideal to help keep the epplets' code free of display/input handling,
concentrating on what they have been written for (checking the number of
unread emails for example :)).

Cheers,

Rached

On Sun 03 Nov 2002, enlightenment-cvs@... wrote:
> Enlightenment CVS committal
> 
> Author  : rephorm
> Project : e17
> Module  : libs/eprog
> 
> Dir     : e17/libs/eprog
> 
> 
> Modified Files:
>       Tag: SPLIT
> 	configure 
> 
> 
> Log Message:
> 
> Ooops, test wouldn't build due to missing include dir.
> (thanks marmot)
> 
> ===================================================================
> RCS file: /cvsroot/enlightenment/e17/libs/eprog/Attic/configure,v
> retrieving revision 1.1.2.1
> retrieving revision 1.1.2.2
> diff -u -3 -r1.1.2.1 -r1.1.2.2
> --- configure	3 Nov 2002 04:18:47 -0000	1.1.2.1
> +++ configure	3 Nov 2002 20:26:22 -0000	1.1.2.2
> @@ -125,7 +125,7 @@
>    OUTPUT=$EXE
>    BUILDFLAGS=""
>    LDFLAGS=$LDFLAGS" -L./ -L/usr/local/lib -L../src "$LIBS 
> -  CFLAGS=$CFLAGS" -I. "$INCLUDES
> +  CFLAGS=$CFLAGS" -I. -I../src "$INCLUDES
>    echo "Building tool..."
>    $CC $BUILDFLAGS $CFLAGS $SRC $LDFLAGS $EXE_LINK -o $OUTPUT
>    cd ../src
> 
> 

eprog_test SEGV.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 24520)]
0x4005d652 in evas_render_updates (e=0x120000c) at evas_render.c:65
65         MAGIC_CHECK(e, Evas, MAGIC_EVAS);
(gdb) bt
#0  0x4005d652 in evas_render_updates (e=0x120000c) at evas_render.c:65
#1  0x400a6f97 in e_idle () from /usr/local/e17/lib/libeprog.so.0
#2  0x40034a19 in ecore_event_filter_idle_handle () at e_ev_filter.c:95
#3  0x40038292 in ecore_event_loop () at e_events.c:309
#4  0x08048c49 in main ()
#5  0x400cd5b0 in __libc_start_main () from /lib/libc.so.6

The segv happens immediately after drawing the contents of the window.

I thought there was some MAGIC_CHECK bug thingie that had been fixed in
evas? (not sure, but it rings some bell). And yes, my evas build is dated
October 29, so I'm sure that's not the problem.


-- 
                               |  /*\
Ibukun Olumuyiwa               |  \ /  Join the ASCII Ribbon Campaign
http://www.xcomputerman.com    |   X   against HTML mail today!
                               |  / \

enlightenment-cvs@... wrote on Fri, Nov 15, 2002 at 05:50:39PM -0800
> Enlightenment CVS committal
> 
> Author  : rephorm
> Project : e17
> Module  : libs/eprog
> 
> Dir     : e17/libs/eprog/src
> 
> 
> Modified Files:
>       Tag: SPLIT
> 	eprog.c 
> 
> 
> Log Message:
> 
> silly me.
> don't segfault on resize if no resize handler has been set

Having a few error on ./configure,./make and ./make install.
Compiling and make install on the libs is no prob but fail to compile
the test prog tho'.Maybe you can look into it.Thanks

Error during ./configure & ./make :

Ok.
Building library...
Building test app...
test.c: In function `main':
test.c:64: warning: passing arg 2 of `eprog_resize_handler_set' from
incompatible pointer type
/tmp/ccgdmCEK.o(.text+0x32): In function `main':
: undefined reference to `eprog_shaped_set'
/tmp/ccgdmCEK.o(.text+0x43): In function `main':
: undefined reference to `eprog_borderless_set'
/tmp/ccgdmCEK.o(.text+0x57): In function `main':
: undefined reference to `eprog_title_set'
/tmp/ccgdmCEK.o(.text+0x70): In function `main':
: undefined reference to `eprog_name_class_set'
/tmp/ccgdmCEK.o(.text+0x83): In function `main':
: undefined reference to `eprog_min_size_set'
/tmp/ccgdmCEK.o(.text+0x2a9): In function `main':
: undefined reference to `eprog_move'
collect2: ld returned 1 exit status

CaT.
-- 
JC Wong,Singapore   http://polaroids.webhop.org/~catalyst
  ICQ: 19663610               catalyst@...          
---------------------------------------------------------
A man was reading The Canterbury Tales one Saturday morning, when his
wife asked "What have you got there?"  Replied he, "Just my cup and Chaucer."

Hmm, looks like i forgot to do a list reply.
Just so everyone else knows, if you have errors while compiling the test
program after doing a cvs update it is because it is trying to link the new
test program against the older installed version of the library. So, one
solution is to ./make install and then ./make again.
sometime i should get around to fixing this. in the mean time, if anyone else
wants to, feel free.
--
brian

Hi,

I've been watching E development recently and I've notices that EFM's
replacement hasn't even been started (well apart from the UML). I know that
Christian Kreibich and Mandrake (two of the main EFM developers?) either no
longer have the time, have jobs etc. or are not longer interested in
developing E at the moment(?).
I think that evas2 would be a great place to start a filemanager and I was
intensly impressed with EFM (mmm.. typebuffer). EFSD is just sitting in CVS
waiting to be used and I was wondering if anyone had any plans to go ahead and
restart development on the filemanager?
I don't know what Raster's plans for the filemanager are.. is it e18?
I for one would love to start work on it but unfortunately won't be able to
touch it for at least 6 months due to other commitments.
Is there anyone else interested in EFM or is it dead?

Mark P.

Mark Phalan writes:
 > I've been watching E development recently and I've notices that EFM's
 > replacement hasn't even been started (well apart from the UML).

   Quite the contrary; evidence is fully functional and after some
   final touches will be released RSN.  At the time, I also intend
   to freeze the API.

 > I think that evas2 would be a great place to start a filemanager

   evidence builds against evas2.  It can also build against
   gnome-canvas, but you miss all the sexiness then.
   evas2 is used for a fully themable icon-view (where all engines
   are shared objects, so you can easily extend functionality without
   anyone crying bloat).

   evidence also has the mandatory tree-view, and a browser-view a la
   NeXT/Step or Mac OS X which has proved invaluable in handling for
   instance mp3-dirs.

 > and I was intensly impressed with EFM (mmm.. typebuffer).

   evidence features a typebuffer which will likely get more integrated
   with Escreen over time -- as in, start a text-mode app from typebuffer,
   send output to a tab in Eterm.

 > EFSD is just sitting in CVS waiting to be used and I was wondering

   Like about everything else, file-backends are pluggable shared
   objects in evidence.  evidence doesn't much mind if meta-data come
   from a POSIX backend or whatever, so adding a backend for your
   favourite file-system abstraction (gnome-vfs, efsd, kio, ...)
   should not be an issue.  I am contemplating adding an efsd-backend
   after the gnome-vfs one, unless of course you want to jump the gun. ; )

 > if anyone had any plans to go ahead and restart development on the
 > filemanager?

   Been there, done that.
   Additional coders welcome.

 > is it e18?

   Man, we haven't even released e17.  : (

 > Is there anyone else interested in EFM or is it dead?

   Far from it.

   rgds,
 Azundris




Screenshots:   http://evidence.sourceforge.net/screenshots/
"If you don't like what you see, make a better theme!"

Source:
cvs -z3 -d:pserver:anonymous@... login
(There's also RPM-download, but since I've been keeping busy, that's not up-to-date
 most of the time)