Re: [E-devel] Spam.
On Thu, 08 Feb 2018 02:41:18 + Mike Blumenkrantz wrote: > by permanently ip banning anyone creating tickets at a rapid pace. Ah so that is the real reason I was banned :P -- William L. Thomson Jr. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Spam.
On 08/02/2018 13:23, Carsten Haitzler wrote: On Thu, 08 Feb 2018 12:41:06 + Bertrand Jacquin said: > you don't need to manually go close every ticket. just find one ticket > and the > problem user and tell me. it's possible to wipe the mess easily enough > on the > cmdline. i put together a small script that can qeury the sql db and > nuke the > user AND tasks they authored: > > sudo ./phab-nuke-spam-user.sh jdnjka Hug no, that will create inconsistency in the database, instead the "remove destoy" tool should be used as explained on https://secure.phabricator.com/book/phabricator/article/users/. $ sudo -u apache /srv/web/phab.enlightenment.org/bin/remove destroy @username that;'s actually what the script does... but it identifies all the tasks created by the user and nukes those separately then nukes the user.. it uses the pha remove tool to do it, but mysql to query to find out what to remove... :) Oh alright, we're all good then, thanks! specifically this is it: #!/bin/sh M="mysql -sN -D" USER="$1" USERPHID=`$M phabricator_user -e \ "select phid from user where userName=\"$USER\";"` for ID in \ `$M phabricator_maniphest -e \ "select id from maniphest_task where authorPHID='"$USERPHID"';"`; do echo Nuke T$ID /srv/web/phab.enlightenment.org/bin/remove destroy --force "T$ID" done echo Nuke @$USER /srv/web/phab.enlightenment.org/bin/remove destroy --force "@$USER" -- Bertrand -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Spam.
On Thu, 08 Feb 2018 12:41:06 + Bertrand Jacquin said: > > > you don't need to manually go close every ticket. just find one ticket > > and the > > problem user and tell me. it's possible to wipe the mess easily enough > > on the > > cmdline. i put together a small script that can qeury the sql db and > > nuke the > > user AND tasks they authored: > > > > sudo ./phab-nuke-spam-user.sh jdnjka > > Hug no, that will create inconsistency in the database, instead the > "remove destoy" tool should be used as explained on > https://secure.phabricator.com/book/phabricator/article/users/. > >$ sudo -u apache /srv/web/phab.enlightenment.org/bin/remove destroy > @username that;'s actually what the script does... but it identifies all the tasks created by the user and nukes those separately then nukes the user.. it uses the pha remove tool to do it, but mysql to query to find out what to remove... :) specifically this is it: #!/bin/sh M="mysql -sN -D" USER="$1" USERPHID=`$M phabricator_user -e \ "select phid from user where userName=\"$USER\";"` for ID in \ `$M phabricator_maniphest -e \ "select id from maniphest_task where authorPHID='"$USERPHID"';"`; do echo Nuke T$ID /srv/web/phab.enlightenment.org/bin/remove destroy --force "T$ID" done echo Nuke @$USER /srv/web/phab.enlightenment.org/bin/remove destroy --force "@$USER" -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Spam.
you don't need to manually go close every ticket. just find one ticket and the problem user and tell me. it's possible to wipe the mess easily enough on the cmdline. i put together a small script that can qeury the sql db and nuke the user AND tasks they authored: sudo ./phab-nuke-spam-user.sh jdnjka Hug no, that will create inconsistency in the database, instead the "remove destoy" tool should be used as explained on https://secure.phabricator.com/book/phabricator/article/users/. $ sudo -u apache /srv/web/phab.enlightenment.org/bin/remove destroy @username Cheers -- Bertrand -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Spam.
On Thu, 8 Feb 2018 10:47:37 +0100 Marcel Hollerbach said: > Hi, > > On 02/08/2018 10:35 AM, Carsten Haitzler (The Rasterman) wrote: > > On Thu, 08 Feb 2018 02:41:18 + Mike Blumenkrantz > > said: > > > >> This is the second mail I'm sending about this topic. The volume and > >> frequency of the spam tickets is increasing. Something needs to be done, > >> either by moving to a different project hosting service which > >> prevents/filters spam or by permanently ip banning anyone creating tickets > >> at a rapid pace. > > > > moving project hosting is a crazy option. we loose all our tickets, patches, > > wiki etc. if we don't then invest 100's of hours of moving things around and > > restarting on something else. then there is the fun of "alternative hosting" > > eventually "going away or degrading". been there before. i think you're > > over-reacting to 10 spam tickets from 1 user today. > > > > i looked at your recent activities and it looks like it was all "jdnka" and > > they seem to all originate from 183.166.174.13 according to phab's logs. > > > > geoip says this one comes from huangshan city, china. banning a single ip, i > > doubt will have much effect unless there is a pattern of every spam account > > coming from this same ip or a restricted range of them. so far i know of > > just 2 spam accounts: > > > > bvhgfh5 (the previous one you mentioned - cant get logs for ip now - too > > old) jdnjka (this one) > > > > are there others? i only know of 2 instances of spam (i would consider > > these 2 instances even if 10 of spam tickets were created per account). can > > you point me to others? 2 does not make a pattern yet. i do notice they both > > use the same email domain for email address for the user. unfortunately phab > > only has the ability it whitelist email domains, not blacklist them. i've > > added blacklisting to phab's auth email stuff right now on e.org, so we'll > > nbe carrying this patch for a while... i hope it works. it's simple > > enough...i blacklisted the domain used here anyway now. > > > > you don't need to manually go close every ticket. just find one ticket and > > the problem user and tell me. it's possible to wipe the mess easily enough > > on the cmdline. i put together a small script that can qeury the sql db and > > nuke the user AND tasks they authored: > > > >sudo ./phab-nuke-spam-user.sh jdnjka > > > > for example. don't waste your time closing etc. every ticket for now i > > haven't nuked the above yet in the interests of gathering more data... do > > you have any more data to share? > > > > Its like 1 user per week, that creates ~10 tickets, i usally report them > to beber, who is deleting the users. A few other usernames: ok. i only have heard of these 2 above. the below is news to me. > xcjdd5v > lskd89 lskd89 seems to be deleted, but xcjdd5v also uses the same email address domain... so the blacklist i put in should stop this. > I cannot get more names since they are deleted, and the tickets are > deleted, but its since december like this. I usally post them on phab in > the spam group :) well i'd have liked to know more of these so i can find patterns... it's knowing the patterns that allows for finding some way to block them. removing the user and their mess is an easy enough script like above. please let me know when this happens and who it is etc. etc. so i can find a pattern. at least the email domain is common. they may switch to a new email provider, but this likely will eventually exhaust their supply of "easy to register" email providers and make them give up. we have a blacklist now and it can expand as long as i know who the culprits are. i've nuked all the 3 above that still exist (easy to do). let me know about more. > Greetings, > bu5hm4n > > > > > > >> -- > >> Check out the vibrant tech community on one of the world's most > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >> ___ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > 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" -- Carsten Haitzler - ras...@rasterman.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Re: [E-devel] Spam.
Hi, On 02/08/2018 10:35 AM, Carsten Haitzler (The Rasterman) wrote: On Thu, 08 Feb 2018 02:41:18 + Mike Blumenkrantz said: This is the second mail I'm sending about this topic. The volume and frequency of the spam tickets is increasing. Something needs to be done, either by moving to a different project hosting service which prevents/filters spam or by permanently ip banning anyone creating tickets at a rapid pace. moving project hosting is a crazy option. we loose all our tickets, patches, wiki etc. if we don't then invest 100's of hours of moving things around and restarting on something else. then there is the fun of "alternative hosting" eventually "going away or degrading". been there before. i think you're over-reacting to 10 spam tickets from 1 user today. i looked at your recent activities and it looks like it was all "jdnka" and they seem to all originate from 183.166.174.13 according to phab's logs. geoip says this one comes from huangshan city, china. banning a single ip, i doubt will have much effect unless there is a pattern of every spam account coming from this same ip or a restricted range of them. so far i know of just 2 spam accounts: bvhgfh5 (the previous one you mentioned - cant get logs for ip now - too old) jdnjka (this one) are there others? i only know of 2 instances of spam (i would consider these 2 instances even if 10 of spam tickets were created per account). can you point me to others? 2 does not make a pattern yet. i do notice they both use the same email domain for email address for the user. unfortunately phab only has the ability it whitelist email domains, not blacklist them. i've added blacklisting to phab's auth email stuff right now on e.org, so we'll nbe carrying this patch for a while... i hope it works. it's simple enough...i blacklisted the domain used here anyway now. you don't need to manually go close every ticket. just find one ticket and the problem user and tell me. it's possible to wipe the mess easily enough on the cmdline. i put together a small script that can qeury the sql db and nuke the user AND tasks they authored: sudo ./phab-nuke-spam-user.sh jdnjka for example. don't waste your time closing etc. every ticket for now i haven't nuked the above yet in the interests of gathering more data... do you have any more data to share? Its like 1 user per week, that creates ~10 tickets, i usally report them to beber, who is deleting the users. A few other usernames: xcjdd5v lskd89 I cannot get more names since they are deleted, and the tickets are deleted, but its since december like this. I usally post them on phab in the spam group :) Greetings, bu5hm4n -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Spam.
On Thu, 08 Feb 2018 02:41:18 + Mike Blumenkrantz said: > This is the second mail I'm sending about this topic. The volume and > frequency of the spam tickets is increasing. Something needs to be done, > either by moving to a different project hosting service which > prevents/filters spam or by permanently ip banning anyone creating tickets > at a rapid pace. moving project hosting is a crazy option. we loose all our tickets, patches, wiki etc. if we don't then invest 100's of hours of moving things around and restarting on something else. then there is the fun of "alternative hosting" eventually "going away or degrading". been there before. i think you're over-reacting to 10 spam tickets from 1 user today. i looked at your recent activities and it looks like it was all "jdnka" and they seem to all originate from 183.166.174.13 according to phab's logs. geoip says this one comes from huangshan city, china. banning a single ip, i doubt will have much effect unless there is a pattern of every spam account coming from this same ip or a restricted range of them. so far i know of just 2 spam accounts: bvhgfh5 (the previous one you mentioned - cant get logs for ip now - too old) jdnjka (this one) are there others? i only know of 2 instances of spam (i would consider these 2 instances even if 10 of spam tickets were created per account). can you point me to others? 2 does not make a pattern yet. i do notice they both use the same email domain for email address for the user. unfortunately phab only has the ability it whitelist email domains, not blacklist them. i've added blacklisting to phab's auth email stuff right now on e.org, so we'll nbe carrying this patch for a while... i hope it works. it's simple enough...i blacklisted the domain used here anyway now. you don't need to manually go close every ticket. just find one ticket and the problem user and tell me. it's possible to wipe the mess easily enough on the cmdline. i put together a small script that can qeury the sql db and nuke the user AND tasks they authored: sudo ./phab-nuke-spam-user.sh jdnjka for example. don't waste your time closing etc. every ticket for now i haven't nuked the above yet in the interests of gathering more data... do you have any more data to share? > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > 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" -- Carsten Haitzler - ras...@rasterman.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: entrance
On Mon, May 31, 2010 at 8:03 AM, Vincent Torri wrote: > > > On Mon, 31 May 2010, Gustavo Sverzut Barbieri wrote: > >> On Mon, May 31, 2010 at 4:22 AM, Vincent Torri >> wrote: >>> >>> >>> On Mon, 31 May 2010, Christopher Michael wrote: >>> On 05/31/2010 03:08 AM, Vincent Torri wrote: > > > On Mon, 31 May 2010, Vincent Pomageot wrote: > >> Hi, >> >> Entrance has been removed from svn 3 month ago. >> You can get it by checking out a revision before 46590. > > as quaker still don't want to (can't ?) work on a new entrance, I'm > more > inclined to add it again to svn. He deleted it by saying a new one will > be added soon. 3 months later, nothing. The good thing would have be to > add an "entrance2" and do the move *after* the new code is in svn, > whatever the status of entrance was. > > Vincent > Or the other way ... moving 'entrance' to OLD (rather than total removal), and start working on entrance2 :) >>> >>> same thing, what is important is to not remove the old code before the >>> new one is in svn >> >> the code was broken and causing more harm than good. Actually it >> should have been removed way before. > > no, it should have been fixed. And btw, it's strange. I have several reports > from users that said that it was working. I tried to fix it like years ago, before giving up in the amount of brokeness in code I've found and possible cases to fall in bugs. Then for my own good, even tho I fixed my current issue at the time, I moved to something else and -locked option was introduced. Entrance was full of possible races, missing signals and so on, that's why I suggested writing a new one instead of digging into lots of incorrect code. Except by the theme, nothing was worth re-using, and frankly the theme was not that useful as it was based on blingbling and we rather go more "default.edj" or even use Elementary for it and cut some work or deprecated library usage (esmart). Given that we have restricted resources, I followed raster's advice and did not waste my time in it at that point to focus on e17, as raster himself and others were doing. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: entrance
On Mon, 31 May 2010, Gustavo Sverzut Barbieri wrote: > On Mon, May 31, 2010 at 4:22 AM, Vincent Torri wrote: >> >> >> On Mon, 31 May 2010, Christopher Michael wrote: >> >>> On 05/31/2010 03:08 AM, Vincent Torri wrote: On Mon, 31 May 2010, Vincent Pomageot wrote: > Hi, > > Entrance has been removed from svn 3 month ago. > You can get it by checking out a revision before 46590. as quaker still don't want to (can't ?) work on a new entrance, I'm more inclined to add it again to svn. He deleted it by saying a new one will be added soon. 3 months later, nothing. The good thing would have be to add an "entrance2" and do the move *after* the new code is in svn, whatever the status of entrance was. Vincent >>> >>> Or the other way ... moving 'entrance' to OLD (rather than total removal), >>> and start working on entrance2 :) >> >> same thing, what is important is to not remove the old code before the >> new one is in svn > > the code was broken and causing more harm than good. Actually it > should have been removed way before. no, it should have been fixed. And btw, it's strange. I have several reports from users that said that it was working. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: entrance
On Mon, May 31, 2010 at 4:22 AM, Vincent Torri wrote: > > > On Mon, 31 May 2010, Christopher Michael wrote: > >> On 05/31/2010 03:08 AM, Vincent Torri wrote: >>> >>> >>> On Mon, 31 May 2010, Vincent Pomageot wrote: >>> Hi, Entrance has been removed from svn 3 month ago. You can get it by checking out a revision before 46590. >>> >>> as quaker still don't want to (can't ?) work on a new entrance, I'm more >>> inclined to add it again to svn. He deleted it by saying a new one will >>> be added soon. 3 months later, nothing. The good thing would have be to >>> add an "entrance2" and do the move *after* the new code is in svn, >>> whatever the status of entrance was. >>> >>> Vincent >>> >> >> Or the other way ... moving 'entrance' to OLD (rather than total removal), >> and start working on entrance2 :) > > same thing, what is important is to not remove the old code before the > new one is in svn the code was broken and causing more harm than good. Actually it should have been removed way before. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: entrance
On Mon, 31 May 2010, Christopher Michael wrote: > On 05/31/2010 03:08 AM, Vincent Torri wrote: >> >> >> On Mon, 31 May 2010, Vincent Pomageot wrote: >> >>> Hi, >>> >>> Entrance has been removed from svn 3 month ago. >>> You can get it by checking out a revision before 46590. >> >> as quaker still don't want to (can't ?) work on a new entrance, I'm more >> inclined to add it again to svn. He deleted it by saying a new one will >> be added soon. 3 months later, nothing. The good thing would have be to >> add an "entrance2" and do the move *after* the new code is in svn, >> whatever the status of entrance was. >> >> Vincent >> > > Or the other way ... moving 'entrance' to OLD (rather than total removal), > and start working on entrance2 :) same thing, what is important is to not remove the old code before the new one is in svn Vincent -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Exchange - A new place to trade themes and showcase applications and modules.
Vincent wrote: > > On Mon, 21 Jul 2008, Jose Gonzalez wrote: >> >> Get-e *was* good, and useful. It could've done more in terms of >> this and that, >> but so could everything. But I don't see why everyone feels that >> 'there can be >> only one' of anything. I just don't understand this persistent idea >> that I've >> seen here often. It's not good to have that, not at all. > > Sure, it's of course easy to upload things 2 times, to be sure that > all the modules are at the same version, same for all themes, etc... > That doesn't necessarily have to be the case, and certainly not manually. There could be more, or less, or something different, to get-e, if it wants to... it just has to decide what, where, and how far to go. >> Why can't there be many sites each catering to specific needs.. > > I agree here. But with get-e.org and exchange, we had 2 sites that > host the *same* things. It would be a pain to maintain both sites, > especially if the number of themes, background apps, modules, etc... > grows a lot. > There's got to be more to a web presence to E than themes... and if you think about it. :) Click to lower your debt and consolidate your monthly expenses. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m2bkMNJMVOTiAMLHEJDvcykQ2tn75cFj8jtoKLTybpR6esv/ - 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] {Spam?} Re: Exchange - A new place to trade themes and showcase applications and modules.
On Mon, 21 Jul 2008, Jose Gonzalez wrote: > > Get-e *was* good, and useful. It could've done more in terms of this and > that, > but so could everything. But I don't see why everyone feels that 'there can be > only one' of anything. I just don't understand this persistent idea that I've > seen here often. It's not good to have that, not at all. Sure, it's of course easy to upload things 2 times, to be sure that all the modules are at the same version, same for all themes, etc... > Why can't there be many sites each catering to specific needs.. I agree here. But with get-e.org and exchange, we had 2 sites that host the *same* things. It would be a pain to maintain both sites, especially if the number of themes, background apps, modules, etc... grows a lot. Vincent - 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] {Spam?} Re: [Evas] possible bug in gradient
On Wed, 9 Jul 2008, Jose Gonzalez wrote: I wrote: I'd _love_ using gradients, in fact I would use them much more often, _if_ not everytime I start using them, it all feels like I'm operating a powerful machine that has 100s of controls and I don't understand anything. Perhaps this is an inherent problem from the gradient complexity, but I'd appreciate if we had some documentary material that outlines how to achieve which kind of results, which gradient type to use for what, how many stops for what effect etc. etc. Ok, let me try and give you a fairly simplified description of what gradients are basically about, and how evas tries to deal with this.. for better or worse. ... ... ...But to get back to the subject at hand here, and before going on to give more details on current evas gradients, let me ask you this: How would you answer the above two 'general' questions.. or rather, what would *you* like to see as an api that would make you want to use gradients more? Not much time to reflect on this? Well, that's understandable :) Let me go ahead and review the current set of gradient api funcs in evas, give some criticisms, and propose some changes I'd like to make to improve things there (and yes, they would break all gradient stuff). First, recall I mentioned the two parts involved in gradients: 1) Those aspects related to defining a 1-dim image (or "spectrum" as I sometimes call it). 2) Those aspects related to defining how to map the above to a 2-dim region - and this covers things like the gradient type, spread-mode, and such things. Ok, for (1) in evas we currently have the following (set) api funcs: void evas_object_gradient_color_stop_add(obj, r,g,b,a, int delta); void evas_object_gradient_alpha_stop_add(obj, a, int delta); void evas_object_gradient_color_data_set(obj, *data, len, has_alpha); void evas_object_gradient_alpha_data_set(obj, *data, len); void evas_object_gradient_direction_set(obj, *data, int direction); void evas_object_gradient_offset_set(obj, *data, float offset); and also, void evas_object_gradient_clear(obj); The 'clear' api func removes any stops or data that might have been set before. The 'offset' api func effectively moves the origin of the 1-dim image, this is something that as far as I know isn't supported by any vgfx api/spec (which is unfortunate since it can give very nice animation effects which are otherwise difficult to obtain for some gradient types, eg. radial ones). The 'direction' api func just reverses the start/end of the 1-dim, and though not directly supported by most vgfx apis/specs, it can be easily obtained - it's mostly a simple convenience function. The 'color_data' and 'alpha_data' api funcs are to allow for setting such a 1-dim image with premul and alpha-only data, rather than going thru any kind of procedural description. It's not supported by any vgfx api/spec that I know of, not directly anyway.. though you can certainly consider such data as an equi-distant set of stops and add it that way (modulo some gymnastics with premul data and alpha masks and such). The 'color_stop' and 'alpha_stop' api funcs evas' current procedural descriptions for defining the spectrum -- and these I have real issues with. Not only is this method of specifying stops not supported by any 'standard' vgfx api/spec, the use of the "int delta" as either some kind of 'weight' or maybe 'distance to a next' is somewhat un-intuitive and very difficult to work with for gui editors and such. I propose getting rid of this legacy stuff (inhereted from the equally archaic Imlib2 method), and adopt a more standard method. In fact, let's start from scratch altogether here and let me propose a minimal set of grdient-spectrum related api functions that more closely matches what's given by most vgfx apis/specs: void evas_object_gradient_clear(obj); // keep this one void evas_object_gradient_color_stop_insert(obj, r,g,b,a, float pos); // where 'pos' is clamped to be in [0,1]. Any previous stop at same pos // will be overwritten. Must insert one stop at pos 0 and one at pos 1 // to get a valid gradient spectrum. This and matches what most use. One could then possibly add the following funcs to make it easier/more-intuitive to input, query, and manipulate such gradient stops: void evas_object_gradient_color_stop_get(obj, int index, *r,*g,*b,*a,*pos); // get the value of the stop at 'index', where these are ordered from 0 to // (number_of_stops - 1) according to increasing position. If 'index' is >= // the current number of stops, or index < 0, this does nothing. void evas_object_gradient_color_stop_set(obj, int index, r,g,b,a,pos); // modifies the r,g,b,a,pos values of the stop at the given index, // where 'pos' is clamped to lie between the prev and next (if any) stop // positions in the gradient, and again does nothing if 'index' >= current // number of stops or index < 0. void
Re: [E-devel] {Spam?} How to apply a transformation to a Evas object?
Hey, > How to apply a transformation to a Evas object? For > example, rotate a Evas object. rotation (other than 90, 180 or 270 degrees) is not supported in Evas Vincent - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: EFL and Webkit
Vincent wrote: > .. >> >> Then go from there and build things like an evas-3D lib if >> desired.. possibly dependent on gl but able to render to any evas by >> say rendering to a gl buffer and getting argb data if need be, or some >> other way.. > > just to mention that the direct3d engine can also do (obviously) 3d. > Currently, the d3d engine can not, but i have a new engine which uses > vertex buffers, like the open gl ones. Maybe it would be interesting > to support both api. > Well, if you just expose 'native surfaces' then you don't need anything more - you just draw to those with whatever libs/apis you want. But there are other ways too, eg. one could have engine specific evas objs which would allow you to specify certain obj-funcs, a 'draw' func in particular. In any case, the idea of having something like a 3d-scene object would be to abstract away from such specific apis like gl or direct3d. What api could it provide instead? Well, that could vary from something that simply allows one to 'set' a file on such an object and it'd just load a 3d scene description and maybe allow one to change some stuff... or it could give a set of primitive objs, or have some sort of high-level 3d api, or whatnot. Of course it could still allow you to use low-level apis like gl or direct3d where appropriate. What is needed here though, is *one* concrete mechanism worked-out. > maybe we whould also look at gallium for 3d. > As this would give...??? - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: EFL and Webkit
On Mon, 10 Mar 2008, [EMAIL PROTECTED] wrote: > Ummm I'm not sure I follow you here at all. What you've > mentioned above seems far more reaching - not quite just dealing with > implementing image obj 'native surfaces', which is what I was wondering > about here. > Maybe the other engine-ers (Cedric, Vincent, Gustavo) can give > their own views here as well, but let me just be a bit more specific as > to how I'd imagined this and see if it makes sense. > > By 'native surfaces' I'd meant things like xrender pictures, > gl textures (maybe pbuffers), sdl surfaces, etc. So, more like engine- > renderer specific 'buffer surfaces'. > One'd then have get/set functions for image objs of 'similar' > evas engines (xrender-x11, gl-x11,...), along with various specialty > funcs to query whatever extra stuff specific such 'surfaces' might > have (eg. wether a gl texture is an nv-rect, its actual size, etc). > Ideally, there would also be given a means to convert such surfaces > to argb data (wether exposed or just internal). > > I'd imagined these funcs in each engine header, nothing at all > in the general evas api, and one would implement the funcs in the > engine modules, likely via the use of a new 'object function' to get > an evas object's 'engine_data'. > > Or at least, that's more or less what I envisioned for these. > > Then go from there and build things like an evas-3D lib if > desired.. possibly dependent on gl but able to render to any evas by > say rendering to a gl buffer and getting argb data if need be, or some > other way.. just to mention that the direct3d engine can also do (obviously) 3d. Currently, the d3d engine can not, but i have a new engine which uses vertex buffers, like the open gl ones. Maybe it would be interesting to support both api. maybe we whould also look at gallium for 3d. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: libs/ecore raster
On Sun, Mar 16, 2008 at 2:12 PM, Vincent Torri <[EMAIL PROTECTED]> wrote: > > > >> Btw, -lecore_evas is in my .pc file. > > > > it doesn't set it when doing a cross-compile. > > so your fix is not correct. I'll look at it when i'll cross compile evas He was using openmoko cross compiler toolchain, that uses openembedded, better to try it too. This problem is kinda strange, I took a look at his machine and we could not find any problem on desktops, but on that openmoko it fails like that. -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: libs/ecore raster
>> Btw, -lecore_evas is in my .pc file. > > it doesn't set it when doing a cross-compile. so your fix is not correct. I'll look at it when i'll cross compile evas Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Google Summer of Code 2008
On Tue, 26 Feb 2008, Viktor Kojouharov wrote: > As far as suggestions go, here's my 2 cents: > > 1.5 Bringing the evas gl engine up to standard. can you detail a bit what can be done in the gl engine ? You can modify the wiki, instead of answering in the ML (http://wiki.enlightenment.org/index.php/SoC_Project_Ideas) thanks Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Google Summer of Code 2008
On Fri, 29 Feb 2008, [EMAIL PROTECTED] wrote: > > Vincent wrote: > >> * writing an evince-like prog in full edje > > Why would anyone not familiar with "e" care about anything like > this? There's already an evince. Why would a similar app, but with this > "edje", be of any interest to anyone, or of interest enough that they'd > pay someone to do it? why writing another wm as already very good wm exist ? why writing a new graphic lib as already good ones exist ? etc... what i wanted, is a gui that is not like evince and use the power of edje (see the wiki) With your reasonning, just gave up all the EFL, as they are libs to write mainly gui. And a lot of tool already exist using gnome or kde. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: libs/ecore vapier
On Saturday 26 January 2008, Vincent Torri wrote: > On Sat, 26 Jan 2008, Mike Frysinger wrote: > > On Saturday 26 January 2008, Vincent Torri wrote: > >> On Sat, 26 Jan 2008, Mike Frysinger wrote: > >>> On Saturday 26 January 2008, Vincent Torri wrote: > > #ifdef HAVE_NETINET_IN_H > > -#include > > -#elif _WIN32 > > -#include > > +# include > > +#endif > > +#ifdef HAVE_WINSOCK2_H > > +# include > > #endif > > it is completely useless to check it in configure script as winsowk2.h > is always avalaible on windows. So you replace one #ifdef which always > works by a check in configure + a #ifdef. Where is the gain ? > >>> > >>> so you dont have to keep adding crap for every random windows related > >>> compiler. like the random windows mobile / ce / whatever microsoft > >>> puts out. do it once, do it right, and then you're done. > >> > >> You do not it right. Before doing that, I asked mingw devs on how to do > >> that. I think that they know a bit more on how to do that than you. > >> > Please, revert what you committed. > >>> > >>> unless you can show this being incorrect, no > >> > >> With cegcc, I have to define / undefine macro (in Eet_private.h). So > >> anyway I have to check whether or not cegcc is used or not. > >> > >> And as I told you, people that know a lot more than you on windows told > >> me how I have to check things correctly. If you don't revert your > >> changes, I'll do it myself and i would like you to ask me questions and > >> waiting for my answers before commiting when dealing with windows stuff. > >> I can do mistakes, and I would be glad to know them. But here, what i > >> did here is correct. > > > > polluting multiple places with windows cruft that do the same thing over > > and over is not the way to go. if you want to maintain a mess of ifdefs, > > write it in *one* place and have all the other files pull it in. > > for example, about the mmap and fcntl calls in eet_lib.c, you would > suggest to write in eet_win32.c the ports of these functions and call them > in eet_lib.c ? exactly ... where we can unify these pieces without touching common code the better. not sure if there's a "core" piece of e17 where we can move all of this, but if we had a few files that we could just drop into the different e libraries, that'd be a good start i think (think gnulib here). like a "system.h" where we stick all of the win32 ifdefs/includes and then everyone pulls that. your thoughts on mmap/fcntl sound like an excellent example. _e_mmap() / _e_fd_cloexec(). -mike signature.asc Description: This is a digitally signed message part. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: libs/ecore vapier
On Sat, 26 Jan 2008, Mike Frysinger wrote: > On Saturday 26 January 2008, Vincent Torri wrote: >> On Sat, 26 Jan 2008, Mike Frysinger wrote: >>> On Saturday 26 January 2008, Vincent Torri wrote: > #ifdef HAVE_NETINET_IN_H > -#include > -#elif _WIN32 > -#include > +# include > +#endif > +#ifdef HAVE_WINSOCK2_H > +# include > #endif it is completely useless to check it in configure script as winsowk2.h is always avalaible on windows. So you replace one #ifdef which always works by a check in configure + a #ifdef. Where is the gain ? >>> >>> so you dont have to keep adding crap for every random windows related >>> compiler. like the random windows mobile / ce / whatever microsoft puts >>> out. do it once, do it right, and then you're done. >> >> You do not it right. Before doing that, I asked mingw devs on how to do >> that. I think that they know a bit more on how to do that than you. >> Please, revert what you committed. >>> >>> unless you can show this being incorrect, no >> >> With cegcc, I have to define / undefine macro (in Eet_private.h). So >> anyway I have to check whether or not cegcc is used or not. >> >> And as I told you, people that know a lot more than you on windows told me >> how I have to check things correctly. If you don't revert your changes, >> I'll do it myself and i would like you to ask me questions and waiting >> for my answers before commiting when dealing with windows stuff. I can do >> mistakes, and I would be glad to know them. But here, what i did here is >> correct. > > polluting multiple places with windows cruft that do the same thing over and > over is not the way to go. if you want to maintain a mess of ifdefs, write > it in *one* place and have all the other files pull it in. for example, about the mmap and fcntl calls in eet_lib.c, you would suggest to write in eet_win32.c the ports of these functions and call them in eet_lib.c ? I'm not against it. I can do it. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} [offtopic]
On Thursday 24 January 2008, Vincent Torri wrote:
> On Thu, 24 Jan 2008, Mike Frysinger wrote:
> > can you please fix your e-mail/isp/whatever sucks ... this {Spam?} in the
> > subject is ridiculous
>
> Yes, it's ridiculous and no i can't. It's the server of my university
> that add it.
there are plenty of free e-mail services out there without retarded setups.
gmail does pop/imap and transparent forwarding.
> I can tell them that it's ridiculous, if you want.
you should
-mike
signature.asc
Description: This is a digitally signed message part.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} [offtopic]
On Thu, 24 Jan 2008, Mike Frysinger wrote:
> can you please fix your e-mail/isp/whatever sucks ... this {Spam?} in the
> subject is ridiculous
Yes, it's ridiculous and no i can't. It's the server of my university
that add it. I can tell them that it's ridiculous, if you want.
Vincent
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} [offtopic]
can you please fix your e-mail/isp/whatever sucks ... this {Spam?} in the
subject is ridiculous
-mike
signature.asc
Description: This is a digitally signed message part.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E17 under OpenBSD and other goodies.
On Thu, 24 Jan 2008, Carsten Haitzler (The Rasterman) wrote: >> Warnings: >> Four warnings:about "HAVE_STDLIB_H" being redefined. > > i don't know where this comes from, but config.h is included onle once in > Eet_private.h and that is included only once in each .c file. where are the > previous definitions? certainly in jpeglib.h (more precisely in jconfig.h). That header is crappy. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Current status of e_nm
Hello. On Wed, 2008-01-23 at 00:55, Vincent Torri wrote: > > > On Tue, 22 Jan 2008, Stefan Schmidt wrote: >> o Is the initial author, I heard rephorm, still around to share the >> bigger picture behing the code? > > afaik, rephorm is not reading that list anymore. Thanks for the info. So I will relay on the sentences of たll the other devs here when sending patches. regards Stefan Schmidt signature.asc Description: Digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Current status of e_nm
On Tue, 22 Jan 2008, Stefan Schmidt wrote: > o Is the initial author, I heard rephorm, still around to share the > bigger picture behing the code? afaik, rephorm is not reading that list anymore. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Requirements for exiftags in Epsilon?
On Tue, 4 Dec 2007 01:41:39 +0200 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled: > On Dec 4, 2007 12:40 AM, Tilman Sauerbeck <[EMAIL PROTECTED]> wrote: > > Vincent Torri [2007-12-03 23:04]: > > > > > > > > > On Mon, 3 Dec 2007, Gustavo Sverzut Barbieri wrote: > > > > > > > Hi guys, > > > > > > > > We found the root of those "unaligned loads", it was in canon.c > > > > (http://www.enlightenment.org/viewvc/e17/libs/epsilon/src/lib/exiftags/canon.c?hideattic=1&r1=1.2&r2=1.3), > > > > with a patch tilman applied in order to reduce relocations due lots of > > > > strings requiring it at load time. > > > > > > > > The problem, according to a Red Hat gcc compiler engineer friend of > > > > mine, is that that construction is not valid according to 6.7.2.1/18 > > > > of C99-TC2 and GCC should not allow that, so it's both a bug with GCC > > > > and canon.c. > > > > > > > > canon.c could be fixed and still do few relocations by using one huge > > > > string with \0 as separators and place pointers to segments of this > > > > string on the struct. But it's a pain to do. > > > > > > > > So, I'd like to ask those who are using this exiftags support from > > > > Epsilon. I really don't think this should be in epsilon anyway... the > > > > only use of it in CVS is at esmart_thumb... and it's about > > > > orientation, which is a standard tag... So I request permission to > > > > remove all this exiftags stuff, if required I can add the code to find > > > > out orientation support and generate already rotated images later. > > > > This should make things a lot simpler, smaller and faster to start. > > > > > > > > comments? may I remove? > > > > > > I have contacted tilman on irc. No answer from him yet, but if you can > > > wait some hours, or a day, so that he can answer > > > > I don't use exiftags. Simply ripping out the code and throwing it away > > doens't sound right though. > > I'm trying to find someone using it and which usage. To me it looks > more like old code lying around, if one wants to use exif, libexif > might be a wiser choice (upstream supported, etc). this could be an option as well. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: apps/e jeffdameth
On Tuesday, 08 January 2008, at 17:45:56 (-0200), Gustavo Sverzut Barbieri wrote: > I really dislike using more than 80cols, for problems like using > OO-style programming, then just choose another language that doesn't > make you type the stupid long name every time... Hopefully such an absurd statement was made for purposes of humor and not as a serious suggestion Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "Because I want you to understand what my music means to me...and what it means for me to be able to share it with someone." -- Captain Jean-Luc Picard (Patrick Stewart), ST:TNG, "Lessons" - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: apps/e jeffdameth
On Jan 8, 2008 6:17 AM, Ethan Grammatikidis <[EMAIL PROTECTED]> wrote: > > On Mon, 07 Jan 2008 23:21:46 +0100 > Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > > > Kim Woelders schrieb: > > > Michael Jennings wrote: > > > > > >> On Monday, 07 January 2008, at 21:06:04 (+0100), > > >> Kim Woelders wrote: > > >> > > >> > > >>> (and the line length is set to 80 of course :) ). > > >>> > > >> I got into the habit of using 132 instead of 80 because 80 columns > > >> is all too often not enough for readability, particularly when > > >> using lengthier OO-style function naming > > >> (namespace_object_action(OBJECT_CAST(object), ...) -- See how ugly > > >> that wrapped? Ick!), and the vast majority of terminals (including > > >> xterm and Eterm) have 80/132 column toggles built-in, even > > >> key-bindable. > > >> > > >> To me, sticking with an 80-column limit for coding is like using > > >> gcc 2.7.2.3 to compile all your software: it was great 10 years > > >> ago, but we live in a different world now. Even the Linux console > > >> itself can do well beyond 80 columns. :) > > >> > > >> But tabs vs. spaces is far more likely to result in spaghetti code > > >> then setting the column limit. > > >> > > >> Michael > > >> > > >> > > > Yeah, I was just trolling (although the 80 is about the only thing > > > I do care about). We are talking personal preferences here and are > > > most likely never going to agree. You say "when I write code like > > > this I really need very long lines" and to that I will say "then > > > don't write code like that". > > > > > > Somebody(?) should just lay down the rules so it's clear what they > > > are. > > Full ack. > > > > Peter > > I find 80 columns essential for reading docs while working on code, and for > working on one file while referencing one or more others. I keep my ttys and > editors next to my browser window, or roll up the browser window for multiple > files. I can't work any other way. ;) > > As for tabs v spaces - ugh, don't get me started, lol! +1 ACK! I really dislike using more than 80cols, for problems like using OO-style programming, then just choose another language that doesn't make you type the stupid long name every time... -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: apps/e jeffdameth
On Tuesday, 08 January 2008, at 10:33:00 (+0200), Chady Kassouf wrote: > I don't think it's a matter of tabs vs spaces as much as it is about > consistency within the source. You like spaces, someone else likes > tabs, but as long as they're consistent in the source, there's no > big problem, it's when you mix them together that it starts to > become messy. This is actually a very common misconception. Due to certain techniques of indentation, particularly those that align content on a particular line with something on the previous line, use of spaces is essentially unavoidable. Thus, in 99.9% of cases there will be a mixture if tabs are used at all. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "Nowadays they say you need a special chip to put in the TV so kids can't watch this and that. In my day, we didn't need a chip. My mom was the chip. End of story." -- Ray Charles - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: apps/e jeffdameth
On Jan 8, 2008 10:17 AM, Ethan Grammatikidis <[EMAIL PROTECTED]> wrote: > [snip] > > I find 80 columns essential for reading docs while working on code, and > for working on one file while referencing one or more others. I keep my ttys > and editors next to my browser window, or roll up the browser window for > multiple files. I can't work any other way. ;) > > As for tabs v spaces - ugh, don't get me started, lol! > > > I don't think it's a matter of tabs vs spaces as much as it is about consistency within the source. You like spaces, someone else likes tabs, but as long as they're consistent in the source, there's no big problem, it's when you mix them together that it starts to become messy. -- Chady 'Leviathan' Kassouf http://chady.net/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: apps/e jeffdameth
On Mon, 07 Jan 2008 23:21:46 +0100 Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > Kim Woelders schrieb: > > Michael Jennings wrote: > > > >> On Monday, 07 January 2008, at 21:06:04 (+0100), > >> Kim Woelders wrote: > >> > >> > >>> (and the line length is set to 80 of course :) ). > >>> > >> I got into the habit of using 132 instead of 80 because 80 columns > >> is all too often not enough for readability, particularly when > >> using lengthier OO-style function naming > >> (namespace_object_action(OBJECT_CAST(object), ...) -- See how ugly > >> that wrapped? Ick!), and the vast majority of terminals (including > >> xterm and Eterm) have 80/132 column toggles built-in, even > >> key-bindable. > >> > >> To me, sticking with an 80-column limit for coding is like using > >> gcc 2.7.2.3 to compile all your software: it was great 10 years > >> ago, but we live in a different world now. Even the Linux console > >> itself can do well beyond 80 columns. :) > >> > >> But tabs vs. spaces is far more likely to result in spaghetti code > >> then setting the column limit. > >> > >> Michael > >> > >> > > Yeah, I was just trolling (although the 80 is about the only thing > > I do care about). We are talking personal preferences here and are > > most likely never going to agree. You say "when I write code like > > this I really need very long lines" and to that I will say "then > > don't write code like that". > > > > Somebody(?) should just lay down the rules so it's clear what they > > are. > Full ack. > > Peter I find 80 columns essential for reading docs while working on code, and for working on one file while referencing one or more others. I keep my ttys and editors next to my browser window, or roll up the browser window for multiple files. I can't work any other way. ;) As for tabs v spaces - ugh, don't get me started, lol! - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: apps/e jeffdameth
Kim Woelders schrieb: > Michael Jennings wrote: > >> On Monday, 07 January 2008, at 21:06:04 (+0100), >> Kim Woelders wrote: >> >> >>> (and the line length is set to 80 of course :) ). >>> >> I got into the habit of using 132 instead of 80 because 80 columns is >> all too often not enough for readability, particularly when using >> lengthier OO-style function naming >> (namespace_object_action(OBJECT_CAST(object), ...) -- See how ugly >> that wrapped? Ick!), and the vast majority of terminals (including >> xterm and Eterm) have 80/132 column toggles built-in, even >> key-bindable. >> >> To me, sticking with an 80-column limit for coding is like using gcc >> 2.7.2.3 to compile all your software: it was great 10 years ago, but >> we live in a different world now. Even the Linux console itself can >> do well beyond 80 columns. :) >> >> But tabs vs. spaces is far more likely to result in spaghetti code >> then setting the column limit. >> >> Michael >> >> > Yeah, I was just trolling (although the 80 is about the only thing I do > care about). We are talking personal preferences here and are most > likely never going to agree. You say "when I write code like this I > really need very long lines" and to that I will say "then don't write > code like that". > > Somebody(?) should just lay down the rules so it's clear what they are. > Full ack. Peter - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: apps/e jeffdameth
Michael Jennings wrote: > On Monday, 07 January 2008, at 21:06:04 (+0100), > Kim Woelders wrote: > >> (and the line length is set to 80 of course :) ). > > I got into the habit of using 132 instead of 80 because 80 columns is > all too often not enough for readability, particularly when using > lengthier OO-style function naming > (namespace_object_action(OBJECT_CAST(object), ...) -- See how ugly > that wrapped? Ick!), and the vast majority of terminals (including > xterm and Eterm) have 80/132 column toggles built-in, even > key-bindable. > > To me, sticking with an 80-column limit for coding is like using gcc > 2.7.2.3 to compile all your software: it was great 10 years ago, but > we live in a different world now. Even the Linux console itself can > do well beyond 80 columns. :) > > But tabs vs. spaces is far more likely to result in spaghetti code > then setting the column limit. > > Michael > Yeah, I was just trolling (although the 80 is about the only thing I do care about). We are talking personal preferences here and are most likely never going to agree. You say "when I write code like this I really need very long lines" and to that I will say "then don't write code like that". Somebody(?) should just lay down the rules so it's clear what they are. /Kim - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: apps/e jeffdameth
On Monday, 07 January 2008, at 21:06:04 (+0100), Kim Woelders wrote: > (and the line length is set to 80 of course :) ). I got into the habit of using 132 instead of 80 because 80 columns is all too often not enough for readability, particularly when using lengthier OO-style function naming (namespace_object_action(OBJECT_CAST(object), ...) -- See how ugly that wrapped? Ick!), and the vast majority of terminals (including xterm and Eterm) have 80/132 column toggles built-in, even key-bindable. To me, sticking with an 80-column limit for coding is like using gcc 2.7.2.3 to compile all your software: it was great 10 years ago, but we live in a different world now. Even the Linux console itself can do well beyond 80 columns. :) But tabs vs. spaces is far more likely to result in spaghetti code then setting the column limit. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "A leader takes people where they want to go. A great leader takes people where they don't necessarily want to go, but ought to be." -- Rosalynn Carter - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: apps/e jeffdameth
Vincent Torri wrote: > > On Mon, 7 Jan 2008, Kim Woelders wrote: >> I put that file there at a point where I got annoyed with the formatting >> style mess in imlib2. The formatting style details, among other things >> tabs/spaces, were set up in an attempt to minimize the overall change >> caused by running indent on src/lib/*.c at that time. IIRC using spaces >> in stead of tabs resulted in slightly fewer changes. >> >> Actually, I think the "original raster formatting style" is closer to >> the one in e16/e/.indent.pro, which specifies to use tabs. >> >> I think it would be a good thing to specify a recommended/default indent >> profile, and require that apps/libs explicitly place a .indent.pro at >> top level if they want to deviate. > > about tabs vs spaces, I would prefer spaces. We all have different text > editors, configured in some ways. Not mentionning all other people that do > not develop on e and want to see the sources. That imply that a source > code using tabs will look horrible to the reader if the text editor is not > configured with the correct number of spaces for a tabulation. > > other thoughts ? > I prefer spaces too, although I don't care much one way or the other, as long as the rules are clear (and the line length is set to 80 of course :) ). /Kim - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: apps/e jeffdameth
On Mon, 7 Jan 2008, Kim Woelders wrote: > I put that file there at a point where I got annoyed with the formatting > style mess in imlib2. The formatting style details, among other things > tabs/spaces, were set up in an attempt to minimize the overall change > caused by running indent on src/lib/*.c at that time. IIRC using spaces > in stead of tabs resulted in slightly fewer changes. > > Actually, I think the "original raster formatting style" is closer to > the one in e16/e/.indent.pro, which specifies to use tabs. > > I think it would be a good thing to specify a recommended/default indent > profile, and require that apps/libs explicitly place a .indent.pro at > top level if they want to deviate. about tabs vs spaces, I would prefer spaces. We all have different text editors, configured in some ways. Not mentionning all other people that do not develop on e and want to see the sources. That imply that a source code using tabs will look horrible to the reader if the text editor is not configured with the correct number of spaces for a tabulation. other thoughts ? Vincent - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: ecore_x_pointer_xy_get_prefetch
Vincent Torri wrote: --snip-- >> WTH !!! >> >> Who broke ecore_x ?? > > me > >> This also effects ecore_x_default_screen_get. >> These functions are not specific to ecore_xcb, but rather are generic >> ecore_x functions, so this needs to be fixed like NOW > > that kind of functions are used only for xcb Really? then why have a ecore_x convenience function for getting the current display ? IMO, this is a nice function to have for people that don't know much about X programming, but wanna make use of ecore_x. (well, for > ecore_x_default_screen, i can add it for Xlib too, even if it is really > needed for XCB as it is not stored at all, contrary to Xlib which stores > the default screen in the Display structure), Regardless if Xlib stores it or not, the point of having something like ecore_x is to make it easy for people to code apps using X. as mentioned in the > documentation. So, except me (I don't think that someone else is using > ecore with xcb), nobody should use those files. > > I *know* that i need to add them for the Xlib backend. > --snip-- > > Vincent > dh - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: ecore_x_pointer_xy_get_prefetch
I lost track of that thread, I'll make a point to check the archive and get back to you this weekend. On Dec 29, 2007 12:15 PM, Vincent Torri <[EMAIL PROTECTED]> wrote: > > > On Sat, 29 Dec 2007, Christopher Michael wrote: > > > Hisham Mardam Bey wrote: > >> ~/code/e17/libs/ecore/src/lib/ecore_x > >> > >> .oOo. grep prefetch *.[ch] | grep xy > >> > >> ecore_xcb_window.c:ecore_x_pointer_xy_get_prefetch(Ecore_X_Window window) > >> Ecore_X.h:EAPI void ecore_x_pointer_xy_get_prefetch(Ecore_X_Window window); > >> > >> Which effectively places it in Ecore_X.h without having stubs for it > >> in the C files. People that try to use it will get compile time > >> errors: > >> > >> /tmp/ccwsbRaX.o: In function `_eg_grab_region_start': > >> egrab.c:(.text+0x426): undefined reference to > >> `ecore_x_pointer_xy_get_prefetch' > >> collect2: ld returned 1 exit status > >> > >> This needs to be fixed, pronto. > >> > > > > WTH !!! > > > > Who broke ecore_x ?? > > me > > > This also effects ecore_x_default_screen_get. > > These functions are not specific to ecore_xcb, but rather are generic > > ecore_x functions, so this needs to be fixed like NOW > > that kind of functions are used only for xcb (well, for > ecore_x_default_screen, i can add it for Xlib too, even if it is really > needed for XCB as it is not stored at all, contrary to Xlib which stores > the default screen in the Display structure), as mentioned in the > documentation. So, except me (I don't think that someone else is using > ecore with xcb), nobody should use those files. > > I *know* that i need to add them for the Xlib backend. > > BUT > > ecore_xcb is not perfect. I've sent several mails about that and i am > waiting for some people to answer them (that is, mainly, raster, Nathan > and maybe rephorm, but he does not read the e-dev ML anymore, iirc. > Other people can comment too, of course). > > "fixing" all those files is VERY long. I don't want to do some work once, > and see that I need to modify all that changes again (i've already written > ecore_xcb at least 3 times). > > So, one solution would be to disable ecore_xcb at all, and use some > #define in Ecore_X.h around xcb-specific functions (or removing them) > > comments ? > > Vincent > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: ecore_x_pointer_xy_get_prefetch
On Sat, 29 Dec 2007, Christopher Michael wrote: > Hisham Mardam Bey wrote: >> ~/code/e17/libs/ecore/src/lib/ecore_x >> >> .oOo. grep prefetch *.[ch] | grep xy >> >> ecore_xcb_window.c:ecore_x_pointer_xy_get_prefetch(Ecore_X_Window window) >> Ecore_X.h:EAPI void ecore_x_pointer_xy_get_prefetch(Ecore_X_Window window); >> >> Which effectively places it in Ecore_X.h without having stubs for it >> in the C files. People that try to use it will get compile time >> errors: >> >> /tmp/ccwsbRaX.o: In function `_eg_grab_region_start': >> egrab.c:(.text+0x426): undefined reference to >> `ecore_x_pointer_xy_get_prefetch' >> collect2: ld returned 1 exit status >> >> This needs to be fixed, pronto. >> > > WTH !!! > > Who broke ecore_x ?? me > This also effects ecore_x_default_screen_get. > These functions are not specific to ecore_xcb, but rather are generic > ecore_x functions, so this needs to be fixed like NOW that kind of functions are used only for xcb (well, for ecore_x_default_screen, i can add it for Xlib too, even if it is really needed for XCB as it is not stored at all, contrary to Xlib which stores the default screen in the Display structure), as mentioned in the documentation. So, except me (I don't think that someone else is using ecore with xcb), nobody should use those files. I *know* that i need to add them for the Xlib backend. BUT ecore_xcb is not perfect. I've sent several mails about that and i am waiting for some people to answer them (that is, mainly, raster, Nathan and maybe rephorm, but he does not read the e-dev ML anymore, iirc. Other people can comment too, of course). "fixing" all those files is VERY long. I don't want to do some work once, and see that I need to modify all that changes again (i've already written ecore_xcb at least 3 times). So, one solution would be to disable ecore_xcb at all, and use some #define in Ecore_X.h around xcb-specific functions (or removing them) comments ? Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Starting
sorry, the CVS above is for if you have a ssh key... to anonymous CVS:
cvs -z3 -d :pserver:[EMAIL PROTECTED]:/var/cvs/e co e17
--
Kak Kan: Level Up!
--
<< || 11 | 01 | 07 || >>
EPISODIO 3 LANCADO! - Luna F; Parte2
:: :: CyberEnvironment :: ::
}]| www.mdkcore.da.ru |[{
--
2, 3, 4, 5, 6, 7, 8 and back
2, 3, 4, 5, 6, 7, get back
2, 3, 4, 5, 6, 7, 8 and back
2, 3, 4, 5, 6, 7, cat CAT
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Starting
And to get the e17 source you can visit this address:
[ http://www.enlightenment.org/p.php?p=contribute&l=en ]
or, using CVS difectly:
export CVS_RSH=ssh
cvs -z3 -d [EMAIL PROTECTED]:/cvs/e co e17
Abraços, XD
--
Kak Kan: Level Up!
--
<< || 11 | 01 | 07 || >>
EPISODIO 3 LANCADO! - Luna F; Parte2
:: :: CyberEnvironment :: ::
}]| www.mdkcore.da.ru |[{
--
2, 3, 4, 5, 6, 7, 8 and back
2, 3, 4, 5, 6, 7, get back
2, 3, 4, 5, 6, 7, 8 and back
2, 3, 4, 5, 6, 7, cat CAT
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Starting
Hey, > I think in start making themes and packages (.deb, .rpm, .tgz). > I would like to know, how to animateds wallpapers and animateds icons? Exist > a manual for this things? How to use etk, ewl, edje, for criate theme's > elements? You can look at some documentation here: http://web.enlightenment.org/p.php?p=docs&l=en The documentation here is maybe not up to date. There's also a wiki here: http://wiki.enlightenment.org/index.php/Main_Page especially the edje articles A good start would be to look at the animated wallpapers at http://www.get-e.org/ and get the edc and look inside it, to see how it is made. regards Vincent - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Requirements for exiftags in Epsilon?
On Dec 4, 2007 12:40 AM, Tilman Sauerbeck <[EMAIL PROTECTED]> wrote: > Vincent Torri [2007-12-03 23:04]: > > > > > > On Mon, 3 Dec 2007, Gustavo Sverzut Barbieri wrote: > > > > > Hi guys, > > > > > > We found the root of those "unaligned loads", it was in canon.c > > > (http://www.enlightenment.org/viewvc/e17/libs/epsilon/src/lib/exiftags/canon.c?hideattic=1&r1=1.2&r2=1.3), > > > with a patch tilman applied in order to reduce relocations due lots of > > > strings requiring it at load time. > > > > > > The problem, according to a Red Hat gcc compiler engineer friend of > > > mine, is that that construction is not valid according to 6.7.2.1/18 > > > of C99-TC2 and GCC should not allow that, so it's both a bug with GCC > > > and canon.c. > > > > > > canon.c could be fixed and still do few relocations by using one huge > > > string with \0 as separators and place pointers to segments of this > > > string on the struct. But it's a pain to do. > > > > > > So, I'd like to ask those who are using this exiftags support from > > > Epsilon. I really don't think this should be in epsilon anyway... the > > > only use of it in CVS is at esmart_thumb... and it's about > > > orientation, which is a standard tag... So I request permission to > > > remove all this exiftags stuff, if required I can add the code to find > > > out orientation support and generate already rotated images later. > > > This should make things a lot simpler, smaller and faster to start. > > > > > > comments? may I remove? > > > > I have contacted tilman on irc. No answer from him yet, but if you can > > wait some hours, or a day, so that he can answer > > I don't use exiftags. Simply ripping out the code and throwing it away > doens't sound right though. I'm trying to find someone using it and which usage. To me it looks more like old code lying around, if one wants to use exif, libexif might be a wiser choice (upstream supported, etc). -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Requirements for exiftags in Epsilon?
Vincent Torri [2007-12-03 23:04]: > > > On Mon, 3 Dec 2007, Gustavo Sverzut Barbieri wrote: > > > Hi guys, > > > > We found the root of those "unaligned loads", it was in canon.c > > (http://www.enlightenment.org/viewvc/e17/libs/epsilon/src/lib/exiftags/canon.c?hideattic=1&r1=1.2&r2=1.3), > > with a patch tilman applied in order to reduce relocations due lots of > > strings requiring it at load time. > > > > The problem, according to a Red Hat gcc compiler engineer friend of > > mine, is that that construction is not valid according to 6.7.2.1/18 > > of C99-TC2 and GCC should not allow that, so it's both a bug with GCC > > and canon.c. > > > > canon.c could be fixed and still do few relocations by using one huge > > string with \0 as separators and place pointers to segments of this > > string on the struct. But it's a pain to do. > > > > So, I'd like to ask those who are using this exiftags support from > > Epsilon. I really don't think this should be in epsilon anyway... the > > only use of it in CVS is at esmart_thumb... and it's about > > orientation, which is a standard tag... So I request permission to > > remove all this exiftags stuff, if required I can add the code to find > > out orientation support and generate already rotated images later. > > This should make things a lot simpler, smaller and faster to start. > > > > comments? may I remove? > > I have contacted tilman on irc. No answer from him yet, but if you can > wait some hours, or a day, so that he can answer I don't use exiftags. Simply ripping out the code and throwing it away doens't sound right though. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgpd5yR3z0LcG.pgp Description: PGP signature - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Requirements for exiftags in Epsilon?
On Mon, 3 Dec 2007, Gustavo Sverzut Barbieri wrote: > Hi guys, > > We found the root of those "unaligned loads", it was in canon.c > (http://www.enlightenment.org/viewvc/e17/libs/epsilon/src/lib/exiftags/canon.c?hideattic=1&r1=1.2&r2=1.3), > with a patch tilman applied in order to reduce relocations due lots of > strings requiring it at load time. > > The problem, according to a Red Hat gcc compiler engineer friend of > mine, is that that construction is not valid according to 6.7.2.1/18 > of C99-TC2 and GCC should not allow that, so it's both a bug with GCC > and canon.c. > > canon.c could be fixed and still do few relocations by using one huge > string with \0 as separators and place pointers to segments of this > string on the struct. But it's a pain to do. > > So, I'd like to ask those who are using this exiftags support from > Epsilon. I really don't think this should be in epsilon anyway... the > only use of it in CVS is at esmart_thumb... and it's about > orientation, which is a standard tag... So I request permission to > remove all this exiftags stuff, if required I can add the code to find > out orientation support and generate already rotated images later. > This should make things a lot simpler, smaller and faster to start. > > comments? may I remove? I have contacted tilman on irc. No answer from him yet, but if you can wait some hours, or a day, so that he can answer regards Vincent - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Nightly build log for E17 on 2007-11-22 17:22:57 -0800
On Fri, 23 Nov 2007, Toma wrote: >> From ewl.log > > edje_cc -v -id ../../../data/themes/e17/images -fd > ../../../data/themes/e17 ../../../data/themes/e17/e17.edc > ../../../data/themes/e17/e17.edj > edje_cc: Error. unable to open "../../../data/themes/e17/e17.edj" for > writing output > >> From there ewl returns error 2 and doesnt install, making all apps > that depend on it fail. > Is e17.edj in the build dir already? Does it have weird permissions? > Or has something fishy happened to the makefile? > -Toma the problems seems to be the option -j2 that is added to 'make'. I've already reported that. It seems that noone changed the script. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Trac? (milestone/todo list visibility)
Do you think it is good to let people the **possibility** to fill bugs and patches in 2 locations ? And as trac is on the main page, and not bugzilla, people (users, not developpers) who want to report bugs and patches will do it in trac, not bugzilla. If you don't like bugzilla for some kind of resons (reasons that I understand), you can also understand that some devs do not want to have to look at 2 locations to see if bugs and patches are reported. If Trac is not intended to replace bugzilla, I would suggest: 1) to put bugzilla on the main page of enlightenment web site. Currently, to find him, you have to look at all the web page and see a small notice about it. 2) to put a big fat warning on the main trac page to say : bugs and patches must be reported in bugzilla only, todo item are in Trac only. What do you think ? Vincent On Fri, 16 Nov 2007, Carsten Haitzler (The Rasterman) wrote: On Thu, 15 Nov 2007 09:40:53 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled: *blah blah - lots of emails - reply to all* i set up track for project timeline/status/completion tracking - ti deos things bugzilla doesn't. 1. it doesn't piss me off so much that i might actually use it. 2. it is not meant to replace bugzilla 3. this is the age of the internet - put in links to buzilla items if they are relevant on a TODO 4. it was intended for handling the TODO file in e. people still ask "what is there to do? how can i help? what's the status?". trac provides a roadmap with a nice nice nice nice summary per project - items to do, items done. a percentage bar. it's simple. 5. i don't intend to use trac for svn. it's just hanging about 6. the wiki is only there for documenting the todo items and providing some central hook to get to them all - nothing else. trac's wiki is too limited for much moe 7. did i mention - this is the a web page. we can use things like links back to the "real' wiki etc.? 8. bugzilla may be working for ewl - great! fantastic! keep using it. it isn't working for me for e - and the TODO file has been in cvs and still is there and is only being updated there. i waned to move it more into a public space. trac seemed to fit the bill. i set it up. 9. bugzilla annoys me to hell - every time i do use it it encouages me to run away and spend as long as possible away from it until i get back. just somehtng simple like "list all bugs open for E17" or just "all bugs open" i can't do. i select "open" and "17" in bugs search but then i need to put in words - i dont wan to search. i want a LIST. come on bugzilla. how hard is it to just list the bugs! so instead i have to spend time int he advanced search fiddling with a bunch of things to create a saved search simply to list the bugs... sure then i can go create a bunch - go share them and people can track progress based on how long the list of bugs are for some saved search they have to go find and select. it just annoys me that the simpl things have to be so complex. providing a simple public status and a simple like like: top priority: * do a * create b * fix c nice to have: * do x * delete y * re-color z etc. doesn't exist with bugzilla. bugzilla also looks ugly :( filing a bug (or for a simple task/todo item) is quite an exercise in filling out forms. there is no ability to do any nice formatting (text only - though i don't mind much, trac does handle this nicely) etc. etc. if you want to use bugzilla as a way of putting down a request or todo item then using bugzilla to also discuss and refine it - draw nice diagrams, tables, etc. etc. it will get ugly. trac seems to lend itself to this much better. as i said - do NOT STOP USING BUGZILLA. i want to use trac for tracking TODO items for E - they are NOT being tracked in bugzilla. i want to have the TODO list for e much more visible. let people directly comment on it and maybe provide ideas or shortcuts etc. some TODO items are very fuzzy and need more solidification. trac seems to be a good tool for that. On Nov 15, 2007 5:40 AM, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: So I set up Trac: http://trac.enlightenment.org/e As per the news: http://www.enlightenment.org/p.php?p=news/show&l=en&news_id=6 it's intended for project tracking. tracking our TODO items, etc. etc. it seems it's only me that likes TODO in CVS. no one else except a few core devs even knows its there. so i am thinking that we use trac to put up the TODO items and file tickets for them - then we can track what is to be done, even have discussions on each item - draw up wiki-like documents on them, find out who is doing them etc. etc. it even provides a NICE wishlist system. it's friendlier than bugzilla, but not as powerful. Ok, I really like trac, but keeping both doesn't solve the previous problem of people not using bugzilla, instead it create another point of replication. I also like bugzilla completeness, but unless we'll create hierarchical bug dependenci
Re: [E-devel] {Spam?} Re: Trac? (milestone/todo list visibility)
On Thu, 15 Nov 2007 14:32:52 +0100 Massimiliano Calamelli <[EMAIL PROTECTED]> babbled: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thu, 15 Nov 2007 06:28:15 -0600 > Nick Hughart <[EMAIL PROTECTED]> wrote: > > > Anyone opposed to something like Google Calendar to figure out the best > > meeting times? It is nice because it allows you to overlay other's > > calendars on top of your own so we can find the holes. This may be more > > then some people are willing to do, but it will be hard to schedule any > > type of meeting without knowing when people will be available. > > Dunno if useful in this way, but http://www.doodle.ch is interesting looks interesting - except i dont see support for multiple timezones or being able to shift a schedule around (suggest a new time) : ( > My 2 cents > > Massimiliano > - -- > Massimiliano Calamelli > http://mcalamelli.netsons.org > [EMAIL PROTECTED] > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.4 (MingW32) > > iD8DBQFHPEqHleGEL56NNP4RAveoAKDP/sjMHPOT3p5NB0IOpPJXAHBtXwCgnJ1l > ttNQYVUPiL4r/3tx7H34Cak= > =TD+i > -END PGP SIGNATURE- > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Trac? (milestone/todo list visibility)
On Nov 15, 2007 2:46 PM, Koen Kooi <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Nick Hughart schreef: > > This was not meant to turn into a big deal. Trac is up there, no one is > > forcing you to use it yet. > > Since there are now patches in there, people *are* forced to use it if > they want to avoid getting yelled for ignoring patches... Ok, i have to speak because the patch in trac is mine (don't know if there are others). As i said on irc, that patch was to test trac functionality (attaching files), the patch is an old an unused one, it was posted by myself about 6 months ago to the ml and it didnt get applied, so as far as i understand this "there are patches on trac right now" is out of scope because of the above mentioned. Even so i have to agree that having both systems is a waste of effort for developers and users, even if they are split and we only use trac for some task and bugzilla for other. turran. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (Darwin) > > iD8DBQFHPE2lMkyGM64RGpERAux1AKCzwss8kgiNCJ+eX1Bd/GF7GrEn6ACeLn54 > 4yFoq3Ex41A4EtKjrH7IXB0= > =db52 > -END PGP SIGNATURE- > > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Trac? (milestone/todo list visibility)
On Thursday 15 November 2007 13:15:07 Nick Hughart wrote: > Before any decision like this can be made, a meeting should take place > to discuss it along with some of the other heated issues that have been > currently discussed on the mailing list. If someone knows of a good way > to find out when most people are available it would be nice. We should > have as many people as possible since this is a pretty big deal for most > people. For a first meeting, discussing the model for futur development and the tool we will use, seems to be the best topic to start from. It should not be only a discussion, but lead us to some important decision. But before everyone start adding it's name to this list and flood the ML. We could perhaps just use a page on the wiki. And every one interested by this meeting could put his name on the page with his time zone and the prefered time (GMT) for a meeting. Cedric - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Trac? (milestone/todo list visibility)
Which wiki would that be now? There is the existing one and now the one in trac. On 11/15/07, Cedric BAIL <[EMAIL PROTECTED]> wrote: > On Thursday 15 November 2007 13:15:07 Nick Hughart wrote: > > Before any decision like this can be made, a meeting should take place > > to discuss it along with some of the other heated issues that have been > > currently discussed on the mailing list. If someone knows of a good way > > to find out when most people are available it would be nice. We should > > have as many people as possible since this is a pretty big deal for most > > people. > > For a first meeting, discussing the model for futur development and the tool > we will use, seems to be the best topic to start from. It should not be only > a discussion, but lead us to some important decision. > But before everyone start adding it's name to this list and flood the > ML. We > could perhaps just use a page on the wiki. And every one interested by this > meeting could put his name on the page with his time zone and the prefered > time (GMT) for a meeting. > > Cedric > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Trac? (milestone/todo list visibility)
The fact that trac has been added as a link on the main title bar makes it seem pretty official. It also means that anyone coming to the site will use trac instead of bugzilla which isn't on the main titlebar. dan Nick Hughart wrote: > This was not meant to turn into a big deal. Trac is up there, no one is > forcing you to use it yet. Quit acting like a bunch of whiny children. > It is up there for people to play with and people have already expressed > that they like Trac. Personally I find Bugzilla painful to use and > others have agreed with me there. Is Trac the best? probably not. Is > it going to replace Bugzilla? that is yet to be determined. There is > nothing set in stone and we will not be maintaining two separate > trackers as that is just a nightmare, which you so obviously pointed out. > > Before any decision like this can be made, a meeting should take place > to discuss it along with some of the other heated issues that have been > currently discussed on the mailing list. If someone knows of a good way > to find out when most people are available it would be nice. We should > have as many people as possible since this is a pretty big deal for most > people. > > In the meantime, chill out, we are not trying to screw anything up or > kill off your beloved Bugzilla. We are just testing the waters, seeing > what Trac is capable of, and seeing if the community as a whole enjoys > it more. If in the end it's no better, then we will most likely stick > to Bugzilla given it is already in place and has all the bugs in it. > > Vincent Torri wrote: >> On Thu, 15 Nov 2007, Gustavo Sverzut Barbieri wrote: >> >> >>> On Nov 15, 2007 5:40 AM, The Rasterman Carsten Haitzler >>> >> >> it even provides a NICE wishlist system. it's friendlier than bugzilla, but not as powerful. >>> Ok, I really like trac, but keeping both doesn't solve the previous >>> problem of people not using bugzilla, instead it create another point >>> of replication. >>> >> >> There is already one (maybe more) patch in trac. So we now have to look at >> two locations for patches. >> >> I don't see any problem to have trac storing TODO and such, but, imho, >> patches should only go to bugzilla (if we keep trac and buzilla) >> >> so now, we have mails + bugzilla + trac >> >> Vincent >> >> - >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Trac? (milestone/todo list visibility)
This was not meant to turn into a big deal. Trac is up there, no one is forcing you to use it yet. Quit acting like a bunch of whiny children. It is up there for people to play with and people have already expressed that they like Trac. Personally I find Bugzilla painful to use and others have agreed with me there. Is Trac the best? probably not. Is it going to replace Bugzilla? that is yet to be determined. There is nothing set in stone and we will not be maintaining two separate trackers as that is just a nightmare, which you so obviously pointed out. Before any decision like this can be made, a meeting should take place to discuss it along with some of the other heated issues that have been currently discussed on the mailing list. If someone knows of a good way to find out when most people are available it would be nice. We should have as many people as possible since this is a pretty big deal for most people. In the meantime, chill out, we are not trying to screw anything up or kill off your beloved Bugzilla. We are just testing the waters, seeing what Trac is capable of, and seeing if the community as a whole enjoys it more. If in the end it's no better, then we will most likely stick to Bugzilla given it is already in place and has all the bugs in it. Vincent Torri wrote: > On Thu, 15 Nov 2007, Gustavo Sverzut Barbieri wrote: > > >> On Nov 15, 2007 5:40 AM, The Rasterman Carsten Haitzler >> > > >>> it even provides a NICE wishlist system. it's friendlier than bugzilla, but >>> not >>> as powerful. >>> >> Ok, I really like trac, but keeping both doesn't solve the previous >> problem of people not using bugzilla, instead it create another point >> of replication. >> > > There is already one (maybe more) patch in trac. So we now have to look at > two locations for patches. > > I don't see any problem to have trac storing TODO and such, but, imho, > patches should only go to bugzilla (if we keep trac and buzilla) > > so now, we have mails + bugzilla + trac > > Vincent > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Trac? (milestone/todo list visibility)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick Hughart schreef: > This was not meant to turn into a big deal. Trac is up there, no one is > forcing you to use it yet. Since there are now patches in there, people *are* forced to use it if they want to avoid getting yelled for ignoring patches... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHPE2lMkyGM64RGpERAux1AKCzwss8kgiNCJ+eX1Bd/GF7GrEn6ACeLn54 4yFoq3Ex41A4EtKjrH7IXB0= =db52 -END PGP SIGNATURE- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Trac? (milestone/todo list visibility)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 15 Nov 2007 06:28:15 -0600 Nick Hughart <[EMAIL PROTECTED]> wrote: > Anyone opposed to something like Google Calendar to figure out the best > meeting times? It is nice because it allows you to overlay other's > calendars on top of your own so we can find the holes. This may be more > then some people are willing to do, but it will be hard to schedule any > type of meeting without knowing when people will be available. Dunno if useful in this way, but http://www.doodle.ch is interesting My 2 cents Massimiliano - -- Massimiliano Calamelli http://mcalamelli.netsons.org [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (MingW32) iD8DBQFHPEqHleGEL56NNP4RAveoAKDP/sjMHPOT3p5NB0IOpPJXAHBtXwCgnJ1l ttNQYVUPiL4r/3tx7H34Cak= =TD+i -END PGP SIGNATURE- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Trac? (milestone/todo list visibility)
Anyone opposed to something like Google Calendar to figure out the best meeting times? It is nice because it allows you to overlay other's calendars on top of your own so we can find the holes. This may be more then some people are willing to do, but it will be hard to schedule any type of meeting without knowing when people will be available. Nick Hughart wrote: > This was not meant to turn into a big deal. Trac is up there, no one is > forcing you to use it yet. Quit acting like a bunch of whiny children. > It is up there for people to play with and people have already expressed > that they like Trac. Personally I find Bugzilla painful to use and > others have agreed with me there. Is Trac the best? probably not. Is > it going to replace Bugzilla? that is yet to be determined. There is > nothing set in stone and we will not be maintaining two separate > trackers as that is just a nightmare, which you so obviously pointed out. > > Before any decision like this can be made, a meeting should take place > to discuss it along with some of the other heated issues that have been > currently discussed on the mailing list. If someone knows of a good way > to find out when most people are available it would be nice. We should > have as many people as possible since this is a pretty big deal for most > people. > > In the meantime, chill out, we are not trying to screw anything up or > kill off your beloved Bugzilla. We are just testing the waters, seeing > what Trac is capable of, and seeing if the community as a whole enjoys > it more. If in the end it's no better, then we will most likely stick > to Bugzilla given it is already in place and has all the bugs in it. > > Vincent Torri wrote: > >> On Thu, 15 Nov 2007, Gustavo Sverzut Barbieri wrote: >> >> >> >>> On Nov 15, 2007 5:40 AM, The Rasterman Carsten Haitzler >>> >>> >> >> it even provides a NICE wishlist system. it's friendlier than bugzilla, but not as powerful. >>> Ok, I really like trac, but keeping both doesn't solve the previous >>> problem of people not using bugzilla, instead it create another point >>> of replication. >>> >>> >> There is already one (maybe more) patch in trac. So we now have to look at >> two locations for patches. >> >> I don't see any problem to have trac storing TODO and such, but, imho, >> patches should only go to bugzilla (if we keep trac and buzilla) >> >> so now, we have mails + bugzilla + trac >> >> Vincent >> >> - >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> >> > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Trac? (milestone/todo list visibility)
On Thu, 15 Nov 2007, Gustavo Sverzut Barbieri wrote: > On Nov 15, 2007 5:40 AM, The Rasterman Carsten Haitzler >> it even provides a NICE wishlist system. it's friendlier than bugzilla, but >> not >> as powerful. > > > Ok, I really like trac, but keeping both doesn't solve the previous > problem of people not using bugzilla, instead it create another point > of replication. There is already one (maybe more) patch in trac. So we now have to look at two locations for patches. I don't see any problem to have trac storing TODO and such, but, imho, patches should only go to bugzilla (if we keep trac and buzilla) so now, we have mails + bugzilla + trac Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} News from the E stables
On Tue, 13 Nov 2007 16:05:55 +1100, Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote : > On Tue, 6 Nov 2007 19:07:00 +0100 (CET) Vincent Torri > <[EMAIL PROTECTED]> babbled: > > > --snip-- > > > > I was just wondering if it was the right time to start a new theme, > > which is a big big work. > > it is a big work, but the old one just was annoying me too much. i > was trying to do graphics for the wizard and it just wasn't looking > nice. everything i tried looked like crap. > I agree, the bling-bling theme doesn't look good at all when there are too many widgets on the same window. Just put more than 3 buttons and the interface will probably look overloaded. Do you have any mockup of the new widget-set? I've seen some shots of the window-borders, but what really is important is to have a coherent and non-intruisive look for the widgets imho. Otherwise, you'll end up with the same problems as with the bling-bling theme. Another possibility would be to use an existing theme. Detour would be a perfect candidate for the job! It is already complete, it has a really good look imo and widgets always look good regardless to the layout. And it will also save you a lot of work. What do you think? (Tokyo would also have to agree on this of course.. :)) MoOM - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: argb lossless codec
On Tue, 13 Nov 2007 08:25:51 +0100 (CET) Vincent Torri <[EMAIL PROTECTED]> babbled: > > > On Tue, 13 Nov 2007, Carsten Haitzler (The Rasterman) wrote: > > > On Tue, 23 Oct 2007 20:08:32 +0200 (CEST) Vincent Torri > > <[EMAIL PROTECTED]> babbled: > > > > finally got to play with it. quite interesting. i tried it on some images i > > have (animated): > > > > [ 1:56PM ~/C/data/demo/e_anim_reflection ] du -sh . > > 1.9M. > > [ 1:55PM ~/e_codec ] ./encode out.erv > > '/home/raster/C/data/demo/e_anim_reflection_big/e_%04d.png' 120 0 > > * file : /home/raster/C/data/demo/e_anim_reflection_big/e_0001.png > > * file : /home/raster/C/data/demo/e_anim_reflection_big/e_0002.png > > ... > > [ 1:56PM ~/e_codec ] ls out.erv > > 4.4M out.erv > > > > double the size :/ :( > > where can I get those png ? in e17_bg_shiny_reflection.edj ? in my homedir. i'll need to wait until i have real internet before uploading. > > we've talked on irc - we can continue there. i think this is great work btw. > > one problem in this is you compress a whole plane at a time. it woudl be > > easier to compress 1 tile at a time (eg a 16x16 tile of the image - split > > into 4 planes of 16x16) then you will tend to keep pixles of similar vlaue > > together allowing for the compressor to create better dictionaries. i would > > compress 1 tile at a time, not a who,e series of them - as this will allow > > for "random access" later more easily on decode. > > I've tried to compress using the tiles (btw, the code is there). But in my > tests, for "small images" like 200x200, compressing the whole image in > planar colorspace gave better results. > > I would like to try again with your images, to see what I can do sure. > thank you > > Vincent > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: argb lossless codec
On Tue, 13 Nov 2007, Carsten Haitzler (The Rasterman) wrote: > On Tue, 23 Oct 2007 20:08:32 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> > babbled: > > finally got to play with it. quite interesting. i tried it on some images i > have (animated): > > [ 1:56PM ~/C/data/demo/e_anim_reflection ] du -sh . > 1.9M. > [ 1:55PM ~/e_codec ] ./encode out.erv > '/home/raster/C/data/demo/e_anim_reflection_big/e_%04d.png' 120 0 > * file : /home/raster/C/data/demo/e_anim_reflection_big/e_0001.png > * file : /home/raster/C/data/demo/e_anim_reflection_big/e_0002.png > ... > [ 1:56PM ~/e_codec ] ls out.erv > 4.4M out.erv > > double the size :/ :( where can I get those png ? in e17_bg_shiny_reflection.edj ? > we've talked on irc - we can continue there. i think this is great work btw. > one problem in this is you compress a whole plane at a time. it woudl be > easier > to compress 1 tile at a time (eg a 16x16 tile of the image - split into 4 > planes of 16x16) then you will tend to keep pixles of similar vlaue together > allowing for the compressor to create better dictionaries. i would compress 1 > tile at a time, not a who,e series of them - as this will allow for "random > access" later more easily on decode. I've tried to compress using the tiles (btw, the code is there). But in my tests, for "small images" like 200x200, compressing the whole image in planar colorspace gave better results. I would like to try again with your images, to see what I can do thank you Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} News from the E stables
On Tue, 6 Nov 2007 19:07:00 +0100 (CET) Vincent Torri <[EMAIL PROTECTED]> babbled: > > > On Mon, 5 Nov 2007, Carsten Haitzler (The Rasterman) wrote: > > > 2. Lets have actual weekly or monthly developer meetings - literally all-in > > live discussions - maybe IRC? Have actual agendas in meetings. Minutes. > > We are doing irc meetings about xcb, and it's always very useful. then lets (at some point soon) have some for e. > > 4. Try an organise some annual get-together. An "E meet" (I think I'll just > > call it "The Rave" for now - it fits with the whole E thing). So Literally > > find a place on the planet we all can/want to go to - go there. > > The french developpers have already met deveral times. Actually not for > thinking about E but for dining in a good restaurant :) that's all good too. i know its just dinner, but over dinner i am sure you talked code, hacking and all sorts of stuff. :) the main point is to get people together in person to talk, share and just get to know eachother. > > Now we also need to fix up enlightenment.org a bit - I intend to sink a bit > > of time into solidifying some content. The Wiki has a fair bit. Anyone is > > welcome to contribute as they see fit. > > imho, the enlightenment web site is not good. It's quite difficult to find > informations. The horizontal menu is too small. In that page: > > http://www.enlightenment.org/p.php?p=download&l=en > > the paragraph about e17 is not clear enough (there are 2 links without > explanation. Why doing a small page to say : go to other small pages) > > etc... dj2 is simplifiying it. :) > > But the primary thing of importance is getting E17 out the door. It's > > actually looking petty good. Only 2 really big TODO items left. I'm doing a > > theme revamp. The Default theme has very much aged. The gold bling isn't > > incredibly popular. I'm working on something I think people will love - and > > it still shows off E. It will replace the current default - and will also > > knock off some of the "comment the default theme so its better documented > > for people to build new themes from and learn Edje. > > I was just wondering if it was the right time to start a new theme, which > is a big big work. it is a big work, but the old one just was annoying me too much. i was trying to do graphics for the wizard and it just wasn't looking nice. everything i tried looked like crap. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E and mplayer
On Wed, 7 Nov 2007, Carsten Haitzler (The Rasterman) wrote: > On Tue, 6 Nov 2007 18:08:30 +0100 (CET) Vincent Torri <[EMAIL PROTECTED]> > babbled: > >> >> >> On Tue, 6 Nov 2007, raoul wrote: >> >> mplpayer is sometimes the only player than can render streams fast enough >> (for example hd content compressed with a h264 codec) > > we dont use xvideo for display- that does put a dent in the video output speed > already. unless you use the GL engine and have a fragment-shader capable card > (nv6xxx and up for example), you will be using software for yuv->rgb and > scaling and that will... take its toll. > > unfortunately mplayer provides NO way to use/integrate it with another app > (other than swallowing its window). it provides no way to have it provide yuv > data via a shm segment or whatever (without patching mplayer), that i know of, > thus it can't be used. my comment was not about emotion, but for all the players available (xine, totem with gstreamer and vlc) mplayer is better that these with hd content with a video stream coded with h264 algo. Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} News from the E stables
On Mon, 5 Nov 2007, Carsten Haitzler (The Rasterman) wrote: > 2. Lets have actual weekly or monthly developer meetings - literally all-in > live > discussions - maybe IRC? Have actual agendas in meetings. Minutes. We are doing irc meetings about xcb, and it's always very useful. > 4. Try an organise some annual get-together. An "E meet" (I think I'll just > call it "The Rave" for now - it fits with the whole E thing). So Literally > find > a place on the planet we all can/want to go to - go there. The french developpers have already met deveral times. Actually not for thinking about E but for dining in a good restaurant :) > Now we also need to fix up enlightenment.org a bit - I intend to sink a bit of > time into solidifying some content. The Wiki has a fair bit. Anyone is welcome > to contribute as they see fit. imho, the enlightenment web site is not good. It's quite difficult to find informations. The horizontal menu is too small. In that page: http://www.enlightenment.org/p.php?p=download&l=en the paragraph about e17 is not clear enough (there are 2 links without explanation. Why doing a small page to say : go to other small pages) etc... > But the primary thing of importance is getting E17 out the door. It's actually > looking petty good. Only 2 really big TODO items left. I'm doing a theme > revamp. The Default theme has very much aged. The gold bling isn't incredibly > popular. I'm working on something I think people will love - and it still > shows > off E. It will replace the current default - and will also knock off some of > the "comment the default theme so its better documented for people to build > new > themes from and learn Edje. I was just wondering if it was the right time to start a new theme, which is a big big work. regards Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: libs/ecore nash
>> Shouldn't the bit-field members be placed at the end of the struct to be >> useful ? > > Not sure exactly what you mean.. but there is no real reason to do > anything except make sure the bitfields are adjacent in the structure. You're right :) regards Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Porting EFL to windows mobile ?
On Mon, 8 Oct 2007, Rodolfo Hansen wrote: > Yes, there is a mingwce project... > > The cegcc people have ~2 toolchains for wince development... something close > to a posix compatibility layer, and the mingwce library they have... > > aparently the posix compat. layer lacks some important functions, (I checked > out from svn now, and will double check with latest versions), and the > mingwce version makes ./configure a mess for everything... plus I have very > little experience with win32/mingw32 Nevertheless you can try the 16 bits engine using directdraw that I have added in cvs :) regards Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: {Spam?} Re: improvements of configure
On Fri, 5 Oct 2007, Carsten Haitzler (The Rasterman) wrote: > On Fri, 5 Oct 2007 15:05:50 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> > babbled: > > for now lets do this with 1 package that covers most things and let that > settle. if no one reports major breaks then make the same changes to others. > for example do edje - it produces binaries and libs (no modules though) and > you > already mailed a patch - put changes in there, let it settle for 2 or 3 weeks > - if all is well, do the rest? ok Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: improvements of configure
On Fri, 5 Oct 2007 15:05:50 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> babbled: > > > On Fri, 5 Oct 2007, Carsten Haitzler (The Rasterman) wrote: > > > On Tue, 2 Oct 2007 18:31:34 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> > > babbled: > > > > ok- looking at the patch gives me meat to chew on :) overall this looks > > good. i'm a little dubious of the whole libtool version thing - i actually > > HATE it. i'd prefer the libtool revision/version/whatever stuff is > > sourced/generated from the package itself (eg 0.5.0 for edje) and we will > > increment this ONE version info only. i know what major and minor versions > > mean - most developers do/should so i'd rather have a single version tag > > there if possible - all the space used up by the libtool scheme comments > > could work on some script mojo to work out the libtool version magic from > > the package version. i really want to keep them consistent at all times if > > possible. thats my only issue - otherwise it seems ok to me. > > ok > > so, about libtool : > > 1) I remove the big doc > 2) from the package version (minor, major, micro), i create: > > version_info = ($major + $minor):$micro:$minor > > I know that ewl does not use that libtool behavio, so I'll not change > libtool version info in ewl, but I'll do the other modifications > > I plan to add AC_LIBTOOL_WIN32_DLL to the following libraries in libs/ : > > eet, evas, ecore, embryo, edje, efreet, etk and ewl. I'll maybe add it > later for emotion (when the evas sink will be finished), epeg and epsilon. > > I plan to do the other changes for all libs in libs/ except: > > edb, estyle, etox, evoak and ewd, as they are not maintained anymore > > Should I modify imlib2 ? yeah - modify that. imlib2 is on life support basically - but no development. > Is it good for everyone ? (Especially etk maintainers, as they might not > want that libtool version scheme). > > I'll look at proto/ and apps/ later for now lets do this with 1 package that covers most things and let that settle. if no one reports major breaks then make the same changes to others. for example do edje - it produces binaries and libs (no modules though) and you already mailed a patch - put changes in there, let it settle for 2 or 3 weeks - if all is well, do the rest? > Vincent > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > 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] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: improvements of configure
On Fri, 5 Oct 2007, Carsten Haitzler (The Rasterman) wrote: > On Tue, 2 Oct 2007 18:31:34 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> > babbled: > > ok- looking at the patch gives me meat to chew on :) overall this looks good. > i'm a little dubious of the whole libtool version thing - i actually HATE it. > i'd prefer the libtool revision/version/whatever stuff is sourced/generated > from the package itself (eg 0.5.0 for edje) and we will increment this ONE > version info only. i know what major and minor versions mean - most developers > do/should so i'd rather have a single version tag there if possible - all the > space used up by the libtool scheme comments could work on some script mojo to > work out the libtool version magic from the package version. i really want to > keep them consistent at all times if possible. thats my only issue - otherwise > it seems ok to me. ok so, about libtool : 1) I remove the big doc 2) from the package version (minor, major, micro), i create: version_info = ($major + $minor):$micro:$minor I know that ewl does not use that libtool behavio, so I'll not change libtool version info in ewl, but I'll do the other modifications I plan to add AC_LIBTOOL_WIN32_DLL to the following libraries in libs/ : eet, evas, ecore, embryo, edje, efreet, etk and ewl. I'll maybe add it later for emotion (when the evas sink will be finished), epeg and epsilon. I plan to do the other changes for all libs in libs/ except: edb, estyle, etox, evoak and ewd, as they are not maintained anymore Should I modify imlib2 ? Is it good for everyone ? (Especially etk maintainers, as they might not want that libtool version scheme). I'll look at proto/ and apps/ later Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} slow down with last CVS on n800
On 10/2/07, Vincent Torri <[EMAIL PROTECTED]> wrote: > On Tue, 2 Oct 2007, Gustavo Sverzut Barbieri wrote: > > > Hi guys, > > > > Someone made a change to CVS that turned things really slow on N800 > > devices. Since expedite still runs quite fast, so I believe it is > > related to Ecore (EcoreEvas?) or Edje. > > > > We're trying to hunt it, but if you have a clue, then say to help us > > saving time. > > have you tried the old ecore_evas test ? I can be a good test to know if > it's only related to ecore_evas. I will try. > otherwise, i committed stuff on ecore but it only affects Windows > platform. > > that's where a good ChangeLog would be useful. we have CVS logs, but it doesn't help much :-/ PS: you can see logs using git too (http://staff.get-e.org), it's much easier. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} slow down with last CVS on n800
On Tue, 2 Oct 2007, Gustavo Sverzut Barbieri wrote: > Hi guys, > > Someone made a change to CVS that turned things really slow on N800 > devices. Since expedite still runs quite fast, so I believe it is > related to Ecore (EcoreEvas?) or Edje. > > We're trying to hunt it, but if you have a clue, then say to help us > saving time. have you tried the old ecore_evas test ? I can be a good test to know if it's only related to ecore_evas. otherwise, i committed stuff on ecore but it only affects Windows platform. that's where a good ChangeLog would be useful. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Nightly build log for E17 on 2007-09-29 07:03:24 -0700
On 9/29/07, Vincent Torri <[EMAIL PROTECTED]> wrote: > > > On Sat, 29 Sep 2007, Gustavo Sverzut Barbieri wrote: > > > These changes in specific are meant to easy bindings :-) Actually we > > have some more that should come later, they're related to etk_base and > > etk_base_type, that will be added to all signal-emitted structures, so > > we will have a way to identify which struct is that and how to do a > > lookup for which wrapper to use. > > > > Anyway, it's better to improve these things sooner than later. > > the doc too. For example etk_type_new(). What's the meaning of the last > parameter ? It's the description of type signals, take a look at etk_button.c for example. I'll add the missing comment there. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Nightly build log for E17 on 2007-09-29 07:03:24 -0700
On Sat, 29 Sep 2007, Gustavo Sverzut Barbieri wrote: > These changes in specific are meant to easy bindings :-) Actually we > have some more that should come later, they're related to etk_base and > etk_base_type, that will be added to all signal-emitted structures, so > we will have a way to identify which struct is that and how to do a > lookup for which wrapper to use. > > Anyway, it's better to improve these things sooner than later. the doc too. For example etk_type_new(). What's the meaning of the last parameter ? Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Itask Patch
On Tue, 18 Sep 2007, Zachary Goldberg wrote: > I attempted to submit this patch on the Itask Homepage > (http://code.google.com/p/itask-module/) however the page gave me an > error. Anyway, I figured its probably better to post here anyway for > general public scrutiny. > > > This is a small patch to fix the itask module for the recent upstream > changes to gc api. It's maybe even better to put it in bugzilla. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: suggestion for the night build system
On Mon, 17 Sep 2007, David Seikel wrote: >> >> i want to write some, using the check library, gcov and lcov. I >> currently have some problems using lcov when the source code is not >> is the same directory tree than the tests (raster wants them in the >> test/ dir). > > The nightly build system tries to be generic. So to support testing, > we would need to define some standard way of invoking those tests. On > the other hand, the nature of E development means that most tests > proggies are GUI apps that are not as easily tested. autogen.sh + configure + make. That's what I use. I think that it's good enough. I mention that I want to add tests whose results can be tested programmatically. ecore_evas test in test/orig is not a test that I would add in unit tests, for example. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: suggestion for the night build system
On Thu, 6 Sep 2007 23:26:58 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> wrote: > > > On Thu, 6 Sep 2007, Andreas Volz wrote: > > > Am Wed, 5 Sep 2007 23:07:34 -0500 schrieb andres: > > > >> I'm writting some Edje development documentation and realizing how > >> many code examples all around the docs are broken over small > >> details. Which is ok by me but it could be very discouraging to > >> others. > >> > >> I think we should commit all code examples to a separate folder and > >> setup the nightly build system to compile them (or run some test > >> script for the interpreted languages). > > > > There're a lot of tests in the examples dir of eflpp. Would be nice > > to compile (and run) all tests in a nightly test and see the > > results at the next day. This would save me some time while > > developing eflpp. I think other libs may benefit also. > > > > So this is a good idea. Perhaps it's also a good idea to start > > writing more classic unit tests and run them each night. > > i want to write some, using the check library, gcov and lcov. I > currently have some problems using lcov when the source code is not > is the same directory tree than the tests (raster wants them in the > test/ dir). The nightly build system tries to be generic. So to support testing, we would need to define some standard way of invoking those tests. On the other hand, the nature of E development means that most tests proggies are GUI apps that are not as easily tested. Most E stuff is written in C using autotools, so that will be where testing infrastructure should be developed first. I think the simplest way would be similar to how the gendoc script is currently supported. If a gendoc script is found in the packages base directory, it is used to generate docs. So a test.sh script could be used in a similar way. The other thing to keep in mind is that the system currently runs on the E web server. We don't want to soak up resources running tests. Everything is run with the lowest CPU and IO priority, so performance testing is probably a waste of time. signature.asc Description: PGP signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: win32 patch for eet
On Tue, 11 Sep 2007, Carsten Haitzler (The Rasterman) wrote: > On Tue, 28 Aug 2007 15:53:27 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> > babbled: > >> >> Hey, >> >> The edje bug I was hunting on the windows platform comes from eet. the %a >> modifier, used to get the float or double values, is not supported on >> windows (see the big comment in the patch). >> >> I have some questions about that patch: >> >> 1) do I copy/paste it for float or do I factorize the code ? (only the >> last lines are specific to double). >> >> 2) Does someone see improvements regards the speed or the algorithm ? >> >> 3) I see a comment about solaris in the eet_data_get_double() function. >> Should we use that function on the solaris platform ? If so, which >> preprocessor command I have to use ? >> >> thank you > > i don't see a problem with this - anyone else disagree? I also recall that bugs #181 and #182 have been open for that stuff. Vincent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: suggestion for the night build system
On Thu, 6 Sep 2007, Andreas Volz wrote: > Am Wed, 5 Sep 2007 23:07:34 -0500 schrieb andres: > >> I'm writting some Edje development documentation and realizing how >> many code examples all around the docs are broken over small details. >> Which is ok by me but it could be very discouraging to others. >> >> I think we should commit all code examples to a separate folder and >> setup the nightly build system to compile them (or run some test >> script for the interpreted languages). > > There're a lot of tests in the examples dir of eflpp. Would be nice to > compile (and run) all tests in a nightly test and see the results at > the next day. This would save me some time while developing eflpp. I > think other libs may benefit also. > > So this is a good idea. Perhaps it's also a good idea to start writing > more classic unit tests and run them each night. i want to write some, using the check library, gcov and lcov. I currently have some problems using lcov when the source code is not is the same directory tree than the tests (raster wants them in the test/ dir). I'll try again this week end Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} EFL on Win32 Status
Hey, I am the one who maintain the windows port. On Thu, 2 Aug 2007, Tyrael wrote: > The past few days i have spent considerable time looking into EFL's source > code and now i am wandering of the status of EFL's port in windows. > I am very interested in participating to this project see below for that ;) >> From what i have seen, Evas now has a Win32 engine(based on DirectDraw) and > the majority of the rest of the core libs (with the exception of ecore...) > should be rather trivial(with exceptions) to port > > However since Ecore is needed, i am wandering if anyone has started working > on it, even on conceptual level ? on my hd, ecore_win32 and ecore_evas are working. Only few ecore modules are available on windows : ecore itself (without ecore_exe), ecore_txt, ecore_job, ecore_win32 and ecore_evas. embryo and edje can be compiled easily, it's on my hd too. I'm planning to put in cvs ecore_win32 and ecore_evas in late august. The current big big problem: in a eet function, when reading a compressed eet file, libjpeg returns an error. I don't understand why. That means that all the edje files with compressed images can not be read. If it's fixed, ewl and etk can be ported without problems. Here are my plans: 1) finishing the opengl engine, based on glew [1]. I've finished it this afternoon. But it is slower than the directdraw engine (maybe it's because my graphic card, a geforce 2 gts). I have to clean it a bit before it goes into cvs. 2) fixing the direct3d engine. There is a problem i can't understand. See below. 3) fixing that eet (libjpeg ?) problem. 4) implement the ecore_exe features for windows, using CreateThread or CreateProcess. That's a pain. But that will allow other ecore modules to be easily written. 5) distributing MinGW ports and maybe NSIS installer (I've already written both for eet) Where you can help me: 1) looking at that eet problem. It's the most important thing to fix for the Windows port. 2) if you know a bit of direct3d, look at that program: http://www.maths.univ-evry.fr/pages_perso/vtorri/files/d3d.cpp it should display an animation in the top-left corner of the window. See the first lines to compile it with mingw. There is no animation. If you can find why, it will hep me a lot. I think that the problem comes from the initialisation of direct3d (in data_init()), but I'm not sure. 3) If you solved the 2 previous points, you can try to look at ecore_exe :) regards Vincent [1] http://glew.sourceforge.net/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: {Spam?} Re: evas common engine as a direct rendering library?
On 7/25/07, Jorge Luis Zapata Muga <[EMAIL PROTECTED]> wrote: > On 7/25/07, Vincent Torri <[EMAIL PROTECTED]> wrote: > > > > > > On Wed, 25 Jul 2007, Carsten Haitzler (The Rasterman) wrote: > > > > > > be careful - then you need to deal with merging the branch - the existing > > > software enigne code wont stay still forever. > > > > before talking about merging, maybe it's time to write some code. There > > has been several times, by mails, discussions about internal changes and > > absolutely no code at all is available for other devs. > > > > The code is (and was) available (the same with other code ideas) at > http://code.google.com/p/efl-research/ my fault for not telling other > devs about it on the ml (as i did on the irc) but was calling for > other devs to join, so now its time =) > > Note that currently this is just a prototype, it works right now, but > now im changing how scanlines/pt functions are called so i can merge > this code with the software_16 engine and have a common libary for gfx > routines for two different format surfaces (ARGB 1 plane, RGB565 > A5 2 planes, and also use a look up table for such functions instead > of many conditionals. > > I've also changed the main data type, instead of a RGBA_Image it is a > RGBA_Surface, the Image should be a wrapper on top of it. So this > simple change means a lot of troubles with the current evas image > loading/saving/process functions, but i think it worths :) we'll end with SDL :-/ It's SDL_Surface is just like that, but I don't see any other way. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: {Spam?} Re: evas common engine as a direct rendering library?
On 7/25/07, Vincent Torri <[EMAIL PROTECTED]> wrote: > > > On Wed, 25 Jul 2007, Carsten Haitzler (The Rasterman) wrote: > > > > be careful - then you need to deal with merging the branch - the existing > > software enigne code wont stay still forever. > > before talking about merging, maybe it's time to write some code. There > has been several times, by mails, discussions about internal changes and > absolutely no code at all is available for other devs. > The code is (and was) available (the same with other code ideas) at http://code.google.com/p/efl-research/ my fault for not telling other devs about it on the ml (as i did on the irc) but was calling for other devs to join, so now its time =) Note that currently this is just a prototype, it works right now, but now im changing how scanlines/pt functions are called so i can merge this code with the software_16 engine and have a common libary for gfx routines for two different format surfaces (ARGB 1 plane, RGB565 A5 2 planes, and also use a look up table for such functions instead of many conditionals. I've also changed the main data type, instead of a RGBA_Image it is a RGBA_Surface, the Image should be a wrapper on top of it. So this simple change means a lot of troubles with the current evas image loading/saving/process functions, but i think it worths :) turran. > so, if you're reluctant to merge with cvs, we have 2 solutions: > > 1) continuing the discussion by mail, hence no code will be available. > It's a wonderful way to do development. > 2) moving from cvs to another vcs, which allows merging easier than with > cvs. > > Vincent > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: libs/etk andrunko
On 7/25/07, Vincent Torri <[EMAIL PROTECTED]> wrote: > > > On Wed, 25 Jul 2007, Chady Kassouf wrote: > > > On 7/25/07, Vincent Torri <[EMAIL PROTECTED]> wrote: > >> > >> > >> > >> > >> hmmm, make it hard to run such apps on desktops with 2 or more virtual > >> desktops or monitors. There are other inconvenients with mdi > > > > > > > > Sure it might have inconveniences, but etk is a toolkit, and it's not up to > > the toolkit to decide how a GUI should be done... it's up to the interface > > designer, and the toolkit should provide all the facilities... > > but then, etk allows the designer to use bad design solutions. mdi is not > a "facility". It's a bad design for making ui (imho). The application i am developing is a full screen application that simulates a desktop with it's own windows (themed decorations and so). I agree that in most cases mdi is not a good solution but in this case it's, and it's was not me who decided it, it's was our usability/designer team. So I believe choice is always good, as long as it a choice BR Andrunko > Vincent > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Andre Moreira Magalhaes (andrunko) Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] Skype: andrunko - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: {Spam?} Re: evas common engine as a direct rendering library?
On Wed, 25 Jul 2007 16:01:05 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> babbled: > > > On Wed, 25 Jul 2007, Carsten Haitzler (The Rasterman) wrote: > > > > be careful - then you need to deal with merging the branch - the existing > > software enigne code wont stay still forever. > > before talking about merging, maybe it's time to write some code. There > has been several times, by mails, discussions about internal changes and > absolutely no code at all is available for other devs. > > so, if you're reluctant to merge with cvs, we have 2 solutions: > > 1) continuing the discussion by mail, hence no code will be available. > It's a wonderful way to do development. > 2) moving from cvs to another vcs, which allows merging easier than with > cvs. nothing to do with cvs that makes merging hard - if the same src is changed in 2 places - you get a conflict. humans need to resolve them. what we should do to start is JUST split off src/lib/engines/common - it already produces a .a file that is linked INTO libevas.so - ALL you need to do for now is produce a .so instead and link runtime as a separate .so - that then allows us to clean up the API to be clean - a little bit at a time, and once its clean to be split entirely - split it. this way it stays in head - and we have minimal breaks. :) > Vincent > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > 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] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: libs/etk andrunko
On Wed, 25 Jul 2007, Chady Kassouf wrote: > On 7/25/07, Vincent Torri <[EMAIL PROTECTED]> wrote: >> >> >> >> >> hmmm, make it hard to run such apps on desktops with 2 or more virtual >> desktops or monitors. There are other inconvenients with mdi > > > > Sure it might have inconveniences, but etk is a toolkit, and it's not up to > the toolkit to decide how a GUI should be done... it's up to the interface > designer, and the toolkit should provide all the facilities... but then, etk allows the designer to use bad design solutions. mdi is not a "facility". It's a bad design for making ui (imho). Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: {Spam?} Re: evas common engine as a direct rendering library?
On Wed, 25 Jul 2007, Carsten Haitzler (The Rasterman) wrote: > > be careful - then you need to deal with merging the branch - the existing > software enigne code wont stay still forever. before talking about merging, maybe it's time to write some code. There has been several times, by mails, discussions about internal changes and absolutely no code at all is available for other devs. so, if you're reluctant to merge with cvs, we have 2 solutions: 1) continuing the discussion by mail, hence no code will be available. It's a wonderful way to do development. 2) moving from cvs to another vcs, which allows merging easier than with cvs. Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: evas common engine as a direct rendering library?
On Wed, 25 Jul 2007 08:17:55 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> babbled: > > > On Sat, 21 Jul 2007, Carsten Haitzler (The Rasterman) wrote: > > > On Thu, 19 Jul 2007 00:20:16 +0200 "Jorge Luis Zapata Muga" > > <[EMAIL PROTECTED]> babbled: > > > >> Hi all, i have taken evas to be my guinea pig here =) > >> > >> I've split the common engine code into a different library, because > >> with time it has became a really good direct rendering library. what > >> would it benefit us? i have the idea that abstracting at the canvas > >> level and at the rendering level would make objects to render > >> themselves, and get away from engine level several non needed stuff > >> because there's maybe no engine that can do what evas do internally. > >> the latter isnt fully decided yet, but isolating concepts on the > >> library is a good thing imho, you can do more benchmarks and have more > >> control on what every part of the library does. So the first step im > >> doing is to abstract the direct rendering code, if anyone is > >> interested on this, reply :) > > > > I think this is a good idea. I have nothing against it - but we need to be > > aware that it makes breaking internal rendering api's harder :( i do agree > > that this will make benchmarks and testing of just raw routines much much > > much easier. for now i think this extra lib can just ship with evas - we > > can split it out later as/when needed. for now a big sign of "this api is > > going to break > > - don't use it in your app unless you like api's always breaking" on it. :) > > again, a branch in cvs can be a good idea to test that. be careful - then you need to deal with merging the branch - the existing software enigne code wont stay still forever. > Vincent > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > 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] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: evas common engine as a direct rendering library?
On Sat, 21 Jul 2007, Carsten Haitzler (The Rasterman) wrote: > On Thu, 19 Jul 2007 00:20:16 +0200 "Jorge Luis Zapata Muga" > <[EMAIL PROTECTED]> babbled: > >> Hi all, i have taken evas to be my guinea pig here =) >> >> I've split the common engine code into a different library, because >> with time it has became a really good direct rendering library. what >> would it benefit us? i have the idea that abstracting at the canvas >> level and at the rendering level would make objects to render >> themselves, and get away from engine level several non needed stuff >> because there's maybe no engine that can do what evas do internally. >> the latter isnt fully decided yet, but isolating concepts on the >> library is a good thing imho, you can do more benchmarks and have more >> control on what every part of the library does. So the first step im >> doing is to abstract the direct rendering code, if anyone is >> interested on this, reply :) > > I think this is a good idea. I have nothing against it - but we need to be > aware that it makes breaking internal rendering api's harder :( i do agree > that > this will make benchmarks and testing of just raw routines much much much > easier. for now i think this extra lib can just ship with evas - we can split > it out later as/when needed. for now a big sign of "this api is going to break > - don't use it in your app unless you like api's always breaking" on it. :) again, a branch in cvs can be a good idea to test that. Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Nightly builds - Was: Is this a community project?
> Off the top of my head. sf.net has a compile farm that can be used for > such things SF has closed its Compile Farm service: http://sourceforge.net/forum/forum.php?forum_id=665365 Vincent - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Nightly builds - Was: Is this a community project?
On Mon, 16 Jul 2007 18:05:53 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> wrote: > > Off the top of my head. sf.net has a compile farm that can be used > > for such things > > SF has closed its Compile Farm service: > > http://sourceforge.net/forum/forum.php?forum_id=665365 Bummer. qemu builds then I guess. signature.asc Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Is this a community project?
On Mon, 9 Jul 2007, Carsten Haitzler (The Rasterman) wrote: > > i swear i recently cleaned out the patches - like a few weeks back? > Actually.. .I think we need a patches mailing list...? bugzilla [1] is a good way to save patches, and to report bugs. No need for another ML. Bugzilla is also a good way to save propositions about API. I'm working on several projects that are using bugzilla and I think that it is far better than having patches in some mail. You can assign a person to review that bug/patch, you can define a priority (so that, when asparagus time comes, you can have a look at all the bugs/patches you want to be fixed/applied), etc... Vincent - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: libs/edje pfritz
On 7/7/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > > On 7/7/07, Vincent Torri <[EMAIL PROTECTED]> wrote: > > On Sat, 7 Jul 2007, Dr. Michael 'Mickey' Lauer wrote: > > > > > Vincent Torri wrote: > > > > > >> On Fri, 6 Jul 2007, Enlightenment CVS wrote: > > >>> style = EVAS_TEXT_STYLE_OUTLINE_SHADOW; > > >>>else if (ep->part->effect == > EDJE_TEXT_EFFECT_OUTLINE_SOFT_SHADOW) > > >>> style = EVAS_TEXT_STYLE_OUTLINE_SOFT_SHADOW; > > >>> + else if (ep->part->effect == EDJE_TEXT_EFFECT_FAR_SHADOW) > > >>> +style = EVAS_TEXT_STYLE_FAR_SHADOW; > > >>> + else if (ep->part->effect == > EDJE_TEXT_EFFECT_FAR_SOFT_SHADOW) > > >>> +style = EVAS_TEXT_STYLE_FAR_SOFT_SHADOW; > > >>> + else if (ep->part->effect == EDJE_TEXT_EFFECT_GLOW) > > >>> +style = EVAS_TEXT_STYLE_GLOW; > > > > > >>> #define EDJE_TEXT_EFFECT_SOFT_SHADOW 5 > > >>> #define EDJE_TEXT_EFFECT_OUTLINE_SHADOW 6 > > >>> #define EDJE_TEXT_EFFECT_OUTLINE_SOFT_SHADOW 7 > > >>> -#define EDJE_TEXT_EFFECT_LAST8 > > >>> +#define EDJE_TEXT_EFFECT_FAR_SHADOW 8 > > >>> +#define EDJE_TEXT_EFFECT_FAR_SOFT_SHADOW 9 > > >>> +#define EDJE_TEXT_EFFECT_GLOW 10 > > >>> +#define EDJE_TEXT_EFFECT_LAST 11 > > > > > >> Isn't it better to use an enum + a switch, instead of defines + > if/else ? > > > > > > FWIW, I agree. What we lose in runtime performance we gain more than > > > twice in clarity and maintenance. > > > > I'm not sure we loose in runtime speed. switch are handle with lookup > > tables with enums (iirc), and the compiler can do better optimizations > > than with a bunch of if/else > > yep, it will not loose, and even if it was the case it would be so > minimum and not worth more than maintenance. I actually did a small test and compiled to assembly, an if/else will compile to exactly the same amount of `cmpl` statements as a switch, and almost the same amount of jumps. The only difference is in the logic of branching: the compiler will compile an if/else to branch on the else part, while the switch statement will always jump, so they're both jumping and affecting the pipeline, but any performance difference between the two is relative, and probably not noticeable. -- Chady 'Leviathan' Kassouf http://chady.net/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: libs/edje pfritz
On 7/7/07, Vincent Torri <[EMAIL PROTECTED]> wrote: > On Sat, 7 Jul 2007, Dr. Michael 'Mickey' Lauer wrote: > > > Vincent Torri wrote: > > > >> On Fri, 6 Jul 2007, Enlightenment CVS wrote: > >>> style = EVAS_TEXT_STYLE_OUTLINE_SHADOW; > >>>else if (ep->part->effect == > >>> EDJE_TEXT_EFFECT_OUTLINE_SOFT_SHADOW) > >>> style = EVAS_TEXT_STYLE_OUTLINE_SOFT_SHADOW; > >>> + else if (ep->part->effect == EDJE_TEXT_EFFECT_FAR_SHADOW) > >>> +style = EVAS_TEXT_STYLE_FAR_SHADOW; > >>> + else if (ep->part->effect == EDJE_TEXT_EFFECT_FAR_SOFT_SHADOW) > >>> +style = EVAS_TEXT_STYLE_FAR_SOFT_SHADOW; > >>> + else if (ep->part->effect == EDJE_TEXT_EFFECT_GLOW) > >>> +style = EVAS_TEXT_STYLE_GLOW; > > > >>> #define EDJE_TEXT_EFFECT_SOFT_SHADOW 5 > >>> #define EDJE_TEXT_EFFECT_OUTLINE_SHADOW 6 > >>> #define EDJE_TEXT_EFFECT_OUTLINE_SOFT_SHADOW 7 > >>> -#define EDJE_TEXT_EFFECT_LAST8 > >>> +#define EDJE_TEXT_EFFECT_FAR_SHADOW 8 > >>> +#define EDJE_TEXT_EFFECT_FAR_SOFT_SHADOW 9 > >>> +#define EDJE_TEXT_EFFECT_GLOW 10 > >>> +#define EDJE_TEXT_EFFECT_LAST 11 > > > >> Isn't it better to use an enum + a switch, instead of defines + if/else ? > > > > FWIW, I agree. What we lose in runtime performance we gain more than > > twice in clarity and maintenance. > > I'm not sure we loose in runtime speed. switch are handle with lookup > tables with enums (iirc), and the compiler can do better optimizations > than with a bunch of if/else yep, it will not loose, and even if it was the case it would be so minimum and not worth more than maintenance. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E CVS: libs/edje pfritz
On Sat, 7 Jul 2007, Dr. Michael 'Mickey' Lauer wrote: > Vincent Torri wrote: > >> On Fri, 6 Jul 2007, Enlightenment CVS wrote: >>> style = EVAS_TEXT_STYLE_OUTLINE_SHADOW; >>>else if (ep->part->effect == >>> EDJE_TEXT_EFFECT_OUTLINE_SOFT_SHADOW) >>> style = EVAS_TEXT_STYLE_OUTLINE_SOFT_SHADOW; >>> + else if (ep->part->effect == EDJE_TEXT_EFFECT_FAR_SHADOW) >>> +style = EVAS_TEXT_STYLE_FAR_SHADOW; >>> + else if (ep->part->effect == EDJE_TEXT_EFFECT_FAR_SOFT_SHADOW) >>> +style = EVAS_TEXT_STYLE_FAR_SOFT_SHADOW; >>> + else if (ep->part->effect == EDJE_TEXT_EFFECT_GLOW) >>> +style = EVAS_TEXT_STYLE_GLOW; > >>> #define EDJE_TEXT_EFFECT_SOFT_SHADOW 5 >>> #define EDJE_TEXT_EFFECT_OUTLINE_SHADOW 6 >>> #define EDJE_TEXT_EFFECT_OUTLINE_SOFT_SHADOW 7 >>> -#define EDJE_TEXT_EFFECT_LAST8 >>> +#define EDJE_TEXT_EFFECT_FAR_SHADOW 8 >>> +#define EDJE_TEXT_EFFECT_FAR_SOFT_SHADOW 9 >>> +#define EDJE_TEXT_EFFECT_GLOW 10 >>> +#define EDJE_TEXT_EFFECT_LAST 11 > >> Isn't it better to use an enum + a switch, instead of defines + if/else ? > > FWIW, I agree. What we lose in runtime performance we gain more than > twice in clarity and maintenance. I'm not sure we loose in runtime speed. switch are handle with lookup tables with enums (iirc), and the compiler can do better optimizations than with a bunch of if/else regards Vincent - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: ecore_x with xcb backend
On Tue, 17 Apr 2007 08:35:01 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> babbled: > > > On Tue, 17 Apr 2007, Carsten Haitzler (The Rasterman) wrote: > > > ecore_x_window_prop_properties_get(Ecore_X_Window win, int count, > > Ecore_X_Atom *properties, Ecore_X_Atom types, int sizes, unsigned char > > ***datas, int **nums) > > > > that would fetch 'count' properties from a window in 1 round trip instead of > > 'count' round trips. ecore_x_window_prop_property_get_prefetch() i would > > simplify to sending the xcb request and then when it arrives produce an > > ECORE_X_REPLY_WINDOW_PROPERTY event - the event would contain the contents > > of the reply (when it comes in). the xlib implementation of that cal would > > do the round-trip property get and then post an event so you pay a > > round-trip cost anyway, but the reply it just deferred onto the end of the > > event queue. > > > > the above will not break current api, will give benefits in avoiding > > round-trips, and be simple to maintain and implement. apps would need to use > > the new calls to get a benefit - but that is to be expected. the point is - > > that if xcb doesn't exist - they still work just fine using xlib. no > > #ifdef's in apps. > > and what about the case the xcb backend is used and the user does not use > these new functions, but the old ones ? then these functions behave exactly like xlib - they send a request, block and wait for the reply. > Vincent > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: ecore_x with xcb backend
On Tue, 17 Apr 2007, Carsten Haitzler (The Rasterman) wrote: > ecore_x_window_prop_properties_get(Ecore_X_Window win, int count, Ecore_X_Atom > *properties, Ecore_X_Atom types, int sizes, unsigned char ***datas, int > **nums) > > that would fetch 'count' properties from a window in 1 round trip instead of > 'count' round trips. ecore_x_window_prop_property_get_prefetch() i would > simplify to sending the xcb request and then when it arrives produce an > ECORE_X_REPLY_WINDOW_PROPERTY event - the event would contain the contents of > the reply (when it comes in). the xlib implementation of that cal would do the > round-trip property get and then post an event so you pay a round-trip cost > anyway, but the reply it just deferred onto the end of the event queue. > > the above will not break current api, will give benefits in avoiding > round-trips, and be simple to maintain and implement. apps would need to use > the new calls to get a benefit - but that is to be expected. the point is - > that if xcb doesn't exist - they still work just fine using xlib. no #ifdef's > in apps. and what about the case the xcb backend is used and the user does not use these new functions, but the old ones ? Vincent - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: Update GUI inside thread
On Mon, 12 Feb 2007, Carsten Haitzler (The Rasterman) wrote: > > oh - god. those api's SUCK. they impose threads on their callers, like it or > not. very evil. threads should (imho) be hidden from any calling process. > libxine does this and i did some evil stuff to hide this in emotion and merge > it all back to the main thread - i used fd_handlers too (and a pipe). it seems > to work just fine as it's being used for every frame that is rendered. exactly the same for the gstreamer backend. Since 0.10, gstreamer is threaded. Vincent - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
