Re: [E-devel] evas textblock broken without linebreak

2012-04-12 Thread Tom Hacohen
On 12/04/12 04:43, David Seikel wrote:
> Starting from line 6048 of evas_object_textblock.c there is a macro
> defined BREAK_AFTER, that, in the absence of HAVE_LINEBREAK, refers to
> a non existant "str" array.  Yep, I'm trying to compile it on an
> embedded system that has no linebreak thingy (library?).

Odd. I haven't tested it in a while, but when I had, it was fine, I 
don't get why it would change.

Anyhow, ok, I'm on it.

As raster said though, it's a good thing to have. ;P

--
Tom.


--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] evas textblock broken without linebreak

2012-04-12 Thread Tom Hacohen
Fixed, in svn.

Thanks.

On 12/04/12 10:08, Tom Hacohen wrote:
> On 12/04/12 04:43, David Seikel wrote:
>> Starting from line 6048 of evas_object_textblock.c there is a macro
>> defined BREAK_AFTER, that, in the absence of HAVE_LINEBREAK, refers to
>> a non existant "str" array.  Yep, I'm trying to compile it on an
>> embedded system that has no linebreak thingy (library?).
>
> Odd. I haven't tested it in a while, but when I had, it was fine, I
> don't get why it would change.
>
> Anyhow, ok, I'm on it.
>
> As raster said though, it's a good thing to have. ;P
>
> --
> Tom.
>
>
> --
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>


--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: tasn trunk/evas/src/lib/canvas

2012-04-12 Thread Tom Hacohen
Since when do we mention small bug fixes in the changelog?

--
Tom.

On 12/04/12 10:22, Vincent Torri wrote:
> Changelog...
>
> On Thu, Apr 12, 2012 at 9:20 AM, Enlightenment SVN
>   wrote:
>> Log:
>> Evas textblock: Fixed building without liblinebreak.
>>
>>   Thanks to David Seikel for spotting it and suggesting the solution.
>>
>> Author:   tasn
>> Date: 2012-04-12 00:20:01 -0700 (Thu, 12 Apr 2012)
>> New Revision: 70123
>> Trac: http://trac.enlightenment.org/e/changeset/70123
>>
>> Modified:
>>   trunk/evas/src/lib/canvas/evas_object_textblock.c
>>
>> Modified: trunk/evas/src/lib/canvas/evas_object_textblock.c
>> ===
>> --- trunk/evas/src/lib/canvas/evas_object_textblock.c   2012-04-12 07:14:21 
>> UTC (rev 70122)
>> +++ trunk/evas/src/lib/canvas/evas_object_textblock.c   2012-04-12 07:20:01 
>> UTC (rev 70123)
>> @@ -6055,9 +6055,9 @@
>>   #else
>>
>>   #define BREAK_AFTER(i) \
>> -   ((!str[i + 1]) || \
>> -(_is_white(str[i])&&  !_is_white(str[i + 1])) || \
>> -(!_is_white(str[i])&&  _is_white(str[i + 1])))
>> +   ((!text[i + 1]) || \
>> +(_is_white(text[i])&&  !_is_white(text[i + 1])) || \
>> +(!_is_white(text[i])&&  _is_white(text[i + 1])))
>>
>>   #endif
>>
>>
>>
>> --
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> ___
>> enlightenment-svn mailing list
>> enlightenment-...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
> --
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>


--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] evas textblock broken without linebreak

2012-04-12 Thread Tom Hacohen
On 12/04/12 11:11, David Seikel wrote:
> 
>
> I'll say again though, if I'm not using it, for ANYTHING, then it's
> just a waste of space and time to have on this embedded system that
> needs to be as small as possible.  I don't need intl, it's only ever
> gonna be used in English.  I probably don't even need line breaking,
> but I don't know yet.  If I do, a simple "Is this a space in ASCII?" is
> all I'll ever need.  Since that's pretty much what I get if I
> --disable-linebreak, then it's important to me that it actually works.
>
> It's not a good thing to waste more time compiling stuff I don't need,
> especially when I sometimes have to compile it on a x486, or qemu
> pretending it's a x486.  The more time I can shave of those 9 hour
> compiles, the better.  The smaller I can make it, the better.  The less
> code the government testing labs have to deal with, the better.  There
> are many reasons why I should get rid of stuff that's entirely useless
> for this specific project.  Especially if it's just a --disable-foo to
> get rid of it.
>
> I do wish people would stop telling me "Oh just include this, and just
> include that, it's all good".  I'm the one that knows what the specs
> are for this job, and I'm the one that has to shave off as much useless
> stuff as is reasonable.  I get to decide what goes and what stays based
> on my knowledge of the project, so if I'm making an effort to remove
> something, there's a good reason why, and people should just stop
> second guessing me.  "It's just not needed" is a great reason to remove
> things if possible in this project.
>
> In a later, non embedded, not needing to be approved by the government,
> not having to run on a x486, project I plan on doing, and another one I
> started in January, there will be need for all the bells and whistles.
> In this project, and the next embedded project, it's really important
> to cut the bloat.
>
> Remember, one of the important things we claim for EFL is it's small
> size and usefulness on embedded systems.  I'm reality checking those
> claims in some of my work.  I need to get it to work on a tiny little
> x486.  Personally I would have preferred a somewhat more grunty ARM,
> on an even smaller board, but I could not convince the client of
> that.  The x486 board had one thing on it that could not be found on
> any ARM board, at a reasonable cost, an interface to some other part of
> the hardware of the completed system. Oh well, at least I like this
> sort of challange.  B-)
>
> So next time I say "Hey, X is not working well when you disable Y, but
> it should", please, I don't want people telling me over and over again
> "Just leave Y in, it's all good, you'll need it".  Coz at that stage,
> I've already decided that I'm better off without it, with damn good
> reasons.
>
> 
>
> 

I just wonder why this rant was posted as a reply to my post, all I said 
is that it's a good thing to have.

--
Tom.


--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Eobj - Request for review/comments

2012-04-15 Thread Tom Hacohen
On 13/04/12 13:17, Carsten Haitzler (The Rasterman) wrote:
> hey tom. some of these i already mentioned to you, but i'll repeat here for 
> the
> good of everyone following:

Yeah, I already fixed some of those just after we talked, but thanks. :)
>
> 1. eobj_data_get() inside the method funcs - please just pass the object class
> data as a pointer to the func - figured out in the handler parent as its more
> efficient. :)

Yeah, done. :)
> 2. passing "op" i think has dubious value. it allows you to implement multiple
> methods using a single function (and switch internally based on op id), BUT i
> think this is rare at best or not needed. frankly slapping __UNUSED__'s all
> thru these funcs is just going to be noisy and pointless. :)

Yep.
> 3. in examples/access... protected really is a pointless complication. it's
> private data and just as visible and modifiable as any other private data. :)

Nah, it's a good example. It's trivial to come up with the way to do it 
yourself, but having an example that does it exactly is good for people 
seeking for the right way of doing stuff.

> 4. aaah varags for list of parent classes... coolio. i was wondering how
> multi-inheritance was going to work.

Yeah. :)
> 5. just as examples, it might be nicer to use named field filling eg:
>
> static const Eobj_Class_Description class_desc = {
>  .name  = "Mixin",
>  .type  = EOBJ_CLASS_TYPE_MIXIN,
>  .ops   = EOBJ_CLASS_DESCRIPTION_OPS(&MIXIN_BASE_ID, 
> op_desc,
> MIXIN_SUB_ID_LAST),
>  .events= NULL,
>  .data_size = 0,
>  .constructor   = _constructor,
>  .destructor= _destructor,
>  .class_constructor = _class_constructor,
>  .class_destructor  = NULL
> };
>
> in fact for 0's or NULLS, just leave them out so its easier to read:
>
> static const Eobj_Class_Description class_desc = {
>  .name   = "Mixin",
>  .type   = EOBJ_CLASS_TYPE_MIXIN,
>  .ops= EOBJ_CLASS_DESCRIPTION_OPS(&MIXIN_BASE_ID,
> op_desc, MIXIN_SUB_ID_LAST),
>  .constructor= _constructor,
>  .destructor = _destructor,
>  .class_constructor  = _class_constructor,
> };
>
> it's easier to see the field name so u know what it is meant to be used for,
> and skipping "unused" things leads to less cruft to sift through.

I generally agree, but I consider the examples as something people 
should copy & paste from, or at least as test cases (I use them like 
that atm) so I want them to be cross-platform.
>
> 6. eobj.c could be split into class, base class, obj funcs and callback funcs.
> into 4 files. :)

Yeah, messy inside, I know. :)
> 7. eobj_super_do()... wtf?

I used "super" because that's the common naming for that (it's like that 
in python and java among others). It's just for calling the function of 
the super-class, or more correctly, the next on in the mro.

> 8. why is Eobj_Op a uintptr_t? not just an int? any good reason? varargs does
> take care of this for us... ? (and by that same token eobj_do should terminate
> with a: (Eobj_Op)0, not NULL) :)

No idea why I ever made it a uintptr_t, WTH. :) Fixed now.
> 9. imho u want to eobj_ref() and eobj_unref() inside many funcs like 
> eobj_do_()
> to keep a refcount as long as the func is doing things with the obj

You are right, fixed.
> 10. missing the abstraction funcs/macros to "get me the real object pointer
> from Eobj *obj". eg treat it as an id and look up in a table... or as
> a double-pointer etc. :) either way - an abstraction there to sanity check the
> obj ptr and get the REAL obj ptr from it. (theoretically that can be compiled
> into a NOP to just hand u the ptr as-is - but in real life it will be doing
> footwork to do indirect lookups as crash prevention).

Yeah, never got around to it, will do it when I implement the "id" 
system. It's internal anyway...
> 11. eobj_constructor_super()  eobj_destructor_super() ?? pls explain 
> :)

Same as #7, it's just a way to call the next function in the mro in the 
specific case of the constructors/destructors.
> 12. eobj_event_callback_*() - cool. i now raise the spectre of MAYBE 
> supporting
> closures. what in gods green earth would be a closure here? well it would just
> be a callback WHERE maybe we manage the func data for the app OR we add 
> another
> "environment" param. such an environment sould need to be freed for the app
> when cb is deleted (or obj is deleted that cb is on) and any objects 
> references
> from this environment automatically get reffed when added as a cb or unreffed
> later. how to achieve this - not sure. some way to declare the create the
> environment struct and declare what inside of it may be an object handle? this
> of course leads to uglies like lists, hashes or arrays of objects.. and we
> begin to look like eet... anyway - i'm just bringing this up as

Re: [E-devel] Eobj - Request for review/comments

2012-04-15 Thread Tom Hacohen
On 13/04/12 14:02, Carsten Haitzler (The Rasterman) wrote:
> On Mon, 02 Apr 2012 12:58:21 +0300 Tom Hacohen  said:
>
> i have some more things as my brain churned that i didn't add to my previous
> mail:
>
> 15. eobj_generic_data_* ... i really think this should support passing in a
> free func for generic data (NULL == dont free it), and previous egenric data 
> is
> auto-greed if u set new data on top, same when u del - dont bother returning
> the pointer to it except on get. ALSO for generic data - can u provide a TYPE
> param - string, opque, eobj, opaque list, object list etc. types. opaque is
> unknown to eobj, but string can be used to account for memory objects and eobj
> can be used to have eobj auto unref attached generic data if its another eobj
> or list of eobj's. this would come it very handy.

I thought about it, but it felt a bit fat to me... The problem is that 
we'd have to save a free function/NULL for every property which is kinda 
wasteful. Especially since you can in most cases just have a delete 
callback and free the properties from there. If you really think it's a 
must, I'll add it.
> 16. eobj_event_callback_add() can be a macro imho. :)

Done.
> 17. maybe we can shorten callback to cb for brevity, also other full words
> might be shorter? opinions? save typing? generic_data ->  gdata? ...

Perhaps, we just need to decide on better naming. :)
> 18. ok so we have callbacks that are of course called in-line in the stack. 
> i'm
> mulling over if we should use the same callback system to POST events
> (messages) on a queue and then to be able to process them later as part of the
> ecore event loop. you will have to register a message queueing func with eobj
> - but eobj can handle reffing the target obj whenever u pose a msg cb and
> unreffing when msg event is finished in the queue. this can definitely help 
> out
> here. now the obj can choose if it wants to call cb's inline or defer on the
> event queue... :) in fact this can even get quite smart - if in the mainloop 
> it
> queues, if from a thread.. it can use the ecore async infra to send the cb's 
> to
> the mainloop as messages... oooh baby... :)

The biggest advantage (and it's really big in my pov) with inline 
callbacks is that you don't have to allocate data on the heap for the 
event info, you can just allocate data on the stack. It's a big save 
code-wise, and I'm certain performance-wise as well. If you make it 
"dynamic" i.e decided by eobj, you'd have to allocate the data (as the 
callback call my be deferred) which is annoying. Also, signals in many 
cases cause resizes of other objects and deferring those means the code 
we write won't be able to get the up to date info, which is also annoying...
> 19. and speaking of threads... i am wondering if maybe.. just maybe... we 
> might
> not want to provide some locking/unlocking infra for eobj? it probably needs 
> to
> handle recursive locks WITHIN the same thread... :/ let the flames begin!

Nah. :)
> 20. pants on.

Never!

Thanks for reviewing. If you can, please also reply to the questions I 
asked in my first (and second?) posts. For example what I said about the 
"flush" function that we talked about the other day, but not only...

