Re: [E-devel] [Announce] Gadman module
Carsten wrote: Yeah, and it sounds like a fine 'security minded' approach.. but in practice it's not going to make much of a difference since edje is used along with all sorts of code that's highly insecure. see above. it is important. it's a mistake microsoft have made all over the place for years and have spent years cleaning up. vb script in word documents able to take your files and modify them or destroy them or send them to others etc. What! That MS made it easy to have malware, adware, viruses, and other necessary aspects of the modern computing experience... well, that's just an eeexageration. :) Actually, the whole thing is screwed from the ground up man, there's little that can be done to have interaction with 'the world' in a rich, free, real-time sense and also be 'secure', not with the way the common, legacy systems are designed right now. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Announce] Gadman module
On Wed, 07 May 2008 02:38:19 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled: Carsten wrote: Yeah, and it sounds like a fine 'security minded' approach.. but in practice it's not going to make much of a difference since edje is used along with all sorts of code that's highly insecure. see above. it is important. it's a mistake microsoft have made all over the place for years and have spent years cleaning up. vb script in word documents able to take your files and modify them or destroy them or send them to others etc. What! That MS made it easy to have malware, adware, viruses, and other necessary aspects of the modern computing experience... well, that's just an eeexageration. :) Actually, the whole thing is screwed from the ground up man, there's little that can be done to have interaction with 'the world' in a rich, free, real-time sense and also be 'secure', not with the way the common, legacy systems are designed right now. sure. with great power comes great responsibility. that's where i draw the line. themes are something u can safely use and try out - or should be. install software at your peril. its a matter of managing expectations. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Network Manager
I'll try it with Hardy then: nm-applet doesn't work in Ubuntu started with Entrance both with xfce 4 panel and fbpanel, not even gnome panel of course. Of course, I'm talking of an E17 session. Thanks for the suggestion :) Luca 2008/5/7 Gustavo Sverzut Barbieri [EMAIL PROTECTED]: On Tue, May 6, 2008 at 8:08 PM, The DarkMaster [EMAIL PROTECTED] wrote: Sure, I believe this would serve really a lot to the E17 Desktop Shell. We really need a network manager for Enlightenement, specially one compatible with nm. Also, maybe the creation of this module would be a nice occasion to have a look in the Entrance nm-not working bug. In case some of you do not know, if you start the system with entrance, nm doesn't work at all. I don't know why honestly but that's the reason why OpenGEU uses GDm instead than Entrance... I know many of you aren't interested in Entrance anymore but I believe it is a great DM and it should be supported. I don't like exalt much too... also because it is incompatible with nm... well, in any case I wish you all the best in developing this tool, man! bye, I use fedora 8 + entrance (cvs) and nm + stalonetray + nm-applet, these set work fine. -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/efreet dj2
Enlightenment CVS committal
Author : dj2
Project : e17
Module : libs/efreet
Dir : e17/libs/efreet/src/lib
Modified Files:
efreet_ini.c
Log Message:
- if we can't parse the INI file we can't set ini-data so return NULL
instead of an invalid ini file
Are you sure this has no consequences? I'm pretty sure I did it that way
for a reason (maybe parse empty or non-existing file?)
Sebastian
===
RCS file: /cvs/e/e17/libs/efreet/src/lib/efreet_ini.c,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -3 -r1.11 -r1.12
--- efreet_ini.c 7 May 2008 02:16:50 - 1.11
+++ efreet_ini.c 7 May 2008 03:04:58 - 1.12
@@ -55,6 +55,7 @@
if (!ini) return NULL;
ini-data = efreet_ini_parse(file);
+if (!ini-data) FREE(ini);
return ini;
}
@@ -79,8 +80,7 @@
f = fopen(file, rb);
if (!f) return NULL;
-if (fstat(fileno(f), file_stat)
-|| file_stat.st_size 1)
+if (fstat(fileno(f), file_stat) || file_stat.st_size 1)
{
fclose(f);
return NULL;
@@ -274,7 +274,7 @@
EAPI int
efreet_ini_section_set(Efreet_Ini *ini, const char *section)
{
-if (!ini || !ini-data || !section) return 0;
+if (!ini || !(ini-data) || !section) return 0;
ini-section = ecore_hash_get(ini-data, section);
return (ini-section ? 1 : 0);
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-cvs mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] location of unit tests
On Wed, May 7, 2008 at 6:29 AM, Vincent Torri [EMAIL PROTECTED] wrote: raster, dan and me had a small discussion about the location of unit tests. Dan and me were for putting them in efl_lib/tests and raster in e17/tests/efl_lib raster arguments are for putting them outside efl_lib/ are 1) lots of data in src/. Indeed, maybe big files can be needed. That can increase the size of the tarball. 2) end users and packagers do not need them 3) if unit tests are in the tarball, packager can maybe think that they must ship them. raster: if you think that i have forgotten something, please add any argument I just want to raise some point regarding putting unit test inside the released tarball. It should ease the work of a release manager, just run make dist-check and if all the tests passed, you are ready for a release. Another situation where it can help, is when someone compile the library from source and has some problem, so we could just ask him to run make check and send us the report. This should help developper that use our lib by providing an easier learning path. In any case, having unit test and coverage report will be really helpfull, so as soon as everyone agreed on Vincent proposal, I am for adding the necessary stuff to eet at least (but all efl libs should have their own unit test, I think). -- Cedric BAIL - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Announce] Gadman module
Then one needs to extend edje/embryo scripting far more than it's currently capable of.. and for it to be sufficiently capable for general kinds of 'apps' it may need to have access to system calls and other things. One'd also need to have well-known entry points into the .edj file - either a special main group or a special script function to execute on load or some such, and have all being executed in some kind of 'runtime'. i have plans to do this with edje. it'd actually be very simple. the plans go like this: 1. allow edje objects to be ONLY defined by embryo script. right now you can specify a message handling callback for an object and then script sections when events (programs) get triggered. there is always one on load so it's easy to run code when the object is loaded for setup etc. etc. but i want to go further and add a resize() callback and a part_text_set() callback and then the code logic here handles all of that. 2. combined with #1 above add more hooks for the script to be able to CREATE and DESTROY and MANIPULATE evas objects directly. edje would track these make sure they are cleaned up on object destruction and maybe enforce limits (like no more than 1000 objects or some user settable limits). 3. add the ability to load other edje objects from the same file, so you can mix and match the older layout and declarative way of doing objects and the script/code way. 4. add a few more calls like adding/deleting pollers It's interesting that Flash seems to have originally centered around AS, but Flex is more about a balanced combo of AS plus a declarative xml syntax and css (plus their designer/builder apps of course), and this is what most others do as well (except possibly JavaFX). Anyway... yeah, extending embryo scripting to allow for more dynamic handling of edje/evas objects would be very useful, but I think you're going to want the ability to 'load' objects from other edj files as well.. or at least have edje itself load such other files and let embryo functions get whatever groups/parts it needs from that file. One could argue that edje should *optionally* allow for other scripting languages (ie. optionally compiled, loadable mods), after all one could extend edje to support python or javascript in an extended edc with such added scripts.. but that would mean duplicating a lot of edje code, so why not add it as optional modules, etc. But one could instead argue that one keep whatever script/code logic separate from the initial ui/gfx description, and have the code load that external edj/eet/whatever file and work with that. But for this to work best it'd mean that the script/code would really need to go *beyond* what the edje api provides.. into the realm of what the edje-edit api has, so that one can dynamically create/modify/ destroy edje/evas objects (as you mentioned). In the end, I'd probably agree with this latter approach, especially for more complex stuff.. ie. separate code logic which uses other resource file(s) for its initial gfx-ui description (and it's basically what I'd meant with themable-evas-objects for C code, though it could be done with scripting too). this should allow you to pretty much do anything that flash does with actionscript, BUT only locally within a limited sandbox. i do NOT intend to add network access or any filesystem access or anything else - this is dangerous. you download and use a theme (blindly) and suddenly it's reading your emails and sending them of to someone else. themes are NOT programs. they are not meant to be. you should not have to even think of security with them. at worst they should just be annoying and useless. Note that things like Flash/mxml (then to swf) or Silverlight/ xaml (may also have some binary representation), unlike edje/edc, have extensive 'script' language support and allow for separating the code logic from the 'gui' part in separate files if desired (though I suppose one could do this with edje/edc/embryo). edje is not far of there. see above. it needs just a few calls and exporting some evas and edje controls and bingo. you can do just the same. embryo is a E... modulo some gfx bits that are still not in evas, and a fairly flexible animation framework, and video/multimedia stuff... and a browser plugin... :) Alternatively, there's no need that edje should be everything to everyone, and it might be better to have other things address further needs, eg. evolve/edc for more involved widgets, maybe other animation mechanisms, etc. it should help abstract the ui from the code. it should not become the code. as above. i have had plans for a long time and will get to them eventually - it's all easy to do. i just have no NEED for it right now, and have other things to do, so i haven't done it. PS. Didn't someone send some edje/embryo
Re: [E-devel] E CVS: libs/efreet dj2
[EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : dj2 Project : e17 Module : libs/efreet Dir : e17/libs/efreet/src/lib Modified Files: efreet_ini.c Log Message: - if we can't parse the INI file we can't set ini-data so return NULL instead of an invalid ini file Are you sure this has no consequences? I'm pretty sure I did it that way for a reason (maybe parse empty or non-existing file?) We'll have to wait to see if anyone complains. The problem is, we can't tell if issue is failed parsing or non-existing file. We may need to put a check in there for non-existant file. But, I don't think we should be pretending everything is good if the file fails to parse. dan - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/efreet dj2
On Wed, May 7, 2008 at 8:27 AM, dan sinclair [EMAIL PROTECTED] wrote: We'll have to wait to see if anyone complains. The problem is, we can't tell if issue is failed parsing or non-existing file. We may need to put a check in there for non-existant file. But, I don't think we should be pretending everything is good if the file fails to parse. dan If this does end up breaking things, it would be a good idea to add a comment in that code block describing the scenario, and adding a test case to catch any future regression. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2008-05-07 07:09:03 -0700
Build log for Enlightenment DR 0.17 on 2008-05-07 07:09:03 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: edje_viewer http://download.enlightenment.org/tests/logs/edje_viewer.log enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, edb, e_dbus, edje_editor, edje, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/efreet dj2
Nathan Ingersoll wrote: On Wed, May 7, 2008 at 8:27 AM, dan sinclair [EMAIL PROTECTED] wrote: We'll have to wait to see if anyone complains. The problem is, we can't tell if issue is failed parsing or non-existing file. We may need to put a check in there for non-existant file. But, I don't think we should be pretending everything is good if the file fails to parse. dan If this does end up breaking things, it would be a good idea to add a comment in that code block describing the scenario, and adding a test case to catch any future regression. In efreet_desktop_read, the result from efreet_ini_new isn't checked, so it will break. And in efreet_desktop_save efreet_ini_new is used to create a new ini struct regardless whether a file exists. Sebastian - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Network Manager
Hello. On Tue, 2008-05-06 at 11:59, Christopher Michael wrote: I've talked w/ raster last night stefan_schmidt today about redoing the network module for E. Ideally, we would like todo a network frontend that is capable of utilizing various backends (e_nm, conman, etc, etc). ACK. Also exalt people wpuld be welcome. They already have some experience with network management in E. Stefan expressed interest in this and is willing to work on the e_nm backend a bit more, which is great. The reason why this has slkipped is that I left OpenMoko and thus doing this no longer as my work job. After the leaving I needed some time for relaxing. I'll continue my work on e_nm on private base as I like to have in in E for other use cases anyway. :) Will take lo nger as fun project, but will make progress. I think I can start to clean up the current mess I have right now at the end of may and start working on it on mid june again. The front end should be able to be configured to handle various network cards backends, ideally allowing the user to switch between any device and/or backend easily. Multiple devices is nice. Not a must for the start IMHO, but nice for later use cases. Switching betwenn different backends needs some thinking. Do you like to be able to do this on-the-fly and expect everything to work? Or some kind of configuration for the backend that will go live after at the next start of the manager? I think what we need at this stage (planning), along with other things, is different UI ideas. What would people like to see in terms of frontend ? Sounds good. Some first ideas: o Gadget for the shelf to show signal strength for wifi, gsm/3g and indicates what kind of connection is used atm. o Click on the gadget shows available wifi networks, and other network connections like ethernet (Only with connected cable?) and wireless broadband modems. o Some kind of advanced settings UI. Handling stored connections, set IP address, stuff for complicated wifi setup, etc.. Not sure how connected this should be to the gadget. Just a *very* short list of stuff. I like a lot of the nm-applet stuff, but there are things that can be improved. I'll send a longer list with ideas for the UI in some days. To tired today. Is there a general consensus as to which backends should be supported ? I can work on e_nm. Not yet looked on connman. Still on my todo, but never came to it. Anyone else did this already? Then we have exalt. Are the devs interested in such an idea? Can anyone provide an objective pros/cons on the various backends ? I can do this for e_nm in my later mail. regards Stefan Schmidt signature.asc Description: Digital signature - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Network Manager
Hello. On Tue, 2008-05-06 at 17:36, Ross Vandegrift wrote: On Tue, May 06, 2008 at 09:27:07PM +0200, The DarkMaster wrote: Hallo, I'm very interested in this topic and an E17 network manager is really needed by my OpenGEU distro too. Well, I believe taht a good choice would be that of using Network Manager from Gnome: http://www.gnome.org/projects/NetworkManager/ Since I started working on e_nm, Stefan has contributed a number of patches to the infrastructure for it. A proof-of-concept that doesn't do much of anything with that library is at http://kallisti.us/~ross/enetmgr-0.1.tar.gz Cool. Motivation push. People really using it. ;) I have some updates to it that don't even build against current libe_nm. I also have to update it to some newer API changes. Besides that I have a lot stuff in some hacky patches that are to ugly for upstream. I need to sit down, sort things out and push them out for review. regards Stefan Schmidt signature.asc Description: Digital signature - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Shared Strings
Yesterday we had a discussion on irc, if we should put abstract data types of ecore and of evas into a single standalone lib. The whole discussion came up because of the two implementations of the shared strings. And in fact if we really want to share strings efficient, we have to share them over the borders of the different libraries. Raster's idea was to first put the shared string stuff in this new library because both implementation have the same api (of course the names are different) and the same functionality. Remains the question which implementation we use. Therefor I've written a small test application, to measure the time it takes to create new strings, access new strings and to delete them. You can find the program here: mowem.de/ecore/compare.c And here a here the plot of the result mowem.de/ecore/result_direct.ps In short words, since evas uses a static bucket count it has a very good performance for few strings, for many ecore has a good access time, but still pays the price for the reordering of the increased or decreased bucket count. Peter - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Network Manager
Stefan Schmidt wrote: Hello. On Tue, 2008-05-06 at 11:59, Christopher Michael wrote: I've talked w/ raster last night stefan_schmidt today about redoing the network module for E. Ideally, we would like todo a network frontend that is capable of utilizing various backends (e_nm, conman, etc, etc). ACK. Also exalt people wpuld be welcome. They already have some experience with network management in E. Certainly :) Stefan expressed interest in this and is willing to work on the e_nm backend a bit more, which is great. The reason why this has slkipped is that I left OpenMoko and thus doing this no longer as my work job. After the leaving I needed some time for relaxing. Hehehehe, no problem :) We all need time to relax now and again. I'll continue my work on e_nm on private base as I like to have in in E for other use cases anyway. :) Will take lo nger as fun project, but will make progress. I think I can start to clean up the current mess I have right now at the end of may and start working on it on mid june again. Sounds good. We're not trying to rush this...wanna take our time here and get things right. The front end should be able to be configured to handle various network cards backends, ideally allowing the user to switch between any device and/or backend easily. Multiple devices is nice. Not a must for the start IMHO, but nice for later use cases. No, not a must have for the start, but certainly something to keep in mind during development. Switching betwenn different backends needs some thinking. Do you like to be able to do this on-the-fly and expect everything to work? Ideally, yes. Or some kind of configuration for the backend that will go live after at the next start of the manager? I suppose that would be acceptable also. I think what we need at this stage (planning), along with other things, is different UI ideas. What would people like to see in terms of frontend ? Sounds good. Some first ideas: o Gadget for the shelf to show signal strength for wifi, gsm/3g and indicates what kind of connection is used atm. Agreed. o Click on the gadget shows available wifi networks, and other network connections like ethernet (Only with connected cable?) and wireless broadband modems. Agreed. o Some kind of advanced settings UI. Handling stored connections, set IP address, stuff for complicated wifi setup, etc.. Not sure how connected this should be to the gadget. Well, should at least be accessible from the menu somehow. Perhaps under a Configuration entry. Just a *very* short list of stuff. I like a lot of the nm-applet stuff, but there are things that can be improved. I'll send a longer list with ideas for the UI in some days. To tired today. No Problem :) dh Is there a general consensus as to which backends should be supported ? I can work on e_nm. Not yet looked on connman. Still on my todo, but never came to it. Anyone else did this already? Then we have exalt. Are the devs interested in such an idea? Can anyone provide an objective pros/cons on the various backends ? I can do this for e_nm in my later mail. regards Stefan Schmidt - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Shared Strings
Were these numbers from ecore before or after cedric's changes this morning? On Wed, May 7, 2008 at 1:20 PM, Peter Wehrfritz [EMAIL PROTECTED] wrote: Yesterday we had a discussion on irc, if we should put abstract data types of ecore and of evas into a single standalone lib. The whole discussion came up because of the two implementations of the shared strings. And in fact if we really want to share strings efficient, we have to share them over the borders of the different libraries. Raster's idea was to first put the shared string stuff in this new library because both implementation have the same api (of course the names are different) and the same functionality. Remains the question which implementation we use. Therefor I've written a small test application, to measure the time it takes to create new strings, access new strings and to delete them. You can find the program here: mowem.de/ecore/compare.c And here a here the plot of the result mowem.de/ecore/result_direct.ps In short words, since evas uses a static bucket count it has a very good performance for few strings, for many ecore has a good access time, but still pays the price for the reordering of the increased or decreased bucket count. Peter - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Menu check and radio buttons
Howdee,
Ive noticed it before, but while working on something new, it seems
kind of silly to have the radio and check buttons from the menu
respond to different signals as the radio and check button widgets.
eg.
Heres the code from the widget:
program {
name:turn_on1;
signal: e,state,checked;
source: e;
action: STATE_SET enable 0.0;
target: hoz;
target: vert;
transition: SINUSOIDAL 0.2;
}
program {
name:turn_off1;
signal: e,state,unchecked;
source: e;
action: STATE_SET active 0.0;
target: hoz;
target: vert;
transition: SINUSOIDAL 0.2;
}
Heres the code from the menu:
program {
name:menu_on;
signal: e,state,on;
source: e;
action: STATE_SET active 0.0;
target: item1;
}
program {
name:menu_off;
signal: e,state,off;
source: e;
action: STATE_SET default 0.0;
target: item1;
}
As you can see, theyre basically the same thing (granted the widget
has a signal_emit in it too) but it should at least be able to do the
same signals and then just whack an alias on them! Im going to lump it
all together regardless, but theres still 2 programs doing essentially
the same thing.
Or am I totally off the mark here?
Toma
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Menu check and radio buttons
On Thu, 8 May 2008 10:19:39 +0800 Toma [EMAIL PROTECTED] babbled:
that is true. this will break all existing themes, but it's probably worth
fixing.
Howdee,
Ive noticed it before, but while working on something new, it seems
kind of silly to have the radio and check buttons from the menu
respond to different signals as the radio and check button widgets.
eg.
Heres the code from the widget:
program {
name:turn_on1;
signal: e,state,checked;
source: e;
action: STATE_SET enable 0.0;
target: hoz;
target: vert;
transition: SINUSOIDAL 0.2;
}
program {
name:turn_off1;
signal: e,state,unchecked;
source: e;
action: STATE_SET active 0.0;
target: hoz;
target: vert;
transition: SINUSOIDAL 0.2;
}
Heres the code from the menu:
program {
name:menu_on;
signal: e,state,on;
source: e;
action: STATE_SET active 0.0;
target: item1;
}
program {
name:menu_off;
signal: e,state,off;
source: e;
action: STATE_SET default 0.0;
target: item1;
}
As you can see, theyre basically the same thing (granted the widget
has a signal_emit in it too) but it should at least be able to do the
same signals and then just whack an alias on them! Im going to lump it
all together regardless, but theres still 2 programs doing essentially
the same thing.
Or am I totally off the mark here?
Toma
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
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)[EMAIL PROTECTED]
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Menu check and radio buttons
2008/5/8 The Rasterman Carsten Haitzler [EMAIL PROTECTED]:
On Thu, 8 May 2008 10:19:39 +0800 Toma [EMAIL PROTECTED] babbled:
that is true. this will break all existing themes, but it's probably worth
fixing.
I feel bad now. :D
Toma
ps. Not if you change the menu radio and check to normal widgets they
should just be drawn like regular ones... leaving the old code to just
stay dormant and unused?
Howdee,
Ive noticed it before, but while working on something new, it seems
kind of silly to have the radio and check buttons from the menu
respond to different signals as the radio and check button widgets.
eg.
Heres the code from the widget:
program {
name:turn_on1;
signal: e,state,checked;
source: e;
action: STATE_SET enable 0.0;
target: hoz;
target: vert;
transition: SINUSOIDAL 0.2;
}
program {
name:turn_off1;
signal: e,state,unchecked;
source: e;
action: STATE_SET active 0.0;
target: hoz;
target: vert;
transition: SINUSOIDAL 0.2;
}
Heres the code from the menu:
program {
name:menu_on;
signal: e,state,on;
source: e;
action: STATE_SET active 0.0;
target: item1;
}
program {
name:menu_off;
signal: e,state,off;
source: e;
action: STATE_SET default 0.0;
target: item1;
}
As you can see, theyre basically the same thing (granted the widget
has a signal_emit in it too) but it should at least be able to do the
same signals and then just whack an alias on them! Im going to lump it
all together regardless, but theres still 2 programs doing essentially
the same thing.
Or am I totally off the mark here?
Toma
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
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)[EMAIL PROTECTED]
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
