Re: [E-devel] Exchange
http://exchange.enlightenment.org/index.html has an error that suggests there is a permissions problem with the MySQL database. Im franticly trying to get it back up online but I dont know nearly enough about the problem to fix it. -Toma. On 24 May 2010 17:57, Dave Andreoli wrote: > I can confirm also the exhange API is down :( > dave > > 2010/5/24 Tom Haste : >> Hi all, >> >> http://exchange.enlightenment.org/ >> >> is now a 500 error. Can someone please fix this? :| >> >> Toma. >> >> -- >> >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] How do I get my gtk themes to apply to gtk apps under e17?
On 05/26/2010 02:30 AM, David C. Rankin wrote: > 02:27 alchemy:~> ls -1 .gtkrc* > .gtkrc-2.0 Oh, no, Do NOT attempt to start gnome with the ~/.gtkrc-2.0 file in place. I'm sure it is something specific with my config, but __it hit the fan and soon as I attempted to start gnome after running e17 while leaving ~/.gtkrc-2.0 in place. The machine lost its mind and required a hard reset as all console input was met with 'Cannot allocate memory' and there was no way to ssh into the box. The errors were: May 26 18:39:55 alchemy init: cannot fork, retry.. May 26 18:40:32 alchemy syslog-ng[1927]: last message repeated 7 times May 26 18:40:36 alchemy init: cannot fork, retry.. May 26 18:41:32 alchemy syslog-ng[1927]: last message repeated 11 times May 26 18:41:36 alchemy init: cannot fork, retry.. May 26 18:42:33 alchemy syslog-ng[1927]: last message repeated 11 times May 26 18:42:36 alchemy init: cannot fork, retry.. May 26 18:42:36 alchemy init: cannot fork, retry.. May 26 18:42:45 alchemy sshd[3796]: error: fork: Cannot allocate memory May 26 18:42:46 alchemy init: cannot fork, retry.. May 26 18:43:05 alchemy syslog-ng[1927]: last message repeated 3 times May 26 18:43:05 alchemy sshd[3796]: error: fork: Cannot allocate memory May 26 18:43:07 alchemy init: cannot fork, retry.. May 26 18:43:33 alchemy syslog-ng[1927]: last message repeated 5 times May 26 18:43:36 alchemy udevd[721]: udev_event_run: fork of child failed: Cannot allocate memory May 26 18:43:37 alchemy init: cannot fork, retry.. May 26 18:43:37 alchemy udevd[721]: udev_event_run: fork of child failed: Cannot allocate memory May 26 18:43:42 alchemy syslog-ng[1927]: last message repeated 11 times May 26 18:43:42 alchemy init: cannot fork, retry.. May 26 18:43:42 alchemy udevd[721]: udev_event_run: fork of child failed: Cannot allocate memory May 26 18:43:47 alchemy syslog-ng[1927]: last message repeated 11 times May 26 18:43:47 alchemy init: cannot fork, retry.. May 26 18:43:47 alchemy udevd[721]: udev_event_run: fork of child failed: Cannot allocate memory May 26 18:43:52 alchemy syslog-ng[1927]: last message repeated 11 times May 26 18:43:52 alchemy init: cannot fork, retry.. May 26 18:44:02 alchemy syslog-ng[1927]: last message repeated 2 times May 26 18:44:02 alchemy udevd[721]: udev_event_run: fork of child failed: Cannot allocate memory May 26 18:44:07 alchemy syslog-ng[1927]: last message repeated 11 times May 26 18:44:07 alchemy init: cannot fork, retry.. May 26 18:44:07 alchemy udevd[721]: udev_event_run: fork of child failed: Cannot allocate memory May 26 18:44:12 alchemy syslog-ng[1927]: last message repeated 11 times May 26 18:44:12 alchemy init: cannot fork, retry.. I think I'll alias an e17 and gnome start that copies into place and removes the file to be safe in the future. :p -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Adding new ssh keys to svn.enlightenment.org
On Wednesday, 26 May 2010, at 23:58:31 (+0200), Andreas Volz wrote: > yesterday I added a second key to ~/.ssh/authorized_keys2 on > svn.enlightenment.org and my access was working again. But hours > later the file was back the old. I repeated it multiple times. Commit your keys to SVN in the devs tree. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "Well done is better than well said."-- Benjamin Franklin -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Adding new ssh keys to svn.enlightenment.org
Hello, yesterday I added a second key to ~/.ssh/authorized_keys2 on svn.enlightenment.org and my access was working again. But hours later the file was back the old. I repeated it multiple times. Does someone know more about it? regards Andreas -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 screenlock still will not accept password - had to go to xlock
On Wed, May 26, 2010 at 09:39, David C. Rankin wrote: > Guys, > > I ran into this problem the last time I worked with e17 ~ 9 months or > so ago. > The problem is when the screensaver activates and the e17 lock is activated, > there is no way to unlock the session without killing X. There is no > individual > lck/lock process to kill. The only workaround is to use 'xlock' as the lock > process which makes me miss out on the great looking e17 unlock screen. > > I can't recall where we left the issue last, but has there been any > progress on > this issue? My setup is E17-svn-r48925 on opensuse 11.0 using dmitry's rpms. > Any > thoughts, tests, workarounds, etc.. would really be appreciated. Sounds like a PAM problem for me. E17 normally uses PAM for the password, so you should check your PAM settings in you distro, or if the packages of E you're using are properly built with PAM support. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore Event Handlers
On 05/26/2010 03:51 PM, Gustavo Sverzut Barbieri wrote:
> On Wed, May 26, 2010 at 3:45 PM, Christopher Michael
> wrote:
>> Hi all,
>>
>> I ran into a snafu wrt acpi stuff. Keep in mind that some of the things
>> mentioned here are not in svn yet. I'll try to iterate the short version:
>>
>> acpi bindings get added to e_config. When e_acpi is initialized, we
>> create event handlers for the events specified in e_config so that when
>> the event fires we can call any existing binding(s) (ex: When Adapter is
>> unplugged, dim the screen. So we create a handler for the
>> acpi_ac_adapter event). In e_config, we will potentially have two
>> acpi_ac_adapter events...one for plugged (dim the screen), one for
>> unplugged (undim the screen).
>>
>> The problem that I ran into is this:
>>
>> During acpi_init, when creating the event_handlers for ac_adapter, two
>> event_handlers get created (plugged& unplugged). The problem is that
>> because 2 handlers get created, when the ac_adapter changes, the events
>> are firing twice :( (ex: ac_adapter is unplugged, event fires to dim the
>> screen), but because 2 event handlers were created the event gets fired
>> againso now we are getting two calls to dim the screen, even tho the
>> second "handler" is really for undim.
>>
>> The second handler is really for when ac_adapter gets plugged back in,
>> but due to the nature of how devices are handled in acpi, we don't have
>> separate E_EVENT_ACPI's for adapter. This could be fixed by
>> adding/changing E_EVENT_ACPI_AC_ADAPTER_PLUGGED/UNPLUGGED, but this
>> would also require E_EVENT_ACPI's to be created for every possible
>> device state: (ie: battery_charging, battery_removed, etc, etc).
>>
>> Obviously, I am against this approach as we really have no way of
>> knowing all the possible states that any given device supports...hence
>> why I took the generic approach of using one E_EVENT_ACPI for a given
>> device, and passing it some params that could then be acted on (ie: when
>> the ac_adapter event fires, it's "params" will be 0 or 1 depending on
>> adapter state, lid event has "params" of 0 or 1 for open/closed, etc, etc).
>>
>> What I would like to do is add an ecore_event_handler_type_get function
>> because the Ecore_Event_Handler struct is not exposed via API.
>>
>> Reasoning here is: we add the event handlers to a list during init, so
>> what I could do is before adding those handlers to the list, I could
>> iterate the list and check that a handler for that type has already been
>> added, and skip it, etc, etc.
>>
>> Would anyone be against the addition of ecore_event_handler_type_get ??
>> If so, are there any thoughts on a better approach to this problem ??
>
> I'm not sure I understand what you mean. This situation should be
> similar to others we already have, like ECORE_EVENT_SIGNAL_EXIT that
> carries in the event structure the reason of the event (see struct
> _Ecore_Event_Signal_Exit).
Ok, let me try to clear this up a little then:
2 event handlers get added for one event (E_EVENT_ACPI_AC_ADAPTER).
One handler is supposed to handle "plugged in", the other "unplugged",
but both use the same E_EVENT_ACPI_AC_ADAPTER.
Now, the event comes in (adapter gets unplugged).
e_acpi receives the event via ecore_event_handler twice because of the
two bindings (plugged & unplugged), but really only one event occured
("plugged")so "plugged" event ends up getting called twice.
>
> I see no problem registering twice the same event, just the callbacks
> need to handle it differently, like for plug you use func1 and for
> unplug you use func2, they would do: if (!ev->plug) return and if
> (ev->plug) return respectively.
>
This is where the "rub" might be ... all events are handled by the same
callback. Inside the e_acpi_cb_event, we check for any bindings that
relate to the event, and call the bindingsPerhaps I just need to
rethink that event callback stuff
dh
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore Event Handlers
On Wed, May 26, 2010 at 3:45 PM, Christopher Michael wrote: > Hi all, > > I ran into a snafu wrt acpi stuff. Keep in mind that some of the things > mentioned here are not in svn yet. I'll try to iterate the short version: > > acpi bindings get added to e_config. When e_acpi is initialized, we > create event handlers for the events specified in e_config so that when > the event fires we can call any existing binding(s) (ex: When Adapter is > unplugged, dim the screen. So we create a handler for the > acpi_ac_adapter event). In e_config, we will potentially have two > acpi_ac_adapter events...one for plugged (dim the screen), one for > unplugged (undim the screen). > > The problem that I ran into is this: > > During acpi_init, when creating the event_handlers for ac_adapter, two > event_handlers get created (plugged & unplugged). The problem is that > because 2 handlers get created, when the ac_adapter changes, the events > are firing twice :( (ex: ac_adapter is unplugged, event fires to dim the > screen), but because 2 event handlers were created the event gets fired > againso now we are getting two calls to dim the screen, even tho the > second "handler" is really for undim. > > The second handler is really for when ac_adapter gets plugged back in, > but due to the nature of how devices are handled in acpi, we don't have > separate E_EVENT_ACPI's for adapter. This could be fixed by > adding/changing E_EVENT_ACPI_AC_ADAPTER_PLUGGED/UNPLUGGED, but this > would also require E_EVENT_ACPI's to be created for every possible > device state: (ie: battery_charging, battery_removed, etc, etc). > > Obviously, I am against this approach as we really have no way of > knowing all the possible states that any given device supports...hence > why I took the generic approach of using one E_EVENT_ACPI for a given > device, and passing it some params that could then be acted on (ie: when > the ac_adapter event fires, it's "params" will be 0 or 1 depending on > adapter state, lid event has "params" of 0 or 1 for open/closed, etc, etc). > > What I would like to do is add an ecore_event_handler_type_get function > because the Ecore_Event_Handler struct is not exposed via API. > > Reasoning here is: we add the event handlers to a list during init, so > what I could do is before adding those handlers to the list, I could > iterate the list and check that a handler for that type has already been > added, and skip it, etc, etc. > > Would anyone be against the addition of ecore_event_handler_type_get ?? > If so, are there any thoughts on a better approach to this problem ?? I'm not sure I understand what you mean. This situation should be similar to others we already have, like ECORE_EVENT_SIGNAL_EXIT that carries in the event structure the reason of the event (see struct _Ecore_Event_Signal_Exit). I see no problem registering twice the same event, just the callbacks need to handle it differently, like for plug you use func1 and for unplug you use func2, they would do: if (!ev->plug) return and if (ev->plug) return respectively. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Ecore Event Handlers
Hi all, I ran into a snafu wrt acpi stuff. Keep in mind that some of the things mentioned here are not in svn yet. I'll try to iterate the short version: acpi bindings get added to e_config. When e_acpi is initialized, we create event handlers for the events specified in e_config so that when the event fires we can call any existing binding(s) (ex: When Adapter is unplugged, dim the screen. So we create a handler for the acpi_ac_adapter event). In e_config, we will potentially have two acpi_ac_adapter events...one for plugged (dim the screen), one for unplugged (undim the screen). The problem that I ran into is this: During acpi_init, when creating the event_handlers for ac_adapter, two event_handlers get created (plugged & unplugged). The problem is that because 2 handlers get created, when the ac_adapter changes, the events are firing twice :( (ex: ac_adapter is unplugged, event fires to dim the screen), but because 2 event handlers were created the event gets fired againso now we are getting two calls to dim the screen, even tho the second "handler" is really for undim. The second handler is really for when ac_adapter gets plugged back in, but due to the nature of how devices are handled in acpi, we don't have separate E_EVENT_ACPI's for adapter. This could be fixed by adding/changing E_EVENT_ACPI_AC_ADAPTER_PLUGGED/UNPLUGGED, but this would also require E_EVENT_ACPI's to be created for every possible device state: (ie: battery_charging, battery_removed, etc, etc). Obviously, I am against this approach as we really have no way of knowing all the possible states that any given device supports...hence why I took the generic approach of using one E_EVENT_ACPI for a given device, and passing it some params that could then be acted on (ie: when the ac_adapter event fires, it's "params" will be 0 or 1 depending on adapter state, lid event has "params" of 0 or 1 for open/closed, etc, etc). What I would like to do is add an ecore_event_handler_type_get function because the Ecore_Event_Handler struct is not exposed via API. Reasoning here is: we add the event handlers to a list during init, so what I could do is before adding those handlers to the list, I could iterate the list and check that a handler for that type has already been added, and skip it, etc, etc. Would anyone be against the addition of ecore_event_handler_type_get ?? If so, are there any thoughts on a better approach to this problem ?? dh -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Elementary widgets leaking icons/content
Hi Guys! Some elementary widgets (all that have icons and are being used in editje, at least) are leaking the icons/content. The current behavior is: when I set an icon, the old icon is unreferenced and the swallow that contains the icon is hidden. So, the icon not appears, but still live! I don't know if the correct approach is delete the last used icon when I'll set the new icon. But, IMHO, makes sense. Can I implement this approach to delete the old icon in elm__icon_set or only write a warning about it in the docs? Delete the old when the new is set makes sense to the content too? BR, -- Fabiano Fidêncio ProFUSION embedded systems http://www.profusion.mobi -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] e17 screenlock still will not accept password - had to go to xlock
Guys, I ran into this problem the last time I worked with e17 ~ 9 months or so ago. The problem is when the screensaver activates and the e17 lock is activated, there is no way to unlock the session without killing X. There is no individual lck/lock process to kill. The only workaround is to use 'xlock' as the lock process which makes me miss out on the great looking e17 unlock screen. I can't recall where we left the issue last, but has there been any progress on this issue? My setup is E17-svn-r48925 on opensuse 11.0 using dmitry's rpms. Any thoughts, tests, workarounds, etc.. would really be appreciated. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] How do I get my gtk themes to apply to gtk apps under e17?
On 05/26/2010 01:55 AM, Lionel ORRY wrote: > The other way, if you want to keep homogeneous with your configured > Gnome desktop, is to launch gnome-settings-daemon at e17 startup. A > bit more memory consuming, but will not mess with your actual > configuration since it will take care of applying it the same way as > on your gnome desktop. > > regards, > Lionel Thanks Lionel, Maybe we should think about having e17 check for ~/.gtkrc-2.0 and ~/.gtkrc-2.0-e17 and if either is present -- use it. That would allow a separate gtk config for e17 without placing a ~/.gtkrc-2.0. Like kde, etc.. does it: 02:27 alchemy:~> ls -1 .gtkrc* .gtkrc-2.0 .gtkrc-2.0-gnome-color-chooser .gtkrc-2.0-kde .gtkrc-2.0-kde4 Nothing fancy, just a simple: [[ -r ~/.gtkrc-2.0-e17 ]] && . ~/.gtkrc-2.0-e17 in the e17 setup or wherever it should go for e17. Just a thought. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
