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

[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 use of the full version (it should really
> have been our only version since day one, sadly we didn't had it when
> we did our first release, so it was added to late). Now that we have a
> chance to fix that, better take it !
>
> That's all I could think about that really matter.

Perhaps. I believe having the same name as what we had before is a big 
advantage (easier for people to "learn"), but I guess I can change it. 
Lets see what 

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

[Vincent Torri]

On Mon, Apr 23, 2012 at 12:57 PM, Enlightenment SVN
 wrote:
> Log:
> Eobj: Changed weak-ref to work without allocating a structure.
>
>  Thanks to cedric.
>
> Author:       tasn
> Date:         2012-04-23 03:57:04 -0700 (Mon, 23 Apr 2012)
> New Revision: 70415
> Trac:         http://trac.enlightenment.org/e/changeset/70415
>
> Modified:
>  trunk/PROTO/eobj/lib/Eobj.h trunk/PROTO/eobj/lib/eobj.c 
> trunk/PROTO/eobj/tests/eobj_test_general.c
>
> Modified: trunk/PROTO/eobj/lib/Eobj.h
> ===
> --- trunk/PROTO/eobj/lib/Eobj.h 2012-04-23 08:26:40 UTC (rev 70414)
> +++ trunk/PROTO/eobj/lib/Eobj.h 2012-04-23 10:57:04 UTC (rev 70415)
> @@ -535,46 +535,19 @@
>  */
>
>  /**
> - * @struct _Eobj_Weak_Ref
> - * This is exposed for performance, please use eobj_weak_ref_get() when you
> - * actually want to get the refed object.
> - */
> -struct _Eobj_Weak_Ref
> -{
> -   Eobj *obj; /**< The object being referenced. */
> -};
> -
> -/**
> - * @typedef Eobj_Weak_Ref
> - * Weak reference type for Eobj.
> - */
> -typedef struct _Eobj_Weak_Ref Eobj_Weak_Ref;
> -
> -/**
>  * @brief Create a new weak reference to obj.
>  * @param obj The object being referenced.
> - * @return A new weak reference.
> + * @param wref The pointer to use for the weak ref.
>  */
> -EAPI Eobj_Weak_Ref *eobj_weak_ref_new(const Eobj *obj);
> +EAPI void eobj_weak_ref_add(const Eobj *obj, Eobj **wref);

why don't you return the ref ? be consistant like the rest of the EFL
: return the value.

Vincent

--
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 IN trunk/PROTO/eobj: lib tests

[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

[Vincent Torri]

On Mon, Apr 23, 2012 at 2:32 PM, Enlightenment SVN
 wrote:
> Log:
> Eobj: Make eobj_weak_ref_add return the obejct being reffed.
>
>  Suggested by vtorri.
>
> Author:       tasn
> Date:         2012-04-23 05:32:36 -0700 (Mon, 23 Apr 2012)
> New Revision: 70418
> Trac:         http://trac.enlightenment.org/e/changeset/70418
>
> Modified:
>  trunk/PROTO/eobj/lib/Eobj.h trunk/PROTO/eobj/lib/eobj.c
>
> Modified: trunk/PROTO/eobj/lib/Eobj.h
> ===
> --- trunk/PROTO/eobj/lib/Eobj.h 2012-04-23 12:32:34 UTC (rev 70417)
> +++ trunk/PROTO/eobj/lib/Eobj.h 2012-04-23 12:32:36 UTC (rev 70418)
> @@ -545,8 +545,9 @@
>  * @brief Create a new weak reference to obj.
>  * @param obj The object being referenced.
>  * @param wref The pointer to use for the weak ref.
> + * @return The object being referenced (obj).
>  */
> -EAPI void eobj_weak_ref_add(const Eobj *obj, Eobj **wref);
> +EAPI Eobj *eobj_weak_ref_add(const Eobj *obj, Eobj **wref);

hmm, why do you need to return it in wref, then ???

Vincent

--
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

[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] Pager as hidden desktop gadget / edge bindings

[Nikolas Arend]

On 04/21/2012 09:12 PM, Nikolas Arend wrote:
> On 04/20/2012 09:55 PM, Nikolas Arend wrote:
>> Hi,
>>
>> I'm having trouble with a couple things that affect usability for me:
>>
>> - I use the pager as a desktop gadget and set it to be on top only when
>> Ctrl+Alt+G is pressed or else, like in my case, when triggered by a
>> mouse binding. Then drag'n'drop is broken, I can drag the windows but
>> they snap back or land on a different virtual desktop. Also dragging
>> icons from itask to the pager does not work (itask is a "hidden" gadget
>> as well). If the pager gadget is on top all the time and not hidden,
>> everything works as expected.
>>
>> - edge bindings stop working erratically, usually when I used it once or
>> twice. I'm not sure what triggers it, but it might start when a window
>> is overlapping with the screen edge for the first time (i.e. window is
>> spanning past the desktop boundaries). But I can't really tell for
>> certain. I use an edge binding to trigger show/hide gadgets, but I'm
>> seeing the same for e.g. triggering comp scale windows.
>>
>> I'm at svn 70308 and use the efenniht theme, but I checked with the
>> default theme as well, same thing. I have composite on (OpenGl engine,
> As a side-note: I have the edge binding problem regardless of whether
> the composite module is loaded or not.
>
> Please let me know if I can provide more information that helps track
> this down.

Is anybody else seeing this, any comments?

Thanks,  Nick


>
> Thanks,  Nick
>
>
>
>> texture from pixmap).
>>
>>
>> Thanks,   Nick
>>
>> --
>> 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
>


-- 

Nikolas Arend
165 California Avenue
Oak Ridge, TN 37830, USA

Phone: +1-865-622-7698
Cell: +1-865-283-9721
Email: nikolas.ar...@gmx.net



--
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] using LZ4 compression tool in eet ?

[thomasg]

On Sun, Apr 22, 2012 at 05:58, Carsten Haitzler  wrote:
> On Sat, 21 Apr 2012 12:08:18 +0200 Vincent Torri  
> said:
>
> actually forget lz4hc... lgpl3.
>
>> hey
>>
>> just found that while reading the gnutls ML :
>>
>> http://code.google.com/p/lz4/
>>
>> it seems that it allows the same ratio for compression than zlib but
>> seems  to be by far faster than zlib
>>
>> the memory consumption should be tested too.
>>
>> What do you think ?
>>
>> Vincent
>>
>> --
>> 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
>>
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)    ras...@rasterman.com
>
>
> --
> 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