--
Tom.

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Eobj - Request for review/comments

2012-04-16 Thread Tom Hacohen
Dear,

One more flaw I found (well actually Daniel found it):
eobj_do accepts "Eobj *" which is obviously not const. This means that 
eobj_do will always return a warning when passing const objects to it, 
even if we just query it for information, without changing.
This means that working with "cost Eobj *" will not be possible anymore.

I'm thinking about just adding eobj_query that will accept "const Eobj 
*" and will only let you execute "const compatible" operations on it. 
What do you think?

--
Tom.

On 02/04/12 12:58, Tom Hacohen wrote:
> Dear,
>
> As some of you may know, my team and I have been working on Eobj, a new
> objecting system for EFL. The current concept of varargs and having
> eobj_do (you'll see what I'm talking about) was suggested to me by
> raster and cedric, but I believe someone else deserves the original
> credit, so please, if you know who I should be giving credit to, let me
> know.
>
> I uploaded my current Eobj code to:
> http://www.enlightenment.org/~tasn/eobj.tgz
> Please feel free to take a look at the "lib" and at the examples in the
> examples dir. This example code uses cmake, because that's what I find
> most comfortable to work with, but the final version will be integrated
> into EFL and will use autotools, or in other words, please don't bother
> commenting about the build system.
>
> It's done and can be integrated into the EFL except for a couple of
> things that are not yet decided:
> 1. Thaw/freeze are not implemented yet
>   * Do we want to be able to freeze per object or globally to all objects?
>   * Do we want to be able to freeze per signal or just the whole object?
> (freezing just per signal can be risky because there might be other
> signals and applications that expect certain signal sequence and failing
> to block all will cause inconsistencies).
> 2. There are still some slow paths - will be fixed as needed.
> 3. I'm still uncertain about ref/unref + weak-ref + named-ref.
>   * I'm not sure yet about which kinds of refing we want. I'm pretty
> certain we want named refs and "object" name refs (i.e linking between
> objects). And I do believe we need weak ref/unref, but again not yet
> decided.
> 4. Many cases are not checked for validity and are just allowed. I plan
> on having 2 modes, one for checking those, and the fast mode that will
> just be fast. Possibly by having a compilation option + env var to turn
> the checks on.
> 5. No docs/proper internal naming yet, but API and examples should be solid.
> 6. Currently the order of functions called is: object functions, mixin
> functions and only then, composite object functions - should decide if
> that's what we want. I like it.
> 7. Mixin constructors are not called ATM.
>   * Will be fixed. The reason it was not done yet is that MIXINs are 2nd
> rate citizens, as we don't yet have a use for them in the EFL.
> 8. Currently only classes have data, not mixins. - Will be extended.
>   * I'm thinking about just letting them use the generic data and make
> the common case faster...
> 9. I plan on adding a signal indicating signal callbacks
> addition/removal. - I.e you'll get a "some registered to 'resize' event"
> signal.
>   * Very useful in many cases.
> 10. Static class method IDs will be added soon.
>   * Raster suggested a cool idea that will help speed things up, which is
> static IDs. It's not done yet, but it's 99% supported.
> 11. Class type and all of that handling is not yet final.
>   * Currently you have a class type of either: EOBJ_CLASS_TYPE_REGULAR,
> EOBJ_CLASS_TYPE_REGULAR_NO_INSTANT, EOBJ_CLASS_TYPE_INTERFACE, or
> EOBJ_CLASS_TYPE_MIXIN. I'm not sure if we need more, or if it should be
> ditched.
> 12. Missing a flush function after eobj_do. - I plan on adding a "flush"
> (I need a better name) function that will be called at the end of
> eobj_do automatically. This will let us defer changes in an easier manner.
>   * I'm not sure about this one. In one hand, it makes it easier to defer
> changes, though on the other, it's deference is not optimal, would have
> been better to just create an infrastructure that will let us do better
> deference of changes.
> 13. Missing a way to group set/get.
>   * I plan on making a way to say "set and get both modify the same
> property" which is not yet implemented.
>
> Please comment on the API (either the class API or the actual usage API)
> and especially on the bullets I wrote above.
>
> Please also take a look at the elw_boxedbutton "widget" in the evas
> example which shows the API for han

Re: [E-devel] Eobj - Request for review/comments

2012-04-17 Thread Tom Hacohen
On 17/04/12 10:55, Carsten Haitzler (The Rasterman) wrote:
> i don't see the point. it's just a pointer to something. it's fine as-is. in
> this way of doing an api we no longer can use the const attribute to say
> anything about the object here. there isn't a lot of point either.

I find it nice to have in cases where you want to query the object but 
not modify it. For example, but not only: when returning textblock 
cursors (assuming they were Eobj as well) from the textblock API...

But ok, if you think it's not needed ATM I'll just wait until I find a 
concrete use case.

Thanks for your comment.

--
Tom.


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: tasn trunk/PROTO/eobj/lib

2012-04-18 Thread Tom Hacohen
Hehe, yeah. :) The other Daniel, not you ;)

--
Tom.

On 18/04/12 13:23, Daniel Juyung Seo wrote:
> hehe obviously there are multiple instances of daniel now.
> On Apr 17, 2012 9:58 PM, "Enlightenment SVN"
> wrote:
>
>> Log:
>> Eobj: Fixed docs.
>>
>>   Thanks to Daniel.
>>
>> Author:   tasn
>> Date: 2012-04-17 05:58:33 -0700 (Tue, 17 Apr 2012)
>> New Revision: 70268
>> Trac: http://trac.enlightenment.org/e/changeset/70268
>>
>> Modified:
>>   trunk/PROTO/eobj/lib/Eobj.h
>>
>> Modified: trunk/PROTO/eobj/lib/Eobj.h
>> ===
>> --- trunk/PROTO/eobj/lib/Eobj.h 2012-04-17 12:49:53 UTC (rev 70267)
>> +++ trunk/PROTO/eobj/lib/Eobj.h 2012-04-17 12:58:33 UTC (rev 70268)
>> @@ -699,11 +699,11 @@
>>
>>   /**
>>   * @def EOBJ_BASE_DATA_DEL(key)
>> - * Get generic data from object.
>> + * Del generic data from object.
>>   * @param key the key associated with the data
>>   *
>>   * @see #EOBJ_BASE_DATA_SET
>> - * @see #EOBJ_BASE_DATA_DEL
>> + * @see #EOBJ_BASE_DATA_GET
>>   */
>>   #define EOBJ_BASE_DATA_DEL(key) EOBJ_BASE_ID(EOBJ_BASE_SUB_ID_DATA_DEL),
>> EOBJ_TYPECHECK(const char *, key)
>>
>>
>>
>>
>> --
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> ___
>> enlightenment-svn mailing list
>> enlightenment-...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>>
> --
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: cedric trunk/eina/src/lib

2012-04-18 Thread Tom Hacohen
On 18/04/12 14:44, Gustavo Sverzut Barbieri wrote:
> You are forcing it to a fixed File descriptor. Also you're imposing the
> getenv() in every log function. Make it a global state that can be enabled
> based on a numerical level. I'd also introduce a new backtrace function
> that can be provided by user, or just a generic "post log" user function
> that can contain a backtrace one, so maybe we can use it better.
>

getenv should probably be cached, yeah.

numerical level: good idea.

file descriptor: should be the same as the eina log prints.

backtrace function: no comment.

--
Tom.


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: cedric trunk/eina/src/lib

2012-04-19 Thread Tom Hacohen
On 19/04/12 03:25, Cedric BAIL wrote:
> Having a log post callback could be interesting, but I am wondering
> what else use it could have than current eina_log don't have. Do you
> have any use case in mind ?

Yeah, that's why I said "no comment" I can't find a use case for it... 
The purpose of the backtrace is to help people find the place that 
triggered the error in their code, and I don't see how that'll help there.

--
Tom.

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: cedric trunk/eina/src/lib

2012-04-19 Thread Tom Hacohen
On 19/04/12 10:34, Michael Blumenkrantz wrote:
> bottom line: this is a feature; we are in a feature freeze, and we have been
> for a month. it must be removed immediately.
>

It seems you are correct.

--
Tom.

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: cedric trunk/eina/src/lib

2012-04-19 Thread Tom Hacohen
On 19/04/12 11:17, Michael Blumenkrantz wrote:
> there's a number of other commits which also have broken the freeze, but I'm
> still hopeful that, for the non-essential ones, the authors will acknowledge
> their fault and revert the commits.
>

To be honest, I forgot about the freeze.

--
Tom.

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Eobj - Request for review/comments

2012-04-23 Thread Tom Hacohen
On 23/04/12 05:15, Cedric BAIL wrote:
> On Mon, Apr 2, 2012 at 6:58 PM, Tom Hacohen  wrote:
>> 3. I'm still uncertain about ref/unref + weak-ref + named-ref.
>> * I'm not sure yet about which kinds of refing we want. I'm pretty
>> certain we want named refs and "object" name refs (i.e linking between
>> objects). And I do believe we need weak ref/unref, but again not yet
>> decided.
>
> I am all for weak ref and named ref. You should by the way fix the
> weak ref to remember file and line of their allocation, that would
> help for debugging. Weak ref could have a debug and production mode.
> It could in production just be referencing up the EObj and returning a
> pointer to EObj, but in debug build it would allocate a weak
> reference.
> This means we don't need ref/unref in my opinion (You already know I
> am highly against those).
>

Already there. Do you like what's there atm? Named weak-refs make no 
sense and furthermore, weak-refs are not interchangeable with 
strong-refs, so what you are suggesting doesn't make sense for us. Did 
you look at the current implementations of weak-ref and named-refs? Do 
you like them?

>> 4. Many cases are not checked for validity and are just allowed. I plan
>> on having 2 modes, one for checking those, and the fast mode that will
>> just be fast. Possibly by having a compilation option + env var to turn
>> the checks on.
>
> I am not sure the env var would be practical in all case (due to
> inline for example and change in behaviour).

I'm talking about internal sanity checking, I don't see how that'd matter.
>
>> 5. No docs/proper internal naming yet, but API and examples should be solid.
>
> It would be nice to have a document that explain the design and idea.
> Including what _super (And why it is not named warp10 as it should
> be), what composite means, what are our goal, why we did redesign our
> own object model, and stuff like that.

Yeah, it's in my TODO, somewhere. You have to understand though, it's 
not a top priority comparing to integration into Evas for example. All 
the changes in eobj in the last couple of days were to support the 
integration into evas we are working on at the moment.
>
>> 10. Static class method IDs will be added soon.
>> * Raster suggested a cool idea that will help speed things up, which 
>> is
>> static IDs. It's not done yet, but it's 99% supported.
>
> Don't also forget to use eina_mempool. I will go after repacking
> algorithms when you are done.

I already forgot about it. Though seriously, I know, just didn't get to it.
>
>> 12. Missing a flush function after eobj_do. - I plan on adding a "flush"
>> (I need a better name) function that will be called at the end of
>> eobj_do automatically. This will let us defer changes in an easier manner.
>> * I'm not sure about this one. In one hand, it makes it easier to 
>> defer
>> changes, though on the other, it's deference is not optimal, would have
>> been better to just create an infrastructure that will let us do better
>> deference of changes.
>
> What about a pre and post signal emitted when we start a _do command ?

pre: "we are about to possibly do something"? Sounds unneeded. As for 
post: "we possibly did something before" - sounds useless as well. Don't 
you agree? Maybe there are uses for that, but please provide example use 
cases.
>
>> Also, we are also working on automatic eobj bindings generation for
>> other languages, so if you have anything to comment on this matter as
>> well, please do. I see this as one of the most important parts of this
>> change.
>
> Hum, I have a very stupid things to say here. Would it be possible to
> generate bindings at compile time and not at runtime ? Performance
> wise it's a much better option and it would make scripting on good
> speed track. I don't know how you plan to do this bindings generation,
> but if you start from a file description, maybe it could also generate
> the .c/.h file and just put some nice /* *** EOBJECT GENERATOR : YOU
> CAN EDIT CODE BELOW THIS LINE *** */, /* *** EOBJECT GENERATOR : YOU
> SHOULDN'T TOUCH THE LINE BELOW *** */. Just trowing an idea here.

Already like that. Well, without the ugly comments. :)
>
>> Bug reports, comments, suggestions, or whatever are more than welcomed!
>
> Just another comment, eobj_event_callback_del_full and
> eobj_event_callback_del. I would just make
> eobj_event_callback_del_full be eobj_event_callback_del and rename
> eobj_event_callback_del as eobj_event_callback_del_lazy. Reason, is
> that we should encourage the 

Re: [E-devel] E SVN: tasn IN trunk/PROTO/eobj: lib tests

2012-04-23 Thread Tom Hacohen
On 23/04/12 15:16, Vincent Torri wrote:
> why don't you return the ref ? be consistant like the rest of the EFL
> : return the value.

I gave it a short thinking and decided not to, but the decision was 
quite arbitrary. As you can see, in eobj_ref, I do return the object, it 
just didn't feel right in the weak ref case.

Will change it to return the object in a second.

--
Tom.


--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: tasn trunk/PROTO/eobj/lib

2012-04-23 Thread Tom Hacohen
On 23/04/12 15:34, Vincent Torri wrote:
> hmm, why do you need to return it in wref, then ???

