Cedric BAIL ha scritto il 23/10/2015 alle 21:36:
> On Fri, Oct 23, 2015 at 7:12 AM, Carsten Haitzler
> wrote:
>> On Fri, 23 Oct 2015 08:02:30 +0200 Massimo Maiurana
>> said:
>>> Cedric BAIL ha scritto il 22/10/2015 alle 00:47:
Hi,
On Wed, Oct 21, 2015 at 3:38 PM, Massimo Maiurana
On Fri, Oct 23, 2015 at 7:12 AM, Carsten Haitzler wrote:
> On Fri, 23 Oct 2015 08:02:30 +0200 Massimo Maiurana said:
>> Cedric BAIL ha scritto il 22/10/2015 alle 00:47:
>> > Hi,
>> >
>> > On Wed, Oct 21, 2015 at 3:38 PM, Massimo Maiurana
>> > wrote:
>> >> I rebuilt EFL/E from current git and for
On Fri, 23 Oct 2015 08:02:30 +0200 Massimo Maiurana said:
> Cedric BAIL ha scritto il 22/10/2015 alle 00:47:
> > Hi,
> >
> > On Wed, Oct 21, 2015 at 3:38 PM, Massimo Maiurana
> > wrote:
> >> I rebuilt EFL/E from current git and for some reason my startup
> >> application didn't start anymore. I
Cedric BAIL ha scritto il 22/10/2015 alle 00:47:
> Hi,
>
> On Wed, Oct 21, 2015 at 3:38 PM, Massimo Maiurana wrote:
>> I rebuilt EFL/E from current git and for some reason my startup
>> application didn't start anymore. I thought that wiping out the efreet
>> cache could make all working again, b
Hi,
On Wed, Oct 21, 2015 at 3:38 PM, Massimo Maiurana wrote:
> I rebuilt EFL/E from current git and for some reason my startup
> application didn't start anymore. I thought that wiping out the efreet
> cache could make all working again, but instead it made evrything not
> displaying applications
I rebuilt EFL/E from current git and for some reason my startup
application didn't start anymore. I thought that wiping out the efreet
cache could make all working again, but instead it made evrything not
displaying applications :(
Menus are still populated, though. Odd.
In syslog I see these line
Fixed.
Special thanks to vtorri.
http://trac.enlightenment.org/e/changeset/78302
Daniel Juyung Seo (SeoZ)
On Sun, Oct 21, 2012 at 4:34 PM, Daniel Juyung Seo wrote:
> I found the reason.
> http://trac.enlightenment.org/e/changeset/78294
> It should be fixed.
>
> Daniel Juyung Seo (SeoZ)
>
> On Su
I found the reason.
http://trac.enlightenment.org/e/changeset/78294
It should be fixed.
Daniel Juyung Seo (SeoZ)
On Sun, Oct 21, 2012 at 3:23 PM, Daniel Juyung Seo wrote:
> Dear all, I just upgraded my Ubuntu 12.04 to Ubuntu 12.10 and got
> build issue with efreet.
>
>> make[2]: *** No rule to m
Looks good.
Thanks in SVN!
Daniel Juyung Seo (SeoZ)
On Thu, Sep 20, 2012 at 8:06 PM, Zbigniew Kosinski
wrote:
> Hello,
>
> Right now efreet_shutdown function doesn't return values below 0.
>
> In my opinion, efreet_mime_shutdown function should behave in the same way
> as efreet_shutdown.
>
> I
Hello,
Right now efreet_shutdown function doesn't return values below 0.
In my opinion, efreet_mime_shutdown function should behave in the same way
as efreet_shutdown.
I have prepared patch proposal to prevent decrementing init counter below 0.
Please take a look at attached file.
BR,
Zbigni
Hey
efreet_desktop_environment_get() is declared in efreet_desktop.h (as
an exported function) and in efree_private.h.
The declaration in efree_private.h shoul be removed.
Vincent
--
Live Security Virtual Conference
Exc
Am Samstag, 30. Juni 2012 um 00:45 schrieb Sebastian Dransfeld:
> On 06/29/2012 11:01 PM, Leif Middelschulte wrote:
> > Am Freitag, 29. Juni 2012 um 22:55 schrieb Sebastian Dransfeld:
> > > On 06/29/2012 09:05 PM, Leif Middelschulte wrote:
> > > >
> > > > That's weird. I trust your code knowledge
On 06/29/2012 11:01 PM, Leif Middelschulte wrote:
> Am Freitag, 29. Juni 2012 um 22:55 schrieb Sebastian Dransfeld:
>> On 06/29/2012 09:05 PM, Leif Middelschulte wrote:
>>>
>>> That's weird. I trust your code knowledge. But I have my files in
>>> ~/Arbeitsfläche and they used to be displayed by e_
Am Freitag, 29. Juni 2012 um 22:55 schrieb Sebastian Dransfeld:
> On 06/29/2012 09:05 PM, Leif Middelschulte wrote:
> >
> > That's weird. I trust your code knowledge. But I have my files in
> > ~/Arbeitsfläche and they used to be displayed by e_fm.
> > Now they are not shown anymore since e assu
On 06/29/2012 09:05 PM, Leif Middelschulte wrote:
>
> That's weird. I trust your code knowledge. But I have my files in
> ~/Arbeitsfläche and they used to be displayed by e_fm.
> Now they are not shown anymore since e assumes ~/Desktop, which is wrong.
> Either the translation is missing or Micro
Am Freitag, 29. Juni 2012 um 20:25 schrieb Sebastian Dransfeld:
> On 06/29/2012 03:21 PM, Leif Middelschulte wrote:
> > Am Freitag, 29. Juni 2012 um 15:17 schrieb Michael Blumenkrantz:
> > > On Fri, 29 Jun 2012 15:08:33 +0200
> > > Leif Middelschulte > > (mailto:[email protected])> wrot
On 06/29/2012 03:21 PM, Leif Middelschulte wrote:
> Am Freitag, 29. Juni 2012 um 15:17 schrieb Michael Blumenkrantz:
>> On Fri, 29 Jun 2012 15:08:33 +0200
>> Leif Middelschulte > (mailto:[email protected])> wrote:
>>
>>> Hello everyone,
>>>
>>> I've noticed that apparently instead of jus
Am Freitag, 29. Juni 2012 um 15:17 schrieb Michael Blumenkrantz:
> On Fri, 29 Jun 2012 15:08:33 +0200
> Leif Middelschulte (mailto:[email protected])> wrote:
>
> > Hello everyone,
> >
> > I've noticed that apparently instead of just using the string in
> > ~/.config/xdg-dirs (or what
On Fri, 29 Jun 2012 15:08:33 +0200
Leif Middelschulte wrote:
> Hello everyone,
>
> I've noticed that apparently instead of just using the string in
> ~/.config/xdg-dirs (or whatever the name is), the directory names are
> translated using gettext, leading to missbehavior. It used to be done rig
Hello everyone,
I've noticed that apparently instead of just using the string in
~/.config/xdg-dirs (or whatever the name is), the directory names are
translated using gettext, leading to missbehavior.
It used to be done right, but now this translation sneaked in.
Comments anyone? Mike? Sebast
On Wed, 24 Aug 2011 23:03:03 +0200 Nicolas Aguirre
said:
> Hi
>
> Tonight i update all my EFL and i see a regression in Efreet. My last
> update was a week ago.
> efreet_mime_type_icon_get("image/png", getenv("E_ICON_THEME"), 48);
> return always NULL or whatever the mime type i give to him.
>
Hi
Tonight i update all my EFL and i see a regression in Efreet. My last
update was a week ago.
efreet_mime_type_icon_get("image/png", getenv("E_ICON_THEME"), 48);
return always NULL or whatever the mime type i give to him.
Any ideas ?
--
Nicolas Aguirre
Mail: [email protected]
Web: htt
On Tue, 05 Apr 2011 14:04:17 + Tom Hacohen
said:
> It is a habit, and I do use a script, I guess I haven't updated for
> quite some time now (at work, at home I update on a weekly basis).
then its a too infrequent habit :) daily man! daily!
> --
> Tom.
>
> On Tue, 2011-04-05 at 17:35 +090
It is a habit, and I do use a script, I guess I haven't updated for
quite some time now (at work, at home I update on a weekly basis).
--
Tom.
On Tue, 2011-04-05 at 17:35 +0900, Carsten Haitzler wrote:
> On Tue, 05 Apr 2011 07:26:05 + Tom Hacohen
> said:
>
> you really should make a habit o
On Tue, 05 Apr 2011 07:26:05 + Tom Hacohen
said:
you really should make a habit of svn updating the tree every day and
rebuilding everything (use a script). it doesn't take very long. make it a
morning habit. you dont have to wait for the build - you can do your morning
email reading while it
I thought I was using latest... I just didn't bother verifying.
I will try to reproduce it, until then: sorry for the noise.
--
Tom.
On Tue, 2011-04-05 at 09:21 +0200, Sebastian Dransfeld wrote:
> On 04/05/2011 09:07 AM, Tom Hacohen wrote:
> > No idea what rev it was, but now it's latest (wasn'
On 04/05/2011 09:07 AM, Tom Hacohen wrote:
> No idea what rev it was, but now it's latest (wasn't too old anyway).
You got to be kidding me. If you don't use latest, how am I supposed to
find your problem? In all latest changes to efreet I fixed a lot of
problems.
> Anyhow, you should just add
No idea what rev it was, but now it's latest (wasn't too old anyway).
Anyhow, you should just add new desktop files (for example install an
app to your system) and then it should crash.
--
Tom.
On Mon, 2011-04-04 at 22:33 +0200, Sebastian Dransfeld wrote:
> BTW, efreet_util_desktop_exec_find at
BTW, efreet_util_desktop_exec_find at efreet_utils.c:279 isn't current,
or? Which revision?
efreet_util_desktop_exec_find is at line 219, and the call to
ecore_file_app_exe_get is at line 237
S.
On 04/04/2011 01:14 PM, Carsten Haitzler (The Rasterman) wrote:
> On Sun, 03 Apr 2011 15:48:49 +000
On 04/04/2011 06:54 PM, Sebastian Dransfeld wrote:
> On 04/04/2011 05:02 PM, Tom Hacohen wrote:
>> On Mon, 2011-04-04 at 16:57 +0200, Sebastian Dransfeld wrote:
>>> Nope, this crash is because of the utils cache, not the regular desktop
>>> cache. So it's pure efreet internal.
>>
>> And do you know
On Mon, 4 Apr 2011, Sebastian Dransfeld wrote:
> On 04/04/2011 05:02 PM, Tom Hacohen wrote:
>> On Mon, 2011-04-04 at 16:57 +0200, Sebastian Dransfeld wrote:
>>> Nope, this crash is because of the utils cache, not the regular desktop
>>> cache. So it's pure efreet internal.
>>
>> And do you know
On 04/04/2011 05:02 PM, Tom Hacohen wrote:
> On Mon, 2011-04-04 at 16:57 +0200, Sebastian Dransfeld wrote:
>> Nope, this crash is because of the utils cache, not the regular desktop
>> cache. So it's pure efreet internal.
>
> And do you know how to fix it? :P
>
> Do you need more info from me?
No
On Mon, 2011-04-04 at 16:57 +0200, Sebastian Dransfeld wrote:
> Nope, this crash is because of the utils cache, not the regular desktop
> cache. So it's pure efreet internal.
And do you know how to fix it? :P
Do you need more info from me?
--
Tom.
-
Nope, this crash is because of the utils cache, not the regular desktop
cache. So it's pure efreet internal.
S.
On 04/04/2011 01:14 PM, Carsten Haitzler (The Rasterman) wrote:
> On Sun, 03 Apr 2011 15:48:49 + Tom Hacohen
> said:
>
> mwahahahahah!
>
> actually.. my suspicion is that e still
On Sun, 03 Apr 2011 15:48:49 + Tom Hacohen
said:
mwahahahahah!
actually.. my suspicion is that e still refs a desktop file and doesnt release
it and change it on the efreet changed event...
> Here ya go, managed to make it happen again.
> With this* cache I get the following backtrace:
> #1
Here ya go, managed to make it happen again.
With this* cache I get the following backtrace:
#10
#11 0xb761c623 in ecore_file_app_exe_get (app=0xb1318978 ) at ecore_file.c:854
#12 0xb756604a in efreet_util_desktop_exec_find (exec=0xad10d00
"gnome-terminal") at efreet_utils.c:279
#13 0x08096829 in
As I said, my issue was "out of bound" address... So something is wrong :)
On Fri, Apr 1, 2011 at 4:21 PM, Cedric BAIL wrote:
> On Fri, Apr 1, 2011 at 12:56 PM, Carsten Haitzler
> wrote:
> > On Fri, 1 Apr 2011 09:16:39 +0200 [email protected] said:
> >> I don't get it. Isn't eet supposed to
On Fri, 1 Apr 2011 15:45:20 +0200 Leif Middelschulte
said:
> 2011/4/1 Carsten Haitzler :
> > On Fri, 1 Apr 2011 09:16:39 +0200 [email protected] said:
> >
> >> I don't get it. Isn't eet supposed to detect corrupt files? I guess it is
> >> something inside efreet, tried to find it but didn't se
On Fri, Apr 1, 2011 at 3:42 PM, Carsten Haitzler wrote:
> On Fri, 1 Apr 2011 15:21:42 +0200 Cedric BAIL said:
>> On Fri, Apr 1, 2011 at 12:56 PM, Carsten Haitzler
>> wrote:
>> > On Fri, 1 Apr 2011 09:16:39 +0200 [email protected] said:
>> >> I don't get it. Isn't eet supposed to detect corrup
2011/4/1 Carsten Haitzler :
> On Fri, 1 Apr 2011 09:16:39 +0200 [email protected] said:
>
>> I don't get it. Isn't eet supposed to detect corrupt files? I guess it is
>> something inside efreet, tried to find it but didn't see anything weird.
>
> well only as corrupt as eet will fail finding stu
On Fri, 1 Apr 2011 15:21:42 +0200 Cedric BAIL said:
> On Fri, Apr 1, 2011 at 12:56 PM, Carsten Haitzler
> wrote:
> > On Fri, 1 Apr 2011 09:16:39 +0200 [email protected] said:
> >> I don't get it. Isn't eet supposed to detect corrupt files? I guess it is
> >> something inside efreet, tried to
On Fri, Apr 1, 2011 at 12:56 PM, Carsten Haitzler wrote:
> On Fri, 1 Apr 2011 09:16:39 +0200 [email protected] said:
>> I don't get it. Isn't eet supposed to detect corrupt files? I guess it is
>> something inside efreet, tried to find it but didn't see anything weird.
>
> well only as corrupt
On Fri, Apr 1, 2011 at 1:57 PM, Carsten Haitzler wrote:
> next time.. back it up... we can sift through forensically after and you
> can
> have a working system again.
>
I know... Didn't really think that'll work.
--
Tom.
-
On Fri, 1 Apr 2011 09:16:39 +0200 [email protected] said:
> I don't get it. Isn't eet supposed to detect corrupt files? I guess it is
> something inside efreet, tried to find it but didn't see anything weird.
well only as corrupt as eet will fail finding stuff in the header. rememebr eet
files
On Fri, 1 Apr 2011 12:26:29 +0300 Tom Hacohen said:
> On Fri, Apr 1, 2011 at 7:58 AM, Carsten Haitzler wrote:
>
> > On Thu, 31 Mar 2011 17:20:42 +0200 Tom Hacohen
> > said:
> >
> > aaagh! did you keep a copy of the "corrupt" cache file? seriously.. we need
> > to
> > find a way to protect again
On Fri, Apr 1, 2011 at 7:58 AM, Carsten Haitzler wrote:
> On Thu, 31 Mar 2011 17:20:42 +0200 Tom Hacohen
> said:
>
> aaagh! did you keep a copy of the "corrupt" cache file? seriously.. we need
> to
> find a way to protect against this. checksums, magic values scattered
> about...
> something. if
On Fri, Apr 1, 2011 at 9:16 AM, wrote:
> I don't get it. Isn't eet supposed to detect corrupt files? I guess it is
> something inside efreet, tried to find it but didn't see anything weird.
I completly agree. eet should never cause a crash on bad data, the
problem is likely more in how efreet us
I don't get it. Isn't eet supposed to detect corrupt files? I guess it is
something inside efreet, tried to find it but didn't see anything weird.
S.
> On Thu, 31 Mar 2011 17:20:42 +0200 Tom Hacohen
> said:
>
> aaagh! did you keep a copy of the "corrupt" cache file? seriously.. we
> need to
> fi
On Thu, 31 Mar 2011 17:20:42 +0200 Tom Hacohen
said:
aaagh! did you keep a copy of the "corrupt" cache file? seriously.. we need to
find a way to protect against this. checksums, magic values scattered about...
something. if the cache file is broken efreet should ignore it and rebuild.
> Happens
Happens both at home and at work. And since it didn't happen to you, I
assumed removing the cache will work, and indeed it does.
So it's just a malformed cache, AGAIN. :)
FIXED.
Thanks,
Tom.
On Thu, 2011-03-31 at 12:15 -0300, Lucas De Marchi wrote:
> Hi Tom
>
> On Thu, Mar 31, 2011 at 11:52 AM
Hi Tom
On Thu, Mar 31, 2011 at 11:52 AM, Tom Hacohen
wrote:
> Actually, it's more than that, it happens also in other cases.
>
> Issue:efreet_util_desktop_exec_find passes bad pointers (out of bound)
> to ecore_file_app_exe_get...
>
> efreet_cache strikes back? (the invalid pointer is acquired fr
Actually, it's more than that, it happens also in other cases.
Issue:efreet_util_desktop_exec_find passes bad pointers (out of bound)
to ecore_file_app_exe_get...
efreet_cache strikes back? (the invalid pointer is acquired from
efreet_util_cache_names).
--
Tom.
On Thu, 2011-03-31 at 16:34 +0200
Hey,
Every time a desktop file gets updated, efreet makes e crash.
Way to reproduce: run "touch /usr/share/applications/xchat.desktop" (or
whatever other desktop file.
This is very annoying, this means e segs every time we install an
application.
Do you guys also get it?
--
Tom.
My mistake, sorry. efreet_icon_cache_create is segfaulting, as shown in my
previous email.
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in t
On 03/14/2011 06:01 PM, Dave Ray wrote:
> Efreet in the latest svn source does not seem to work correctly on MacOS
> 10.6. Parts of it work, but efreet_desktop_cache_create is segfaulting. I'm
> not passing any optional flags to ./autogen.sh when I build efreet. e17 seems
> to run ok anyway but
Efreet in the latest svn source does not seem to work correctly on MacOS 10.6.
Parts of it work, but efreet_desktop_cache_create is segfaulting. I'm not
passing any optional flags to ./autogen.sh when I build efreet. e17 seems to
run ok anyway but I need to stop the segfaulting.
Any help very
On 03/14/2011 01:13 AM, Dave Ray wrote:
> Efreet in the latest svn source does not seem to work correctly on MacOS
> 10.6. Parts of it work, but efreet_desktop_cache_create is segfaulting.
> Efreet also has trouble resolving directory paths when I run efreet_test.
> Before I post details, has an
Efreet in the latest svn source does not seem to work correctly on MacOS 10.6.
Parts of it work, but efreet_desktop_cache_create is segfaulting. Efreet also
has trouble resolving directory paths when I run efreet_test. Before I post
details, has anyone encountered this before or have a links to
On 02/15/2011 06:07 AM, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 09 Feb 2011 14:18:19 -0500 Christopher Michael
> said:
>
> i haven't seen this. fixed by now?
>
Seems to be. Running latest trunk here now (for a couple days now) and
it hasn't seg'd yet.
dh
>> Hi Seb,
>>
>> Latest efreet
Yup.
I really should get better at replying when I fix stuff.
S.
On 02/15/2011 12:07 PM, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 09 Feb 2011 14:18:19 -0500 Christopher Michael
> said:
>
> i haven't seen this. fixed by now?
>
>> Hi Seb,
>>
>> Latest efreet from trunk is a naughty boy !
On Wed, 09 Feb 2011 14:18:19 -0500 Christopher Michael
said:
i haven't seen this. fixed by now?
> Hi Seb,
>
> Latest efreet from trunk is a naughty boy ! ;) BT Here:
>
> http://pastebin.com/Kd9xtPHv
>
> dh
>
> --
> T
Hi Seb,
Latest efreet from trunk is a naughty boy ! ;) BT Here:
http://pastebin.com/Kd9xtPHv
dh
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before th
On 02/01/2011 01:47 PM, Sebastian Dransfeld wrote:
> On 02/01/2011 06:14 PM, Christopher Michael wrote:
>> On 02/01/2011 03:33 AM, Sebastian Dransfeld wrote:
>>> On 01/31/2011 11:39 PM, Christopher Michael wrote:
Hi Seb,
Getting a nasty segfault with current efreet trunk. Here is the
On 02/01/2011 06:14 PM, Christopher Michael wrote:
> On 02/01/2011 03:33 AM, Sebastian Dransfeld wrote:
>> On 01/31/2011 11:39 PM, Christopher Michael wrote:
>>> Hi Seb,
>>>
>>> Getting a nasty segfault with current efreet trunk. Here is the bt:
>>>
>>> #0 0x0058cb02 in strrchr () from /lib/libc.so
On 02/01/2011 03:33 AM, Sebastian Dransfeld wrote:
> On 01/31/2011 11:39 PM, Christopher Michael wrote:
>> Hi Seb,
>>
>> Getting a nasty segfault with current efreet trunk. Here is the bt:
>>
>> #0 0x0058cb02 in strrchr () from /lib/libc.so.6
>> #1 0x0030862b in efreet_cache_icon_fallback_lookup_
On 01/31/2011 11:39 PM, Christopher Michael wrote:
> Hi Seb,
>
> Getting a nasty segfault with current efreet trunk. Here is the bt:
>
> #0 0x0058cb02 in strrchr () from /lib/libc.so.6
> #1 0x0030862b in efreet_cache_icon_fallback_lookup_path (icon=0x81bcd18)
> at efreet_icon.c:838
> #2 0x
Hi Seb,
Getting a nasty segfault with current efreet trunk. Here is the bt:
#0 0x0058cb02 in strrchr () from /lib/libc.so.6
#1 0x0030862b in efreet_cache_icon_fallback_lookup_path (icon=0x81bcd18)
at efreet_icon.c:838
#2 0x003089ce in efreet_icon_path_find (theme_name=0x81bc088 "Buuf-Deuc
On 11/26/2010 04:35 PM, Vincent Torri wrote:
>
>
> On Fri, 26 Nov 2010, Christopher Michael wrote:
>
>> Ok, well it compiles now, but getting:
>>
>> efreet_icon.c: In function 'efreet_icon_theme_cache_check':
>> efreet_icon.c:1269: warning: implicit declaration of function
>> 'ecore_time_get'
>>
>
On Fri, 26 Nov 2010, Christopher Michael wrote:
> Ok, well it compiles now, but getting:
>
> efreet_icon.c: In function 'efreet_icon_theme_cache_check':
> efreet_icon.c:1269: warning: implicit declaration of function
> 'ecore_time_get'
>
> efreet_desktop_command.c: In function 'efreet_desktop_e
Ok, well it compiles now, but getting:
efreet_icon.c: In function 'efreet_icon_theme_cache_check':
efreet_icon.c:1269: warning: implicit declaration of function
'ecore_time_get'
efreet_desktop_command.c: In function 'efreet_desktop_exec_cb':
efreet_desktop_command.c:286: warning: implicit declar
A. Alright, thanks :)
dh
On 11/26/2010 03:40 PM, Vincent Torri wrote:
>
>
> it's me. I compiled only on windows. i fix it
>
> Vincent
>
> On Fri, 26 Nov 2010, Christopher Michael wrote:
>
>> Seems someone broke efreet wrt compiling. Just will not build anymore :(
>>
>> make[3]: Entering direc
it's me. I compiled only on windows. i fix it
Vincent
On Fri, 26 Nov 2010, Christopher Michael wrote:
> Seems someone broke efreet wrt compiling. Just will not build anymore :(
>
> make[3]: Entering directory `/home/devilhorns/e/trunk/efreet/src/lib'
> CC libefreet_la-efreet.lo
> efreet.
Seems someone broke efreet wrt compiling. Just will not build anymore :(
make[3]: Entering directory `/home/devilhorns/e/trunk/efreet/src/lib'
CC libefreet_la-efreet.lo
efreet.c: In function 'efreet_init':
efreet.c:57: warning: implicit declaration of function 'eet_init'
efreet.c:59: warnin
Ok, ignore this patch ... seems there are some more places where data ==
NULL needs fixing :(
dh
On 04/14/2010 11:48 AM, Christopher Michael wrote:
> Here is a small patch for Efreet which fixes the warning(s) issued at E
> startup about eina_hash_del being called with Data == NULL. This patch
>
Here is a small patch for Efreet which fixes the warning(s) issued at E
startup about eina_hash_del being called with Data == NULL. This patch
does fix the problem, but there may be a better way to go about this,
hence why I did not direct commit.
I've tested it here with no ill effects, but I
On 04/07/2010 07:09 PM, Carsten Haitzler (The Rasterman) wrote:
> On Tue, 06 Apr 2010 21:01:07 +0200 Sebastian Dransfeld
> said:
>
>> I think I now have all components needed to make the new cache mechanism
>> complete. It is not perfect, but I think it should work well enough.
>
> indeed. one of
On 04/07/2010 07:09 PM, Carsten Haitzler (The Rasterman) wrote:
> On Tue, 06 Apr 2010 21:01:07 +0200 Sebastian Dransfeld
> said:
>
>> I think I now have all components needed to make the new cache mechanism
>> complete. It is not perfect, but I think it should work well enough.
>
> indeed. one of
On Tue, 06 Apr 2010 21:01:07 +0200 Sebastian Dransfeld
said:
> I think I now have all components needed to make the new cache mechanism
> complete. It is not perfect, but I think it should work well enough.
indeed. one of the last nigglies got fixed (system config apps list in e works
again! :)
I think I now have all components needed to make the new cache mechanism
complete. It is not perfect, but I think it should work well enough.
Please test, and report bugs.
If someone wants to improve on what I have done, fell free.
I'm not sure how much time I will have in the near future, and
On Sat, 11 Jul 2009 11:40:17 -0300 Gustavo Sverzut Barbieri
said:
> Efreet is a core technology for E17, but we need a maintainer for it.
> Mekius is busy, as we all are, so if you have some spare time to help
> with it, please say so :-)
>
> I used to work a bit with efreet doing code for E17 a
Twas brillig at 11:40:17 11.07.2009 UTC-03 when [email protected] did
gyre and gimble:
GSB> Efreet is a core technology for E17, but we need a maintainer for
GSB> it. Mekius is busy, as we all are, so if you have some spare time
GSB> to help with it, please say so :-)
Oh , noes! I onl
On Thu, Jul 2, 2009 at 9:02 AM, Nick Hughart wrote:
> On Thu, 02 Jul 2009 16:24:58 +0700
> Mikhail Gusarov wrote:
>
>>
>> Twas brillig at 00:04:48 02.07.2009 UTC-05 when [email protected] did
>> gyre and gimble:
>>
>> NH> Efreet does not follow any of this new specification to my
>> NH> knowledg
On Mon, Jun 29, 2009 at 11:10 AM, Mikhail
Gusarov wrote:
>
> Twas brillig at 07:10:55 29.06.2009 UTC+07 when [email protected] did
> gyre and gimble:
>
> MG> Fix:
>
> I've found a problem with this fix. Here's the correct one:
correct one in svn, thanks!
--
Gustavo Sverzut Barbieri
http:
On Thu, 02 Jul 2009 16:24:58 +0700
Mikhail Gusarov wrote:
>
> Twas brillig at 00:04:48 02.07.2009 UTC-05 when [email protected] did
> gyre and gimble:
>
> NH> Efreet does not follow any of this new specification to my
> NH> knowledge so updating it would probably help solve the problem
> NH>
Twas brillig at 00:04:48 02.07.2009 UTC-05 when [email protected] did gyre and
gimble:
NH> Efreet does not follow any of this new specification to my
NH> knowledge so updating it would probably help solve the problem you
NH> describe.
Hmm, updating what? Efreet, specification or mime-type de
On Mon, 29 Jun 2009 07:18:35 +0700
Mikhail Gusarov wrote:
> Hello,
>
> I've stumbled upon the problem with lower-priority mime-types matching
> in Efreet. Let's see the definition of application/x-palm-database and
> application/x-aportisdoc:
>
>
> Palm OS database
>
>
>
>
>
>
>
Twas brillig at 07:10:55 29.06.2009 UTC+07 when [email protected] did
gyre and gimble:
MG> Fix:
I've found a problem with this fix. Here's the correct one:
pgpfq9330r3I1.pgp
Description: PGP signature
Index: src/lib/efreet_mime.c
===
Hello,
I've stumbled upon the problem with lower-priority mime-types matching
in Efreet. Let's see the definition of application/x-palm-database and
application/x-aportisdoc:
Palm OS database
AportisDoc document
According to definition, file with .pd
Hello,
Efreet_Mime did not match last set of magics for given mime-type due to
missing check after the loop. This bug was partially masked by the
problem fixed in my previous patch.
Fix:
pgprZD6FXbEVv.pgp
Description: PGP signature
Index: src/lib/efreet_mime.c
=
On Mon, 23 Mar 2009 11:09:29 +0100 (CET) Vincent Torri
said:
>
> hey,
>
> here is a patch for efreet that should remove the leaks found with the
> following code (see bug #247)
>
> #include
> int main()
> {
>efreet_mime_init();
>efreet_mime_shutdown();
>return 0;
> }
>
> I don't
hey,
here is a patch for efreet that should remove the leaks found with the
following code (see bug #247)
#include
int main()
{
efreet_mime_init();
efreet_mime_shutdown();
return 0;
}
I don't know the efreet code veery much, so i think that one of the
efreet authors should look at it
Sorry to take that long, but I committed a similar patch in r38975.
Just added the "_" before the name to match other EFL libraries.
Regards,
On Wed, Jan 28, 2009 at 9:12 PM, wrote:
> Hello,
>
> Here is a patch for efreet that make it work when used from c++ programs.
> I'm not sure if it is co
hey,
i've committed a patch from Albin Tonerre that adds the doc rules to
create the doc
can someone update the geenration of the inline doc, please ?
Vincent
--
Create and Deploy Rich Internet Apps outside the browse
Hello,
Here is a patch for efreet that make it work when used from c++ programs.
I'm not sure if it is correct, but hope someone with C knowleage will
correct it if needed.
Best regards,
Teodor Petrov
p.s. link to the patch http://pastebin.ca/1321183
p.p.s. and the patch below
Index: src/lib/e
Got it sorted out. My code was trying to process a mime.cache file as if
it was a .desktop. Thanks for your time tho :)
dh
Sebastian Dransfeld wrote:
> Christopher Michael wrote:
>> Why does efreet return a "efreet_desktop_generic_fields_parse error:
>> no Name" even when a .desktop does have a
Christopher Michael wrote:
> Why does efreet return a "efreet_desktop_generic_fields_parse error: no
> Name" even when a .desktop does have a Name= specified ?
Got an example of a desktop file where this happens?
Sebastian
Why does efreet return a "efreet_desktop_generic_fields_parse error: no
Name" even when a .desktop does have a Name= specified ?
Thanks,
dh
--
___
enlightenment-devel mailing l
On Sun, 7 Dec 2008 05:16:05 +0100 (CET) Dave Andreoli <[EMAIL PROTECTED]>
babbled:
>
> - "Carsten Haitzler (The Rasterman)" <[EMAIL PROTECTED]> ha scritto:
>
> > On Sat, 6 Dec 2008 20:47:08 +0100 (CET) Dave Andreoli
> > <[EMAIL PROTECTED]>
> > babbled:
> >
> >
> > >
> > > I think the best
- "Carsten Haitzler (The Rasterman)" <[EMAIL PROTECTED]> ha scritto:
> On Sat, 6 Dec 2008 20:47:08 +0100 (CET) Dave Andreoli
> <[EMAIL PROTECTED]>
> babbled:
>
>
> >
> > I think the best way is the simple API presented in the patch:
> >
> > EAPI const char* efreet_mime_default_application
On Sat, 6 Dec 2008 20:47:08 +0100 (CET) Dave Andreoli <[EMAIL PROTECTED]>
babbled:
>
> I think the best way is the simple API presented in the patch:
>
> EAPI const char* efreet_mime_default_application_get(const char *mime);
> EAPI void efreet_mime_default_application_set(const char *mime, con
1 - 100 of 147 matches
Mail list logo