I don't see any problem using an LGPLv3 library. Are there really any
changes necessary to make use of it in eet? Also, would it have to be
distributed in a way where LGPL parts would actually be packed into an
Eet binary or Eet source code?
Although I of course can understand that it would not be possible to
use Eet in an environment where no LGPL library could be accepted,
wherever or whyever that would be.

Other than that, would it really be worth it? Even if in the best case
the compression is only a little worse than zlib and compression time
would be a lot faster - would it really be worth it?
Eet usually is used WORM-style (Write Once / Read Many), so
compression time is hardly an issue - but if decompression is not
significantly faster (or even slower?), and file size is larger (thus
I/O, which more often than not is a bottle-neck nowadays, being lower)
you'd actually not gain anything but lose run-time performance
instead.
On the lz4hc page I only spotted compression benchmarks, nothing about
decompression - if basic information is missing, there usually is a
reason.

If anything, what would make sense for Eet would be the XZ format, using LZMA.
Compared to zlib, compression is a lot slower, but decompression is
not much slower - and compression ratio and through that I/O
throughput a lot higher.
XZs liblzma is LGPLv2.1 though.

Lastly: why would it be trouble supporting additional compression
methods? Eet uses file format versions in the binary, right? Why not
have features supported starting from a certain format version? Sure,
that would make old files incompatible but would this really be an
API-break? As I see it it would just mean newer files, or programs
using newer files, would have to depend on a newer minor release of
Eet without any actual API changes (in any case though it is an ABI
change for the Eet files I guess).
A way to do such a change might be having a new major release for it
and default to the old zlib compression, so users who require for
example XZ support can depend on it properly and not risk producing
files nobody can use, for no reason.

~thomasg

--
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] using LZ4 compression tool in eet ?

[Vincent Torri]

On Mon, Apr 23, 2012 at 3:05 PM, thomasg  wrote:
> On Sun, Apr 22, 2012 at 05:58, Carsten Haitzler  wrote:
>> On Sat, 21 Apr 2012 12:08:18 +0200 Vincent Torri  
>> said:
>>
>> actually forget lz4hc... lgpl3.
>>
>>> hey
>>>
>>> just found that while reading the gnutls ML :
>>>
>>> http://code.google.com/p/lz4/
>>>
>>> it seems that it allows the same ratio for compression than zlib but
>>> seems  to be by far faster than zlib
>>>
>>> the memory consumption should be tested too.
>>>
>>> What do you think ?
>>>
>>> Vincent
>>>
>>> --
>>> 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
>>>
>>
>>
>> --
>> - Codito, ergo sum - "I code, therefore I am" --
>> The Rasterman (Carsten Haitzler)    ras...@rasterman.com
>>
>>
>> --
>> 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
>
> I don't see any problem using an LGPLv3 library. Are there really any
> changes necessary to make use of it in eet? Also, would it have to be
> distributed in a way where LGPL parts would actually be packed into an
> Eet binary or Eet source code?
> Although I of course can understand that it would not be possible to
> use Eet in an environment where no LGPL library could be accepted,
> wherever or whyever that would be.
>
> Other than that, would it really be worth it? Even if in the best case
> the compression is only a little worse than zlib and compression time
> would be a lot faster - would it really be worth it?
> Eet usually is used WORM-style (Write Once / Read Many), so
> compression time is hardly an issue - but if decompression is not
> significantly faster (or even slower?), and file size is larger (thus
> I/O, which more often than not is a bottle-neck nowadays, being lower)
> you'd actually not gain anything but lose run-time performance
> instead.
> On the lz4hc page I only spotted compression benchmarks, nothing about
> decompression - if basic information is missing, there usually is a
> reason.
>
> If anything, what would make sense for Eet would be the XZ format, using LZMA.
> Compared to zlib, compression is a lot slower, but decompression is
> not much slower - and compression ratio and through that I/O
> throughput a lot higher.
> XZs liblzma is LGPLv2.1 though.