I don't understand what you mean. I'm setting wref to obj and 
registering wref as a pointer that'll be updated automatically upon 
deletion of the object... I didn't update the docs yet (doing it atm), 
but that's what it does.

--
Tom.

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Elementary's new (internal) widget hierarchy

2012-04-29 Thread Tom Hacohen
Hey,

Thanks a lot for doing these reports/docs.

The code reduction seems impressive, and just shows again that we have 
delayed this change for too long. :) Will also reduce the number of API 
I assume, and that's great.

Regarding the image: I was thinking more of an inheritance graph of the 
whole elm widgets, i.e:

 Elm_Widget
 /\
Elm_ContainerElm_Foo
   | |
Elm_Box   Elm_Bar
   |
   Elm_Button

Just to understand the new inheritance design you chose, which in my 
pov, is more important than the actual implementation details. The 
inheritance design is "visible" to users of the API, while internal 
implementation is not.

Again, thanks a lot for all the info.

Is there anything in specific you want people to test/review? I.e you 
want more detailed examination of the API or of the internals? Please 
elaborate. I can't promise anything, but soon enough I'll have to jump 
in and read as well, as some of my team's future work is related.

--
Tom.

On 25/04/12 22:24, Gustavo Chaves wrote:
> Bump again.
>
> Both http://people.profusion.mobi/~glima/elm/group__Widget.html
> and http://git.profusion.mobi/cgit.cgi/glima/elementary/ are updated.
>
> Tom, there's an image there illustrating the old and new class schemas
> side by side, now. Enjoy.
>
> I'd be vary glad to have people testing and reviewing too.
>
> Tom, here's a (maybe outdated, by now, because of constant rebases)
> table on code reduction based on number of semi-colons. I used this
> metric to be more fair, taking in account that I wiped up all widgets,
> ecrustifying them and letting all fine, apart from porting.
>
> File Original code New code Reduction
> elm_bubble.c 186 67 63%
> elm_button.c 264 130 51%
> elm_check.c 249 126 49%
> elm_frame.c 174 90 48%
> elm_radio.c 265 162 39%
> elm_slider.c 562 385 31%
>
> Cheers.
>
> On Tue, Apr 3, 2012 at 3:06 PM, Gustavo Chaves  <mailto:gl...@profusion.mobi>> wrote:
>
> Just a bump on the matter: git repo for analisys rebased and updated.
>
>
> On Tue, Apr 3, 2012 at 10:40 AM, Tom Hacohen
> mailto:tom.haco...@samsung.com>> wrote:
>
> On 03/04/12 16:36, Gustavo Chaves wrote:
>
> Will be done, don't worry :)
>
>
> I'm not worried, but this is probably the easiest thing to
> review and gives a lot of info.
>
>
> I'll make # of semicolon comparisons per widget file, later.
>
> Yay, thanks.
>
> Perfectly working.
>
>
> Great. :)
>
> --
> Tom.
>
>
>
>
> --
> Gustavo Lima Chaves
> Senior Developer
> ProFUSION embedded systems
> http://profusion.mobi
>
>
>
>
> --
> Gustavo Lima Chaves
> Senior Developer
> ProFUSION embedded systems
> http://profusion.mobi
>


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] e fails to build and xkbmap fails to set variant

2012-05-01 Thread Tom Hacohen
On 01/05/12 07:22, P Purkayastha wrote:
> 1. e fails to build with this error:
> 
> Making all in po
> make[2]: Entering directory
> `/var/tmp/portage/x11-wm/enlightenment-/work/e/po'
> make enlightenment.pot-update
> make[3]: Entering directory
> `/var/tmp/portage/x11-wm/enlightenment-/work/e/po'
> make[3]: *** No rule to make target
> `../src/modules/xkbswitch/e_mod_keybindings.c', needed by
> `enlightenment.pot-update'.  Stop.
> make[3]: Leaving directory
> `/var/tmp/portage/x11-wm/enlightenment-/work/e/po'
> make[2]: *** [enlightenment.pot] Error 2
> make[2]: Leaving directory
> `/var/tmp/portage/x11-wm/enlightenment-/work/e/po'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/var/tmp/portage/x11-wm/enlightenment-/work/e'
> make: *** [all] Error 2
> emake failed
> 
> 
> 
> 
> 2. After the move to core e the setxkbmap -variant has stopped working.
> In my case, it tries to run
> 
> RUN: 'setxkbmap 'us' -variant 'dvorak,' -model 'default''
> 
> There are no more layouts specified after 'us', so simply removing the
> "," at the end of dvorak makes it work. The attached patch works for me.
> 

Same for me. I checked the manual, and it's specified there the , is not
needed unless we use multiple layouts.

Raster, if it's broken for you with japanese, you should possibly send a
bug report for the setxkbmap guys and make them fix your issue.

Bottom line: we should apply this patch if it fixes it.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [PATCH] Bring tiling module from EXTRAS into core

2012-05-02 Thread Tom Hacohen
On 02/05/12 10:54, Boris Faure wrote:
> Actually, even with the module loaded but not configured, it shouldn't
> change the desktop experience.
>

But it wastes ram...

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: tasn IN trunk/evas/src: lib lib/canvas modules/engines/gl_x11

2012-05-02 Thread Tom Hacohen
You didn't trouble me, I didn't even notice it (didn't update), but I 
guess some other people update very often (or just unlucky). :)

Anyhow, np.

--
Tom.

On 02/05/12 17:03, Sung W. Park wrote:
> hmm... ok, I guess something went wrong somewhere.  I'll try a clean build
> tomorrow before resubmitting it.
>
> sorry about the trouble.
>
> -Sung
>
> On Wed, May 2, 2012 at 8:07 PM, Enlightenment SVN<
> no-re...@enlightenment.org>  wrote:
>
>> Log:
>> Revert "Cleaned up some evas_gl code and added surface cap feature."
>>
>>   This reverts commit 70617.
>>
>>   According to stefan_schmidt, reverting this fixes compilation errors.
>>
>> Author:   tasn
>> Date: 2012-05-02 04:07:29 -0700 (Wed, 02 May 2012)
>> New Revision: 70624
>> Trac: http://trac.enlightenment.org/e/changeset/70624
>>
>> Modified:
>>   trunk/evas/src/lib/Evas_GL.h trunk/evas/src/lib/canvas/evas_gl.c
>> trunk/evas/src/modules/engines/gl_x11/evas_engine.c
>>
>> Modified: trunk/evas/src/lib/Evas_GL.h
>> ===
>> --- trunk/evas/src/lib/Evas_GL.h2012-05-02 10:54:14 UTC (rev 70623)
>> +++ trunk/evas/src/lib/Evas_GL.h2012-05-02 11:07:29 UTC (rev 70624)
>> @@ -2,6 +2,7 @@
>>   #define _EVAS_GL_H
>>
>>   #include
>> +//#include
>>
>>   #ifdef __cplusplus
>>   extern "C" {
>> @@ -421,11 +422,6 @@
>>   * @param w The width of the surface.
>>   * @param h The height of the surface.
>>   * @return The created GL surface object, or NULL on failure.
>> - *
>> - * The surface_create function internally finds the closest surface
>> - * configureation that matches the input config. The function then
>> internally
>> - * sets the input config parameters to the configuratoin that was actually
>> - * used to create the surface.
>>   */
>>   EAPI Evas_GL_Surface *evas_gl_surface_create (Evas_GL
>> *evas_gl, Evas_GL_Config *cfg, int w, int h) EINA_WARN_UNUSED_RESULT
>> EINA_ARG_NONNULL(1,2);
>>
>>
>> Modified: trunk/evas/src/lib/canvas/evas_gl.c
>> ===
>> --- trunk/evas/src/lib/canvas/evas_gl.c 2012-05-02 10:54:14 UTC (rev 70623)
>> +++ trunk/evas/src/lib/canvas/evas_gl.c 2012-05-02 11:07:29 UTC (rev 70624)
>> @@ -39,7 +39,7 @@
>>
>> if (!evas_gl->evas->engine.func->gl_context_create)
>>   {
>> -ERR("Evas GL engine not available.");
>> +ERR("GL engine not available\n");
>>  free(evas_gl);
>>  return NULL;
>>   }
>> @@ -96,7 +96,7 @@
>>
>> if (!config)
>>   {
>> -ERR("Invalid Config Pointer!");
>> +ERR("Invalid Config\n");
>>  return NULL;
>>   }
>>
>> @@ -108,7 +108,7 @@
>>
>> if (!surf->data)
>>   {
>> -ERR("Failed creating a surface from the engine.");
>> +ERR("Failed creating a surface from the engine\n");
>>  free(surf);
>>  return NULL;
>>   }
>> @@ -129,7 +129,7 @@
>>
>> if (!surf)
>>   {
>> -ERR("Trying to destroy a NULL surface pointer!");
>> +ERR("Trying to destroy a NULL surface pointer!\n");
>>  return;
>>   }
>>
>> @@ -158,7 +158,7 @@
>> ctx = calloc(1, sizeof(Evas_GL_Context));
>> if (!ctx)
>>   {
>> -ERR("Unable to create a Evas_GL_Context object");
>> +ERR("Unable to create a Evas_GL_Context object\n");
>>  return NULL;
>>   }
>>
>> @@ -175,7 +175,7 @@
>> // Set a few variables
>> if (!ctx->data)
>>   {
>> -ERR("Failed creating a context from the engine.");
>> +ERR("Failed creating a context from the engine\n");
>>  free(ctx);
>>  return NULL;
>>   }
>> @@ -197,7 +197,7 @@
>>
>> if (!ctx)
>>   {
>> -ERR("Trying to destroy a NULL context pointer!");
>> +ERR("Trying to destroy a NULL context pointer!\n");
>>  return;
>>   }
>>
>> @@ -256,12 +256,6 @@
>> return EINA_FALSE;
>> MAGIC_CHECK_END();
>>
>> -   if ((!surf) || (!ns))
>> - {
>> -ERR("Invalid input parameters!");
>> -return EINA_FALSE;
>> - }
>> -
>> return
>> (Eina_Bool)evas_gl->evas->engine.func->gl_native_surface_get(evas_gl->evas->engine.data.output,
>> surf->data, ns);
>>   }
>>
>>
>> Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
>> ===
>> --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2012-05-02
>> 10:54:14 UTC (rev 70623)
>> +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2012-05-02
>> 11:07:29 UTC (rev 70624)
>> @@ -41,26 +41,17 @@
>> int w, h;
>> int vsync;
>>
>> -   // GL Surface Capability
>> -   struct {
>> -int rgb_fmt;
>> -int rgba_fmt;
>> +   // Shader used for Evas_GL_Direct Optimization
>> +   GLuint   df_program;
>> +   GLuint   df_vtx_shader;
>> +   GLuint   df_fgmt_shader;
>> +   GLuint   df_col_attrib;
>> +   GLuint   df_pos_attrib;
>>
>> -int depth_8;
>> -   

Re: [E-devel] [Patch] evas_ojbect_textblock, ellipsis handling

2012-05-03 Thread Tom Hacohen
Dear Shinwoo,

I've checked your issue and I indeed managed to reproduce it using your 
patch (actually, only half of your patch was needed, the text was 
enough, no need for the style).

It's not really a textblock issue. It's just a matter of a bad edje, or 
maybe a calculation, can't tell. The problem is that the size of the 
textblock is very "unstable" because of the ellipsis. In such cases, the 
textblock should not be used for sizing, so it must be defined as fixed: 
1 X; (height doesn't really matter, the width is the issue) as I 
suggested before.

I don't think it can easily be fixed, especially since it's currently 
just a not supported behaviour. How would you expect it to behave?

--
Tom.

On 24/04/12 05:29, cnook wrote:
> Dear Mr. Tom,
>
> Finally!! I have attacked patch for your example. To make the issue, please
> follow as below.
>
>elementary_test>  popup>  popup-center-title + text +1 button
>
> Then the popup needs some time to display itself with following log.
>
>ERR<32658>:evas_main evas_object_smart.c:599
> evas_object_smart_need_recalculate_set() Object 0xb76d5df8 is not stable
> during recalc loop
>ERR<32658>:evas_main evas_object_smart.c:599
> evas_object_smart_need_recalculate_set() Object 0xb76d5df8 is not stable
> during recalc loop
>    ...
>
> Please check this on the textblock side. Thanks a lot.
>
> Sincerely,
> Shinwoo Kim.
>
> 2011/11/21 Tom Hacohen
>
>> On 21/11/11 16:04, cnook wrote:
>>
>>> Dear Mr. Tom,
>>>
>>> The issue comes again with different example.
>>> So I have attached previous patch for resolving. (Actually I have made
>>> from the latest version)
>>>
>>
>>
>> Dear Shinwoo,
>>
>> As I said in a previous email to the list, a compilable example or an edje
>> I can run with edje_player would be very appreciated. I currently can't
>> reproduce the issue and thus I can't even check you solution works (I trust
>> you that it works, but still...), nor can I verify the problem.
>>
>> As for your patch:
>>
>> c->w will be smaller than c->wmax in A LOT of cases, that's actually
>> intentional, setting c->wmax to c->w makes no sense in textblock, as it'll
>> break a lot of code.
>>
>> c->wmax is used to determine the actual *used* width, and c->w is the
>> width of the textblock object.
>>
>> So for example, if we have a textblock with a size of 300x300 and
>> assuming the string "a" * 100 (100 'a's in a row) have a width of 1000 and
>> that the textblock contains that string:
>> c->w = 300;
>> c->wmax = 1000;
>>
>> Making edje know that 300 is just not enough to show this string. That's
>> how the min size calculation actually works.
>>
>> You can try adding "fixed: 1 1;" to the textblock part if you wish to
>> implement your behaviour, that's exactly what it does.
>>
>>
>> With that being said, there might be a bug there, as your condition should
>> always be false in that place (or at least in the cases that matter), and
>> for that, I need the example I asked for. :)
>>
>> --
>> Tom.
>>
>>
>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>
>>
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Bug report - keybindings don't work while Everything is open

