trying to compile eeze I get the following error:
eeze_udev_watch.c: In function 'eeze_udev_watch_add':
eeze_udev_watch.c:311: error: too many arguments to function
'udev_monitor_new_from_netlink'
--
Massimo Maiurana massimoragusa.linux.it
http://massimo.solira.orgGPG keyID #70
Hey,
you will find in http://trac.enlightenment.org/e/ticket/582 the
improvements of the text grid object (patch of Evas against a revision +
the corresponding textgrid code, and an example of use).
The status is here: http://trac.enlightenment.org/e/wiki/Evas
Don't hesitate to try it and to
On Sat, 4 Sep 2010 01:25:01 -0300 Lucas De Marchi
said:
according to setpriority manual it works on the "process" not the "specific
thread within the process". yes - i know on linux threads are implemented AS
processes - but as such pthread doesnt explicitly say that that is the case. i
should ha
Now it doesn't make any sense. For SCHED_OTHER policy, the only prio allowed
is 0. What you want is to set the nice value, which is done with setpriority
call
On Sep 3, 2010 9:55 PM, "Enlightenment SVN"
wrote:
Log:
rr->other
Author: raster
Date: 2010-09-03 17:54:53 -0700 (Fri, 03
On Fri, 3 Sep 2010 12:22:26 -0300 "Eduardo Lima (Etrunko)"
said:
see bug report. "works for me". explained in the report. :)
> Fellows,
>
> Attached you can find a simple and _exaggerated_ test of a problem I
> found while developing an application. Consider that we have quite
> many small rect
On Fri, 3 Sep 2010 21:34:18 -0300 Lucas De Marchi
said:
yeah. should have been OTHER. :)
> Are you sure you want it to have RT priority? By your description I would
> say you are looking for 'nice'
>
> On Sep 3, 2010 10:40 AM, "Enlightenment SVN"
> wrote:
> > Log:
> > * ecore: ecore_thread are
Are you sure you want it to have RT priority? By your description I would
say you are looking for 'nice'
On Sep 3, 2010 10:40 AM, "Enlightenment SVN"
wrote:
> Log:
> * ecore: ecore_thread are not here to bring your computer down, so
> reduce their priority too.
>
> Author: cedric
> Date: 2010-09-
Fellows,
Attached you can find a simple and _exaggerated_ test of a problem I
found while developing an application. Consider that we have quite
many small rectangles placed together that will form the main menu of
the application. But I would like to display those small rectangles
rotated on Z 45
On Fri, Sep 3, 2010 at 9:25 AM, Lucas De Marchi
wrote:
> On Tue, Aug 31, 2010 at 9:52 PM, Michael Jennings wrote:
>> On Tuesday, 31 August 2010, at 20:52:13 (-0300),
>> Lucas De Marchi wrote:
>>
>>> Humn... yes, but at least for EFL, raster and barbieri told me that
>>> I should not trust the pre
On Tue, Aug 31, 2010 at 9:52 PM, Michael Jennings wrote:
> On Tuesday, 31 August 2010, at 20:52:13 (-0300),
> Lucas De Marchi wrote:
>
>> Humn... yes, but at least for EFL, raster and barbieri told me that
>> I should not trust the precedence and always use parenthesis. This
>> was the reason why
On Sun, Aug 29, 2010 at 9:22 AM, Kim Woelders wrote:
> Please don't do this in E16.
>
> I think excessive parentheses deteriorate code readability.
> In general I don't like unnecessary code as it always makes me wonder if
> there is a good reason it is there, which is just annoying when there isn
On Fri, Sep 3, 2010 at 2:28 AM, Tom Haste wrote:
> FYI, Id like to do something like this for 1.0, if people like the
> idea. Analog clocks suck at 32px. :)
I'm all for it... actually it is done in connman/bluez modules as it
will hide the labels if it is too small.
--
Gustavo Sverzut Barbieri
On Mon, 30 Aug 2010 18:59:20 +0200 (CEST) Chidambar 'ilLogict' Zinnoury
said:
pretty much - yes. as a long long will be long enough to contain a time_t... in
general :)
> Hello.
>
> Why does ecore_file_mod_time return a long long instead of a time_t?
> So that we don't need to include time.h?
13 matches
Mail list logo