Iirc, xz uses much more memory than zlib, even during decompression

Vincent

--
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

[E-devel] [patch] doxygen fixes

[Jérôme Pinot]

Hi,

Here are several fixes for the doxygen docs:
- several typos
- unresolved links to EINA_{TRUE,FALSE} and NULL in eeze (and @c)
- misc

Hope it will make it before release...

 ecore/src/lib/ecore_con/Ecore_Con.h   |3 -
 eeze/src/lib/Eeze_Disk.h  |   58 +++---
 eina/src/include/eina_list.h  |6 +--
 eina/src/include/eina_simple_xml_parser.h |2 -
 4 files changed, 35 insertions(+), 34 deletions(-)


-- 
Jérôme Pinot
http://ngc891.blogdns.net/
Index: eeze/src/lib/Eeze_Disk.h
===
--- eeze/src/lib/Eeze_Disk.h(revision 70419)
+++ eeze/src/lib/Eeze_Disk.h(working copy)
@@ -116,7 +116,7 @@
 
 /**
  * @brief Create a new disk object from a /sys/ path or /dev/ path
- * @param path The /sys/ or /dev path of the disk; CANNOT be #NULL
+ * @param path The /sys/ or /dev path of the disk; CANNOT be @c NULL.
  * @return The new disk object
  *
  * This function creates a new #Eeze_Disk from @p path.  Note that this 
function
@@ -128,7 +128,7 @@
 
 /**
  * @brief Create a new disk object from a mount point
- * @param mount_point The mount point of the disk; CANNOT be #NULL
+ * @param mount_point The mount point of the disk; CANNOT be @c NULL
  * @return The new disk object
  *
  * This function creates a new #Eeze_Disk from @p mount_point.  Note that this 
function
@@ -207,7 +207,7 @@
  * @param disk The disk
  * @return The filesystem type
  *
- * This retrieves the filesystem that the disk is using, or #NULL if unknown.
+ * This retrieves the filesystem that the disk is using, or @c NULL if unknown.
  * @since 1.1
  */
 EAPI const char*eeze_disk_fstype_get(Eeze_Disk *disk);
@@ -217,7 +217,7 @@
  * @param disk The disk
  * @return The vendor
  *
- * This retrieves the vendor which manufactured the disk, or #NULL if unknown.
+ * This retrieves the vendor which manufactured the disk, or @c NULL if 
unknown.
  * @since 1.1
  */
 EAPI const char*eeze_disk_vendor_get(Eeze_Disk *disk);
@@ -227,7 +227,7 @@
  * @param disk The disk
  * @return The model
  *
- * This retrieves the model of the disk, or #NULL if unknown.
+ * This retrieves the model of the disk, or @c NULL if unknown.
  * @since 1.1
  */
 EAPI const char*eeze_disk_model_get(Eeze_Disk *disk);
@@ -237,7 +237,7 @@
  * @param disk The disk
  * @return The serial number
  *
- * This retrieves the serial number the disk, or #NULL if unknown.
+ * This retrieves the serial number the disk, or @c NULL if unknown.
  * @since 1.1
  */
 EAPI const char*eeze_disk_serial_get(Eeze_Disk *disk);
@@ -247,7 +247,7 @@
  * @param disk The disk
  * @return The UUID
  *
- * This retrieves the UUID of the disk, or #NULL if unknown.
+ * This retrieves the UUID of the disk, or @c NULL if unknown.
  * A UUID is a 36 character (hopefully) unique identifier which can
  * be used to store persistent information about a disk.
  * @since 1.1
@@ -259,7 +259,7 @@
  * @param disk The disk
  * @return The label
  *
- * This retrieves the label (name) of the disk, or #NULL if unknown.
+ * This retrieves the label (name) of the disk, or @c NULL if unknown.
  * @since 1.1
  */
 EAPI const char*eeze_disk_label_get(Eeze_Disk *disk);
@@ -278,7 +278,7 @@
 /**
  * @brief Return whether the disk is removable
  * @param disk The disk
- * @return EINA_TRUE if removable, else EINA_FALSE
+ * @return @c EINA_TRUE if removable, @c EINA_FALSE otherwise.
  * @since 1.1
  */
 EAPI Eina_Bool  eeze_disk_removable_get(Eeze_Disk *disk);
@@ -289,7 +289,8 @@
  * @param disk The disk
  * @return The mount state
  *