2012-05-04 Thread Tom Hacohen
Hey,

I can't seem to be able to change keyboard layouts with my keybindings
(Ctrl + Space) while Everything is open.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] eina_model should be back ?

2012-05-05 Thread Tom Hacohen
On 05/05/12 07:03, Vincent Torri wrote:
> hey
> 
> shouldn't eina_model be back in trunk, now ?

Yes, probably. This time it should be tested, used and reviewed though,
otherwise it'll just the same story all over again.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: cedric trunk/e/src/bin

2012-05-05 Thread Tom Hacohen
On 05/05/12 06:18, David Seikel wrote:
> Just ignoring the failed allocation and trying to use a NULL pointer
> will likely crash you anyway, but that's just being lazy.  Failing
> gracefully is generally better than failing disgracefully.

Yes, but the amount of work just doesn't worth it.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: cedric trunk/e/src/bin

2012-05-05 Thread Tom Hacohen
On 05/05/12 14:08, Joerg Sonnenberger wrote:
> On Sat, May 05, 2012 at 01:18:48PM +1000, David Seikel wrote:
>> Just ignoring the failed allocation and trying to use a NULL pointer
>> will likely crash you anyway, but that's just being lazy.  Failing
>> gracefully is generally better than failing disgracefully.
> 
> Part of the problem here is that it might *not* crash depending on the
> code path and arguments. E.g. if you allocate a large buffer and the
> first thing you do with the buffer is writing to an attacker controlled
> offset, it can be turned into an arbitary code exploit by making the
> buffer size large enough that the offset effectively becomes a pointer
> itself.

Yeah, depends on the location of the allocation. I was thinking more
about internal infra stuff, but this point is indeed valid.

--
Tom.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] New elm internal code

2012-05-07 Thread Tom Hacohen
Table and box are not containers?

--
Tom.

On 07/05/12 10:18, Daniel Juyung Seo wrote:
> Dear glima,
> While reading the new elm code, I drew a widget inheritance tree.
> Can you verify this?
> Others can refer this graph before reading the code.
> Thanks.
>
> Daniel Juyung Seo (SeoZ)
>
>> -Original Message-
>> From: Gustavo Lima Chaves [mailto:gl...@profusion.mobi]
>> Sent: Friday, May 04, 2012 7:46 AM
>> To: Enlightenment developer list
>> Subject: [E-devel] New elm internal code
>>
>> (O)h(a)i, people.
>>
>> So, another time uploding the work on Elementary, which comprises of
>> internal
>> rewriting WRT the form widgets are created. There's an extensive thread
>> explaining
>> the reasons and means of this task, so please refer to it for technical
>> questions.
>>
>> I have now removed the theme changing bits of the commits, so no "breaks"
>> here.
>> Please report any eventual bug directly to me and I'll fix it.
>>
>> Enjoy.
>>
>> --
>> Gustavo Lima Chaves
>> Computer Engineer @ ProFUSION Embedded Systems
>>
>> --
>> 
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>
>>
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] New elm internal code

2012-05-07 Thread Tom Hacohen
On 07/05/12 16:50, Carsten Haitzler (The Rasterman) wrote:
> On Mon, 07 May 2012 17:07:00 +0900 Daniel Juyung Seo
> said:
>
> actually almost every widget is a container... they all can CONTAIN
> something... like another widget. very few are not. i guess the question is if
> the widget is PRIMARILY just a container (box, table, grid) where all it does
> is arrange children bt in and of itself doesn't do any layout unrelated logic.

Yes. Well they defined everything as containers, so I was just wondering 
why those are not containers as well.

--
Tom.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: tasn trunk/PROTO/eobj/lib

2012-05-08 Thread Tom Hacohen
On 08/05/12 10:09, Vincent Torri wrote:
> I'm just wondering : isn't 'eo' too small for the namespace ? I would
> really prefer 'eobj'. It's not that big and might avoid conflicts with
> other libraries which would also choose 'eo' as namespace

I don't know of any other libraries that use eo for the namespace, but 
anyhow, as you may have noticed, I chose eobj as the namespace, it's 
cedric and raster who asked me to change to eo... Convince them. :)

--
Tom.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: tasn trunk/PROTO/eobj/lib

2012-05-08 Thread Tom Hacohen
On 08/05/12 10:25, Vincent Torri wrote:
> I also don't know such lib, but i also don't know the libraries that
> will be written in the future as well.

That's their job not to steal the namespace, the same way we hope they 
won't steal azy, evas, eina and etc...

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: tasn trunk/PROTO/eobj/lib

2012-05-08 Thread Tom Hacohen
On 08/05/12 10:41, Vincent Torri wrote:
> http://eodev.sourceforge.net/eo/doc/html/index.html
>
> it's a C++ library that has eo as namespace. That means that if
> someone writes a C++ binding of our Eo, its namespace will conflict
> withthe above library if they are used together.

Again, good point, please convince raster/cedric. I don't really care 
about the naming, they wanted something short and cedric suggested eo. 
Ask them what name they prefer and I'll change it, I don't really care. :)

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] New elm internal code

2012-05-09 Thread Tom Hacohen
On 09/05/12 11:13, Daniel Juyung Seo wrote:
> Welcome back glima!
> Yes the tree has to be auto generated.
> It was time spending to draw that diagram.

It's super easy to auto-generate... Just parse the smart class parent 
from the source and put every pair in a dot file. Graphviz will take 
care of the rest.

--
Tom


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Eio dep in edje

2012-05-10 Thread Tom Hacohen
Dear Cedric,

You ruined my life. Seriously, I don't want Eio and it's pissing me off. 
:) It's only a dep for edje_watch, so just if you don't detect eio, 
don't build edje_watch.

Vincent said he'll take a look tonight, but please if you see it's not 
fixed by tomorrow, fix it.

Thanks,
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Issue with xkbswitch

2012-05-10 Thread Tom Hacohen
Hey,

I have an issue with a certain slowness in xkbswitch's responsiveness.

How to reproduce:
1. Use at least 2 layouts.
2. Assign a key to switch to the next layout.
3. Press the combination fast twice in a row.

Expected result: it'll switch to the layout after the next.
Actual result: it only switches to the next layout.

This sucks.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Screen resolution not remembered

2012-05-12 Thread Tom Hacohen
On 12/05/12 11:37, Andreas Volz wrote:
> Ok, I've no better solution so I did a workaround. I created a script
> that calls "xrandr --size 1920x1080" to set resolution. Then after E
> is started I press a button in my shelf to change resolution. Very
> ugly but faster than using E menus.

If you are into ugly hacks, why don't you make that script launch
automatically at e start?

--
Tom.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Elementary: Question. Fonts in elm entry object

2012-05-13 Thread Tom Hacohen
On 11/05/12 23:07, Art B wrote:
> I can't seem to figure/understand how to modify the fonts(name or size)
> trough my elm C client-code. I can do this easily with an edje TEXTBLOCK
> object. But then I miss out on anchors for example.
>
> I would appreciate greatly if someone could explain how to do this with
> elementary for me. A code example would suffice also.

I added a short paragraph to the entry docs to explain how it can be 
done. Doc generation is currently broken on the server, but you can just 
access the following file:
http://svn.enlightenment.org/svn/e/trunk/elementary/src/lib/elm_entry.h 
and search for entry-style-set.

Also, there's a code example available in ecrire ( 
http://svn.enlightenment.org/svn/e/trunk/ecrire/ ). Or more 
specifically, in main.c:510, function: "editor_font_set". You should 
probably check that out as well.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: glima trunk/elementary/src/lib

2012-05-14 Thread Tom Hacohen
On 13/05/12 18:14, Gustavo Sverzut Barbieri wrote:
> That's the single sane way to do it, and the case for every toolkit
> out there, be ObjC, C++ or C.  The developer needs to understand the
> hierarchy in order to use, you can't call a method in a object that
> did not implement, but admittedly C makes it more cumbersome as you
> must type the namespace and class name, while C++ and ObjC does that
> for you.
>
> If you think about that now, although not having to think about the
> hierarchy to type the name, the user indeed needs to know if the
> object supports parts setting, and which. If you call part set on a
> box, it will do nothing.
>
> We could keep the backwards compatibility thing and do not deprecate
> it, but in my opinion it is bad because:
>
> Once we allow extending Elementary from outside, more libraries
> will create more components and these may have their own common
> methods. Imagine a library provides a base widget BW and dozen
> widgets, all with the same methods. You'll have some my_bw_method().
> You cannot/should not create elm_object_method(), thus you'll generate
> some inconsistency here as out-of-library widgets can't use the same
> pattern.
>
> All in all the elm_object_ methods were mostly hacked in afterwards,
> and that hurts. As we did not had any common "layout" to inherit,
> every widget did the same code over and over again: Button, Checkbox,
> Frame... all had text set on their own. Again, we lacked the
> inheritance, then there was no other way than "move this to the base
> widget operations" to solve the problem. Now we do have and we better
> use it.

Yep. Also, it's a good idea to take a look at GTK+'s docs. They actually 
did a nice job showing all the hierarchy and thus what functions you can 
hope to use.

For example:
http://developer.gnome.org/gtk/2.24/GtkButton.html

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [Patch] evas_ojbect_textblock, ellipsis handling

2012-05-14 Thread Tom Hacohen
Hm... ?

On 14/05/12 13:24, Kim Shinwoo wrote:
> DEAR TOM, PLEASE REVIEW THIS. IT'S NOT MORNING. HAHAHA..
>
> 2012/5/4 Kim Shinwoo:
>> Please leave your attention from the previous patch.
>> I have newly revised the patch on both backport and trunk.
>>
>> 2012/5/4 Kim Shinwoo:
>>> Dear Tom,
>>>
>>> I have attached a patch to make proper edje which uses the textblock
>>> with ellipsis!
>>> Please review the patch and keep it on upstream.
>>>
>>> Sincerely,
>>> Shinwoo Kim.
>>>
>>> 2012/5/4 Kim Shinwoo:
>>>> Dear Tom, Good afternoon again! ;p
>>>> I'm back with gd news!! The "fixed:1 x" resolved this issue
>>>> finally. Thank you for your help!!
>>>>
>>>> 2012/5/4 Kim Shinwoo:
>>>>> Dear Tom, Good afternoon! :p
>>>>> Thanks for your response. Tomorrow.. actually today.. I will check it with
>>>>> revised edje which has "fixed:1 x";.
>>>>>
>>>>>> maybe a calculation
>>>>> hmm.. it would be able to be caused by calculation, then we cannot say..
>>>>> "Now, issue is resolved."?
>>>>> Doesn't the calculation problem occur, if I use the "fixed:1 x;"? then we
>>>>> can say.. "Now, issue is resolved."!
>>>>> Anyhow, test is the best way to check..
>>>>>
>>>>>
>>>>>> I don't think it can easily be fixed, especially since it's currently
>>>>>> just a not supported behaviour. How would you expect it to behave?
>>>>> Does it mean "fixed: 0 x;" - textblock with ellipsis is used for sizing - 
>>>>> ?
>>>>> yeap, we cannot expect the behavior.. ah.. delayed calculation.. dead 
>>>>> lock..
>>>>> :-/
>>>>>
>>>>> I will be back. -.,-)=b
>>>>> Shinwoo Kim.
>>>>>
>>>>> 2012년 5월 3일 목요일에 Tom Hacohen님이 작성:
>>>>>
>>>>>> Dear Shinwoo,
>>>>>>
>>>>>> I've checked your issue and I indeed managed to reproduce it using your
>>>>>> patch (actually, only half of your patch was needed, the text was
>>>>>> enough, no need for the style).
>>>>>>
>>>>>> It's not really a textblock issue. It's just a matter of a bad edje, or
>>>>>> maybe a calculation, can't tell. The problem is that the size of the
>>>>>> textblock is very "unstable" because of the ellipsis. In such cases, the
>>>>>> textblock should not be used for sizing, so it must be defined as fixed:
>>>>>> 1 X; (height doesn't really matter, the width is the issue) as I
>>>>>> suggested before.
>>>>>>
>>>>>> I don't think it can easily be fixed, especially since it's currently
>>>>>> just a not supported behaviour. How would you expect it to behave?
>>>>>>
>>>>>> --
>>>>>> Tom.
>>>>>>
>>>>>> On 24/04/12 05:29, cnook wrote:
>>>>>>> Dear Mr. Tom,
>>>>>>>
>>>>>>> Finally!! I have attacked patch for your example. To make the issue,
>>>>>>> please
>>>>>>> follow as below.
>>>>>>>
>>>>>>> elementary_test>   popup>   popup-center-title + text +1 button
>>>>>>>
>>>>>>> Then the popup needs some time to display itself with following log.
>>>>>>>
>>>>>>> ERR<32658>:evas_main evas_object_smart.c:599
>>>>>>> evas_object_smart_need_recalculate_set() Object 0xb76d5df8 is not stable
>>>>>>> during recalc loop
>>>>>>> ERR<32658>:evas_main evas_object_smart.c:599
>>>>>>> evas_object_smart_need_recalculate_set() Object 0xb76d5df8 is not stable
>>>>>>> during recalc loop
>>>>>>> ...
>>>>>>>
>>>>>>> Please check this on the textblock side. Thanks a lot.
>>>>>>>
>>>>>>> Sincerely,
>>>>>>> Shinwoo Kim.
>>>>>>>
>>>>>>> 2011/11/21 Tom Hacohen
>>>>>>>
>>>>>>>> On 21/11/11 16:04, cnook wrote:
&

Re: [E-devel] [Patch] evas_ojbect_textblock, ellipsis handling

2012-05-14 Thread Tom Hacohen
On 04/05/12 08:15, Kim Shinwoo wrote:
> Please leave your attention from the previous patch.
> I have newly revised the patch on both backport and trunk.

You accidentally included some irrelevant changelog information. Anyhow, 
it's in.

Sorry for the time it took me, it somehow slipped between the chairs.

In svn, commit: 70994

I didn't commit the backport, as I don't have a checkout of the backport 
ATM, someone please do it.

--
Tom.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: tasn IN trunk/clouseau/src: . bin

2012-05-14 Thread Tom Hacohen
What do you mean? That it's his old email address? Yeah, it's a pretty 
old commit. :)

