Re: [E-devel] E SVN: nash IN trunk/eina/src: include lib
Enlightenment SVN schrieb:
Log:
Unicde strnlen, and a slight fix to the header so at least part can be read
by
humans.
Also strlen/strnlen are pure.
Author: nash
Date: 2010-07-29 20:39:12 -0700 (Thu, 29 Jul 2010)
New Revision: 50676
Modified:
trunk/eina/src/include/eina_unicode.h trunk/eina/src/lib/eina_unicode.c
Modified: trunk/eina/src/include/eina_unicode.h
===
--- trunk/eina/src/include/eina_unicode.h 2010-07-30 03:20:40 UTC (rev
50675)
+++ trunk/eina/src/include/eina_unicode.h 2010-07-30 03:39:12 UTC (rev
50676)
@@ -42,10 +42,10 @@
EAPI extern const Eina_Unicode *EINA_UNICODE_EMPTY_STRING;
-EAPI size_t
- eina_unicode_strlen(
- const Eina_Unicode *ustr) EINA_ARG_NONNULL(1);
+EAPI size_t eina_unicode_strlen(const Eina_Unicode *ustr)
EINA_ARG_NONNULL(1) EINA_PURE;
+EAPI size_t eina_unicode_strnlen(const Eina_Unicode *ustr, int n)
EINA_ARG_NONNULL(1) EINA_PURE;
+
EAPI Eina_Unicode *
eina_unicode_strdup(
const Eina_Unicode *text) EINA_WARN_UNUSED_RESULT EINA_ARG_NONNULL(1)
Modified: trunk/eina/src/lib/eina_unicode.c
===
--- trunk/eina/src/lib/eina_unicode.c 2010-07-30 03:20:40 UTC (rev 50675)
+++ trunk/eina/src/lib/eina_unicode.c 2010-07-30 03:39:12 UTC (rev 50676)
@@ -81,6 +81,29 @@
}
/**
+ * @brief Returns the length of a Eina_Unicode string, up to a limit.
+ *
+ * This function returns the number of characters in string, up to a maximum
+ * of n. If the terminating character is not found in the string, it returns
+ * n.
+ *
+ * @param ustr String to search
+ * @param n Max length to search
+ * @return Number of characters or n.
+ */
+EAPI size_t
+eina_unicode_strnlen(const Eina_Unicode *ustr, int n)
+{
+ const Eina_Unicode *end;
+ for (end = ustr; *end; end++)
+ ;
+ return end - ustr;
+}
The function doesn't seem to respect n in any way
Regards Peter
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash IN trunk/eina/src: include lib
Brett Nash n...@nash.id.au
On 30/07/2010, at 10:28 PM, Peter Wehrfritz peter.wehrfr...@web.de wrote:
+EAPI size_t
+eina_unicode_strnlen(const Eina_Unicode *ustr, int n)
+{
+ const Eina_Unicode *end;
+ for (end = ustr; *end; end++)
+ ;
+ return end - ustr;
+}
The function doesn't seem to respect n in any way
You are entirely correct. I'll push the actual working code tomorrow.
Thanks.
Regards,
Nash
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Elm_Image and frame
On Thu, Jul 29, 2010 at 2:41 PM, Atton Jonathan jonathan.at...@gmail.com wrote: Hello, I whish to add a frame to elm_image and a way for the theme to display a border/shadow arround the image. I have already do this in elm_photo but I will move it into elm_image where it should be. Currently : - there is no frame, only a els_icon. What I whish to do : - add a frame - add a way to display a border around the image. Here is the problem. els_icon have 2 objects : the container and the image (content). Elm_Image swallow the els_icon in his theme. The image is resize to keep the aspect and the container take all the space it can. Consequently the theme can't know the size of the image. In elm_photo I have added : - a embryo script which retrieve the size of the image from the C code - the C-code (elm_image/photo) listen the size's change on the image and send the size to the theme. If you know a better way to do this, please tell me. Although Raster may find a difference in all these widgets he created, for someone from outside, the differences between bg, image, icon and photo are not clear. They all load an image in some way, they all seem to offer an option to keep aspect, and how to do it. Differences are so little, like loading images with pre-defined names from theme (icon), or emitting signal when clicked (photo), that I guess it is worth to have a single one that does all of that with frames (as you wish), or just provide widgets that inherit from the same base, providing the details but reusing the base. (I like the first approach bit more in this case). BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e code formatting - uncrustify
I think another interesting question is whether uncrustify needs to change wrapping at all? Couldn't we just add some code which checks line length and warns the user if the code has to long lines and print where the offenders are? Automatic wrapping never results in readable code. Sebastian Carsten Haitzler (The Rasterman) wrote: On Thu, 29 Jul 2010 20:55:12 -0700 Michael Jennings m...@kainx.org said: read the mail you replied to originally. i make the statement that you can keep growing the wrap width to fix up the formatting. and you just grow until you cease to wrap. thats avoiding the bug. not fixing it. it's what i said. i didn't change canoes. if its 80 - 85, or 80 - 135 - same principle. as for terminal resizes - all terminals anyone really uses (except for actual vt100's etc.) can be resized - linux console included. you can change screen resolution, text mode and font sizes. no different to a terminal in x - just harder to do the resizing. your argument is well chose 135 because there is a terminal mode. i'll believe that argument the day xterm, rxvt, gnome-terminal, eterm, konsole, the linux fb console etc. etc. all come in 135 wide by default when you run them. your argument justifies making wrap width wider because of standardisation. i argue that that is a slippery slope of simply moving the goalposts as opposed to fixing the formatting itself. that's what i said long before you piped up. please don't tell me i changed canoes mid-stream. On Friday, 30 July 2010, at 10:43:48 (+0900), Carsten Haitzler wrote: you don't get the point - the point is that the formatter doesnt handle wrapping intelligently. Not once in anything that you wrote to me did you state that. So no, that wasn't your point. Changing canoes in midstream because you made an error in logic does not mean I don't get the point. :) you will find code that doesnt fit in 132 die and needs wrapping - and the same problem will exist. That's certainly true. However, there will be *significantly fewer* occurances of the problem, and the result will still be more readable for those problem cases because the right-hand column is further out, allowing more space to work with. It's possible using 132 will eliminate enough problems to make fixing the tool unnecessary, allowing everyone to get back to writing EFL. Isn't it worth a try? the only solution other than fixing the formatter is the slippery slope. fix the problem. don't follow the slippery slope of workarounds. That's not what the logical fallacy referred to as slippery slope means. The URL I provided explains it. you argue that 132 columns is just fine because there is a terminal mode for it. that argument can be extended to any width with just resize your terminal. Not true. Not all terminals can be resized. That's the whole point. If all terminals could be resized to any desired width, it wouldn't matter one wit what column count we chose. Fixed terminals such as the Linux console cannot be resized. That's precisely why the default of 80 tends to be used. the fact is that when you start any terminal... you get an 80 wide one in almost all cases. not 132. you need to change things to be otherwise. thus 80 as a baseline makes sense. 132 doesn't. 132 makes sense for all the reasons I already mentioned. It's not as ideal as 80, no, but it has specific, clear advantages over all other values aside from 80. That may not be enough to make you want to use it, but it's still valid. if your fix to wrapping problems is well just make your terminal wider you're ignoring the actual problem that the formatter can't wrap correctly. Just make your terminal wider is a misrepresentation of my viewpoint, and you know that. Yes, the formatter has issues, but is fixing someone else's formatter something you really want to invest time in this close to release? One could also say that the actual problem is that this whole mess was inflicted on the community without sufficient testing or advance discussion and way too close to the release date to be reasonable. Heaven forbid someone offer a suggestion that might save everyone a lot of time and headaches and have logical reasoning to back it up Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- I want to stand with you on a mountain. I want to bathe with you in the sea. I want to lay like this forever, until the sky falls down on me.-- Savage Garden, Truly, Madly, Deeply -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more
Re: [E-devel] e code formatting - uncrustify
Without wrapping I think almost (if not all) of the readability
issues and strange cases would go away, so this may be the best idea. A
simple $( grep -En ^(.){81} ) will print all lines+linenumbers with
length of 81 or more so that they can be wrapped manually if
necessary...
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e code formatting - uncrustify
On Fri, Jul 30, 2010 at 4:15 PM, Sebastian Dransfeld s...@tango.flipp.net wrote: I think another interesting question is whether uncrustify needs to change wrapping at all? Couldn't we just add some code which checks line length and warns the user if the code has to long lines and print where the offenders are? Automatic wrapping never results in readable code. This is what I was talking since the beginning of this discussion. Lucas De Marchi -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ 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/eet/src: bin examples lib tests
On 07/30/2010 09:54 PM, Enlightenment SVN wrote:
Log:
formatting.- uncrustify
Author: raster
Date: 2010-07-30 18:54:48 -0700 (Fri, 30 Jul 2010)
New Revision: 50698
Modified:
trunk/eet/src/bin/eet_main.c
trunk/eet/src/examples/eet-data-file_descriptor.c
trunk/eet/src/examples/eet-data-nested.c
trunk/eet/src/examples/eet-data-simple.c trunk/eet/src/lib/Eet.h
trunk/eet/src/lib/Eet_private.h trunk/eet/src/lib/eet_cipher.c
trunk/eet/src/lib/eet_connection.c trunk/eet/src/lib/eet_data.c
trunk/eet/src/lib/eet_dictionary.c trunk/eet/src/lib/eet_image.c
trunk/eet/src/lib/eet_lib.c trunk/eet/src/lib/eet_node.c
trunk/eet/src/lib/eet_utils.c trunk/eet/src/tests/eet_data_suite.c
trunk/eet/src/tests/eet_suite.c trunk/eet/src/tests/eet_suite.h
static void
-do_eet_list(const char *file)
+do_eet_list(const char * file)
{
int i, num;
- char **list;
- Eet_File *ef;
+ char ** list;
+ Eet_File * ef;
Not to nit-pick and start anymore flames (lord knows we don't need any
more of that) ... BUT is this Really what we want .. wrt 'const char *
file' vs the current 'const char *file ???
dh
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
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/eet/src: bin examples lib tests
On Fri, 30 Jul 2010 22:16:38 -0400 Christopher Michael cpmicha...@comcast.net
said:
On 07/30/2010 09:54 PM, Enlightenment SVN wrote:
Log:
formatting.- uncrustify
Author: raster
Date: 2010-07-30 18:54:48 -0700 (Fri, 30 Jul 2010)
New Revision: 50698
Modified:
trunk/eet/src/bin/eet_main.c
trunk/eet/src/examples/eet-data-file_descriptor.c
trunk/eet/src/examples/eet-data-nested.c
trunk/eet/src/examples/eet-data-simple.c trunk/eet/src/lib/Eet.h
trunk/eet/src/lib/Eet_private.h trunk/eet/src/lib/eet_cipher.c
trunk/eet/src/lib/eet_connection.c trunk/eet/src/lib/eet_data.c
trunk/eet/src/lib/eet_dictionary.c trunk/eet/src/lib/eet_image.c
trunk/eet/src/lib/eet_lib.c trunk/eet/src/lib/eet_node.c
trunk/eet/src/lib/eet_utils.c trunk/eet/src/tests/eet_data_suite.c
trunk/eet/src/tests/eet_suite.c trunk/eet/src/tests/eet_suite.h
static void
-do_eet_list(const char *file)
+do_eet_list(const char * file)
{
int i, num;
- char **list;
- Eet_File *ef;
+ char ** list;
+ Eet_File * ef;
Not to nit-pick and start anymore flames (lord knows we don't need any
more of that) ... BUT is this Really what we want .. wrt 'const char *
file' vs the current 'const char *file ???
if you can get uncrustify to obey... then good luck :)
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: nash trunk/eina/src/lib
Test it please ;)
On Saturday, July 31, 2010, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
eina: Actually implement strnlen for eina_unicode.
Author: nash
Date: 2010-07-30 20:54:09 -0700 (Fri, 30 Jul 2010)
New Revision: 50700
Modified:
trunk/eina/src/lib/eina_unicode.c
Modified: trunk/eina/src/lib/eina_unicode.c
===
--- trunk/eina/src/lib/eina_unicode.c 2010-07-31 03:21:55 UTC (rev 50699)
+++ trunk/eina/src/lib/eina_unicode.c 2010-07-31 03:54:09 UTC (rev 50700)
@@ -95,7 +95,8 @@
eina_unicode_strnlen(const Eina_Unicode *ustr, int n)
{
const Eina_Unicode *end;
- for (end = ustr; *end; end++)
+ const Eina_Unicode *last = ustr + n; /* technically not portable ;-) */
+ for (end = ustr; *end last end; end++)
;
return end - ustr;
}
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