- * This returns the mounted state of the disk.  #EINA_TRUE if mounted, else 
#EINA_FALSE.
+ * This returns the mounted state of the disk.  @c EINA_TRUE if mounted,
+ * @c EINA_FALSE otherwise.
  * @since 1.1
  */
 EAPI Eina_Bool  eeze_disk_mounted_get(Eeze_Disk *disk);
@@ -297,7 +298,7 @@
 /**
  * @brief Get the previously set mount wrapper for a disk
  * @param disk The disk
- * @return The wrapper, or NULL on failure
+ * @return The wrapper, or @c NULL on failure.
  *
  * This returns the wrapper previously set with eeze_disk_mount_wrapper_set
  * @since 1.1
@@ -308,11 +309,11 @@
  * @brief Set a wrapper to run mount commands with
  * @param disk The disk to wrap mount commands for
  * @param wrapper The wrapper executable
- * @return EINA_TRUE on success, else EINA_FALSE
+ * @return @c EINA_TRUE on success, @c EINA_FALSE otherwise.
  *
  * Use this function to set up a wrapper for running mount/umount commands. 
The wrapper must
  * NOT use any of the standard mount/umount error code return values, and it 
must return 0 on success.
- * Note that this function will call stat() on @p wrapper if not NULL to test 
for existence.
+ * Note that this function will call stat() on @p wrapper if not @c NULL to 
test for existence.
  * @since 1.1
  */
 EAPI Eina_Bool  eeze_disk_mount_wrapper_set(Eeze_Disk *disk, const char 
*wrapper);
@@ -320,7 +32

Re: [E-devel] using LZ4 compression tool in eet ?

[Adrien Nader]

Hi,

On Sat, 21 Apr 2012 12:08:18 +0200 Vincent Torri  said:
> hey
>
> just found that while reading the gnutls ML :
>
> http://code.google.com/p/lz4/
>
> it seems that it allows the same ratio for compression than zlib but
> seems  to be by far faster than zlib
>
> the memory consumption should be tested too.
>
> What do you think ?

New compression formats and libraries regularly get released and my biggest
concern is always that they introduce incompatible changes every few months.
As far as I can tell, this isn't the case for lz4, which should be a good point
(even though there seems to be some changes coming; but as long as they don't
happen every few months...).

> Other than that, would it really be worth it? Even if in the best case
> the compression is only a little worse than zlib and compression time
> would be a lot faster - would it really be worth it?
> Eet usually is used WORM-style (Write Once / Read Many), so
> compression time is hardly an issue - but if decompression is not
> significantly faster (or even slower?), and file size is larger (thus
> I/O, which more often than not is a bottle-neck nowadays, being lower)
> you'd actually not gain anything but lose run-time performance
> instead.
> On the lz4hc page I only spotted compression benchmarks, nothing about
> decompression - if basic information is missing, there usually is a
> reason.
> 
> If anything, what would make sense for Eet would be the XZ format, using LZMA.
> Compared to zlib, compression is a lot slower, but decompression is
> not much slower - and compression ratio and through that I/O
> throughput a lot higher.
> XZs liblzma is LGPLv2.1 though.

XZ(lzma2)/lzma have variable memory requirements. The xz manpage
explains pretty much everything (and #tukaani on freenode is a nice
place if you have questions). Here is the summary:

  The following table summarises the features of the presets:

 Preset   DictSize   CompCPU   CompMem   DecMem
   -0 256 KiB   03 MiB1 MiB
   -1   1 MiB   19 MiB2 MiB
   -2   2 MiB   2   17 MiB3 MiB
   -3   4 MiB   3   32 MiB5 MiB
   -4   4 MiB   4   48 MiB5 MiB
   -5   8 MiB   5   94 MiB9 MiB
   -6   8 MiB   6   94 MiB9 MiB
   -7  16 MiB   6  186 MiB   17 MiB
   -8  32 MiB   6  370 MiB   33 MiB
   -9  64 MiB   6  674 MiB   65 MiB

This shows the big picture, but reading the manpage is quite important (it's
detailled and informative).

That reminds me of one very nice feature of lzma: the decompression speed is
roughly constant in terms of compressed data, i.e. it is independant of the
uncompressed size. In other words, if 10MB of data gets compressed down to 1MB,
it'll get decompressed five times faster than 10MB of data that got compressed
down to 5MB.

However, iirc, lzma can use quite a lot of memory bandwidth.

-- 
Adrien Nader

--
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] using LZ4 compression tool in eet ?

[The Rasterman]

On Mon, 23 Apr 2012 15:05:09 +0200 thomasg  said:

> On Sun, Apr 22, 2012 at 05:58, Carsten Haitzler  wrote:
> > On Sat, 21 Apr 2012 12:08:18 +0200 Vincent Torri 
> > said:
> >
> > actually forget lz4hc... lgpl3.
> >
> >> hey
> >>
> >> just found that while reading the gnutls ML :
> >>
> >> http://code.google.com/p/lz4/
> >>
> >> it seems that it allows the same ratio for compression than zlib but
> >> seems  to be by far faster than zlib
> >>
> >> the memory consumption should be tested too.
> >>
> >> What do you think ?
> >>
> >> Vincent
> >>
> >> --
> >> 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
> >>
> >
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)    ras...@rasterman.com
> >
> >
> > --
> > 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
> 
> I don't see any problem using an LGPLv3 library. Are there really any
> changes necessary to make use of it in eet? Also, would it have to be
> distributed in a way where LGPL parts would actually be packed into an
> Eet binary or Eet source code?

there i a problem because we'd have to compile it into eet - which would make
eet lgpl3. gpl and lgpl3 are also highly propblematice in terms of acceptance.
they are controversial at best.

> Although I of course can understand that it would not be possible to
> use Eet in an environment where no LGPL library could be accepted,
> wherever or whyever that would be.

no, it's the gpl/lgpl3 (as opposed to 2).

> Other than that, would it really be worth it? Even if in the best case
> the compression is only a little worse than zlib and compression time
> would be a lot faster - would it really be worth it?

compression time for just a little worse than zlib is the same as zlib. for 30%
less compression compression is 7x faster and decompression 6x faster. forget
the hc lgpl3 variant. we just gain on decompress speed here. its the normal one
with the size loss that smells interesting.

> Eet usually is used WORM-style (Write Once / Read Many), so
> compression time is hardly an issue - but if decompression is

indeed this is minimally interesting, well until we are generating edj files on
the fly as you type in an edje editor thing that lets u edit and see previews
on the fly... :)

> not significantly faster (or even slower?), and file size is larger (thus

decompression 6x faster - see my other mail. that means load times for config
data and edj files could be improved by this.

> I/O, which more often than not is a bottle-neck nowadays, being lower)
> you'd actually not gain anything but lose run-time performance
> instead.

for uncached (first run) yes - for repeated re-load on cached data... it will
help. :)

> On the lz4hc page I only spotted compression benchmarks, nothing about
> decompression - if basic information is missing, there usually is a
> reason.
> 
> If anything, what would make sense for Eet would be the XZ format, using LZMA.
> Compared to zlib, compression is a lot slower, but decompression is
> not much slower - and compression ratio and through that I/O
> throughput a lot higher.
> XZs liblzma is LGPLv2.1 though.

maybe - as above. depends on if its cached or uncached. :)

> Lastly: why would it be trouble supporting additional compression
> methods? Eet uses file format versions in the binary, right? Why not
> have features supported starting from a certain format version? Sure,
> that would make old files incompatible but would this really be an

no - the other way. newer files (edj files/themes) dont work with older
eet/edje's etc.

> API-break? As I see it it would just mean newer files, or programs
> using newer files, would have to depend on a newer minor release of
> Eet without any actual API changes (in any case though it is an ABI
> change for the Eet files I guess).
> A way to do such a change might be having a new major release for it
> and default to the old zlib compression, so users who require for
> example XZ support can depend on it properly and not risk producing
> files nobody can use, for no reason.

we have it already. this is a pr

Re: [E-devel] using LZ4 compression tool in eet ?

[Joerg Sonnenberger]

On Mon, Apr 23, 2012 at 03:05:09PM +0200, thomasg wrote:
> XZs liblzma is LGPLv2.1 though.

No, only the fallback support for limited platforms using gnulib is.
The rest is PD.

Joerg

--
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

[E-devel] [PATCH] python-elementary: Add all equivalent Label functions from C and drop obsolete label_set/get

[Kai Huuhko]

---
 python-elementary/elementary/__init__.py   |5 +++
 .../elementary/elementary.c_elementary_label.pxi   |   37 ++--
 .../include/elementary/c_elementary.pxd|   11 +-
 3 files changed, 41 insertions(+), 12 deletions(-)

diff --git a/python-elementary/elementary/__init__.py b/python-elementary/elementary/__init__.py
index 2d46105..6ddc056 100644
--- a/python-elementary/elementary/__init__.py
+++ b/python-elementary/elementary/__init__.py
@@ -126,4 +126,9 @@ ELM_WEB_ZOOM_MODE_MANUAL = 0
 ELM_WEB_ZOOM_MODE_AUTO_FIT = 1
 ELM_WEB_ZOOM_MODE_AUTO_FILL = 2
 
+ELM_WRAP_NONE = 0
+ELM_WRAP_CHAR = 1
+ELM_WRAP_WORD = 2
+ELM_WRAP_MIXED = 3
+
 c_elementary.init()
diff --git a/python-elementary/elementary/elementary.c_elementary_label.pxi b/python-elementary/elementary/elementary.c_elementary_label.pxi
index c807519..526bedb 100644
--- a/python-elementary/elementary/elementary.c_elementary_label.pxi
+++ b/python-elementary/elementary/elementary.c_elementary_label.pxi
@@ -21,19 +21,34 @@ cdef class Label(Object):
 Object.__init__(self, parent.evas)
 self._set_obj(elm_label_add(parent.obj))
 