--
Tom.

On 14/05/12 17:46, Leif Middelschulte wrote:
> 2012/5/14 Enlightenment SVN:
>> Log:
>> clouseau: Created clouseau daemon clouseaud.c stab
>>
>>   Signed-off-by: Aharon Hillel
> mixing up mail addresses here?
>>
>> Author:   tasn
>> Date: 2012-05-14 07:37:38 -0700 (Mon, 14 May 2012)
>> New Revision: 71003
>> Trac: http://trac.enlightenment.org/e/changeset/71003
>>
>> Added:
>>   trunk/clouseau/src/bin/ trunk/clouseau/src/bin/clouseaud.c
>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> enlightenment-svn mailing list
>> enlightenment-...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>
>


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: tasn IN trunk/clouseau/src: . bin

2012-05-14 Thread Tom Hacohen
On 14/05/12 18:00, Leif Middelschulte wrote:
> 2012/5/14 Tom Hacohen:
>> What do you mean? That it's his old email address? Yeah, it's a pretty old
>> commit. :)
> Yes, I was just referring to its outdated state. So people know who to
> contact if anything is wrong with this commit and won't get annoyed by
> undeliverable mails.

Ahh, I just noticed he forgot to update his email address. I thought it 
was like that only for the old commits, but you are right, it's for all 
of them. :|

--
Tom.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: glima trunk/elementary/src/lib

2012-05-15 Thread Tom Hacohen
On 15/05/12 12:35, Daniel Juyung Seo wrote:
> Hello,
> elm_layout_text_set instead of elm_layout_part_text_set?
> For elm_object, we supported elm_object_part_text_set and elm_object_text_set.

But you need a name for setting the default part.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Eobj - Request for review/comments

2012-05-16 Thread Tom Hacohen
On 16/05/12 11:01, Carsten Haitzler (The Rasterman) wrote:
> i'm coming back to this. i really still think we should have a free func. if
> it's null, nothing is freed for u. if not null it's called on object delete 
> for
> any remaining properties still there. cost is just 1 more ptr. :)
>

Oldie! Already added it. :) It's in svn with a free func.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: tasn trunk/elementary/src/lib

2012-05-16 Thread Tom Hacohen
On 16/05/12 22:02, Davide Andreoli wrote:
> Changelog? Backport?  no?

Changelog: fix a stupid bug in a widget no one uses (but my colleague it
seems).

Though seriously, changelog: no way I'm adding a changelog entry for
that, we are really getting nuts with the changelog, we have 1
changes like this per release which just clutters the changelog. That's
what bug trackers and associating bugs with releases are for, not the
changelog. If we plan on adding changelog entries for every small
change, we might as well just paste the VCS log there on release (like
some projects do).

As for the backport. It's annoying to do with svn (and our directory
structure), very annoying, also, it's driving me nuts. Again, comparing
to other projects: that's why there are "version maintainers", just for
backporting. When it comes to scratching my own itches: I couldn't care
less about backports, I usually do it, but it's really just too annoying.

We just need to find something to do with backporting (which will be a
lot easier but still annoying with git) and define guidelines for when
to backport (and more importantly who), and when to add changelog
entries. It's just too crazy to go on like that. People are motivated
about improving EFL, not supporting the debian-afraid-of-updates gang.

Just my thoughts. :)

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: tasn trunk/elementary/src/lib

2012-05-17 Thread Tom Hacohen
On 17/05/12 02:15, Carsten Haitzler (The Rasterman) wrote:
> the point of releases and stability is that regardless if *YOU* care, you have
> "users" (customers) who care and stability is about supporting them. making
> bugfix releases with no nasty surprises they can DEPEND on. if you personally
> care about the bug/widget or not is not really relevant. your USERS will care 
> -
> some of them will, AND if you care about the project at all you care about
> users and at least TRY to help them out and make them happy. there are of
> course limits and there is the other side of being unreasonable, but doing a
> backport of a fix is far from unreasonable.

It's painful and annoying. As I said, I do it. You I've done my share of 
backports in the past, it's not that I'm against them/strictly against 
them. I'm just saying it's maybe time to think about this process and 
fix it, because as I said *I* don't care (for my own sake, i.e 
scratching my own itches, like I said) about backports (and most users 
don't care much as well, but lets leave that aside) and it's a painful 
process for me to do. It just makes sense that people that care about 
the older version will maintain them. I.e just have an "old version" 
maintainer.
>
>> Though seriously, changelog: no way I'm adding a changelog entry for
>> that, we are really getting nuts with the changelog, we have 1
>> changes like this per release which just clutters the changelog. That's
>
> the changelog is a small fraction of the size of the svn log. the changelog is
> for packagers and users to see what did change when they GET THE TARBALL. the
> changelog is what i use to update NEWS files at release time. scm log is
> everything. changelog is filtered down entries to the new additions, removals
> and bug fixes done - any bug fix at all that may have affected someone and
> their apps/code etc. (fixing a spelling mistakke in a comment, doc, readme 
> etc.
> isn't going to affect people normally).

I know what a changelog is for, but you have to put a line somewhere. 
I'm certain you'll agree that "Fixed elm_object_text_set to work when 
inserting the text 'aouaA
>> what bug trackers and associating bugs with releases are for, not the
>> changelog. If we plan on adding changelog entries for every small
>
> and then the bug tracker is "cluttered with 1 changes". unlike the
> changelog you have to wait 5 seconds for each bug report page to come up, as
> opposed to a quick scan of a text file to see if your annoying bug has been
> fixed this release or not.

You can just show them all in a list and see all the titles, and it's 
grouped per release so no filtering is needed.
>
>> change, we might as well just paste the VCS log there on release (like
>> some projects do).
>
> no - because scm logs contain all the junk in between.

And changelog just contains a lot of other junk.
>
>> As for the backport. It's annoying to do with svn (and our directory
>> structure), very annoying, also, it's driving me nuts. Again, comparing
>> to other projects: that's why there are "version maintainers", just for
>> backporting. When it comes to scratching my own itches: I couldn't care
>> less about backports, I usually do it, but it's really just too annoying.
>
> 
> svn diff | (cd ~/dev/svn/e/branches/elementary-1.0; patch -p0)
>
> that's annoying? you could script it trivially:
>
> cat backport.sh
> #!/bin/sh
> svn diff | (cd ~/dev/svn/e/branches/$1; patch -p0)
>
> so now it's a simple:
>
> backport.sh elementary-1.0


1. Yes, it's terribly annoying, and you have to maintain checkouts of 
all the branches.
2. It's not as simple as you'll may have conflicts.
3. It's not as easy when you work with git-svn and have multiple commits 
in your queue (can be done, just not as trivial).
>
> reality is that often the changelogs (and patches) don't apply so there is a
> manual fix anyway and no scm is going to magically fix that for you. this is
> the cost of stability and doing releases. this is WHY on most large projects
> there are DEDICATED people who just do the backporting (ie maintaining) of
> stable releases. so please do this. it's the right and professional thing to
> do. our tools are just fine

That's the point of my mail! I wasn't trolling about git, we already 
said we'll move to git after e17 is out, I was just saying we need 
dedicated people to do the backporting, I'm glad we agree.
>
>> We just need to find something to do with backporting (which will be a
>> lot easier but still annoying with git) and define guidelines for when
>
> no easier with git. see above.

Is too, especially when you work with local commits, but also just 
because you don't need to maintain more than one checkout of the code.
>
>> to backport (and more importantly who), and when to add changelog
>> entries. It's just too crazy to go on like that. People are motivated
>> about improving EFL, not supporting the debian-afraid-of-updates gang.
>
> and then all your serious users run away be

Re: [E-devel] E SVN: tasn trunk/elementary/src/lib

2012-05-17 Thread Tom Hacohen
On 17/05/12 11:26, Stefan Schmidt wrote:
> Well, if you don't have a special case for 'aouaA would also affect other text entries. Rare sure, but not as rare as you
> might think. Adding a changelog with the fixed _root cause_ would still
> make sense.

I'm talking about a specific case bug here, not "we didn't allocate 
enough space for strings longer than 5 characters"...
>
> About the only-a-bug-when-reported I can just say this will not work. I
> agree that reported bugs have higher priority and should get an entry,
> but just because it was not reported does not mean it nobody was
> affected by it. Users are as lazy as developers in this regard. :)

Yes, I was trying to be lazy, well either that, or trying to make people 
use trac more. :)
>
>> 1. Yes, it's terribly annoying, and you have to maintain checkouts of
>> all the branches.
>
> I actually would expect this from developers.

I would not. I expect developers to have the code they work on available 
and that's it.
>
>> 2. It's not as simple as you'll may have conflicts.
>
> Sure. And form time to time its even not sensible to do so because too
> much internals changed. Naturally backports will slow down to the most
> important ones while code in the dev branch moves on. More likely to
> happen with elementary right now then say for embryo.

So, we only backport "easy to merge" fixes? We don't fix issues that are 
found in newer versions that also apply to older versions? The 
backporting we do just feels so random.
>
>> 3. It's not as easy when you work with git-svn and have multiple commits
>> in your queue (can be done, just not as trivial).
>
> I'm sorry, but that really reads like an excuse because do don't want to
> use your tools in a better way. Making a new branch and bringing over
> the commits you want to commit and then backport is not that hard with
> git. You can then rebase, or merge. Local changes come with a cost.

True, was an excuse. As I said, it can be done, just also annoying.
>
>> As I said, I know it's important, I'm just saying my "direct" motivation
>> is to improve the EFL and not to support users. I do support users, I
>> help on the ML/IRC and generally available. I care about EFL flourishing
>> and that's why I even bother about arguing. I'm just saying it's getting
>> a bit annoying.
>> Heck, I've been bugging everyone for years to write proper commit logs,
>> doc the code and write unit tests, which achieves stability and more.
>
> We all pester for efl and e17 releases for years and now that we have
> some we need to take care about doing some maintenance as well. Price to
> pay.

Yes, there is a price, but the price shouldn't be retarded and undefined. :)

>> We need to "optimise" the way we work, not only the code we write, and
>> at the moment, we are very far from ideal in that field.
>
> I heartfully agree with you on this. Still just ripping out parts of the
> workflow that are useful for others is no optimisation but a simple
> feature removal to save time. :)

That's part of it. That's why I said, we need version maintainers makes 
things easier.
>
>> Just think about the time wasted, people annoyed by it (me for one) and
>> compare it to the outcome and the benefits we get from it and let us
>> know if you still think we should go on the way we do.
>
> Interestingly it seems to be easy enough to do backports for raster and
> cedric. For me it looks like your own setup makes it harder then needed.
> (No complete checkout, local commits). There is nothing in git and
> git-svn that would block you from having a good setup for this.
>

It also seems to be easy enough for me to write unit tests, proper 
commit logs and doxygen, and yet I'm one of the only ones who do it. I 
guess things are not like they seem, raster and cedric work hard to do 
it. And maybe, I have lower tolerance for repetitive work.

And I'm sorry, but local commits are a huge bonus and a must have for 
me. Before I knew about git-svn I used to work with a local svn repo 
which was painful as well, but still better than not having local 
commits. Complete checkouts - I don't care about all the crap in trunk 
and furthermore, I use git's local branches to have a better workflow.

Git and git-svn don't block me from doing it, I block me from doing it. 
You can't have a good setup with a complete checkout as it makes it hard 
to do bisects for specific libraries/changesets as you'd have to 
recompile everything all the time, you can't have the local branches I 
was talking about and generally it makes a lot of things more difficult 
and it's not how on should work.

I know we have the tech limitation of using SVN, and I'm fine with that, 
as a move to git is planned and everyone will be happy soon enough, but 
what I'm talking about is beyond git-vs-svn it's about our work methodology.

--
Tom.



--
Live Security Virtual Conference
Exclusive live event will cover all

Re: [E-devel] E SVN: tasn IN trunk/elementary: config/default config/illume config/standard src/lib

2012-05-21 Thread Tom Hacohen
Fixed in svn, thanks a lot for your comment.

