[E-devel] [PATCH] Ecore Timer
This patch add the possibility to delay a timer and to know the
pending time before the next wake up.
They should not affect any current code using the timer.
--
Cedric BAIL
From 2789a338fadec7061367790647ee2196fe5e5112 Mon Sep 17 00:00:00 2001
From: Cedric BAIL <[EMAIL PROTECTED]>
Date: Mon, 7 Apr 2008 13:32:26 +0200
Subject: [PATCH] Add ecore_timer_delay and ecore_timer_pending_get.
---
src/lib/ecore/ecore_timer.c | 56 ++-
1 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/src/lib/ecore/ecore_timer.c b/src/lib/ecore/ecore_timer.c
index 480e0a3..93fce30 100644
--- a/src/lib/ecore/ecore_timer.c
+++ b/src/lib/ecore/ecore_timer.c
@@ -97,7 +97,61 @@ ecore_timer_interval_set(Ecore_Timer *timer, double in)
}
/**
- *
+ * Add some delay for the next occurence of a timer.
+ * This doesn't affect the interval of a timer.
+ *
+ * @param timer The timer to change.
+ * @param add The dalay to add to the next iteration.
+ * @ingroup Ecore_Time_Group
+ */
+EAPI void
+ecore_timer_delay(Ecore_Timer *timer, double add)
+{
+ if (!ECORE_MAGIC_CHECK(timer, ECORE_MAGIC_TIMER))
+ {
+ ECORE_MAGIC_FAIL(timer, ECORE_MAGIC_TIMER,
+ "ecore_timer_delay");
+ return;
+ }
+
+ if (timer->frozen)
+ {
+ timer->pending += add;
+ }
+ else
+ {
+ timers = _ecore_list2_remove(timers, timer);
+ _ecore_timer_set(timer, timer->at + add, timer->in, timer->func, timer->data);
+ }
+}
+
+/**
+ * Get the pending time regarding a timer.
+ *
+ * @param timer The timer to learn from.
+ * @ingroup Ecore_Time_Group
+ */
+EAPI double
+ecore_timer_pending_get(Ecore_Timer *timer)
+{
+ double now;
+
+ if (!ECORE_MAGIC_CHECK(timer, ECORE_MAGIC_TIMER))
+ {
+ ECORE_MAGIC_FAIL(timer, ECORE_MAGIC_TIMER,
+ "ecore_timer_pending_get");
+ return 0;
+ }
+
+ now = ecore_time_get();
+
+ if (timer->frozen)
+ return timer->pending;
+ return timer->at - now;
+}
+
+/**
+ *
*
*/
EAPI void
--
1.5.4.GIT
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EWL theming
On 1 Apr, Peter Wehrfritz wrote: > We had already some discussion in the bugtracker (bug #381) about this > issue, but I want to give it a wider audience. To give you a short > overview about the discussion, here the it is in a nutshell. It started > with the question, if the checkbutton needs to be be split into several > widget (as it is now: a container that holds the checkbox and the label) > or if it wouldn't be better to have it in a single widget. The main > reason for this question is/was that if the state of the parent > container (the checkbutton) will change, for example a "mouse,in" event > or a "focus,in", there is no way to change the label or the checkbox. > Although putting it in a single widget would solve this, and we > might/will go that way, it showed a more basically problem, that needs > another - more general - solution. > > To describe the problem more general, if the parent or grandfather or > even higher ancestor will change it look it might to want that some > offsprings will look different, too. For example this is solved in e > menu that the label get a signal "e,state,selected" when the parent is > selected. Although this solution works fine for this case, imagine a > tree where a row is selected (or highlight, why ever) and any label that > has this widget as parent needs to adjust it fg color to be readable, no > matter how many ancestors are between it and the row itself, makes it > much more complicated. And when you concern that any theme action might > do that, like "mouse,in/out", "focus,in/out", "disable/enable" or even > random changes or parent related signals like to have a lighter or no > background, it becomes a very difficult job. > > So here comes my idea, how this could be solved. Any theme part > (actually any edje group) can send a signal to its children. Maybe with > the source set to "this", or some general string. And ewl will pipe them > into the offspring widget theme objects. To reduce some of the upcoming > noise, the theme groups could define if they want to receive/emit > signals, if they want to pipe them directly to their children or if they > want to stop those signals because they have solid bg, so they aren't > affected to those changes. > > Pros: > - theme groups can control the look of the offspring widget > - it is very general solution because the theme isn't constricted to > the signal the library (here ewl) is aware of > > Cons: > - we need to have a way to distinguish between transient signals and > states, because a new created or a revealed widget child needs to know > of the state too, but don't need to know about the whole event history > > Any suggestions are welcome! > > Peter > Just adding a "+1" to this. I have had similar difficulties theming Gtk+ in the past. I admire the old Athena (Xaw) and Motif widget sets because they grant the 'themer' the ability to pick out a widget based on it's parents names and classes as well as it's own. It was somewhat possible to do this with Gtk+ 1.x, but it was a very obscure technique that never quite worked perfectly and failed completely in some apps. I might be wrong, but I think it needs a certain amount of policy dictation to work 100%: "If you want a toolbar-like object, you use this toolbar widget or you risk breaking the user's theme." Maybe there's a better solution, but I can't think of one right now. -- Ethan Grammatikidis 16:32:10 <+flux_control> git blame "struct filled with hex" && shoot_on_sight - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-04-07 07:09:26 -0700
Build log for Enlightenment DR 0.17 on 2008-04-07 07:09:26 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: ecore_li http://download.enlightenment.org/tests/logs/ecore_li.log engage http://download.enlightenment.org/tests/logs/engage.log enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, evolve, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] R: E CVS: apps/e davemds
I've ended up with this odd patch of space between XMMS and 2 XVTs on my smaller screen. It's a good place for modules, and would be better if efm wasn't drawing it's icons in the middle of the screen now. Actually if I may say, I find efm's habbit of putting the icons in the middle of the screen a nuisance; I can't put a bit folder window either above or below them, nor to either side -- Ethan Grammatikidis 16:32:10 <+flux_control> git blame "struct filled with hex" && shoot_on_sight - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] evas-framebuffer.pc.in rename
Hi Unfortunately the addition off expedite_check_engine.m4 in expedite broke the detection of the framebuffer engine in expedite. The course of this is an inconsistent naming of the file "evas-framebuffer.pc.in" which should be named "evas-fb.pc.in" to be consistent with the other engine names. The attached patch renames this file an changes Configure.in and Makefile.am in ecore and evas accordingly. A quick grep in the cvs repository indicates that expedite is the only project that actually uses evas-framebuffer.pc, so the breakage of applying this patch should be minimal. Regards Lars Munch diff -urN e17-orig/libs/ecore/configure.in e17/libs/ecore/configure.in --- e17-orig/libs/ecore/configure.in 2008-03-28 15:38:35.0 +0100 +++ e17/libs/ecore/configure.in 2008-04-07 17:32:33.0 +0200 @@ -606,7 +606,7 @@ AC_MSG_RESULT($want_ecore_evas_fb) if test "x$want_ecore_evas_fb" = "xyes"; then -PKG_CHECK_MODULES(EVAS_FRAMEBUFFER, evas-framebuffer, +PKG_CHECK_MODULES(EVAS_FB, evas-fb, [ AC_DEFINE(BUILD_ECORE_EVAS_FB, 1, [Support for Linux FB in Ecore_Evas]) have_ecore_evas_fb="yes" diff -urN e17-orig/libs/evas/configure.in e17/libs/evas/configure.in --- e17-orig/libs/evas/configure.in 2008-03-14 17:49:47.0 +0100 +++ e17/libs/evas/configure.in 2008-04-07 17:31:04.0 +0200 @@ -1560,7 +1560,7 @@ Makefile evas-cairo-x11.pc evas-directfb.pc -evas-framebuffer.pc +evas-fb.pc evas-glitz-x11.pc evas-opengl-glew.pc evas-opengl-x11.pc diff -urN e17-orig/libs/evas/evas-fb.pc.in e17/libs/evas/evas-fb.pc.in --- e17-orig/libs/evas/evas-fb.pc.in 1970-01-01 01:00:00.0 +0100 +++ e17/libs/evas/evas-fb.pc.in 2008-04-07 17:27:53.0 +0200 @@ -0,0 +1,3 @@ +Name: evas-fb +Description: Evas framebuffer engine +Version: @VERSION@ diff -urN e17-orig/libs/evas/evas-framebuffer.pc.in e17/libs/evas/evas-framebuffer.pc.in --- e17-orig/libs/evas/evas-framebuffer.pc.in 2007-03-31 18:07:43.0 +0200 +++ e17/libs/evas/evas-framebuffer.pc.in 1970-01-01 01:00:00.0 +0100 @@ -1,3 +0,0 @@ -Name: evas-framebuffer -Description: Evas framebuffer engine -Version: @VERSION@ diff -urN e17-orig/libs/evas/Makefile.am e17/libs/evas/Makefile.am --- e17-orig/libs/evas/Makefile.am 2008-02-18 08:20:50.0 +0100 +++ e17/libs/evas/Makefile.am 2008-04-07 17:30:25.0 +0200 @@ -10,7 +10,7 @@ README \ evas-cairo-x11.pc \ evas-directfb.pc \ - evas-framebuffer.pc \ + evas-fb.pc \ evas-glitz-x11.pc \ evas-opengl-x11.pc \ evas-opengl-glew.pc \ @@ -36,7 +36,7 @@ evas.pc.in \ evas-cairo-x11.pc \ evas-directfb.pc \ - evas-framebuffer.pc \ + evas-fb.pc \ evas-glitz-x11.pc \ evas-opengl-x11.pc \ evas-opengl-glew.pc \ @@ -72,7 +72,7 @@ endif if BUILD_ENGINE_FB -pframebuffer = evas-framebuffer.pc +pfb = evas-fb.pc endif if BUILD_ENGINE_GLITZ_X11 @@ -125,7 +125,7 @@ pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = \ - evas.pc $(psoftwarex11) $(psoftwarexcb) $(pdirectfb) $(pframebuffer) \ + evas.pc $(psoftwarex11) $(psoftwarexcb) $(pdirectfb) $(pfb) \ $(psoftwarebuffer) $(psoftwareqtopia) $(popenglx11) $(pcairox11) \ $(pxrenderx11) $(pxrenderxcb) $(pglitzx11) $(psoftwareddraw) $(psoftwaresdl) \ $(psoftware16x11) $(pdirect3d) $(psoftwared16draw) $(popenglglew) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Security problem with e17 screen lock and startx
Hi, Here is a known security problem : - launch an e17 session with startx - lock the screen (with ctrl + l) in order to avoid that others people can use our session - someone (a bad one) kills the x server with (ctrl+alt+backspace) - and get the an opened user session... - or switch to the tty1 with ctrl+alt+f? and then ctrl+c the xserver. Is it possible to forbid the ctrl+alt+backspace and ctrl+alt+f? under e17 lockscreen ? I don't want to use these server flags Option "DontVTSwitch" "True" Option "DontZap" "True" to disable it. This problem doesn't appear with xdm, gdm, kdm, entrance...because the xserver restarts automaticly, but for the addicted "startx" users this problem is a problem. Regards, Guillaume - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Security problem with e17 screen lock and startx
On Mon, 07 Apr 2008 23:54:39 +0200 giggz <[EMAIL PROTECTED]> babbled: this is not a problem with e or e17 - every wm and desktop environment will have this problem. just don't use startx! use a login manager (gdm, kdm, xdm, entrance etc.) stop using startx! just stop! anyone silly enough to use startx deserves the pain they get. u logged into a text console - silly person that did that. > Hi, > > Here is a known security problem : > - launch an e17 session with startx > - lock the screen (with ctrl + l) in order to avoid that others people > can use our session > - someone (a bad one) kills the x server with (ctrl+alt+backspace) > - and get the an opened user session... > - or switch to the tty1 with ctrl+alt+f? and then ctrl+c the xserver. > > Is it possible to forbid the ctrl+alt+backspace and ctrl+alt+f? under > e17 lockscreen ? > I don't want to use these server flags > Option "DontVTSwitch" "True" > Option "DontZap" "True" > to disable it. > > This problem doesn't appear with xdm, gdm, kdm, entrance...because the > xserver restarts automaticly, but for the addicted "startx" users this > problem is a problem. > > Regards, > Guillaume > > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Register now and save $200. Hurry, offer ends at 11:59 p.m., > Monday, April 7! Use priority code J8TLD2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Security problem with e17 screen lock and startx
And I have a little joke about that... A day, I installed a debian, move to unstable, then install deps, then E with entrance. I log in... hmm SHIT ! xterm didn't come with xorg ! :) because of entrance, I was not able to do anything... no apps, not openssh-server installed yet... funny case :). It was a packaged version from alphagemini to test it, but as is seems to not have libpam support, you can't unlock your desktop lock... so I basicaly installed a new one from source... On Tue, Apr 8, 2008 at 12:14 AM, The Rasterman Carsten Haitzler < [EMAIL PROTECTED]> wrote: > On Mon, 07 Apr 2008 23:54:39 +0200 giggz <[EMAIL PROTECTED]> babbled: > > this is not a problem with e or e17 - every wm and desktop environment > will > have this problem. just don't use startx! use a login manager (gdm, kdm, > xdm, > entrance etc.) stop using startx! just stop! anyone silly enough to use > startx > deserves the pain they get. u logged into a text console - silly person > that > did that. > > > Hi, > > > > Here is a known security problem : > > - launch an e17 session with startx > > - lock the screen (with ctrl + l) in order to avoid that others people > > can use our session > > - someone (a bad one) kills the x server with (ctrl+alt+backspace) > > - and get the an opened user session... > > - or switch to the tty1 with ctrl+alt+f? and then ctrl+c the xserver. > > > > Is it possible to forbid the ctrl+alt+backspace and ctrl+alt+f? under > > e17 lockscreen ? > > I don't want to use these server flags > > Option "DontVTSwitch" "True" > > Option "DontZap" "True" > > to disable it. > > > > This problem doesn't appear with xdm, gdm, kdm, entrance...because the > > xserver restarts automaticly, but for the addicted "startx" users this > > problem is a problem. > > > > Regards, > > Guillaume > > > > > > > - > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > Register now and save $200. Hurry, offer ends at 11:59 p.m., > > Monday, April 7! Use priority code J8TLD2. > > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] > > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Register now and save $200. Hurry, offer ends at 11:59 p.m., > Monday, April 7! Use priority code J8TLD2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Steven Le Roux Jabber-ID : [EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
