Re: [E-devel] /usr/local/include/Ebg.h:118: variable or field `obj' declared void
Jakub Troszok writes: > On Wed, Jan 15, 2003 at 03:04:39AM +0200, Elias Pouloyiannis wrote: > > As I was informed in http://e1x.codewordt.co.uk the file manager > > component was removed from e True. > > (AFAIK essence will become the file manager) "How many times!?" :-S There is no "essence." > > You can try out evidence ( http://evidence.sf.net ) which can emulate > > the look of the e file manager > > (though when i tried it i saw that it opens each view in the same window > > so you won't get exactly the same feel) This is correct, and given the shelf, there *technically* is no need for a second window. I do acknowledge however that a lot of *like* to have several windows, and that evidence should accomodate them. Prelim code to address this exists, but needs debugging. I definitely want *stable* multi-windowing for v1.0. > But the question is why efsd is needed ? > And fam ? And why they are running when > there is no file manager by default ? efsd is used to monitor e17's setup files (so e17 can re-read them when they change -- it could reasonably be argued that this isn't really necessary, and that sending the process a HUP might be just as good, but). efsd uses fam for the actual monitoring. regards, Azundris --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] debian
Hi, I know this doesn't really have much to do with E17 itself, but I was wondering if the debian subdirs were good enough to be able to create my own debian packages out of with a few tweaks here or there or if I should just stay away from them for a while. Thanks, Paul --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] debian
On Wed, Jan 15, 2003 at 10:11:38AM -0800, paul merchlewicz wrote: > Hi, > > I know this doesn't really have much to do with E17 itself, but I was > wondering if the debian subdirs were good enough to be able to create my own > debian packages out of with a few tweaks here or there or if I should just > stay away from them for a while. > > Thanks, > Paul For most of the tree, yes, I use them fairly often. There may be a few places that need fixing up or updating though. -- | Nathan Ingersoll \\ Computer Systems & Network Coordinator | | [EMAIL PROTECTED]\\ http://www.ruralcenter.org| | http://ningerso.atmos.org/ \\ Minnesota Center for Rural Health| msg00153/pgp0.pgp Description: PGP signature
Re: [E-devel] debian
In the past I've had so many problems with the configure, make, make install process with other programs that I'm trying to keep my system "installed by package". This is for me and me alone (even if it should take a little more to do). I guess I just noticed the debian directories there and was wondering if they were actually usable (ie. better and cleaner than the ones that I would probably make myself). Paul. On 15 Jan 2003 18:24:29 + Andrew Elcock <[EMAIL PROTECTED]> wrote: > I don't really know what you mean - are you > installing or distributing? > > if installing just follow the notes on > enlightenment.org - it worked for > me. > > If you are distributing yo are on your own - > sooms a tad early... > > Well - that my tuppence worth > > Andy > > > On Wed, 2003-01-15 at 18:11, paul merchlewicz > wrote: > > Hi, > > > > I know this doesn't really have much to do > with E17 itself, but I was > > wondering if the debian subdirs were good > enough to be able to create my own > > debian packages out of with a few tweaks here > or there or if I should just > > stay away from them for a while. > > > > Thanks, > > Paul > > > > > > > --- > > This SF.NET email is sponsored by: A Thawte > Code Signing Certificate > > is essential in establishing user confidence > by providing assurance of > > authenticity and code integrity. Download our > Free Code Signing guide: > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en > > > ___ > > enlightenment-devel mailing list > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- > Andrew Elcock > Rectang.com > > --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] /usr/local/include/Ebg.h:118: variable or field `obj'declared void
> > (AFAIK essence will become the file manager) "How many times!?" :-S There is no "essence." again... that's not my personal opinion. it was only something i read on http://e1x.codewordt.co.uk on a post that as i understood was refering to the essence cvs module... well whatever > > You can try out evidence ( http://evidence.sf.net ) which can emulate > > the look of the e file manager > > (though when i tried it i saw that it opens each view in the same window > > so you won't get exactly the same feel) This is correct, and given the shelf, there *technically* is no need for a second window. I do acknowledge however that a lot of *like* to have several windows, and that evidence should accomodate them. Prelim code to address this exists, but needs debugging. I definitely want *stable* multi-windowing for v1.0. correct. multi-windowing also addresses many other isues (like what happens if you try to view a directory that is being viewed and other) still it would resemble that good-old-loving amiga feel that efm gave me well i can allways wait for the stable release.. (hey...come to think of it... will evidence create desktop icons?) > But the question is why efsd is needed ? > And fam ? And why they are running when > there is no file manager by default ? efsd is used to monitor e17's setup files (so e17 can re-read them when they change -- it could reasonably be argued that this isn't really necessary, and that sending the process a HUP might be just as good, but). efsd uses fam for the actual monitoring. regards, Azundris my point exactly :) --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] !!Ecore!!
as some of you may have noticed... i'e started redoing ecore. for those of you following the code commits going into the SPLIT branch of ecore, you'll know what I mean. i did put some api ideas in there a while ago looking for ideas/comments. not much happened, so i've just scurried along and redone the core event loop now. why you ask? the previous one was a mess. the api wasn't that good either, and it was becoming a bit of a nightmare. i've got (now) what i think is a pretty slick and solid core loop abstraction there in the new ecore code. it works (i've actually tested it now). it provides: timers: they can be one of or (NEW!) repeating (if they return 0, they are 1 off, if they return 1 they will repeat themselves). They work and are really clean. They get passed a data pointer that you can set on timer setup time. They are very accurate in my tests and seem to keep time very well (for now the accuracy is about 0.2 seconds on my machine here (that's the maximum variance of a repeating timer that i've seen), so i'm willing to say most of the accuracy issues would be OS/hardware/box load related. you can add and delete timers and they seem to work. idle enterers: this is what the idle handler used to be called in ecore. it is called once when the ecore main loop is about to "go idle" and wait for more events to be processed. this is normally where you have the program update its current state for the user on screen (or so). the program has stopped processing things and has come to an idle state. you can add and (NEW!) delete these handlers (NEW!) ilders: these are called CONTINUOUSLY in a loop while ecore is waiting for events. these are good for things a program has to do that require non-blocking polling or continuous handling. a call to these doesn't trigger going back into an idle state so if these calls update things that an idle enterer displays the program needs to post a dummy event on the event queue or such to break out of this state. fd handlers: these are generic file descriptor handlers that become active if that file descriptor has any data available to read from or the buffer is available to write to. these can be used for file I/O, network I/O, (and this means, X, IPC and many other things too). They are a generic building block that lets the main loop function and multiplex everything. You can add and delete them signal events: unix signals interrupt anything. they can ruin non-re-entrant code. they can kill programs executing x calls WITHIN the signal handler. The solution is to just have the handler set some flags nd handle the signal later in the event loop. ecore does that for you by turning the signals into events in the event stream. executable "exit" (SIGCHLD) become evens with process id and termination codes as events. if they were directly launched via the ecore launching calls you get the handles generated by them as well. termination, quit and interrupt signals become events too to be handled gracefully. as do (NEW!) SIGPWR and "user defined" signals (SIGUSR1, SIGUSR2) and (NEW!) SIGHUP. the application no longer needs to handle signals and can just loop through its event loop nicely. (NEW!) event posting: the application can create and post its own events to the event queue. it can create new event types and do this cleanly (NEW!) execution: you can execute programs and not have to wait for them to finish (ala system()). You get a process handle back and can attach data to the handle, as well as get events when the child process dies. no zombies are generated as pid exit status is collected for you. time: you can get the current time as a convenient floating point (double) number so you can easily compare times without special code to handle seconds and sub-seconds (milliseconds or nanoseconds) differently. (NEW!) application handling: being able to access the applications command-line arguments any time by storing them globally,and being able to modify them and restart the application (unfinished) using the cmd-line arguments it was started with. now i think this covers a LOT of the most core and BASIC application handling. can anyone suggest anything else? anything that would belong in the area of handling executing of the app, and events/signals etc. now i think about it i think i'm missing a "semaphore lock" handler so u can put some event etcher in a thread and when it becomes active have ti break the select etc... not sure how i'd handle this though. need to think the next thing i need to deal with is: X11, IPC, Job queues, etc. now this isn't "Core" app handling. i'm thinking of making these modules as they all use either fd's (so fd_handlers can deal with them) or can just synthesize events and add an event handler for them. now the question is.. do these modules belong in ecore... ? should i make a bunch of optionally compilable modules (X11, IPC etc.) separate libraries (libecore_x11.so) or separate projects? i'm currently tossing this up, BUT