On 21/05/12 03:56, ChunEon Park wrote:
> How about set the default time to 0.25?
>
> Currently  ecore double_click_time is 0.25.
>
>
> 
>
> -Regards, Hermet-
>
>
>
> -Original Message-
> From: "Enlightenment SVN"
> To:;
> Cc:
> Sent: 2012-05-20 (일) 23:56:35
> Subject: E SVN: tasn IN trunk/elementary: config/default config/illume 
> config/standard src/lib
>
> Log:
> Elm glayer: Made tap timeout a config.
>
> Author:   tasn
> Date: 2012-05-20 07:56:35 -0700 (Sun, 20 May 2012)
> New Revision: 71258
> Trac: http://trac.enlightenment.org/e/changeset/71258
>
> Modified:
>trunk/elementary/config/default/base.src 
> trunk/elementary/config/illume/base.src 
> trunk/elementary/config/standard/base.src 
> trunk/elementary/src/lib/elm_config.c 
> trunk/elementary/src/lib/elm_gesture_layer.c 
> trunk/elementary/src/lib/elm_priv.h
>
> Modified: trunk/elementary/config/default/base.src
> ===
> --- trunk/elementary/config/default/base.src  2012-05-20 14:56:32 UTC (rev 
> 71257)
> +++ trunk/elementary/config/default/base.src  2012-05-20 14:56:35 UTC (rev 
> 71258)
> @@ -55,6 +55,7 @@
> value "glayer_line_angular_tolerance" double: 20.0;
> value "glayer_flick_time_limit_ms" uint: 120; /* ms to finish flick */
> value "glayer_long_tap_start_timeout" double: 1.2; /* sec to start 
> long-tap */
> +  value "glayer_double_tap_timeout" double: 0.2; /* Timeout between two 
> mouse dows when doing double click (and more). */
> value "glayer_continues_enable" uchar: 1;  /* Continues gesture 
> enabled */
> value "week_start" int: 1;
> value "weekend_start" int: 6;
>
> Modified: trunk/elementary/config/illume/base.src
> ===
> --- trunk/elementary/config/illume/base.src   2012-05-20 14:56:32 UTC (rev 
> 71257)
> +++ trunk/elementary/config/illume/base.src   2012-05-20 14:56:35 UTC (rev 
> 71258)
> @@ -55,6 +55,7 @@
> value "glayer_line_angular_tolerance" double: 20.0
> value "glayer_flick_time_limit_ms" uint: 100; /* ms to finish flick */
> value "glayer_long_tap_start_timeout" double: 1.2; /* sec to start 
> long-tap */
> +  value "glayer_double_tap_timeout" double: 0.2; /* Timeout between two 
> mouse dows when doing double click (and more). */
> value "glayer_continues_enable" uchar: 1;  /* Continues gesture 
> enabled */
> value "week_start" int: 1;
> value "weekend_start" int: 6;
>
> Modified: trunk/elementary/config/standard/base.src
> ===
> --- trunk/elementary/config/standard/base.src 2012-05-20 14:56:32 UTC (rev 
> 71257)
> +++ trunk/elementary/config/standard/base.src 2012-05-20 14:56:35 UTC (rev 
> 71258)
> @@ -55,6 +55,7 @@
> value "glayer_line_angular_tolerance" double: 20.0;
> value "glayer_flick_time_limit_ms" uint: 120; /* ms to finish flick */
> value "glayer_long_tap_start_timeout" double: 1.2; /* sec to start 
> long-tap */
> +  value "glayer_double_tap_timeout" double: 0.2; /* Timeout between two 
> mouse dows when doing double click (and more). */
> value "glayer_continues_enable" uchar: 1;  /* Continues gesture 
> enabled */
> value "week_start" int: 1;
> value "weekend_start" int: 6;
>
> Modified: trunk/elementary/src/lib/elm_config.c
> ===
> --- trunk/elementary/src/lib/elm_config.c 2012-05-20 14:56:32 UTC (rev 
> 71257)
> +++ trunk/elementary/src/lib/elm_config.c 2012-05-20 14:56:35 UTC (rev 
> 71258)
> @@ -377,6 +377,7 @@
>  ELM_CONFIG_VAL(D, T, glayer_line_angular_tolerance, T_DOUBLE);
>  ELM_CONFIG_VAL(D, T, glayer_flick_time_limit_ms, T_INT);
>  ELM_CONFIG_VAL(D, T, glayer_long_tap_start_timeout, T_DOUBLE);
> +   ELM_CONFIG_VAL(D, T, glayer_double_tap_timeout, T_DOUBLE);
>  ELM_CONFIG_VAL(D, T, access_mode, T_INT);
>  ELM_CONFIG_VAL(D, T, glayer_continues_enable, T_UCHAR);
>  ELM_CONFIG_VAL(D, T, week_start, T_INT);
> @@ -1032,6 +1033,7 @@
>  _elm_config->glayer_line_angular_tolerance = 20.0; /* 20 DEG */
>  _elm_config->glayer_flick_time_limit_ms = 120;  /* ms to 
> finish flick */
>  _elm_config->glayer_long_tap_start_timeout = 1.2;   /* 1.2 second to 
> start long-tap */
> +   _elm_config->glayer_double_tap_timeout = 0.2;   /* 0.2 seconds between 
> 2 mouse downs of a tap. */
>  _elm_config->glayer_continues_enable = EINA_TRUE;  /* Continue 
> gestures default */
>  _elm_config->week_start = 1; /* monday */
>  _elm_config->weekend_start = 6; /* saturday */
>
> Modified: trunk/elementary/src/lib/elm_gesture_layer.c
> ===
> --- trunk/elementary/s

Re: [E-devel] E SVN: tasn trunk/PROTO/eobj

2012-05-21 Thread Tom Hacohen
On 21/05/12 12:07, Vincent Torri wrote:
> Cflags must add dirs where the exported headers of Eo are located. You
> have only one such header (Eo.h), so you do not need 2 locations,
> here. You should revert that commit

If you look closely, you'll see I put my header in ${includedir} that 
is, I added the correct path. The second path, i.e the eo-@VMAJ@ was 
what I previously had there. I kept that because I'll may add stuff 
there at some point and it doesn't really matter. But I can't revert my 
commit as it'll not work and my commit is correct.

--
Tom.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Bug report - keybindings don't work while Everything is open

2012-05-21 Thread Tom Hacohen
On 21/05/12 13:28, Carsten Haitzler (The Rasterman) wrote:
> On Fri, 04 May 2012 22:09:57 +0300 Tom Hacohen  said:
>
>> Hey,
>>
>> I can't seem to be able to change keyboard layouts with my keybindings
>> (Ctrl + Space) while Everything is open.
>
> thats a bit of a doosey as everything grabs the kbd away from the action
> event handling core... :) we'd need multiple levels of action handling - some
> that always trigger even with grabs, some that don't. ughstix.
>

That's why I suggested q66 to stick to the X settings when switching 
keyboards, they "just work". :)

Annoying...

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Bug report - keybindings don't work while Everything is open

2012-05-21 Thread Tom Hacohen
On 21/05/12 14:56, Carsten Haitzler (The Rasterman) wrote:
> not here - they fail miserably setting multiple kbd layouts

Just with jp for some reason we still don't understand... :)

But it would have worked just fine with X calls, maybe we should do that?

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: tasn trunk/PROTO/eobj

2012-05-21 Thread Tom Hacohen
On 21/05/12 12:20, Vincent Torri wrote:
> On Mon, May 21, 2012 at 11:11 AM, Tom Hacohen  wrote:
>> On 21/05/12 12:07, Vincent Torri wrote:
>>> Cflags must add dirs where the exported headers of Eo are located. You
>>> have only one such header (Eo.h), so you do not need 2 locations,
>>> here. You should revert that commit
>>
>> If you look closely,
>
> you want *me* to look closely at the cmake horror ? Funny.
>
>> you'll see I put my header in ${includedir} that
>> is, I added the correct path. The second path, i.e the eo-@VMAJ@ was
>> what I previously had there. I kept that because I'll may add stuff
>> there at some point and it doesn't really matter. But I can't revert my
>> commit as it'll not work and my commit is correct.
>
> then remove the second header dir and add it later
>
> But, if you follow the EFL scheme wrt those directories, you should
> put them in $includedir/eo-@VMAJ@, and not $includedir.

Yeah, well, all the build related styles will be adjusted to match the 
ones of the EFL once the build tool settles (i.e we conform with the 
rest of the EFL).

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Bug report - keybindings don't work while Everything is open

2012-05-22 Thread Tom Hacohen
On 22/05/12 02:37, Carsten Haitzler (The Rasterman) wrote:
> i tested with all of the country codes supported and its a smattering of about
> 30% of them that behave this way.

That's just odd.
> someone needs to add ecore-x api for that :)
>

* Tom stares at dh/you. :)

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Issue with xkbswitch

2012-05-22 Thread Tom Hacohen
On 21/05/12 14:13, Carsten Haitzler (The Rasterman) wrote:
> xkbswitch stuff will run the setxkbmap pretty much instantly - try stracing e.
> my bet is x itself is taking a while to reconfigure the kbdmap server-side?
>

I guess that sometimes it just takes xkbswitch to start (and finish)... 
We can only solve it with ecore_x...

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Elementary: Question. Fonts in elm entry object

2012-05-23 Thread Tom Hacohen
Cool, thanks.

On 24/05/12 06:51, Carsten Haitzler (The Rasterman) wrote:
> On Sun, 13 May 2012 10:47:50 +0300 Tom Hacohen  said:
>
>> On 11/05/12 23:07, Art B wrote:
>>> I can't seem to figure/understand how to modify the fonts(name or size)
>>> trough my elm C client-code. I can do this easily with an edje TEXTBLOCK
>>> object. But then I miss out on anchors for example.
>>>
>>> I would appreciate greatly if someone could explain how to do this with
>>> elementary for me. A code example would suffice also.
>>
>> I added a short paragraph to the entry docs to explain how it can be
>> done. Doc generation is currently broken on the server, but you can just
>> access the following file:
>
> i fixed the doc generation. yay!
>
>> http://svn.enlightenment.org/svn/e/trunk/elementary/src/lib/elm_entry.h
>> and search for entry-style-set.
>>
>> Also, there's a code example available in ecrire (
>> http://svn.enlightenment.org/svn/e/trunk/ecrire/ ). Or more
>> specifically, in main.c:510, function: "editor_font_set". You should
>> probably check that out as well.
>>
>> --
>> Tom.
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>
>


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [BUG] Items Minimized to Systray Fail to Maximize

2012-05-24 Thread Tom Hacohen
On 24/05/12 14:31, Carsten Haitzler (The Rasterman) wrote:
> 4. tried handbrake-gtk... and this does do what you say..

Just from the app name, it seems it uses gtk, isn't gtk supposed to do 
it right? If it doesn't do it right, open a bug in gtk, if it does but 
handbrake-gtk does something funky, open a bug there.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: hyoyoung trunk/elementary/src/lib

2012-05-24 Thread Tom Hacohen
On 24/05/12 16:46, Gustavo Sverzut Barbieri wrote:
> On Wed, May 23, 2012 at 11:38 PM, Enlightenment SVN
>   wrote:
>>
>> Log:
>> elementary/hoversel: fix indent
>>
>>
>> Author:   hyoyoung
>> Date: 2012-05-23 19:38:59 -0700 (Wed, 23 May 2012)
>> New Revision: 71377
>> Trac: http://trac.enlightenment.org/e/changeset/71377
>>
>> Modified:
>>   trunk/elementary/src/lib/elc_hoversel.c
>>
>> Modified: trunk/elementary/src/lib/elc_hoversel.c
>> ===
>> --- trunk/elementary/src/lib/elc_hoversel.c 2012-05-24 02:26:55 UTC (rev 
>> 71376)
>> +++ trunk/elementary/src/lib/elc_hoversel.c 2012-05-24 02:38:59 UTC (rev 
>> 71377)
>> @@ -230,7 +230,7 @@
>> Evas_Object *obj __UNUSED__,
>> void *event_info __UNUSED__)
>>   {
>> -   elm_hoversel_hover_parent_set((Evas_Object*)data, NULL);
>> +   elm_hoversel_hover_parent_set((Evas_Object *)data, NULL);
>>   }
>
> If you're fixing indent, then remove this ugly (Evas_Object*) cast.
> It's not required in C.

Or if you keep it, at least add a space before the "data" i.e 
"(Evas_Object *) data".

--
Tom.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: hyoyoung trunk/elementary/src/lib

2012-05-24 Thread Tom Hacohen
On 24/05/12 17:09, Carsten Haitzler (The Rasterman) wrote:
> we've never added spaces after casts before... historically.
>
>

I guess that depends on where in the EFL you look. :)

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] contributions page git+svn

2012-05-26 Thread Tom Hacohen
On 26/05/12 14:43, Leif Middelschulte wrote:
> Hey there,
> 
> we list "svn+ssh://u...@svn.enlightenment.org/var/svn/e/evas" as an
> URL example for git-svn. Shouldn't "evas" be trimmed?
> 

No, because it's an example... Furthermore, especially with git people
should have different clones per "module".

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] contributions page git+svn

2012-05-28 Thread Tom Hacohen
On 26/05/12 16:20, Leif Middelschulte wrote:
> 2012/5/26 Sebastian Dransfeld:
>> On 05/26/2012 02:33 PM, Leif Middelschulte wrote:
>>> 2012/5/26 Mike Blumenkrantz:
 It's missing /trunk