-def label_set(self, label):
-_METHOD_DEPRECATED(self, "text_set")
-self.text_set(label)
+def line_wrap_set(self, Elm_Wrap_Type wrap):
+elm_label_line_wrap_set(self.obj, wrap)
 
-def label_get(self):
-_METHOD_DEPRECATED(self, "text_get")
-return self.text_get()
+def line_wrap_get(self):
+return elm_label_line_wrap_get(self.obj)
 
-property label:
-def __get__(self):
-return self.label_get()
+def wrap_width_set(self, int w):
+elm_label_wrap_width_set(self.obj, w)
 
-def __set__(self, label):
-self.label_set(label)
+def wrap_width_get(self):
+return elm_label_wrap_width_get(self.obj)
+
+def ellipsis_set(self, bool ellipsis):
+elm_label_ellipsis_set(self.obj, ellipsis)
+
+def ellipsis_get(self):
+return elm_label_ellipsis_get(self.obj)
+
+def slide_set(self, bool slide):
+elm_label_slide_set(self.obj, slide)
+
+def slide_get(self):
+elm_label_slide_get(self.obj)
+
+def slide_duration_set(self, double duration):
+elm_label_slide_duration_set(self.obj, duration)
+
+def slide_duration_get(self):
+elm_label_slide_duration_get(self.obj)
 
 _elm_widget_type_register("label", Label)
diff --git a/python-elementary/include/elementary/c_elementary.pxd b/python-elementary/include/elementary/c_elementary.pxd
index 0d4631d..b78 100644
--- a/python-elementary/include/elementary/c_elementary.pxd
+++ b/python-elementary/include/elementary/c_elementary.pxd
@@ -179,7 +179,6 @@ cdef extern from "Elementary.h":
 ELM_WRAP_CHAR
 ELM_WRAP_WORD
 ELM_WRAP_MIXED
-ELM_WRAP_LAST
 
 ctypedef enum Elm_Bubble_Pos:
 ELM_BUBBLE_POS_TOP_LEFT
@@ -498,6 +497,16 @@ cdef extern from "Elementary.h":
 
 # Label object
 evas.c_evas.Evas_Object *elm_label_add(evas.c_evas.Evas_Object *parent)
+void elm_label_line_wrap_set(evas.c_evas.Evas_Object *obj, Elm_Wrap_Type wrap)
+Elm_Wrap_Type elm_label_line_wrap_get(evas.c_evas.Evas_Object *obj)
+void elm_label_wrap_width_set(evas.c_evas.Evas_Object *obj, evas.c_evas.Evas_Coord w)
+evas.c_evas.Evas_Coord elm_label_wrap_width_get(evas.c_evas.Evas_Object *obj)
+void elm_label_ellipsis_set(evas.c_evas.Evas_Object *obj, evas.c_evas.Eina_Bool ellipsis)
+evas.c_evas.Eina_Bool elm_label_ellipsis_get(evas.c_evas.Evas_Object *obj)
+void elm_label_slide_set(evas.c_evas.Evas_Object *obj, evas.c_evas.Eina_Bool slide)
+evas.c_evas.Eina_Bool elm_label_slide_get(evas.c_evas.Evas_Object *obj)
+void elm_label_slide_duration_set(evas.c_evas.Evas_Object *obj, double duration)
+double elm_label_slide_duration_get(evas.c_evas.Evas_Object *obj)
 
 # Frame object
 evas.c_evas.Evas_Object* elm_frame_add(evas.c_evas.Evas_Object *parent)
--
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] using LZ4 compression tool in eet ?

[David Seikel]

On Mon, 23 Apr 2012 22:42:22 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Mon, 23 Apr 2012 15:05:09 +0200 thomasg 
> said:
> 
> > On Sun, Apr 22, 2012 at 05:58, Carsten Haitzler
> >  wrote:
> > > On Sat, 21 Apr 2012 12:08:18 +0200 Vincent Torri
> > >  said:
> > >
> > > actually forget lz4hc... lgpl3.
> > >
> > >> hey
> > >>
> > >> just found that while reading the gnutls ML :
> > >>
> > >> http://code.google.com/p/lz4/
> > >>
> > >> it seems that it allows the same ratio for compression than zlib
> > >> but seems  to be by far faster than zlib
> > >>
> > >> the memory consumption should be tested too.
> > >>
> > >> What do you think ?
> > >>
> > >> Vincent
> > >>
> > >> --
> > >> 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
> > >>
> > >
> > >
> > > --
> > > - Codito, ergo sum - "I code, therefore I am"
> > > -- The Rasterman (Carsten Haitzler)
> > >  ras...@rasterman.com
> > >
> > >
> > > --
> > > 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
> > 
> > I don't see any problem using an LGPLv3 library. Are there really
> > any changes necessary to make use of it in eet? Also, would it have
> > to be distributed in a way where LGPL parts would actually be
> > packed into an Eet binary or Eet source code?
> 
> there i a problem because we'd have to compile it into eet - which
> would make eet lgpl3. gpl and lgpl3 are also highly propblematice in
> terms of acceptance. they are controversial at best.
> 
> > Although I of course can understand that it would not be possible to
> > use Eet in an environment where no LGPL library could be accepted,
> > wherever or whyever that would be.
> 
> no, it's the gpl/lgpl3 (as opposed to 2).

