Re: [E-devel] [e-users] Problem with images from trac ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 22 May 2009 02:25:41 +0200 Steven Le Roux ste...@le-roux.info wrote: Hi all, Has someone played with the images directory of the trac ? : http://trac.enlightenment.org/e/wiki/Elementary I don't see any change in history so I guess it's generalized to all the trac... *Error: Macro Image(elementary.png, align=left) failed* Attachment 'wiki:Elementary: elementary.png' does not exist. -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB ste...@le-roux.info 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB Confirmed, i filled up a ticket about this problem (#321) two days ago. Massimiliano - -- Massimiliano Calamelli http://www.mcalamelli.net mcalame...@gmail.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFKFlX8leGEL56NNP4RAuzIAJ9qEXusf4h68an9o8P11ND/1NC1ZACfUrO4 /XzGWqPk/SmDai578vQfTl0= =M6ZA -END PGP SIGNATURE- -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] no wiki docs for edje_editor?
Hi, all: I got that there are some help infos for edje editor on http://wiki.enlightenment.org/index.php/Edje_Editor from edje_editor source code package. But I found there is nothing. I am new to it ,and I want to learn it very much. Any one knows where we beginners can find some docs? Thank you. -- Best Regards -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] no wiki docs for edje_editor?
2009/5/22 Jianchun Zhou jianchun.z...@gmail.com Hi, all: I got that there are some help infos for edje editor on http://wiki.enlightenment.org/index.php/Edje_Editor from edje_editor source code package. But I found there is nothing. I am new to it ,and I want to learn it very much. Any one knows where we beginners can find some docs? Hi, there are no docs specific for edje editor...but all the edje and edc documentation apply gracefully also for the editor. Thank you. -- Best Regards -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EThumb private plugin headers
2009/5/21 Jose Gonzalez jose_...@juno.com: Gustavo Sverzut Barbieri wrote: 2009/5/20 Jose Gonzalez jose_...@juno.com: Gustavo wrote: 2009/5/20 Viktor Kojouharov vkojouha...@gmail.com: On Wed, 2009-05-20 at 15:15 +0200, Gustavo Sverzut Barbieri wrote: On Tue, May 19, 2009 at 1:35 PM, Rafael Antognolli antogno...@profusion.mobi wrote: On Mon, May 18, 2009 at 7:13 PM, Viktor Kojouharov vkojouha...@gmail.com wrote: On Mon, 2009-05-18 at 18:30 -0300, Rafael Antognolli wrote: On Mon, May 18, 2009 at 7:46 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Mon, May 18, 2009 at 6:31 AM, Ryan Raasch ryan.raa...@gmail.com wrote: Hello, I am trying to write an EThumb_Plugin to load an xml file with an embbeded jpeg file. However, the plugins written for Ethumb need ethumb_private.h. This is not very practical to develop plugins outside of the source tree. Is there any thoughts on this? I will help if needed. yeah, Ethumb struct could be moved to Ethumb_Plugin or even better: the attributes we need could have setters in Ethumb.h or Ethumb_Plugin.h, most are already in Ethumb.h, now just need couple to access canvas and all, then move plugins to use it instead. I've just added some getters to Ethumb API. I think they are enough (at least to my plugins), but let me know if you need any other. maybe this is the right thread to brings this up: could be a good idea to have a some sort of generic getter/setter that sets properties for plugins to look at. Instead of having ethumb_video_time_get|set, and the document page equivalent, it would be better to have ethumb_property_get|set or something of that sort, so that plugins can be able to obtain other properties that could be useful, without adding more setters and getters. This would also make the video_time and document_page functions obsolete. I agree. I only have made these video_time and document_page functions because it was simpler than having a generic property get/set function, and since I was not planning to write newer plugins soon, it wasn't really necessary. But maybe it's time to do it now. I'll take a look at it soon, just finishing the client/server stuff and some changes on ethumb lib itself. I disagree as this would defeat the purpose of plugins implementing a set of features. For example, if you start to make it open, applications would need to know deep into plugins, and that's not good. By forcing a explicit api we can stop and think about stuff, how to unify and be consistent. Otherwise applications will start to use emotion plugin on frames and xine plugin on time and mplayer plugins on tick based, defeating the purpose of the whole thing. So far we did document/paging and video, if you need new kind of feature, just say, let's think about it and design a good system, it might help existing stuff as well. I disagree with this. Its entirely up to the plugin to decide what features it can support. Just because the current API covers two cases, doesn't mean that you're safe. I can think of a few other properties besides frame or document page for plugins, and I'm sure other people might think of others as well. As you can imagine I disagree with that. First, the idea with plugins was to transparently handle media, not to specifically talk to one. Applications talk to thumbnailer and say get me a visual representation of this file, and you specify some properties you'd like. Actually these properties should be guessed, but it's too difficult to guess right so we're giving hints. For example, if it was easy to avoid black screens and producer's logo/introduction from videos without wasting too much cpu time, we'd not even specify video properties. Same for documents, if we can find a good heuristics to avoid cover/empty/index pages, we could avoid these properties at all. Remember we're doing a thumbnailer, not a general purpose image resizing framework, the main goal is to make it easy to generate visual representation of files, not to replace gimp/imagemagick. And as I said, these properties are hints, of course plugins might not implement it. But when plugins implement, they have a rule of what to implement. Example, we know video have couple of properties with well known meaning. Generally we should not even specify such properties, but if we do (to overcome technical problems), we might present user with an interface to set such programs, even visually as Playstation3 do for video, you know the parameters you need to set. If we start to let it too loose we'll have to force apps to query installer plugins, then their properties and then try to map these to ui. Xine and others tried to do such a generic property-ui mapper and it sucks hard. There should be no reason to limit what plugins support by hard-coding what properties any potential plugins should have. I really believe it's not a
[E-devel] Evas WinCE crash (font_last_up_to_pos = 0)
Hi,
I have crashes with labels and text under wince. GDB shows:
#1 0x008d2994 in _layout_text_cutoff_get (c=0x2013f820, fmt=0x1a9ea0,
it=0x1a9f50) at evas_object_textblock.c:1544
with
1544 return c-ENFN-font_last_up_to_pos(c-ENDT,
fmt-font.font, it-text,
(gdb) print *c
$1 = {obj = 0x1a7340, o = 0x199e00, lines = 0x1a9f10, ln = 0x1a9f10,
format_stack = 0x17b7f0, x = 0, y = 0, w = 0, h = 0, wmax = 0, hmax = 0,
maxascent = 9,
maxdescent = 2, marginl = 0, marginr = 0, line_no = 0,
underline_extend = 0, have_underline = 0, have_underline2 = 0, align = 0}
(gdb) print c-obj-layer-evas-engine.func
$2 = (Evas_Func *) 0x507000
(gdb) print *(c-obj-layer-evas-engine.func)
where
font_last_up_to_pos = 0.
font_last_up_to_pos is the only function in engine which is 0 !?!
Any Ideas?
Thanks
Klaus
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing,
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, Big Spaceship. http://www.creativitycat.com
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] NOTICE: svn feature freeze this weekend (May 22-24)
Sorry I could not mail earlier, but we're now on feature freeze! On Mon, May 18, 2009 at 12:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Hello all, As discussed in previous threads we will try to stabilize the SVN so packagers can do their work on a more solid base. So let's try to make the SVN more stable during this week and let's stop doing new feature during this weekend, doing bug fixes and testing instead. DEVELOPERS: If you have a massive change that would change all the repository and is still untested, please wait until next Monday or do it as a compile/runtime time option and leave it disabled until Monday. If possible, take a look at Active Tickets (http://trac.enlightenment.org/e/report/1) and validate (close if now invalid!) or try to fix a couple of them. Running valgrind, gdb and memprof are good things to do this week ;-) Thursday night I'll commit a FEATURE-LOCKED to svn trunk and we expect that after that commit we just do fixes. Sunday night I'll remove that file and that commit will be tagged in SVN. Packagers will build on that tag. USERS: Please update your SVN checkouts and try to update daily and report issues to mail list and also as tickets. We want to know what is broken so we can fix it, bear in mind that developers do not use all existent options and combination of them, so corner cases may show here and there. REPORT! If you want to help with development but have no coding skills, please go toActive Tickets and try to reproduce problems, if not possible ask the reporter to check it again and if not reproducible anymore to close the ticket. Willing to help testing? You can do: - compare expedite benchmarks on the same system, tell us if you see regressions. - check memory usage. - check if dialogs work properly. - create a dummy user and start with a clean profile, try to configure the system the way you want, see if it's possible (good way to test if dialogs work properly). References: - http://trac.enlightenment.org/e/wiki/ReleaseSchedule other freeze dates - http://trac.enlightenment.org/e/wiki/Release tasks to do before alpha release - http://trac.enlightenment.org/e/wiki/TestingPlan how to test (needs contributions!) Regards! -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] Re: Evas WinCE crash (font_last_up_to_pos = 0)
answering myself:
r40728 fixed it. Textblocks work fine under WinCE now. Thanks!
Hi,
I have crashes with labels and text under wince. GDB shows:
#1 0x008d2994 in _layout_text_cutoff_get (c=0x2013f820, fmt=0x1a9ea0,
it=0x1a9f50) at evas_object_textblock.c:1544
with
1544 return c-ENFN-font_last_up_to_pos(c-ENDT,
fmt-font.font, it-text,
(gdb) print *c
$1 = {obj = 0x1a7340, o = 0x199e00, lines = 0x1a9f10, ln = 0x1a9f10,
format_stack = 0x17b7f0, x = 0, y = 0, w = 0, h = 0, wmax = 0, hmax = 0,
maxascent = 9,
maxdescent = 2, marginl = 0, marginr = 0, line_no = 0,
underline_extend = 0, have_underline = 0, have_underline2 = 0, align = 0}
(gdb) print c-obj-layer-evas-engine.func
$2 = (Evas_Func *) 0x507000
(gdb) print *(c-obj-layer-evas-engine.func)
where
font_last_up_to_pos = 0.
font_last_up_to_pos is the only function in engine which is 0 !?!
Any Ideas?
Thanks
Klaus
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing,
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, Big Spaceship. http://www.creativitycat.com
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing,
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, Big Spaceship. http://www.creativitycat.com
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [news module] adding or configurating a news feed crashes Enlightenment
Dear enlightenment developers, When I click the button add in the News feed configuration dialog, I get the segmentation fault warning from e17. It is the right add button that relates to adding a new feed to the news module. Also configuring an existing feed gives me a segmentation fault. I found a solution. The problem occurs when the calls to _cb_category_list and _cb_lang_change are made from the functions news_config_dialog_feed_refresh_categories and news_config_dialog_feed_refresh_langs respectively. Within the callback functions the position return by e_widget_ilist_selected_get is then -1. This is weird as for the same ilist the position has been set to pos_to_select or 0 when pos_to_select == -1 with e_widget_ilist_selected_set, before the callback function is called. Nevertheless the call to the two function is not needed when the code doesn't preselect a category or language for a new feed. The attached patch fixes the segmentation problem and the warning that you have to select a category every time you change something in a feed. The ticket ( http://trac.enlightenment.org/e/ticket/317 ) in the tracker has a patch that contains the solution. Kind regards, Mark-Willem Rawnar Jansen _ Nieuws, entertainment en de laatste roddels. Je vind het op MSN.nl! http://nl.msn.com/ -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] Improvements to efm2 hal handling API
Hello, All.
It is approach to integrate places functionality (and more) to efm2.
Improvements to efm2 hal messages processing API.
1. Added E_FM_OP_MOUNT_ERROR and E_FM_OP_UNMOUNT_ERROR slave signals.
These signals occurs when mount or umount call to hal via d-bus
completing with error.
2. Added mount and unmount error dialogs to efm2.
3. Completed mount_fail, umount_ok and umount_fail callbacks in e_fm_hal.
mount_fail is called when error from d-bus received or mount timeout reached.
umount_ok is called when volume successfully unmounted or removed.
unmount_fail is called when error from d-bus received.
4. On hal errors corresponding efm2 windows closing or fallback to favorites
(when open dirs in place activated).
5. On volume removing (for example, unmount from command line) corresponding
efm2 windows closing.
6. Fixed linking to already mounted volumes when new efm2 windows opened or
directory changed (when open dirs in place activated).
7. Only volumes mounted with efm2 will be unmounting when last efm2 window
of it volume is closed.
Now, all e_fm2_hal routines estimating that not only efm2 and e17 can perform
operations with storages and volumes. Next, we need GUI to operate with volumes
by hands as it in others DE.
Sincerely yours, Sergey.
--
Jabber/XMPP: sergey.semer...@gmail.com
Cellular: +7-909-206-5992
Index: e/src/bin/e_fm.c
===
--- e/src/bin/e_fm.c (revision 40767)
+++ e/src/bin/e_fm.c (working copy)
@@ -359,6 +359,8 @@
static void _e_fm_error_ignore_this_cb(void *data, E_Dialog *dialog);
static void _e_fm_error_ignore_all_cb(void *data, E_Dialog *dialog);
+static void _e_fm_hal_error_dialog(const char *title, const char *msg, const char *pstr);
+
static void _e_fm2_file_delete(Evas_Object *obj);
static void _e_fm2_file_delete_menu(void *data, E_Menu *m, E_Menu_Item *mi);
static void _e_fm2_file_delete_delete_cb(void *obj);
@@ -809,15 +811,31 @@
sd = evas_object_smart_data_get(data);
if (!sd) return; // safety
- /* FIXME; some dialog */
if (sd-mount)
{
- e_fm2_hal_unmount(sd-mount);
+// At this moment E_Fm2_Mount object already deleted in e_fm_hal.c
sd-mount = NULL;
- evas_object_smart_callback_call(data, dir_deleted, NULL);
+if (sd-config-view.open_dirs_in_place)
+ e_fm2_path_set(data, favorites, /);
+else
+ evas_object_smart_callback_call(data, dir_deleted, NULL);
}
}
+static void
+_e_fm2_cb_unmount_ok(void *data)
+{
+ E_Fm2_Smart_Data *sd;
+
+ sd = evas_object_smart_data_get(data);
+ if (!sd) return;
+ if (sd-mount)
+ {
+sd-mount = NULL;
+evas_object_smart_callback_call(data, dir_deleted, NULL);
+ }
+}
+
void
_e_fm2_path_parent_set(Evas_Object *obj, const char *path)
{
@@ -945,7 +963,7 @@
if (v)
sd-mount = e_fm2_hal_mount(v,
_e_fm2_cb_mount_ok, _e_fm2_cb_mount_fail,
- NULL, NULL, obj);
+ _e_fm2_cb_unmount_ok, NULL, obj);
}
else if (sd-config-view.open_dirs_in_place == 0)
{
@@ -954,7 +972,7 @@
if (m)
sd-mount = e_fm2_hal_mount(m-volume,
_e_fm2_cb_mount_ok, _e_fm2_cb_mount_fail,
- NULL, NULL, obj);
+ _e_fm2_cb_unmount_ok, NULL, obj);
}
if (!sd-mount || sd-mount-mounted)
@@ -2944,15 +2962,42 @@
udi = e-data;
v = e_fm2_hal_volume_find(udi);
- if (v)
- {
- v-mounted = 0;
- if (v-mount_point) free(v-mount_point);
- v-mount_point = NULL;
- }
+ if (v) e_fm2_hal_mount_del(v);
}
break;
+ case E_FM_OP_MOUNT_ERROR:/*mount error*/
+if (e-data (e-size 1))
+ {
+ E_Volume *v;
+ char *udi;
+
+ udi = e-data;
+ v = e_fm2_hal_volume_find(udi);
+ if (v)
+ {
+ _e_fm_hal_error_dialog(_(Mount Error), _(Can't mount device), e-data);
+ e_fm2_hal_mount_fail(v);
+ }
+ }
+break;
+
+ case E_FM_OP_UNMOUNT_ERROR:/*unmount error*/
+if (e-data (e-size 1))
+ {
+ E_Volume *v;
+ char *udi;
+
+ udi = e-data;
+ v = e_fm2_hal_volume_find(udi);
+ if (v)
+ {
+ _e_fm_hal_error_dialog(_(Unmount Error), _(Can't unmount device), e-data);
+ e_fm2_hal_unmount_fail(v);
+ }
+ }
+break;
+
case E_FM_OP_ERROR:/*error*/
printf(%s:%s(%d) Error from slave #%d: %s\n, __FILE__, __FUNCTION__, __LINE__, e-ref, (char *)e-data);
_e_fm_error_dialog(e-ref, e-data);
@@ -9002,6 +9047,37 @@
}
static void
+_e_fm_hal_error_dialog(const char *title, const char *msg, const char *pstr)
+{
+ E_Manager *man;
+ E_Container *con;
+ E_Dialog *dialog;
+ char text[4096];
+ const char *u, *d, *n, *m;
+
+ man = e_manager_current_get();
+ if
Re: [E-devel] EThumb private plugin headers
Gustavo wrote: .. Nonsense. It's just as possible to do vector stuff as raster stuff with evas, api wise. It's just a pain to support all the various engines people have been adding (in particular the 16bpp ones which you pushed for and now have no interest in supporting), and also to work with its primitive internal engine func api which was designed a long time ago for a quick and limited set of abilities. This latter wouldn't be such a big deal to change if again there were fewer engines. Where do you want to go with this? I keep reading you complaining about 16bpp engine, actually you're the only one that seems to not get it right. Even raster got to understand with its purpose and accepts it, but you keep pushing against it. The purpose of this engine was never to be complete (no gradients), or super-correct (no smooth scale, no render ops, ...), but to be fast and cover the basics that embedded world uses, you could consider it a subset. And there are people using it, just not myself. Cedric uses it with SDL, Vincent and Lars use it with WinCE. It's not a 'subset', it's crap. And completely unnecessary. The return on their investment is a net negative, increasingly heavier and heavier over time. Time and effort spent on those 'engines' would've been *far* better spent in optimizing transform/sampling/compositing and 32-16 conversion, for the 'important' architectures. As to what Carsten feels now and/or earlier regarding these 'engines', only he can really say. Mind you there are too many engines period, it's just that these engines have one particular aspect to them: they introduce the 16bpp color space into input/src data, and doing so is what amounts to a destructive result. PS. Gradients are actually one of the few things that you *could* add fairly easily to these engines, and have them look decent. It's just about everything else that's a problem. There's no loss and large gains in having evas support vgfx directly, as well as further filter and other gfx notions. It's not a problem at all. There is a bit of other stuff at the canvas level that needs redoing if one wants to support complex gfx operations on arbitrary objects, and some of the problems there are due to the way smart-objects were implemented at the canvas level. But again, there's nothing that can't be done, and done quite efficiently - far more so than most current gfx libs do. Save on Cell Phones. Click Now! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTKdW2FZI7qLYUPD6yeCfNG6sFTd78OBF257Jd8iAktxS9932VJls8/ -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some tickets for review...
On Thu, 21 May 2009 08:58:01 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: fixed in svn now. i found it too (while offline) On Thu, 21 May 2009, Marco Trevisan (Treviño) wrote: Vincent Torri wrote: On Wed, 20 May 2009, Marco Trevisan (Treviño) wrote: Marco Trevisan (Treviño) wrote: #319 - Elementary-sms seg.fatults Another issue linked to this as been introduced recently in edje (I guess) since if I use an entry with the parameter elm_entry_editable_set(en, FALSE); I get a segfault with: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1218676160 (LWP 15139)] 0xb7b35c8f in _edje_entry_focus_in_cb () You can experience the same by opening the Anchorview/Anchorblock test in elementary_test I've just tried elementary_test with all the EFL updated and Anchorview or Anchorblock are not seg faulting strange... Anchorblock seg-faulted to me, but now after I've recompiled elementary again (I thought I had done it also before) doesn't anymore. However an elm-app I'm writing, has still the issue if I set to false the READ-only entry. can you write the most simple test case that seg fault for you, please ? Vincent -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EThumb private plugin headers
On Sat, May 23, 2009 at 12:12 AM, Jose Gonzalez jose_...@juno.com wrote: Gustavo wrote: .. Nonsense. It's just as possible to do vector stuff as raster stuff with evas, api wise. It's just a pain to support all the various engines people have been adding (in particular the 16bpp ones which you pushed for and now have no interest in supporting), and also to work with its primitive internal engine func api which was designed a long time ago for a quick and limited set of abilities. This latter wouldn't be such a big deal to change if again there were fewer engines. Where do you want to go with this? I keep reading you complaining about 16bpp engine, actually you're the only one that seems to not get it right. Even raster got to understand with its purpose and accepts it, but you keep pushing against it. The purpose of this engine was never to be complete (no gradients), or super-correct (no smooth scale, no render ops, ...), but to be fast and cover the basics that embedded world uses, you could consider it a subset. And there are people using it, just not myself. Cedric uses it with SDL, Vincent and Lars use it with WinCE. It's not a 'subset', it's crap. And completely unnecessary. Ok, you are right and the world is wrong. Canola is totally unusable in maemo without 16bpp engine. You can get noticeable speedups in openmoko as well. I'm pretty sure Cedric and WinCE guys can step in and say their experiences as well. And regarding crap, it's such a hard word to describe work that INdT paid me to do for more than 3 months. It's very optimized and measured, I'm pretty sure it's not crap. The return on their investment is a net negative, increasingly heavier and heavier over time. Ok, so negative that it enable one of the strongest advocate of EFL. Without Canola's marketing of EFL we would not have things like BlueMaemo (maemo/bluetooth remote control), the openmoko version of bluemaemo, Carman. Without Canola we'd have no Python-EFL that is did bring lots of developers to our platform, and probably would not have myself or the dozen guys that I pay to work on EFL. That said, better not write such stupid thing than write it just in case. You're doing no help in the last 2 years or so, then you come to the project to start creating such stupid flamewars. Time and effort spent on those 'engines' would've been *far* better spent in optimizing transform/sampling/compositing and 32-16 conversion, for the 'important' architectures. I don't know if you forgot on purpose or not, but I keep saying that's not JUST ABOUT THE FSCKING TRANSFORM, IT'S ABOUT THE AMOUNT OF DATA. 24bpp will consume 4 bytes per pixel (due alignment), 16bpp will consume 2 bytes, that's half of the data that you have to load, that's half data to saturate your memory bus, cache. And it's less data to operate on, you can do all R, G and B multiply by A in the same instruction (given some quality constraints that were good enough for users and even graphical designers accepted it). Sure it will use more shifts and masks, but that's almost for free in most ARM platforms. But go ahead, show me the code as we usually say. Prove me wrong, don't flame me wrong. As to what Carsten feels now and/or earlier regarding these 'engines', only he can really say. Mind you there are too many engines period, it's just that these engines have one particular aspect to them: they introduce the 16bpp color space into input/src data, and doing so is what amounts to a destructive result. You can easily ignore that, you did so for gradient2. There is no YUV-RGB (video/emotion), there is no gradient, there is no smooth scale. You're not forced to implement such. I doubt you have not finished a fast gradient2 on software/32 or gl because of software/16. PS. Gradients are actually one of the few things that you *could* add fairly easily to these engines, and have them look decent. It's just about everything else that's a problem. Why care about things that nobody cares? I worked with over dozen designers and none could think of use of single gradients. They usually want layers or semi transparent and radial and all you can imagine, you'll not be able to render that during runtime, specially on such devices. And even if you're able to, you don't need to. And given the absurdly slow code in gradient for software32 that relies on sin/cos/whatever is not present in systems without FPU, we're talking about a dead end. If you ask me, I'd actually add an option to disable gradient build altogether to save space on embedded devices that will not use it. I guess this thread is pretty over, things went really out of control. People were arguing about ethumb and we ended fighting about stupid stuff. I still hope that Viktor did not give up on trying to come with Ethumb/plugins requirements, I'd really like to know what is missing so we can think, design and implement a good platform. -- Gustavo Sverzut
Re: [E-devel] Some tickets for review...
Carsten Haitzler (The Rasterman) wrote: On Thu, 21 May 2009 08:58:01 +0200 (CEST) Vincent Torri vto...@univ-evry.fr said: fixed in svn now. i found it too (while offline) Thanks. What about the tickets? :P -- Treviño's World - Life and Linux http://www.3v1n0.net/ -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EThumb private plugin headers
You seem to be taking this as a judgment on the quality of your work on your soft16 engines whereas if you stopped you'd realize that I'm addressing all rendering engines that use 16bpp data in their gfx pipeline. In this day and age, this is a disaster for anything that wants to grow towards building richer user interfaces. Whatever these devices, they would ultimately be much better served with their software stacks/dev-frameworks investing in enabling 'richer' guis and optimizing things for their systems that can allow for such 'rich' graphical experiences. The benefits of something like the moderate speed gains from a 16bpp gfx pipeline is only seen when one imposes large restrictions on what can be done. If this also becomes a limiting or constraining factor in what your gui libs are allowed to support, then you have a serious problem brewing. According to you: Evas is one example of such balance that I believe is good: it does not allow you to do everything, but the things that it allows you to do it does fast and it's very easy. If one want to do vector or direct pixel manipulation it's not the way to go.. If we buy into this logic, then evas is just perfectly balanced as is and doesn't need anything else.. Why then would I or anyone spend time developing anything further gfx wise? As for the rest of your tirade on gradients or me or whatnot.. I'll leave that up to you to have the final word. :) .. Nonsense. It's just as possible to do vector stuff as raster stuff with evas, api wise. It's just a pain to support all the various engines people have been adding (in particular the 16bpp ones which you pushed for and now have no interest in supporting), and also to work with its primitive internal engine func api which was designed a long time ago for a quick and limited set of abilities. This latter wouldn't be such a big deal to change if again there were fewer engines. Where do you want to go with this? I keep reading you complaining about 16bpp engine, actually you're the only one that seems to not get it right. Even raster got to understand with its purpose and accepts it, but you keep pushing against it. The purpose of this engine was never to be complete (no gradients), or super-correct (no smooth scale, no render ops, ...), but to be fast and cover the basics that embedded world uses, you could consider it a subset. And there are people using it, just not myself. Cedric uses it with SDL, Vincent and Lars use it with WinCE. It's not a 'subset', it's crap. And completely unnecessary. Ok, you are right and the world is wrong. Canola is totally unusable in maemo without 16bpp engine. You can get noticeable speedups in openmoko as well. I'm pretty sure Cedric and WinCE guys can step in and say their experiences as well. And regarding crap, it's such a hard word to describe work that INdT paid me to do for more than 3 months. It's very optimized and measured, I'm pretty sure it's not crap. The return on their investment is a net negative, increasingly heavier and heavier over time. Ok, so negative that it enable one of the strongest advocate of EFL. Without Canola's marketing of EFL we would not have things like BlueMaemo (maemo/bluetooth remote control), the openmoko version of bluemaemo, Carman. Without Canola we'd have no Python-EFL that is did bring lots of developers to our platform, and probably would not have myself or the dozen guys that I pay to work on EFL. That said, better not write such stupid thing than write it just in case. You're doing no help in the last 2 years or so, then you come to the project to start creating such stupid flamewars. Time and effort spent on those 'engines' would've been *far* better spent in optimizing transform/sampling/compositing and 32-16 conversion, for the 'important' architectures. I don't know if you forgot on purpose or not, but I keep saying that's not JUST ABOUT THE FSCKING TRANSFORM, IT'S ABOUT THE AMOUNT OF DATA. 24bpp will consume 4 bytes per pixel (due alignment), 16bpp will consume 2 bytes, that's half of the data that you have to load, that's half data to saturate your memory bus, cache. And it's less data to operate on, you can do all R, G and B multiply by A in the same instruction (given some quality constraints that were good enough for users and even graphical designers accepted it). Sure it will use more shifts and masks, but that's almost for free in most ARM platforms. But go ahead, show me the code as we usually say. Prove me wrong, don't flame me wrong. As to what Carsten feels now and/or earlier regarding these 'engines', only he can really say. Mind you there are too many engines period, it's just that these engines have one particular aspect to them: they introduce the 16bpp color space into input/src data, and doing so is what amounts to a destructive
Re: [E-devel] compilation problem with evas and ecore
On Thu, 21 May 2009, dAgeCKo wrote: Hi When wanting to compile evas or ecore, this ends to this error: libtool: link: cannot find the livrary `' or unhandled argument `/usr/X11R6/lib' make[5]: *** [libecore_x.la] Erreur 1 This is for ecore since I was able to avoid the problem in evas with using other configure options. All my libtool, autoconf and automake are uptodate (debian lenny). I tried to modify configure.ac since the error seems to be there but unsuccesfully. Notes: this happens on the last snapshot as for the svn sources. run: make maintainer-clean then launch autogen.sh again. If the problem is still there, paste the output of configure Vincent -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