>>> You shouldn't define trunk if you want to keep the std layout. But
>>> concatinating "trunk" doesn't make it work here either. Only git svn
>>> clone'ing entire "trunk" works.
>>
>> efl svn hasn't standard layout.
> Thanks for pointing this out. I had the impression it did, but am not
> an expert in svn layouts ;-)
>> And trunk should be before evas.
>>
>> /var/svn/e/trunk/evas
> Objections to correct this and point out that it is not a std layout?

Ah, it's just missing the trunk... :) As I said, the problem is not with 
the Evas.

Anyhow, it's in. Thanks.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] libtasn

2012-06-05 Thread Tom Hacohen
On 01/06/12 16:21, ChunEon Park wrote:
> Betrayer Tom! You've worked for an another opensource!
> 

It's the official lib of my fan club.
> 
> Of course this is a joke. :p

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] libtasn

2012-06-05 Thread Tom Hacohen
On 05/06/12 20:35, Christopher Michael wrote:
> 
> apt-get remove --purge *tasn* :-P:-P


You and Mike are making a huge mistake, I suggest you keep it.

--
Tom.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] libtasn

2012-06-05 Thread Tom Hacohen
On 05/06/12 21:37, Christopher Michael wrote:
> If it functioned properly, I may :-P:-P

I can't change the past, will try to improve the future. :)

--
Tom.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: discomfitor trunk/elementary

2012-06-06 Thread Tom Hacohen
On 06/06/12 22:05, Christopher Michael wrote:
> 
> Lol ;-)

What mail client do you use? For some reason your client breaks
thunderbird's "sort by thread".

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: discomfitor trunk/elementary

2012-06-06 Thread Tom Hacohen
On 06/06/12 22:24, Christopher Michael wrote:
> 
> Not sure which. Whatever came wih my fancy new Samsung Galaxy S II ;-)

I don't use it myself, because I use gmail, but K-9 Mail is an open
source mail client for Android which is considered very good, maybe it's
better than what ships with the S2 and hopefully less broken. :)

https://play.google.com/store/apps/details?id=com.fsck.k9

Btw, grats on the new phone. :)

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] EFL 1.1.1 Release

2012-06-07 Thread Tom Hacohen
On 07/06/12 12:29, Michael Blumenkrantz wrote:
> Hi,
>
> Your new evil release overlord again. The 1.1.1 release is out and ready
> for download. It's only got a few libraries, but they're really good ones.
> Seriously. I've got my name in the AUTHORS, so I definitely know what I'm
> talking about. Upgrade while supplies last, we are not responsible for
> damages, yada yada.
>
> I think I'm getting the hang of this.

Yes, You are doing an amazing job.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Python bindings NOTICE: Getting things Python 3 compatible.

2012-06-11 Thread Tom Hacohen
On 10/06/12 15:13, Kai Huuhko wrote:
> Heads up, expect the unexpected.
>
> I've started getting the bindings ready for Py3.
>
> I'm going to add two functions, fruni and touni (see below), which
> will handle string conversions. Any *_set method taking in strings
> will need to wrap the value(s) in fruni and the *_get methods
> returning char* wrap them in touni.

I was under the impression that we already do that. Anyhow, just to make 
sure, you mean to do that internally in our implementations and not let 
the users of the API do it, right?

--
Tom.



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: tasn trunk/edje/src/lib

2012-06-11 Thread Tom Hacohen
On 12/06/12 02:54, Cedric BAIL wrote:
> On Sun, Jun 10, 2012 at 8:14 PM, Enlightenment SVN
>  wrote:
>> Log:
>> Edje load: Although we don't use them that much, we have refcounts in evas.
>>
>>   Don't assume an evas_object_del has to delete the object.
>
> Woot ? Why would the sub object of Edje object be refcounted ? Only
> Edje is alloed to play with them !

Nah, evas is also allowed to play with them... Also, the fix is more 
correct anyway, code should express what we mean, without too much magic. :)

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: tasn trunk/edje/src/lib

2012-06-12 Thread Tom Hacohen
On 12/06/12 10:00, Cedric BAIL wrote:
> Why would he ? Seriously, nobody should refcount the child of Edje. If
> someone does that bad things are going to happen, like this child
> could be an external and trigger event in a dead parent for example.
> So refcounting the Edje object is fine, referencing its child is
> calling for wrong things to happen.
>

It's a smart child, this means evas smart also has ownership of it and 
it can do whatever it wants. In my case it just refs, calls edje and 
unrefs (which is a very fair use) and that's completely legal. But even 
assuming my usage is not good, this code will currently cause an 
infinite loop on such a case, which is bad.

Why the hell should we assume that an object will be deleted there, and 
that a callback will be called and that the callback will delete the 
object from the edje list? Of course it works, because it's like that at 
the moment, but that just feels way too fragile and full of assumptions.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: raster IN trunk: . terminology terminology/data terminology/data/desktop terminology/data/fonts terminology/data/icons terminology/data/images terminology/data/themes terminology/

2012-06-12 Thread Tom Hacohen
On 12/06/12 13:18, Vincent Torri wrote:
> strikethrough can be done in the textgrid object, no ?

Yeah.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: tasn trunk/evas/src/lib/canvas

2012-06-13 Thread Tom Hacohen
Fixed in 72068, Thanks.

--
Tom.

On 12/06/12 21:23, Daniel Juyung Seo wrote:
> Hello Tom.
> This breaks eyelight. Can you check with eyelight?
>
> Please refer the following screenshot.
> http://www.flickr.com/photos/67308399@N05/718081/in/photostream
> When I run eyelight and move forward/backward fast, objects are not
> deleted correctly.
> howto)
>1. build/install PROTO/eyelight
> 2. run $eyelight -p=efl.elt in trunk/MARKETING/conf/FOSDEM/2011/EFL
>
> This commit broke it.
> Thanks in advance.
>
> Daniel Juyung Seo (SeoZ)
>
> On Mon, Jun 11, 2012 at 5:35 PM, Enlightenment SVN
>  wrote:
>> Log:
>> Evas smart: Remove from the list, don't assume we have not other refcounts.
>>
>>   Without it, it just assumes the object has no refcounts and deletes the
>>   object by force. It's very bad if you use refcounts, because your refcounts
>>   are gone.
>>
>> Author:   tasn
>> Date: 2012-06-11 01:35:07 -0700 (Mon, 11 Jun 2012)
>> New Revision: 71936
>> Trac: http://trac.enlightenment.org/e/changeset/71936
>>
>> Modified:
>>   trunk/evas/src/lib/canvas/evas_object_smart.c
>>
>> Modified: trunk/evas/src/lib/canvas/evas_object_smart.c
>> ===
>> --- trunk/evas/src/lib/canvas/evas_object_smart.c   2012-06-11 08:19:04 
>> UTC (rev 71935)
>> +++ trunk/evas/src/lib/canvas/evas_object_smart.c   2012-06-11 08:35:07 
>> UTC (rev 71936)
>> @@ -301,7 +301,10 @@
>>   {
>> Evas_Object_Smart *o = (Evas_Object_Smart *)(obj->object_data);
>> while (o->contained)
>> - evas_object_del((Evas_Object *)(o->contained));
>> + {
>> +evas_object_smart_member_del(
>> +  EINA_INLIST_CONTAINER_GET(o->contained, Evas_Object));
>> + }
>>   }
>>
>>   EAPI Evas_Object *
>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> enlightenment-svn mailing list
>> enlightenment-...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: raster IN trunk: . terminology terminology/data terminology/data/desktop terminology/data/fonts terminology/data/icons terminology/data/images terminology/data/themes terminology/

2012-06-13 Thread Tom Hacohen
On 13/06/12 16:17, Vincent Torri wrote:
>> typedef struct _Evas_Text_Cell
>> {
>>intglyph;
>>unsigned char  fg, bg;
>>unsigned short bold  : 1;
>>unsigned short italic: 1;
>>unsigned short underline : 1;
>>unsigned short strikethrough : 1;
>>unsigned short fg_extended   : 1;
>>unsigned short bg_extended   : 1;
>> } Evas_Text_Cell;
>
> hmmm, Glyph is what ? In my previous Textgrid object, I used an
> Eina_Unicode, which is a wchar_t (32 bits on unix, 16 bits on windows)
> if wchar_t is available, and un unsigned int (or uint32_t) otherwise.

Glyph is an index of a specific char in a font file, don't use it, as 
it's not the same for all characters across font files. You should use 
Eina_Unicode as did before.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Someone broke hoversel, whoever did it, please fix it

2012-06-13 Thread Tom Hacohen
Resend, never made it to the list.


 Original Message 
Subject: Someone broke hoversel, whoever did it, please fix it
Date: Wed, 13 Jun 2012 15:43:11 +0300
From: Tom Hacohen 
To: enlightenment-devel 

Just open the hoversel test and see.

--
Tom.



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: raster IN trunk: . terminology terminology/data terminology/data/desktop terminology/data/fonts terminology/data/icons terminology/data/images terminology/data/themes terminology/

2012-06-13 Thread Tom Hacohen
On 13/06/12 17:56, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 13 Jun 2012 16:25:23 +0300 Tom Hacohen  said:
>> Glyph is an index of a specific char in a font file, don't use it, as
>> it's not the same for all characters across font files. You should use
>> Eina_Unicode as did before.
>
> no. as this is insufficient. you need. you want an int.
>

First of all, as I said, you can't use the glyph index, because as I 
said, it won't work between fonts, so you have to store the unicode 
value... And if you store the unicode value, why not use Eina_Unicode 
which was made just for that?

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] last call for efm mount bugs

2012-06-13 Thread Tom Hacohen
On 13/06/12 09:37, Michael Blumenkrantz wrote:
> you've all got until this friday to notify me of any remaining efm mount
> bugs. after that I'm switching gears and probably won't be working on it
> for a bit.

Bug:
If you don't have permissions (udisk) to mount efm will open an empty
window and pressing "up" there segs e.

Otherwise, it seems to work.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] last call for efm mount bugs

2012-06-13 Thread Tom Hacohen
On 13/06/12 21:20, Michael Blumenkrantz wrote:
> bt?
> 

Not very useful as I don't have debug symbols and I'm doing something
else ATM, but it's easy to reproduce as I explained, and you'll have to
reproduce to test your fix anyway...

#0  0x7fc0f8a0dd17 in waitpid () from /lib/libpthread.so.0
#1  0x00433f2d in e_alert_show ()
#2  
#3  0x7fc0f778d3a1 in __strlen_sse2 () from /lib/libc.so.6
#4  0x7fc0f778d016 in strdup () from /lib/libc.so.6
#5  0x7fc0e446d07a in ?? () from
/usr/lib/enlightenment/modules/fileman/linu
#6  0x7fc0fa0bbcd2 in edje_match_callback_exec () from
/usr/lib/libedje.so.1
#7  0x7fc0fa0c1203 in _edje_emit_handle () from /usr/lib/libedje.so.1
#8  0x7fc0fa0bd0ef in _edje_message_queue_process () from
/usr/lib/libedje.s
#9  0x7fc0fa0bd257 in ?? () from /usr/lib/libedje.so.1
#10 0x7fc0f99085fb in ?? () from /usr/lib/libecore.so.1
#11 0x7fc0f990515c in _ecore_event_call () from /usr/lib/libecore.so.1
#12 0x7fc0f99095e9 in ?? () from /usr/lib/libecore.so.1
#13 0x7fc0f9909b67 in ecore_main_loop_begin () from
/usr/lib/libecore.so.1
#14 0x00431cf9 in main ()
(gdb) c


--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] last call for efm mount bugs

2012-06-13 Thread Tom Hacohen
On 13/06/12 21:47, Michael Blumenkrantz wrote:
> there's very few strdups in e, so this will be easier than you think
> 

Cool.

Anyhow, bug: connect my s2, press yes on the usb storage option (i.e
make it available to the pc) and then disable this. Nautilus handles it
good, I on the other hand still have icons on my desktop. :|

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: raster IN trunk: . terminology terminology/data terminology/data/desktop terminology/data/fonts terminology/data/icons terminology/data/images terminology/data/themes terminology/

2012-06-13 Thread Tom Hacohen
On 14/06/12 01:27, Carsten Haitzler (The Rasterman) wrote:
> apparently it only uses wchar_t IF its size is >= 4. that's fine. 2 is not
> enough. microsoft got it wrong. :)

Yeah, of course I wouldn't use it if it was less than 4 bytes. :)

--
Tom.




--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Someone broke genlist tree (possibly a while back, probably in the past week)

2012-06-14 Thread Tom Hacohen
Dear borkers,

run:
"valgrind --db-attach=yes 'genlist tree'"
you'll see a tons of the errors I turned on, but also valgrind will 
complain.
CRI<30384>:evas_main ../../../src/lib/main.c:97 evas_debug_magic_null() 
Input object is zero'ed out (maybe a freed object or zero-filled RAM)!


Seriously, stop breaking stuff.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Someone broke hoversel, whoever did it, please fix it

2012-06-14 Thread Tom Hacohen
Just open the hoversel test and see.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Someone broke elm_list <- FIX IT!

2012-06-14 Thread Tom Hacohen
run: elementary_test list
scroll a bit and you'll see the list isn't clipped, BAD BAD BAD!!!