I'd be one of those not accepting of GPL 3, or it's variations.  Google
does not accept any GPL variants in Android officially, even though they
rely on a few GPL parts for the base OS.  Including the Linux kernel.

For what it's worth, I think I found a GPL3 bit buried deep in the
ewebkit dependencies, but I kinda gave up for now after I had gotten
several levels deep in dependency hell.  I think the plan with ewebkit
is to strip out some more dependencies to replace them with EFL bits?
That would help, but right now it's a bitch to compile on Ubuntu
10.04.  I'll try again later, when there is less dependencies, or
after I upgrade to Ubuntu 12.04 later this year.

That's the danger with GPL 3 on huge projects.  The main project might
be BSD or something, but buried deep is a GPL 3 component of a sub
component of a dependency that no one noticed.  Likely coz it was GPL 2
when it went in.  Then the entire thing is contaminated.  FSF has been
painting GPL 2 in a bad light, and swapping licenses on old versions of
GNU stuff with out telling people.  I think that's despicable.

FSF may be good for their Four Freedoms, but they take away an
important freedom with everything they touch.  I have seen GPL
stifling innovation in large projects.  And this is precisely why, we
may not use this new compression thing just coz we want EET to be BSD,
and not be forced to make it GPL.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
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] [patch] doxygen fixes

[Sanjeev BA]

In SVN r70426
Thanks

On Mon, Apr 23, 2012 at 10:30 PM, Jérôme Pinot  wrote:

>
> Hi,
>
> Here are several fixes for the doxygen docs:
> - several typos
> - unresolved links to EINA_{TRUE,FALSE} and NULL in eeze (and @c)
> - misc
>
> Hope it will make it before release...
>
>  ecore/src/lib/ecore_con/Ecore_Con.h   |3 -
>  eeze/src/lib/Eeze_Disk.h  |   58
> +++---
>  eina/src/include/eina_list.h  |6 +--
>  eina/src/include/eina_simple_xml_parser.h |2 -
>  4 files changed, 35 insertions(+), 34 deletions(-)
>
>
> --
> Jérôme Pinot
> http://ngc891.blogdns.net/
>
>
> --
> 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
>
>
--
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: seoz IN trunk/devs: . hyoyoung

[Daniel Juyung Seo]

With great power comes great responsibility.

Daniel Juyung Seo (SeoZ)

On Tue, Apr 24, 2012 at 11:16 AM, Enlightenment SVN
 wrote:
> Log:
> devs/hyoyoung: Added a new developer - hyoyoung.
>  I introduce a new developer, Hyoyoung Chang.
>  Hyoyoung is very passionate developer. He has been
>  contributing over a hundred of patches for a couple of years. I bet he
>  will continue working on this for long.
>  Anyhow, congratulations!
>
> Author:       seoz
> Date:         2012-04-23 19:16:01 -0700 (Mon, 23 Apr 2012)
> New Revision: 70427
> Trac:         http://trac.enlightenment.org/e/changeset/70427
>
> Added:
>  trunk/devs/hyoyoung/ trunk/devs/hyoyoung/id_rsa.pub 
> trunk/devs/hyoyoung/info.txt
>
>
> --
> 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] SVN access recommendation for Hyoyoung Chang

[Daniel Juyung Seo]

In SVN!
I've seen many people left the community after becoming committers. So
only for those who have been working over  some period is worthy of
svn access. I think hyoyoung has enough reason.
Anyhow hyoyoung, please keep in mind I mentioned in the previous email.
Waiting for your good commits :)
Thanks.


Daniel Juyung Seo (SeoZ)

On Fri, Apr 20, 2012 at 9:55 PM, Carsten Haitzler  wrote:
> On Fri, 20 Apr 2012 17:39:45 +0900 Daniel Juyung Seo 
> said:
>
> i would agree with all the below. just one added note. NEVER commit unless u
> will stay around for the next 2-3 hrs after it and be around online. no
> committing friday night and then immediately and then going and getting drunk 
> :)
>
>> Dear all, this is Daniel Juyung Seo.
>>
>> I recommend Hyoyoung to have a SVN commit access.
>> As many of you know, he has been heavily working for elementary so far.
>> If I remember correctly, he has been sent over a hundred patches.
>> And because I think he did enough contribution and it's ok to give him
>> svn access, I recommend him as a committer.
>> If there is no super big objection, I'll add his account in a couple of days.
>> But Hyoyoung, remember once you have svn access you need to be more
>> careful about your code.
>>
>> Thanks.
>>
>> Daniel Juyung Seo (SeoZ)
>>
>> --
>> 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
>>
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)    ras...@rasterman.com
>

