Re: [E-devel] E SVN: illogict trunk/e/src/modules/conf_interaction
Hello! Dans son message intitulé « Re: [E-devel] E SVN: illogict trunk/e/src/modules/conf_interaction » du Tue, 7 Oct 2008 10:58:39 -0300, "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> nous a donné l'occasion de lire : > On Tue, Oct 7, 2008 at 10:45 AM, Toma <[EMAIL PROTECTED]> wrote: > > 2008/10/7 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>: > >> On Tue, Oct 7, 2008 at 10:00 AM, Toma <[EMAIL PROTECTED]> wrote: > >>> 2008/10/7 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>: > On Tue, Oct 7, 2008 at 2:57 AM, Enlightenment SVN > <[EMAIL PROTECTED]> wrote: > > Log: > > Some work on interaction settings: > > - group on a thumbscroll framelist; > > - threshhold ?\226?\134?\146 threshold; > > - add check changed. > > > that's awesome, I see people liked the "check_changed", we > should add this to other dialogs as well. Yes, more commits are to come :) > something else I'd like to see is to move, where possible, > layouts to edje with swallow parts, that way we can have special > layouts in embedded systems like illume. Side effect is to > simplify code a lot. What do you think? I think that is a great idea, the more we rely on Edje instead of fixed widgets, the better. [snip] > >> - themes may wish to change the layout, illume is one of them > >> because it's meant for small touch screen, this might serve for set > >> top boxes to be controlled with remote control. > >> > >> so why not? :-) [snip] That's a really good point, we could have themes that are tailored for specific uses, or even maybe user-selectable profiles in a given theme. > I want to add "sequence box" to edje before the end of the year, so > even the dynamic elements will be possible. (For those that don't know > what I mean with "sequence box", it's a box, or container, that packs > a sequence of objects, you can think of it as vertical/horizontal box > or flow layout, that would position children like a text flow). This > will be easy to add since we know have size hints as object property > and we'll make edje use those. Great! Cheers! Chidambar signature.asc Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ourcade -E17?
On Wed, Oct 8, 2008 at 12:55 PM, jude ui <[EMAIL PROTECTED]> wrote: > Hello , > > I've started , a sourceforge project called ourcade - our goal is to show > all the variety of free and opensource games that anyone could download and > install ... > > The main frontend and some of the backend is going to be based on the > EFL I'm also hoping that ourcade could be a desktop application > paticularly for e17. > > Is there anyone (out of they're spare time of course) that could help this > be a success? > > -if so, plaese email me at [EMAIL PROTECTED] not much time atm, but you could build things using guarana, for example lists and like ;-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Ourcade -E17?
Hello , I've started , a sourceforge project called ourcade - our goal is to show all the variety of free and opensource games that anyone could download and install ... The main frontend and some of the backend is going to be based on the EFL I'm also hoping that ourcade could be a desktop application paticularly for e17. Is there anyone (out of they're spare time of course) that could help this be a success? -if so, plaese email me at [EMAIL PROTECTED] --any developer who is busy with enlightenment ignore this message... - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] EET crypto
On Wed, Oct 8, 2008 at 4:02 PM, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > On Wed, Oct 8, 2008 at 10:19 AM, Cedric BAIL <[EMAIL PROTECTED]> wrote: >> On Wed, Oct 8, 2008 at 3:00 PM, Viktor Kojouharov <[EMAIL PROTECTED]> wrote: >>> On Wed, 2008-10-08 at 14:46 +0200, Cedric BAIL wrote: Hi, As it seems like a good time to break the EFL agains :-). I would like to discuss API/ABI break of eet. I am currently working on adding crypto to eet. My current code only require a key and generate the needed salt and IV for the encryption. So I need to add one more parameter (the key) to all read and write operation of eet. I have currently two possibilities, double the number of function, or just change the existing one. Of course the later solution sounds a little bit cleaner, but it will break all eet applications. A quick search of eet_open in the svn give me 43 differents file using it. Sounds like not a big deal to break it. This could be also be a good time to cleanup the parameters of eet_data_descriptor_element_add also. So guys, what do you think of this move ? >>> >>> Wasn't eet 1.0 released a couple of weeks ago? Breaking the API after >>> the supposed stable 1.0 release just screams wrong in so many ways. >> >> Yeah, I know, that's why I asked. I just don't like the idea of not >> breaking the API/ABI and adding code to work around for marketing >> issue. >> >> Just looking at the TODO. We are planning to add : >> - support for scripting langage to convert from their object type to >> eet data and from eet data to script object. >> - streaming API for both audio and video. >> >> The only draw back on switching to 2.0 branch on Eet, is that we >> currently have one standing bug covered by the test case, that I can >> find a way to fix (bug in dump/undump) and this will mean that at some >> point we will need to make another release of the 1.0 branch. > > Do we need a different key for each read/write operation? I see this > being more a key per file, in that case make an eet_key_set(ef, key) > and check for the set pointer inside read/write operations. > > the existing parameters are really one per entry, like compression. I am not really planning to cypher all the data of the file, but just on a entry basis. So you can cypher eet data, but not picture for example. And I want to add this to eet_data_descriptor_decode and encode too. Between it will be a good time to also remove eet_data_descriptor2_new and eet_data_descriptor3_new. -- Cedric BAIL - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] EET crypto
On Wed, Oct 8, 2008 at 10:19 AM, Cedric BAIL <[EMAIL PROTECTED]> wrote: > On Wed, Oct 8, 2008 at 3:00 PM, Viktor Kojouharov <[EMAIL PROTECTED]> wrote: >> On Wed, 2008-10-08 at 14:46 +0200, Cedric BAIL wrote: >>> Hi, >>> >>>As it seems like a good time to break the EFL agains :-). I would >>> like to discuss API/ABI break of eet. I am currently working on adding >>> crypto to eet. My current code only require a key and generate the >>> needed salt and IV for the encryption. So I need to add one more >>> parameter (the key) to all read and write operation of eet. I have >>> currently two possibilities, double the number of function, or just >>> change the existing one. Of course the later solution sounds a little >>> bit cleaner, but it will break all eet applications. >>> >>>A quick search of eet_open in the svn give me 43 differents file >>> using it. Sounds like not a big deal to break it. This could be also >>> be a good time to cleanup the parameters of >>> eet_data_descriptor_element_add also. >>> >>>So guys, what do you think of this move ? >> >> Wasn't eet 1.0 released a couple of weeks ago? Breaking the API after >> the supposed stable 1.0 release just screams wrong in so many ways. > > Yeah, I know, that's why I asked. I just don't like the idea of not > breaking the API/ABI and adding code to work around for marketing > issue. > > Just looking at the TODO. We are planning to add : > - support for scripting langage to convert from their object type to > eet data and from eet data to script object. > - streaming API for both audio and video. > > The only draw back on switching to 2.0 branch on Eet, is that we > currently have one standing bug covered by the test case, that I can > find a way to fix (bug in dump/undump) and this will mean that at some > point we will need to make another release of the 1.0 branch. Do we need a different key for each read/write operation? I see this being more a key per file, in that case make an eet_key_set(ef, key) and check for the set pointer inside read/write operations. the existing parameters are really one per entry, like compression. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ANN: Guarana and Enjoy 0.1.0
On Wed, Oct 8, 2008 at 4:05 AM, Michael 'Mickey' Lauer <[EMAIL PROTECTED]> wrote: > Congrats to the release, Gustavo! > > Can you briefly summarize how Guarana relates to Ewl, Etk, and > Elementary? Guarana is more than a widget set, we provide some utilities that help development, like the module loader. As for our widget set, it's much like *last* Elementary. Actually I'm talking about this idea for a long time, back to the days Caio and I were hacking Canola2, he doing ETK and I doing Evas/Edje. Going with Evas/Edje was much simpler, much more extensible, it just lacked some base to work on top, that's the base we provided with python-terra (proprietary, python, Canola) and now in guarana (free software - lpgl, Cl). We used to say that "Etk copied just not the api, but the problems from Gtk", since you get some limitations that Gtk imposes to you because of their design. Elementary started out as a simple widget set, but old-fashioned. It *was* very similar to E widgets, don't know why raster did that. I also don't know if it was me talking to him (and sending guarana for beta testing), but he also realized that that is not the way to go and recently changed Elementary to be much more like Guarana... that's awesome, because there is no "infrastructure" need, we just provide smart objects, so it's easy to mix both. I'll try to get raster to drop Elementary and hack on Guarana, so we join efforts ;-) EWL is also different, it abstracts completely Evas/Edje from you. If you want something, you need to get and embedded widget to work with. That's a concept, I can't say it is wrong, but I don't like it. Other great Guarana stuff: - Accessor/Iterator: now in Eina (which we plan to use ASAP, dropping our code), this enables your data types to provide a common interface to access by index or to iterate, you can have as much accessors/iterators as wished for the same data type (unlike Ecore), and it's easy to use. The main reason I wrote so is thinking about Python (and others) integration: you just need to write a python_acessor and iterator and map to Python's __getitem__() and sudently your code will just work :-) - module loader: create a map (grn_loader_conf) of key=(file, symbol, prio, enabled) and it will return a list or the highest priority symbol that matches. It's a very easy way to split your code into modules to be dynamically loaded, specially with mvc - model-view-controller (mvc) basics and integrated with module loader. This is great because your module can request "Give me all the models that implement Model/MainMenu" and you get a list of functions, that you call and get the models. Then you want to "enter" some item, you go and ask: "Give me the first controller for model Model/Folder/Audio", it will try to check for "Model/Folder/Audio" and if not found will try "Model/Folder". That way you can just implement the model folder to list stuff by name, then go do some interesting stuff. When you're done with interesting stuff and you want to do some fancy stuff, you can go and write a Model/Folder/Audio that shows the title, cover art, etc... without need for whole software recompile. It will just work :-) These concepts are not new. I borrowed some from Zope, some from Python itself, some from Turbogears/Ruby-on-Rails. Controller discovery is much like mime-types. I used this kind of infrastructure for Freevo back in 2002, then in Canola1, Canola2 and some other private projects. So it works, and works nice. But we lacked something to use with EFL, and here it is :-) Have fun, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] EET crypto
On Wed, Oct 8, 2008 at 3:00 PM, Viktor Kojouharov <[EMAIL PROTECTED]> wrote: > On Wed, 2008-10-08 at 14:46 +0200, Cedric BAIL wrote: >> Hi, >> >>As it seems like a good time to break the EFL agains :-). I would >> like to discuss API/ABI break of eet. I am currently working on adding >> crypto to eet. My current code only require a key and generate the >> needed salt and IV for the encryption. So I need to add one more >> parameter (the key) to all read and write operation of eet. I have >> currently two possibilities, double the number of function, or just >> change the existing one. Of course the later solution sounds a little >> bit cleaner, but it will break all eet applications. >> >>A quick search of eet_open in the svn give me 43 differents file >> using it. Sounds like not a big deal to break it. This could be also >> be a good time to cleanup the parameters of >> eet_data_descriptor_element_add also. >> >>So guys, what do you think of this move ? > > Wasn't eet 1.0 released a couple of weeks ago? Breaking the API after > the supposed stable 1.0 release just screams wrong in so many ways. Yeah, I know, that's why I asked. I just don't like the idea of not breaking the API/ABI and adding code to work around for marketing issue. Just looking at the TODO. We are planning to add : - support for scripting langage to convert from their object type to eet data and from eet data to script object. - streaming API for both audio and video. The only draw back on switching to 2.0 branch on Eet, is that we currently have one standing bug covered by the test case, that I can find a way to fix (bug in dump/undump) and this will mean that at some point we will need to make another release of the 1.0 branch. -- Cedric BAIL - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: illogict trunk/e/src/modules/conf_interaction
On Wed, Oct 8, 2008 at 7:46 AM, Nicolas Aguirre <[EMAIL PROTECTED]> wrote: > > > 2008/10/7 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> >> >> I want to add "sequence box" to edje before the end of the year, so >> even the dynamic elements will be possible. (For those that don't know >> what I mean with "sequence box", it's a box, or container, that packs >> a sequence of objects, you can think of it as vertical/horizontal box >> or flow layout, that would position children like a text flow). This >> will be easy to add since we know have size hints as object property >> and we'll make edje use those. > > Does it means that we could do dynamics lists directly with edje, and remove > all e_box, guarana base_list, or els_box, and those I used in enna when this > feature will be implemented ? ebox = yes, guarana = no, els_box = never saw. why ebox and not guarana? Because the current code will be similar to ebox, it's a bunch of items laid out in some way, that is still not available in guarana (we call it "sequence_box" here, it's being finished and will be pushed later today -- actually I want to use code in Guarana sequence_box as base for what we plan to integrate in evas/edje). what is guarana base_list, single_selection_list, ...? These are optimized MVC lists. They're limited in some ways, but they're very fast, having the complexity bounded to number of visible items only (O(n_visible)), so if you have a huge list it will not slow down your code in any way. But it's limited (on purpose, some things may change, some may not), one thing is that every row must be the same height, so calculations take place as a simple math. Also, row renderers should be the same, since these will be cycled for all items (we just create/destroy renderers when viewport is resized). However this makes a perfect base for large lists like your whole music collection ;-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] EET crypto
On Wed, 2008-10-08 at 14:46 +0200, Cedric BAIL wrote: > Hi, > >As it seems like a good time to break the EFL agains :-). I would > like to discuss API/ABI break of eet. I am currently working on adding > crypto to eet. My current code only require a key and generate the > needed salt and IV for the encryption. So I need to add one more > parameter (the key) to all read and write operation of eet. I have > currently two possibilities, double the number of function, or just > change the existing one. Of course the later solution sounds a little > bit cleaner, but it will break all eet applications. > >A quick search of eet_open in the svn give me 43 differents file > using it. Sounds like not a big deal to break it. This could be also > be a good time to cleanup the parameters of > eet_data_descriptor_element_add also. > >So guys, what do you think of this move ? Wasn't eet 1.0 released a couple of weeks ago? Breaking the API after the supposed stable 1.0 release just screams wrong in so many ways. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [RFC] EET crypto
Hi, As it seems like a good time to break the EFL agains :-). I would like to discuss API/ABI break of eet. I am currently working on adding crypto to eet. My current code only require a key and generate the needed salt and IV for the encryption. So I need to add one more parameter (the key) to all read and write operation of eet. I have currently two possibilities, double the number of function, or just change the existing one. Of course the later solution sounds a little bit cleaner, but it will break all eet applications. A quick search of eet_open in the svn give me 43 differents file using it. Sounds like not a big deal to break it. This could be also be a good time to cleanup the parameters of eet_data_descriptor_element_add also. So guys, what do you think of this move ? -- Cedric BAIL - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: illogict trunk/e/src/modules/conf_interaction
2008/10/7 Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> > > I want to add "sequence box" to edje before the end of the year, so > even the dynamic elements will be possible. (For those that don't know > what I mean with "sequence box", it's a box, or container, that packs > a sequence of objects, you can think of it as vertical/horizontal box > or flow layout, that would position children like a text flow). This > will be easy to add since we know have size hints as object property > and we'll make edje use those. > Does it means that we could do dynamics lists directly with edje, and remove all e_box, guarana base_list, or els_box, and those I used in enna when this feature will be implemented ? -- Nicolas Aguirre Mail: [EMAIL PROTECTED] Web: http://www.digital-corner.org - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ANN: Guarana and Enjoy 0.1.0
Congrats to the release, Gustavo! Can you briefly summarize how Guarana relates to Ewl, Etk, and Elementary? Cheers, Mickey. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