I already found 2 broken widgets in the last 2 hours and that's without 
even running the tests. Seriously, test your code...

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: raster IN trunk: . terminology terminology/data terminology/data/desktop terminology/data/fonts terminology/data/icons terminology/data/images terminology/data/themes terminology/

2012-06-14 Thread Tom Hacohen
On 13/06/12 18:06, Carsten Haitzler (The Rasterman) wrote:
> its not the freetype font glyph index - its the codepoint - unicode. call it
> whatever u like - it has to be an int. read temrinology's code. it does this
> and it works just fine.. between fonts.

Ok, codepoint, and unicode, that's Eina_Unicode, it's *always* at least 
32 bit which is perfect for what you need. That's what we use for 
unicode codepoints all across the EFL (when it's code I laid my eyes upon).
>
>> said, it won't work between fonts, so you have to store the unicode
>> value... And if you store the unicode value, why not use Eina_Unicode
>> which was made just for that?
>
> 16bits is not enough on windows. at least that's what vincent claims. and 
> there
> is no need or DESIRE to abstract this. size matters. we need 32bits of space.
> efl works on the notion that int == 32bits. make it an int.

It's always 32bit. There are many reasons to abstract that:
1. I did it ages ago and it's already used in many places of the EFL.
2. It shows that the value is supposed to be a valid unicode code point.
3. If the platform's wchar_t is 32bit it'll use it, which means you gain 
debugger support for printing those as wide strings (which is awesome).

It's the same concept of Evas_Coord with the extra benefit of bullet #3.

Vincent:
Anyhow, no matter what you do, call it codepoint, or something like 
that, not glyph.

--
Tom.



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Evas textgrid object

2012-06-15 Thread Tom Hacohen
On 15/06/12 10:22, Vincent Torri wrote:
> Hey
> 
> I just committed the textgrid object, which will be used in
> terminology and maybe a couple of other apps. It needs love, though,
> as I'm not a text master in Evas.
> 
> I've attached a test example, which should give that :
> 
> http://www.maths.univ-evry.fr/pages_perso/vtorri/files/textgrid.png
> 

AWESOME! I'll take a look later today. :)

--
Tom.



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Evas textgrid object

2012-06-19 Thread Tom Hacohen
On 19/06/12 12:44, Vincent Torri wrote:
> it would be nice to have some comparisons with different terminals
> about speed and mem consumption

"time cat" to all the works of shakespeare (
http://www.gutenberg.org/ebooks/100 ) is way faster in Terminology 
compared to xterm:

Terminology: real   0m0.987s
Xterm: real0m2.784s
Urxvt is a bit faster here: real0m0.660s

But raster claims it's not the same for him, and for him terminology 
beats everyone. :)

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] terminology font size

2012-06-19 Thread Tom Hacohen
On 19/06/12 15:21, Sebastian Dransfeld wrote:
> Hi,
>
> Why does my font size in terminology not change? No special config flags.

We don't do any scaling to bitmap fonts, so if you use one, you can't 
resize it IIRC.

--
Tom.



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E17 BUG CALL

2012-06-20 Thread Tom Hacohen
On 20/06/12 16:58, Gustavo Sverzut Barbieri wrote:
> How about if we copy edbus econnman to e17 and talk DBus directly. Remove
> the configuration dialog and add the agent. Do the config dialog externally
> (in python-elm it should ttake a day)

Hallelujah!

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E17 BUG CALL

2012-06-21 Thread Tom Hacohen
On 20/06/12 15:49, Michael Blumenkrantz wrote:
> If you have an e17 bug, reply to this mail or create a ticket for it on
> trac. This is the LAST call. Hint hint.

One that you added today:
1. Set xchat to blink taskbar when someone writes your name.
2. Ask someone (I asked you) to write your name.
3. Quickly (before the other party has the chance to write your name) 
move to another desktop.
4. Move back to the xchat desktop after you see in the pager gadget that 
xchat is blinking.
5. Give xchat focus.

Expected:
xchat should stop blinking.
Actual:
xchat keeps on blinking and I hate you for introducing this bug.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] ecrire and eobj not building on older cmake versions.

2012-06-30 Thread Tom Hacohen
On 01/07/12 01:16, David Seikel wrote:
> If I get no reply I'll just commit later today or tomorrow.

Commit ahead. :)

Though you never attached the fix, so I have nothing to review. :)

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] ecrire and eobj not building on older cmake versions.

2012-06-30 Thread Tom Hacohen
On 01/07/12 09:17, David Seikel wrote:
> That's why I was asking, much easier to just commit than to make a
> patch and send it to the mailing list.  So I was trying to avoid
> sending a patch.  lol

Hehe, OK. As I said, just commit, and prepare yourself to get spanked if 
anything breaks.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] ecrire and eobj not building on older cmake versions.

2012-06-30 Thread Tom Hacohen
On 01/07/12 09:17, David Seikel wrote:
> On Sun, 01 Jul 2012 08:18:27 +0300 Tom Hacohen
>  wrote:
>
>> On 01/07/12 01:16, David Seikel wrote:
>>> If I get no reply I'll just commit later today or tomorrow.
>>
>> Commit ahead. :)
>>
>> Though you never attached the fix, so I have nothing to review. :)
>
> That's why I was asking, much easier to just commit than to make a
> patch and send it to the mailing list.  So I was trying to avoid
> sending a patch.  lol

I'm glad to see the issues were in the FindE* I hacked in minutes, and 
not in anything else.

--
Tom



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: bdilly trunk/ephysics

2012-07-01 Thread Tom Hacohen
I guess that Samsung paid for the development...

--
Tom.

On 01/07/12 10:27, Daniel Juyung Seo wrote:
> Why not ProFUSION?
>
> Daniel Juyung Seo (SeoZ)
>
> On Sat, Jun 30, 2012 at 7:22 AM, Enlightenment SVN
>  wrote:
>> Log:
>> EPhysics: modify copyright notice
>>
>>
>>
>> Author:   bdilly
>> Date: 2012-06-29 15:22:35 -0700 (Fri, 29 Jun 2012)
>> New Revision: 73064
>> Trac: http://trac.enlightenment.org/e/changeset/73064
>>
>> Modified:
>>   trunk/ephysics/COPYING
>>
>> Modified: trunk/ephysics/COPYING
>> ===
>> --- trunk/ephysics/COPYING  2012-06-29 22:22:28 UTC (rev 73063)
>> +++ trunk/ephysics/COPYING  2012-06-29 22:22:35 UTC (rev 73064)
>> @@ -1,6 +1,6 @@
>>   Copyright notice for EPhysics:
>>
>> -Copyright (C) 2012 ProFUSION Embedded Systems and various contributors
>> +Copyright (C) 2012 Samsung Electronics and various contributors
>>(see AUTHORS).
>>
>>   All rights reserved.
>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> enlightenment-svn mailing list
>> enlightenment-...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: caro IN trunk/eina: . m4/common src/tests

2012-07-01 Thread Tom Hacohen
I agree with Gustavo, I don't like it either, why change it? Who did it
bother lately?

--
Tom.

On 01/07/12 21:51, Vincent Torri wrote:
> On Sun, Jul 1, 2012 at 4:49 PM, Gustavo Sverzut Barbieri
>  wrote:
>> On Sun, Jul 1, 2012 at 8:48 AM, Enlightenment SVN
>>  wrote:
>>> Log:
>>> Eina: remove --enable-coverage option.
>>>
>>>   Now, coverage is detected with just --enable-tests.
>>>
>>>   Buildbot maintainers : please remove --enable-coverage option to
>>>   eina (more EFL will be supported later)
>>
>> n...
>> this is bad, coverage is annoying
> 
> no, coverage annoys *you*. And actuallly, why does it annoys you ?
> because of the 2 seconds it takes to generates the html pages ?
> 
> Vincent
> 
>> and I just enable it when I really
>> want to do coverage check.
>>
>> yet I always have the coverage tools in my sys.
>>
>> --
>> Gustavo Sverzut Barbieri
>> http://profusion.mobi embedded systems
>> --
>> MSN: barbi...@gmail.com
>> Skype: gsbarbieri
>> Mobile: +55 (19) 9225-2202
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: caro IN trunk/eina: . m4/common src/tests

2012-07-01 Thread Tom Hacohen
On 01/07/12 21:59, Vincent Torri wrote:
> the plan is to remove configure options, there are too many ones. this
> option is just small one, with no consequences on the behavior of the
> library.
> 
> again : why is it annoying to remove that option ?
> 

I don't remember what it was exactly, but I had some annoyances with
coverage. That's why I usually only enable coverage in a specific build
dir only when I really want it.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: caro IN trunk/eina: . m4/common src/tests

2012-07-01 Thread Tom Hacohen
On 01/07/12 22:09, Vincent Torri wrote:
> On Sun, Jul 1, 2012 at 9:01 PM, Tom Hacohen  wrote:
>> On 01/07/12 21:59, Vincent Torri wrote:
>>> the plan is to remove configure options, there are too many ones. this
>>> option is just small one, with no consequences on the behavior of the
>>> library.
>>>
>>> again : why is it annoying to remove that option ?
>>>
>>
>> I don't remember what it was exactly, but I had some annoyances with
>> coverage.
> 
> if there were some problems, bugs, etc..,why didn't you report them  ?
> 

Because those weren't bugs, just annoyances with how coverage is done.
Nothing you could have done. I seriously don't remember what it was
(maybe because I'm exhausted, I hope my memory will return with some
sleep), but I remember I kinda looked into it.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Textgrid API question:

2012-07-02 Thread Tom Hacohen
Resend, for some reason it didn't get sent... :|

Hey,

Why are the pixels sizes in the API are in int and not Evas_Coord?

--
Tom.



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Textgrid API question:

2012-07-02 Thread Tom Hacohen
On 02/07/12 13:58, Carsten Haitzler (The Rasterman) wrote:
> On Mon, 02 Jul 2012 13:21:09 +0300 Tom Hacohen  said:
>
>> Resend, for some reason it didn't get sent... :|
>>
>> Hey,
>>
>> Why are the pixels sizes in the API are in int and not Evas_Coord?
>
> evas_object_textgrid_cell_size_get() ?
>

Yeah.

--
Tom.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Textgrid API question:

2012-07-02 Thread Tom Hacohen
On 02/07/12 15:31, Carsten Haitzler (The Rasterman) wrote:
> yeah. that should be evas_coord. will fix.

Ah, ok, cool. :)

--
Tom.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: devilhorns trunk/evas

2012-07-03 Thread Tom Hacohen
On 03/07/12 17:34, Iván Briano wrote:
> 2012/7/3 Enlightenment SVN :
>> Log:
>> Evas: Update ChangeLog wrt Tizen Merge.
>>
>>   NB: This is the commit message inside tizen git for this commit. Don't
>>   blame me if the message is not detailed enough for you. Complain to
>>   the original committer about making more detailed commit messages.
>>
> 
> I say we reject changes unless they specify clearly what they do.

Yeah, we even talked about it on IRC and you agreed... You should not
commit things you don't know what they do. You can't know if the commit
is correct, buggy, or implements an unwanted behaviour.

--
Tom.



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: devilhorns trunk/evas

2012-07-03 Thread Tom Hacohen
On 03/07/12 18:31, cpmicha...@comcast.net wrote:
> Well, that makes all this merging nice and simple then. Ok, merging done !! 
> :) Since none (or hardly any) of the tizen git commits rarely ever specify 
> what they do/or fix, then none (or hardly any) of it will get committed 
> anymore. Makes the process much simplier ;) 
> 
> 
> On a serious note tho, alright no problem. I can spend the time tracking down 
> the people who did the commits and getting some sort or (hopefully) sane 
> response from them about what it fixes, etc, etc. Then apply & 
> testassuming that goes well, then maybe commit. Just be aware that, like 
> you said raster, it may take months. 

You can alternatively just read the patches and find out what they are
supposed to do and write changelog entries, news entries and commit logs
accordingly. :) Would probably be easier.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: devilhorns trunk/evas

2012-07-03 Thread Tom Hacohen
On 03/07/12 18:33, cpmicha...@comcast.net wrote:
> Should that also include changes to our own svn from our own developers who 
> don't put in commit messages that mention what the commit fixes ?? I would 
> think so based on this reasoning. 
> 

Of course, and I think developers are finally starting to do it better.
Either way, it's something everyone is trying to improve, and I don't
think you should compare yourself to the lowest standard, but to the
highest. :)

Furthermore, I'm pretty sure you agree anyway and just grumpy because
you have a very annoying task at hand. :)

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] E SVN: raster IN trunk/terminology: . src/bin

2012-07-04 Thread Tom Hacohen
On 03/07/12 20:28, Carsten Haitzler (The Rasterman) wrote:
> xdg-open is horrible. that's a last resort, not firs port of call.
> 

Perhaps it's horrible, but at the moment it's probably the easiest most
unified way of opening apps.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Corinthians campeão da libertadores 2012

2012-07-05 Thread Tom Hacohen
On 05/07/12 06:24, Gustavo Sverzut Barbieri wrote:
> See Twitter trending topics!
>
> No more,
> --the Champion!
>
> PS: Chupa Argentina! Chupa Boca Juniors!
> PS2: Chelsea, you're the next!
>

Have you been drinking?

Though seriously, I never thought of you as a football fan. :)

--
Tom.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


  1   2   3   4   5   6   7   8   9   10   >