--
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

[cnook]

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.
>
>


textblock.issue.on.popup.patch
Description: Binary data
--
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] SVN access recommendation for Hyoyoung Chang

[woohyun]

Oh! hyyoung ~ welcome !!
& Congratulation ~~~ !!!
:)




-Original Message-
From: "Daniel Juyung Seo" 
To: "Carsten Haitzler"; 
Cc: "Enlightenment developer 
list"; 
Sent: 2012-04-24 (화) 11:25:27
Subject: Re: [E-devel] SVN access recommendation for Hyoyoung Chang

In SVN!
I've seen many people left the community after becoming committers. So
only for those who have been working over  some period is worthy of
svn access. I think hyoyoung has enough reason.
Anyhow hyoyoung, please keep in mind I mentioned in the previous email.
Waiting for your good commits :)
Thanks.


Daniel Juyung Seo (SeoZ)

On Fri, Apr 20, 2012 at 9:55 PM, Carsten Haitzler 
@rasterman.com> wrote:
> On Fri, 20 Apr 2012 17:39:45 +0900 Daniel Juyung Seo 
@gmail.com>
> said:
>
> i would agree with all the below. just one added note. NEVER commit unless 
u
> will stay around for the next 2-3 hrs after it and be around online. no
> committing friday night and then immediately and then going and getting 
drunk :)
>
>> Dear all, this is Daniel Juyung Seo.
>>
>> I recommend Hyoyoung to have a SVN commit access.
>> As many of you know, he has been heavily working for elementary so far.
>> If I remember correctly, he has been sent over a hundred patches.
>> And because I think he did enough contribution and it's ok to give him
>> svn access, I recommend him as a committer.
>> If there is no super big objection, I'll add his account in a couple 
of days.
>> But Hyoyoung, remember once you have svn access you need to be more
>> careful about your code.
>>
>> Thanks.
>>
>> Daniel Juyung Seo (SeoZ)
>>
>> 
--
>> 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
>>
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>

--
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] SVN access recommendation for Hyoyoung Chang

[Hyoyoung Chang]

Thanks for recommendation.
It's honor to me. ;P
I have been benefited from E and other open sources.
I'm happy to contribute.

Thank you guys.

On Tue, Apr 24, 2012 at 11:30 AM, woohyun  wrote:
> Oh! hyyoung ~ welcome !!
> & Congratulation ~~~ !!!
> :)
>
>
>
>
> -Original Message-
> From: "Daniel Juyung Seo"
> To: "Carsten Haitzler";
> Cc: "Enlightenment developer 
> list";
> Sent: 2012-04-24 (화) 11:25:27
> Subject: Re: [E-devel] SVN access recommendation for Hyoyoung Chang
>
> In SVN!
> I've seen many people left the community after becoming committers. So
> only for those who have been working over  some period is worthy of
> svn access. I think hyoyoung has enough reason.
> Anyhow hyoyoung, please keep in mind I mentioned in the previous email.
> Waiting for your good commits :)
> Thanks.
>
>
> Daniel Juyung Seo (SeoZ)
>
> On Fri, Apr 20, 2012 at 9:55 PM, Carsten Haitzler 
> @rasterman.com> wrote:
> > On Fri, 20 Apr 2012 17:39:45 +0900 Daniel Juyung Seo 
> @gmail.com>
> > said:
> >
> > i would agree with all the below. just one added note. NEVER commit 
> unless u
> > will stay around for the next 2-3 hrs after it and be around online. no
> > committing friday night and then immediately and then going and getting 
> drunk :)
> >
> >> Dear all, this is Daniel Juyung Seo.
> >>
> >> I recommend Hyoyoung to have a SVN commit access.
> >> As many of you know, he has been heavily working for elementary so 
> far.
> >> If I remember correctly, he has been sent over a hundred patches.
> >> And because I think he did enough contribution and it's ok to give 
> him
> >> svn access, I recommend him as a committer.
> >> If there is no super big objection, I'll add his account in a couple 
> of days.
> >> But Hyoyoung, remember once you have svn access you need to be more
> >> careful about your code.
> >>
> >> Thanks.
> >>
> >> Daniel Juyung Seo (SeoZ)
> >>
> >> 
> --
> >> 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
> >>
> >
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > The Rasterman (Carsten Haitzler)    ras...@rasterman.com
> >
>
> --
> 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

[E-devel] efl release 24hr countdown

[The Rasterman]

ok - my plans are to push out a release about 24hrs from now... anyone got
bugs.. report.. and FIX!. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
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 release 24hr countdown

[Michael Blumenkrantz]

On Tue, 24 Apr 2012 15:47:11 +0900
Carsten Haitzler (The Rasterman)  wrote:

> ok - my plans are to push out a release about 24hrs from now... anyone got
> bugs.. report.. and FIX!. :)
> 

http://30.media.tumblr.com/tumblr_m1dah4cJBT1rrju89o1_500.jpg

--
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