Re: [E-devel] Vertical Align of Edje Textblock
On Jan 18, 2008 4:19 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Wed, 26 Dec 2007 00:29:27 +0100 Thomas Gstädtner [EMAIL PROTECTED] babbled: Hello people, I'm currently working on my first interface in edje and guess I found a bug in the edje-textblock. As I want to do multi-line captions on buttons, I want to have the textblock centered on the button-graphics. I assumed that the valign-property in the style-block was what I wanted, but neither valign=center nor valign=0.5 works. Horizontal align works perfectly. So I also tried to set the align property for the part itself (even if it should be 0.5 0.5 by default) what didn't work, too. As the valign style-property seems to do nothing at all, I assume that's a bug. Can somebody confirm and fix this? :) valign in a textblock is the alignment WITHIN a line of text - so imagine u have a 30point font and a 8point fount on the same line - valign controls where the 8point font is aligned. this clarify things a bit :-) Maybe someone could add it to the wiki? (please remind me later if nobody does). align SHOULD work if you set the min: 1 1; (ie make the minimum size of the part controlled by the minimum size of the text itself. given that the part have a _small_ size (ie: height = 0), then part will grow (due: min: 1 1) and be aligned to _external_ align (the one inside description, not the one inside TEXT, not sure TEXTBLOCK have that), am I right? -- 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 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] [RFC] get-e.org integration in wallpaper configuration module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 18 Jan 2008 08:22:55 +0100 laurent laffont [EMAIL PROTECTED] wrote: With http://e17-stuff.org/ support with icons/entrance/etk/startup themes support, integrating a mean to vote for his/her favorite stuff, this plugin would be amazing Very interesting, thanks for reply! I'll take a look to e17-stuff.org to see what i can parse to do similar work that i've done for get-e.org Massimiliano - -- Massimiliano Calamelli http://mcalamelli.netsons.org [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (MingW32) iD8DBQFHkJqCleGEL56NNP4RAhI0AJ9vCPYiEjgwxEmA8uq1augvSU/YkQCg6i1H FJVMmPpCDpeWaBtAVC3iobQ= =aVek -END PGP 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] Gevas (was: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 ))
On Jan 18, 2008 1:57 PM, Michael 'Mickey' Lauer [EMAIL PROTECTED] wrote: Ben Martin wrote: Unfortunately its too early to demo gevas on meamo and its integration... maybe in 6 months You've been doing or will do more work on that? Great! I'm very interested in combining glib and ecore mainloops. What's your general experience with that? (yes, I've seen gevas in CVS). AFAICT it uses another thread that communicates using pipe. I already talked to raster about ecore-glib mainloop integration and the problems so far are: - ecore cannot be created on top of glib because it have more primitives (idler_enterer, idle_exiter) - glib cannot be created on top of ecore because it expects the primitives to be thread-safe, so you can use g_idle_add() and g_timeout_add() from threads, people often use this to schedule things to be run on the graphics thread (instead of using pipes). So we can have both approaches: suggesting glib to have more primitives or adding locks around globals manipulation. -- 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 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] Vertical Align of Edje Textblock
On Fri, 18 Jan 2008 09:16:52 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: On Jan 18, 2008 4:19 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Wed, 26 Dec 2007 00:29:27 +0100 Thomas Gstädtner [EMAIL PROTECTED] babbled: Hello people, I'm currently working on my first interface in edje and guess I found a bug in the edje-textblock. As I want to do multi-line captions on buttons, I want to have the textblock centered on the button-graphics. I assumed that the valign-property in the style-block was what I wanted, but neither valign=center nor valign=0.5 works. Horizontal align works perfectly. So I also tried to set the align property for the part itself (even if it should be 0.5 0.5 by default) what didn't work, too. As the valign style-property seems to do nothing at all, I assume that's a bug. Can somebody confirm and fix this? :) valign in a textblock is the alignment WITHIN a line of text - so imagine u have a 30point font and a 8point fount on the same line - valign controls where the 8point font is aligned. this clarify things a bit :-) Maybe someone could add it to the wiki? (please remind me later if nobody does). align SHOULD work if you set the min: 1 1; (ie make the minimum size of the part controlled by the minimum size of the text itself. given that the part have a _small_ size (ie: height = 0), then part will grow (due: min: 1 1) and be aligned to _external_ align (the one inside description, not the one inside TEXT, not sure TEXTBLOCK have that), am I right? well textblock itself won't align the text within the tb object to be in the middle, but the tb object will resize to be the minimum size of the tb object when the text is formatted. so that means it will be 2 lines of text (lets say 80x40 in size) then THIS object will align WITHIN its given allocated space (you set rel1/rel2 to cover the entire parent region) and the align property on the part will be able to vertically center the tb object itself. :) -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 -- - 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 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] Gevas (was: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 ))
On Fri, 2008-01-18 at 22:57 -0300, Gustavo Sverzut Barbieri wrote: On Jan 18, 2008 10:41 PM, Ben Martin [EMAIL PROTECTED] wrote: On Fri, 2008-01-18 at 22:27 -0300, Gustavo Sverzut Barbieri wrote: On Jan 18, 2008 10:21 PM, Ben Martin [EMAIL PROTECTED] wrote: On Sat, 2008-01-19 at 10:21 +1100, Carsten Haitzler wrote: while i have nothing against adding locks on primitives - if we do it in one place (ecore) we will need to start doing it everywhere. locks will add overhead. those on limited computing (embedded devices) will feel it most. also if we look at the work needed to add it everywhere - that's not a small undertaking at all. i have decided in the past not to bother as gustavo put this clearly - i kind of expect people to have threads do entirely independent things outside the main gui thread and communicate back cleanly via pipes - glib expects people to use threads with glib and has primitives for making them interact directly with the main loop from a thread. different design approaches there. right now i (personally) thing the best way to integrate is to have ecore main loop and glib main loop run in separate threads, with them communicating via pipes used to glue them together. maybe some pipe wrapping/handling stuff in ecore might help with this? That last one will be my fallback position of adding the needed stuff into glib2 becomes to hard / difficult. If we could add these primitives and write one on the top of the other, then we could even try to get EFL approved as glib-friend under the Gnome foundation, specially on GMAE (Gnome Mobile), this would bring us more developers and even companies. It's nothing more than words/marketing, but it helps a lot in the end... right now they just have Cairo (vectorial, slow) and Clutter (3d-oriented, good with hw-accel but the name can say about software performance...). Evas can fit perfectly in the hole of fast 2d graphics/canvas. Edje is also unmatched by existing software. I'm not too sure about the glib-friend branding having too much meaning... but I'm not a CTO ;p Since gevas has been available for quite a while, admittedly only allowing edje/gtk2 integration but no companies (that have contacted me anyway) have been racing in to help advance gevas. If the glib-friend status was really that sort of road block to corporate adoption then surely one would have stood up to buy that branding for gevas. Well, I'm working at INdT and doing EFL for Maemo, a GTK-device and I can tell how difficult is to have people _look_ at non-Gnome technology. Non-tech people (managers) often buy buzzwords and they want to believe some things. You have to write code, show, push... push... push... NOTE: I'm NOT talking about INdT here, but others companies. INdT is a non-profit research center focused on Nokia, so it's easy for us. I heard from 2 companies with M in the name (moto and marvell) _INFORMAL_ requests to get EFL into GMAE so they can sell it to their managers more easy, phrase was somehow like: We already convinced them to use Gnome tech (GMAE), I don't care what is there, it's approved, if you put this wonderful tech there we can use it, otherwise we need to get yet-another-approval, this was after my talk at ELCE-2007 Well, I guess if/when the layering on top of glib2 happens then we can get the branding fairly easily. But I'm not sure when I'll be able to hack on it at the moment :( At first we were to use Gevas, but it was a bit unmaintained, then we opted to drop Glib completely and use just EFL + Python, this proved to be a sane decision :-) It's hard to get around the perception of gevas being unmaintained. It works for what I use it for so there isn't much point in churning cvs and releases for nothing :/ But whatever happens to solve the need at hand :) But it would seem that gevas fits in well on meamo where they want you to use their gtk2 stuff to appear like other maemo apps with tabs etc. So being able to take advantage of evas+ecore while having all the normal trappings of a maemo app might be quite nice. We're pushing a whole-evas UI and being successful. Admittedly iPhone helped _a lot_ here. We were using ETK with custom theme to make regular GUI widgets, but we're now moving for an all-edje solution with great success. What I see is _NOT_ people trying to use EFL with GTK. People are really losing hope of the toolkit itself, and the requirements for such form-focused toolkits (unless you're doing some POS, ERP, ...). What people want is the Gnome stack, things that integrate nicely with your app, like the tons of libraries they provide (libsoup for http/xml/soap, gnomevfs, gstreamer, telepathy, libpurple, various parsers, integrations, ...). But
Re: [E-devel] Gevas (was: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 ))
On Fri, 2008-01-18 at 22:27 -0300, Gustavo Sverzut Barbieri wrote: On Jan 18, 2008 10:21 PM, Ben Martin [EMAIL PROTECTED] wrote: On Sat, 2008-01-19 at 10:21 +1100, Carsten Haitzler wrote: while i have nothing against adding locks on primitives - if we do it in one place (ecore) we will need to start doing it everywhere. locks will add overhead. those on limited computing (embedded devices) will feel it most. also if we look at the work needed to add it everywhere - that's not a small undertaking at all. i have decided in the past not to bother as gustavo put this clearly - i kind of expect people to have threads do entirely independent things outside the main gui thread and communicate back cleanly via pipes - glib expects people to use threads with glib and has primitives for making them interact directly with the main loop from a thread. different design approaches there. right now i (personally) thing the best way to integrate is to have ecore main loop and glib main loop run in separate threads, with them communicating via pipes used to glue them together. maybe some pipe wrapping/handling stuff in ecore might help with this? That last one will be my fallback position of adding the needed stuff into glib2 becomes to hard / difficult. If we could add these primitives and write one on the top of the other, then we could even try to get EFL approved as glib-friend under the Gnome foundation, specially on GMAE (Gnome Mobile), this would bring us more developers and even companies. It's nothing more than words/marketing, but it helps a lot in the end... right now they just have Cairo (vectorial, slow) and Clutter (3d-oriented, good with hw-accel but the name can say about software performance...). Evas can fit perfectly in the hole of fast 2d graphics/canvas. Edje is also unmatched by existing software. I'm not too sure about the glib-friend branding having too much meaning... but I'm not a CTO ;p Since gevas has been available for quite a while, admittedly only allowing edje/gtk2 integration but no companies (that have contacted me anyway) have been racing in to help advance gevas. If the glib-friend status was really that sort of road block to corporate adoption then surely one would have stood up to buy that branding for gevas. But it would seem that gevas fits in well on meamo where they want you to use their gtk2 stuff to appear like other maemo apps with tabs etc. So being able to take advantage of evas+ecore while having all the normal trappings of a maemo app might be quite nice. But first things first... must, get, device. 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] Call for help: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 )
On Sat, 2008-01-19 at 12:58 +1100, Carsten Haitzler wrote: On Fri, 18 Jan 2008 14:00:53 +1000 Ben Martin [EMAIL PROTECTED] babbled: Also if emotion works well on the n8x0 I'd have that going as part of a demo loop or available for easy exhibition. i actually haven't built libxine and/or emotion for the n800 or my neo(s). :/ it likely will NOT run that well... :( Well, a sub 200mhz smart phone can pull off about 15fps depending on how things are encoded. So I'm still optimistic that an n800 can do acceptably for some video playback... but I'll get back to you on that sometime :) 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] [PATCH] Edje improvement
On Thu, 17 Jan 2008 17:23:18 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: I have been working on some little improvement for Edje recently. The first patch, edje_data_file.diff, add support for a data.file entry inside edc file. It give the possibility to put text file inside edje directy. hmm - ok. sounds ok to me - using that for copyrights and such? Sounds potentially useful - one could even use it to embedd other text-based file formats...? One thing that edje/edc may need is a means of 'typing' the various kinds of edjes. Right now, all these .edj files are used to define a very large and disparate number of things not sure we need this - why? the type is based on what edje groups u have. an edje can contain both an e theme, an ewl theme, an etk theme, an e background etc. etc. - it can contain all of them in 1 file. an edje doesn't have a single type - it may or may not provide data FOR a type of use. it may provide it for multiple uses. How does one know if it's an e17 bg, some clock thing, an etk or ewl theme, an icon, some menu or dialog theme, or who knows what others may use them to define. This kind of thing can become a problem over time. as above. you need to open the edje and look for the data you want. if you are after etk theme elements - you look for them in the file. it may or may not provide them. Maybe time for some way of specifying WHAT these edj files are supposed to be - perhaps something akin to what's done with mime- types... maybe some 'type', 'category', 'description' sorts of data in the edj/edc file (maybe with versions as well)? Anyone have any suggestions on this? again - as above. the files dont have ONE type. they provide data for many things. an e theme provides a bg, all sorts of theme elements and module data and icons and more. you can find out if it is a type by just looking for an entry of a particular name that you may desire/want/need. this is entirely freeform text and can/will expand dramatically as more apps do more things and want/need data from an edje file. remember an e theme does not have to be complete - it can provide just 1 small thing - and e will fall back to the default otherwise. for example. so this is not a simple matter of a file having a type - it has a vast number of possible types - and frankly that is determined by the edje group keys, and those are freeform. jose. _ Save hundreds on an Unsecured Loan - Click here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m3iUASETfimAwEe8X9bUmPtTpfLDeW14o6KQy9FK3cdqdWw/ - 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 -- - 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 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] Call for help: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 )
On Fri, 18 Jan 2008 14:00:53 +1000 Ben Martin [EMAIL PROTECTED] babbled: On Fri, 2008-01-18 at 13:50 +1100, Carsten Haitzler wrote: (Resend) What: Gareth from SCALE has really kindly offered Enlightenment.org (that's use guys) free floor/booth space @ SCALE ( http://www.socallinuxexpo.org/ ) Next February (2008). So it looks like I will be there. Also Nathan of EWL fame and work will likely be there. Is there anyone else in the area (This is southern califronia) who wants to join and help put together/man a booth and at an expo? Hands up now? Suggestions on things to do are welcome. I sort of assumed that maybe folks just sent their suggestions directly to you before thus the low list traffic on the topic :/ I'd go for having demos running on the '73, n8x0 and laptop machine. Maybe pushing the fact that the same edje file is running on all three devices if using emotion that the source code is identical. Though I have no doubt that you are already planning to have those devices demoing I'd be pushing the same easy API, same code angle. Also if emotion works well on the n8x0 I'd have that going as part of a demo loop or available for easy exhibition. i actually haven't built libxine and/or emotion for the n800 or my neo(s). :/ it likely will NOT run that well... :( Unfortunately its too early to demo gevas on meamo and its integration... maybe in 6 months ;) It would be cool to have+show reimplementations of some older games running purely or very heavily in edje/embryo, maybe one day I'll get around to brewing some off :| sure - though i'm unlikely to get time to brew any demos by SCALE. :( -- - 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 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] Epsilon problems
On Tue, 15 Jan 2008 09:36:13 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: see my other mail. load-size is an option. a loader implements it ONLY if it can do a scale-down on load for free. it is a hint, not a requirement. you need to load, then check image size and see if you need to adjust/scale later yourself. so only the svg loader will scale to the size u want - as it can. the others wont' do anything. the jpeg loader will chose the nearest scale size it can manage (which is 1/2, 1/4 or 1/8th the width/height of the original jpeg file - that's all it can do. this it gets for free tho on load. in fact load is faster the more u scale down). Man, we all say some silly things in time, but this has to be one of the good ones from you. :) It's a 'load option' so it's fine for this to be 'optionally' implemented in a loader? Wow! correct. load options include things like DPI settings. do you expect every loader to now scale images based on DPI - the loader doesnt even know what the DPI of most image formats is - will it fake one (eg 75dpi) just to make this work ? these options are there if the loader can do something easily/for free while loading. for some formats like SVG rendering at a DPI is part of loading - or at a size, so it comes for free. for jpeg scaling down by 2, 4 or 8 in each dimension is for free. if every loader implements this i also need to add controls over the scalign quality (smooth or samples for example). Tell me, given that this is really trivial to add in evas, and you end up going thru inefficient loopshoops to get the 'option' to actually work in a 'non-optional' way, then why not just have this actually work? i'd be a lot of changes to a lot of loaders and it would not be universal as above - dpi is entirely optional as most formats don't have a dpi of the image. so some things would/could work, some could not. i chose to go the whole only do it if you can do it directly with the format option. I think evas needs to add an image saving 'size' option, maybe best done via the current flags for saving, so that you can save an image that alreday exists at some size (for whatever reason), to a file at whatever other size one wants. not sure we should do that - as above - its possible to do this with buffer canvases and objects. it's much more flexible as i can ALSO put MULTIPLE objects into the thumb then. i can add watermarks and more to them. Sure, you can do all sorts of things.. but it doesn't mean that it's always the best way to get something simple done. Other than new work required to add something like this via the api, why do you feel that maybe it shouldn't be done? because it now makes savers more complex, adds in a single feature for what is a single use case and is not more generally useful. the buffer canvases do all of it - there is no need to add a saver scale option imho. it just puts more work into every saver (and loader) that is already generic and shared with a common single api (evas itself). ** I doubt it worth the pain, because if we go FDO we must remove any attempt to use .edj as thumbnail format, and it's a good alternative if you want to provide movie thumbnail. Going too generic may hurt more than help if nobody else use it, and believe me these guys are hard to get using done by others, you know the NIH syndrome... agreed it will be painful. i don't think we should force edje into a thumbnail format - BUT eet is possibly useful there as its agnostic when it comes to glib, qt, efl etc.. the gtnome/kde crowd as best i know do not have any such container format handler to pack many data items compactly into a single file with an easy api to access it again. so we are not competing. I can't see why what FDO wants or doesn't want to support as 'acceptable' formats should stop anyone from doing otherwise. In fact, I can't understand why any reasonable, OPEN format would not be acceptable, nor the reason for *requiring* that some particular format *must* be accepted.. and none others?? None of this sounds to me like a body whose decisions should be respected - if indeed that's the way it operates.. it doesn't sound to me like the spirit of foss to do so. a lot of foss is not what u think it would be. there is a lot of political infighting, ego stroking and other things that are not related to being open and free - often open and free decisions make way way for personal ambitions. if we present a format that does not have a native g-whatever or k/qt-whatever implementation it basically will be shunned. if we have a format that is not dependent on our own libs (eg edje depends on evas, ecore and edje so it would suck them into kde/gnome) and is stand-alone it has a better chance as it can be seen as less of an invasion from the nih lands. but in the end - standards bodies - FOSS ones included, are
Re: [E-devel] EET and EDJE improvements
On Fri, 4 Jan 2008 23:02:06 +0100 Cedric BAIL [EMAIL PROTECTED] babbled: Hi, I am looking for a way to improve edje file load time. Right now a large amount of time is logically lost in _eet_data_descriptor_decode. So looking at its profile, most of the time is lost in manipulating string. understandable - this is the parser that takes a nested and tagged set of data chunks and turns it into in-memory data structure goodness. It took me sometime to understand why we need to strdup all we shouldn't be strdup()ing - we should be evas_stringshare_add()ing. that's what the code does. the string allocator is set to evas_stringshare_add(). this does a hash lookup (intended for read-only string tokens) and reference count of string objects. it will only allocate new ones if not already there. EET_T_STRING before returning them. In fact, it's only needed when the Eet_File_Node is compressed, in other case it's not needed. We could sure - though .edj files will get markedly bigger without compression. what you win on strdup() (or memcpy) you lose on increased disk IO - remember disks are on the order of 1/20th or 1/50th or 1/100th or even slower than memory. sure - once in cache you don't suffer this, but now we consume more disk cache as such. so we need to be careful here. just return a pointer to the string and it will live for as long as someone reference the eet file. So inside eet itself its not needed to malloc/free all EET_T_STRING (as the data is valid during all the runtime of _eet_data_descriptor_decode). sure. though note - this means we need to keep an open file handle to the file - that means if you load 2000 .edj files (eg a directory with 2000+ .edj icons) we will need to consume 2000+ file descriptors. file descriptor counts have limits - often much less than the amount of ram you have, so we need to also be careful here. Outside of Eet, we have two possibilities : - we don't change anything (just duplicating all EET_T_STRING in str_alloc like we do now) - we can pass a flag to let the application know that the pointer will live as long as the Eet file referenced. AND we can't compress. The second solution will break all application using Eet_Data_Descriptor_Class as we will need to change str_alloc prototype. I know that Edje and E are using Eet directly, perhaps Rage also. But the first change could be minimal, just a small wrapper that ignore the flag and always dup, will do the job. For Edje, most of EET_T_STRING are in edje_file Eet_File_Node and guess what it's compressed. So it will require modification to edje_cc_out.c to choose if we want to compress this Eet_File_Node or not (could depend on a command line parameter for example). this would be all the strings for the collection names in the edj file. an index as to where to find them. I did a quick implementation of this idea, and load time did improve (around 10% global speed improvement in my test case). eet_data_descriptor_decode doesn't use as much time in load process as before (from 30% of total load time to 15%). The draw back is edje file size increase, as an example for Enlightenment theme it will increase from 2.5M to 2.6M. As making a clean patch for this will take time, I would like to have comments and feed back on this idea before. 10% is a speedup - but not too much of one. gustavo has a very good point of being able to use the file directly and let mmap() handle it. though beware that mmap is only as granular as a page so we would want to cram all our data into page-aligned segments. as you say - strings are repeated a lot. that's because they are written 'verbatim. eet's output has no string dictionary. it writes the actual string (either the element tag name or content). so as such - eet_data.c (the stuff that handles data encoding/decoding) which it layered on top of normal eet stuff, would need to be extended/changed to allow a decoder to request strings as they are now (duplicated via the duplicator callback - whatever it is. for edje and e it's evas_stringshare_add ()), OR to be returned direct from the file with the understanding you will NEED to keep the file handle open. in fact we can chnage this without breaking anything. look at Eet_Data_Descriptor_Class - it's designed to be able to be versioned and extended over time. you can add new str_alloc and str_free funcs at the end - and increment eet's EET_DATA_DESCRIPTOR_CLASS_VERSION. we can add str_direct_alloc() and str_direct_free() members - they just return pointers to a string dictionary segment that holds ALL the string tokens for a eet data descriptor encoded chunk, so the string itself in the chunk is now just a reference offset into the string table (eg 82 bytes into the string table is the string u want), so all strings are now 4byte (32bit) offsets into this chunk (ok - limit of 4GB of strings per chunk. i think we'll live). if set these funcs to non-NULL AND set str_alloc() and
Re: [E-devel] New blog entry - Window manipulation and focus configuration nightmare
On Sun, 30 Dec 2007 18:54:11 +0100 Andreas Volz [EMAIL PROTECTED] babbled: Hello, Since the last months I noticed that E17 is becoming really stable from the technical side. Thanks for this great window manager! But on the other side I noticed that the configuration usability is sometimes a nightmare. The topics are sometimes to big to write them into a single bug report. Because of this I decided to write a blog entry about E17 usability. If you like we could discuss below the article or here about my points. These are only my two cents, but I think maybe someone else could have the same problems. Here is the link to my blog: http://andreasvolz.wordpress.com/ And here a link to this special article: http://andreasvolz.wordpress.com/2007/12/30/e17-window-manipulation-and-configuration-nightmare/ I don't like to flame anyone with my ideas. I hope you see it as useful help. Currently I'm to busy in my job to participate more in E17 development. But perhaps I'm able to help with some usability articles. i would agree to pretty much all you said - a lot of the config ui is due to limited widgets and capabilities - we can MASSIVELY improve this. hell - the config dialogs are all modules now. they can be replaced each with better ones. if each person basically took on board 1 config dialog (module) and for the next 6 months did NOTHING but tried to improve the UI so its incredibly slick, compact, obvious to use and well-worded - we could have things much better. -- - 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 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] Gevas (was: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 ))
On Fri, 18 Jan 2008 14:16:00 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: On Jan 18, 2008 1:57 PM, Michael 'Mickey' Lauer [EMAIL PROTECTED] wrote: Ben Martin wrote: Unfortunately its too early to demo gevas on meamo and its integration... maybe in 6 months You've been doing or will do more work on that? Great! I'm very interested in combining glib and ecore mainloops. What's your general experience with that? (yes, I've seen gevas in CVS). AFAICT it uses another thread that communicates using pipe. I already talked to raster about ecore-glib mainloop integration and the problems so far are: - ecore cannot be created on top of glib because it have more primitives (idler_enterer, idle_exiter) - glib cannot be created on top of ecore because it expects the primitives to be thread-safe, so you can use g_idle_add() and g_timeout_add() from threads, people often use this to schedule things to be run on the graphics thread (instead of using pipes). So we can have both approaches: suggesting glib to have more primitives or adding locks around globals manipulation. while i have nothing against adding locks on primitives - if we do it in one place (ecore) we will need to start doing it everywhere. locks will add overhead. those on limited computing (embedded devices) will feel it most. also if we look at the work needed to add it everywhere - that's not a small undertaking at all. i have decided in the past not to bother as gustavo put this clearly - i kind of expect people to have threads do entirely independent things outside the main gui thread and communicate back cleanly via pipes - glib expects people to use threads with glib and has primitives for making them interact directly with the main loop from a thread. different design approaches there. right now i (personally) thing the best way to integrate is to have ecore main loop and glib main loop run in separate threads, with them communicating via pipes used to glue them together. maybe some pipe wrapping/handling stuff in ecore might help with this? -- 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 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 -- - 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 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] Gevas (was: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 ))
On Jan 18, 2008 10:41 PM, Ben Martin [EMAIL PROTECTED] wrote: On Fri, 2008-01-18 at 22:27 -0300, Gustavo Sverzut Barbieri wrote: On Jan 18, 2008 10:21 PM, Ben Martin [EMAIL PROTECTED] wrote: On Sat, 2008-01-19 at 10:21 +1100, Carsten Haitzler wrote: while i have nothing against adding locks on primitives - if we do it in one place (ecore) we will need to start doing it everywhere. locks will add overhead. those on limited computing (embedded devices) will feel it most. also if we look at the work needed to add it everywhere - that's not a small undertaking at all. i have decided in the past not to bother as gustavo put this clearly - i kind of expect people to have threads do entirely independent things outside the main gui thread and communicate back cleanly via pipes - glib expects people to use threads with glib and has primitives for making them interact directly with the main loop from a thread. different design approaches there. right now i (personally) thing the best way to integrate is to have ecore main loop and glib main loop run in separate threads, with them communicating via pipes used to glue them together. maybe some pipe wrapping/handling stuff in ecore might help with this? That last one will be my fallback position of adding the needed stuff into glib2 becomes to hard / difficult. If we could add these primitives and write one on the top of the other, then we could even try to get EFL approved as glib-friend under the Gnome foundation, specially on GMAE (Gnome Mobile), this would bring us more developers and even companies. It's nothing more than words/marketing, but it helps a lot in the end... right now they just have Cairo (vectorial, slow) and Clutter (3d-oriented, good with hw-accel but the name can say about software performance...). Evas can fit perfectly in the hole of fast 2d graphics/canvas. Edje is also unmatched by existing software. I'm not too sure about the glib-friend branding having too much meaning... but I'm not a CTO ;p Since gevas has been available for quite a while, admittedly only allowing edje/gtk2 integration but no companies (that have contacted me anyway) have been racing in to help advance gevas. If the glib-friend status was really that sort of road block to corporate adoption then surely one would have stood up to buy that branding for gevas. Well, I'm working at INdT and doing EFL for Maemo, a GTK-device and I can tell how difficult is to have people _look_ at non-Gnome technology. Non-tech people (managers) often buy buzzwords and they want to believe some things. You have to write code, show, push... push... push... NOTE: I'm NOT talking about INdT here, but others companies. INdT is a non-profit research center focused on Nokia, so it's easy for us. I heard from 2 companies with M in the name (moto and marvell) _INFORMAL_ requests to get EFL into GMAE so they can sell it to their managers more easy, phrase was somehow like: We already convinced them to use Gnome tech (GMAE), I don't care what is there, it's approved, if you put this wonderful tech there we can use it, otherwise we need to get yet-another-approval, this was after my talk at ELCE-2007 At first we were to use Gevas, but it was a bit unmaintained, then we opted to drop Glib completely and use just EFL + Python, this proved to be a sane decision :-) But it would seem that gevas fits in well on meamo where they want you to use their gtk2 stuff to appear like other maemo apps with tabs etc. So being able to take advantage of evas+ecore while having all the normal trappings of a maemo app might be quite nice. We're pushing a whole-evas UI and being successful. Admittedly iPhone helped _a lot_ here. We were using ETK with custom theme to make regular GUI widgets, but we're now moving for an all-edje solution with great success. What I see is _NOT_ people trying to use EFL with GTK. People are really losing hope of the toolkit itself, and the requirements for such form-focused toolkits (unless you're doing some POS, ERP, ...). What people want is the Gnome stack, things that integrate nicely with your app, like the tons of libraries they provide (libsoup for http/xml/soap, gnomevfs, gstreamer, telepathy, libpurple, various parsers, integrations, ...). But first things first... must, get, device. Did you try the developer's program? -- 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 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list
Re: [E-devel] Gevas (was: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 ))
On Jan 18, 2008 10:21 PM, Ben Martin [EMAIL PROTECTED] wrote: On Sat, 2008-01-19 at 10:21 +1100, Carsten Haitzler wrote: while i have nothing against adding locks on primitives - if we do it in one place (ecore) we will need to start doing it everywhere. locks will add overhead. those on limited computing (embedded devices) will feel it most. also if we look at the work needed to add it everywhere - that's not a small undertaking at all. i have decided in the past not to bother as gustavo put this clearly - i kind of expect people to have threads do entirely independent things outside the main gui thread and communicate back cleanly via pipes - glib expects people to use threads with glib and has primitives for making them interact directly with the main loop from a thread. different design approaches there. right now i (personally) thing the best way to integrate is to have ecore main loop and glib main loop run in separate threads, with them communicating via pipes used to glue them together. maybe some pipe wrapping/handling stuff in ecore might help with this? That last one will be my fallback position of adding the needed stuff into glib2 becomes to hard / difficult. If we could add these primitives and write one on the top of the other, then we could even try to get EFL approved as glib-friend under the Gnome foundation, specially on GMAE (Gnome Mobile), this would bring us more developers and even companies. It's nothing more than words/marketing, but it helps a lot in the end... right now they just have Cairo (vectorial, slow) and Clutter (3d-oriented, good with hw-accel but the name can say about software performance...). Evas can fit perfectly in the hole of fast 2d graphics/canvas. Edje is also unmatched by existing software. -- 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 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] Gevas (was: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 ))
On Jan 18, 2008 8:21 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Fri, 18 Jan 2008 14:16:00 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: On Jan 18, 2008 1:57 PM, Michael 'Mickey' Lauer [EMAIL PROTECTED] wrote: Ben Martin wrote: Unfortunately its too early to demo gevas on meamo and its integration... maybe in 6 months You've been doing or will do more work on that? Great! I'm very interested in combining glib and ecore mainloops. What's your general experience with that? (yes, I've seen gevas in CVS). AFAICT it uses another thread that communicates using pipe. I already talked to raster about ecore-glib mainloop integration and the problems so far are: - ecore cannot be created on top of glib because it have more primitives (idler_enterer, idle_exiter) - glib cannot be created on top of ecore because it expects the primitives to be thread-safe, so you can use g_idle_add() and g_timeout_add() from threads, people often use this to schedule things to be run on the graphics thread (instead of using pipes). So we can have both approaches: suggesting glib to have more primitives or adding locks around globals manipulation. while i have nothing against adding locks on primitives - if we do it in one place (ecore) we will need to start doing it everywhere. locks will add overhead. those on limited computing (embedded devices) will feel it most. also if we look at the work needed to add it everywhere - that's not a small undertaking at all. i have decided in the past not to bother as gustavo put this clearly - i kind of expect people to have threads do entirely independent things outside the main gui thread and communicate back cleanly via pipes - glib expects people to use threads with glib and has primitives for making them interact directly with the main loop from a thread. different design approaches there. right now i (personally) thing the best way to integrate is to have ecore main loop and glib main loop run in separate threads, with them communicating via pipes used to glue them together. maybe some pipe wrapping/handling stuff in ecore might help with this? I really think that the overhead is not noticeable and we can still make it compile-time configurable or even choose the correct implementation at runtime (glib does that, with g_thread_init() or gdk_thread_init() if using GTK/GDK -- http://www.gtk.org/api/2.6/gdk/gdk-Threads.html#gdk-threads-init). I also disagree that we _need_ to provide all ecore primitive as thread safe just because the main-loop ones are. It would be great and help, of course, but it's not necessary. Also, maybe we could revisit some of the code to avoid some globals if we can, it's not a complaint (I don't recall one), but if we find those we could change/fix. As for a helper library, Ulisses did one for python, because the language have some concepts (introspection, mutability) that makes it very easy. It's know as python-dispatcher: http://staff.get-e.org/?p=users/ulisses/python-dispatcher.git;a=summary You just have to annotate some functions with a decorator: @send_to_e_thread_sync(comm) @send_to_e_thread_async(comm) this will send the function to be executed in thread called comm in a synchronous/asynchronous way. it helps a lot and part of it can be done in C as well, but probably much more verbose and explicit :-/ -- 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 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] Vertical Align of Edje Textblock
On Jan 18, 2008 9:16 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Jan 18, 2008 4:19 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Wed, 26 Dec 2007 00:29:27 +0100 Thomas Gstädtner [EMAIL PROTECTED] babbled: Hello people, I'm currently working on my first interface in edje and guess I found a bug in the edje-textblock. As I want to do multi-line captions on buttons, I want to have the textblock centered on the button-graphics. I assumed that the valign-property in the style-block was what I wanted, but neither valign=center nor valign=0.5 works. Horizontal align works perfectly. So I also tried to set the align property for the part itself (even if it should be 0.5 0.5 by default) what didn't work, too. As the valign style-property seems to do nothing at all, I assume that's a bug. Can somebody confirm and fix this? :) valign in a textblock is the alignment WITHIN a line of text - so imagine u have a 30point font and a 8point fount on the same line - valign controls where the 8point font is aligned. this clarify things a bit :-) Maybe someone could add it to the wiki? (please remind me later if nobody does). Done: http://wiki.enlightenment.org/index.php/Edje_Style#Alignment dresb, I added you to the CC so you can update your docs too. -- 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 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] Show disabled style of entry
On Thu, 17 Jan 2008 19:00:02 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: ... actually - you want both. e_entry wraps e_editable. e_editable is a raw bit of text that can be edited - it has no entry box/decoration/background. so you want to emit a disabled state to the entry ANd disable the editable smart too :) On Jan 17, 2008 6:13 PM, Andreas Volz [EMAIL PROTECTED] wrote: Am Thu, 17 Jan 2008 18:00:28 -0300 schrieb Gustavo Sverzut Barbieri: On Jan 17, 2008 3:44 PM, Andreas Volz [EMAIL PROTECTED] wrote: Am Sun, 13 Jan 2008 18:57:56 -0300 schrieb Gustavo Sverzut Barbieri: On Jan 13, 2008 6:16 PM, Adriano Rezende [EMAIL PROTECTED] wrote: On Jan 13, 2008 3:03 PM, Andreas Volz [EMAIL PROTECTED] wrote: Am Sat, 12 Jan 2008 19:44:40 -0300 schrieb Adriano Rezende: I believe you have to emit the signal to sd-editable_object-text_object Search for the following code in your e_entry.c | sd-editable_object = o; | e_editable_theme_set(o, base/theme/widgets, e/widgets/entry); and follow the method e_editable_theme_set. I just took a fast look at the code, so I recommend to test before. Thanks for that hint. I did a better patch and it works now. I think the visual improvement is really nice. http://tux-style.de/tmp/tclock_deactivated_gray.png Now users could see that a text entry is deactivated. I've created a new bug entry about that topic: http://bugzilla.enlightenment.org/show_bug.cgi?id=357 Please review the patch if possible. Commit it or allow me to commit if the patch looks good. Sorry, I don't work on this project. But probably the owner will see the patch and apply the changes. :-) Andreas, Patch looks really small and yes, maybe applied by raster one he have the time to check. As I'm not used to E code, just found something weird with the existing code: edje_object_signal_emit(entry, e,state,enabled, e); Ok, as you noticed correct it was there before my modifications. since entry is not (at least looks like it's not) an Edje object, this will have no effect due defensive programming, edje_object_signal_emit() will find no Edje * with _edje_fetch(obj) and then will return. I just noticed that because I think the signal should be sent to sd-entry_object, not sd-editable_object, it would allow us even to set a clipper and make it transparent, thus disabled items could be semi-transparent! :-) If I'm right and the above code is bogus, then it's just a matter of using sd-entry_object instead of entry, add the theme part and we're done. I think my patch looks good so far. Not sure about the yet existing code. Please one of the E developers should give me the ok for commit the patch. I'll to create some more theme patches in the future and like to know if it's ok this way. Sorry, but if I'm correct and the existing code is wrong, then your patch is useless. Perhaps there's a wrong understanding. Do you say it was wrong before? Then my patch does even not take it worse. And the result is as desired if you look at the screenshot that I attached to the bug report. I'm saying that current code (already commited, in CVS) looks like it was trying to do that, but it is wrong and thus is not working. If the code is fixed and it should work without any patch to _code_ (but we still require the theme patch, modified). I'm talking about e_entry.c line 294: edje_object_signal_emit(entry, e,state,enabled, e); entry is the smart object, not an edje file, so it is doing nothing (due defensive programming in edje_object_signal_emit(), check the code). If this code reads: edje_object_signal_emit(sd-entry_object, e,state,enabled, e); and e/widgets/entry is changed (.edc), then it should work as you want. Notes: 1) I'd use sd-entry_object instead of sd-editable_object because this would free us to do more things, since the editable_object is swallowed inside entry_object, thus we can do things like apply a clipper and change its color, graying it or even making it transparent. 2) I'd not add yet another API call to editable. That's my understanding, what do you think about it? -- 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 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
Re: [E-devel] [PATCH] Cache, software 16 common engine and SDL
On Mon, 7 Jan 2008 18:46:17 +0100 Cedric BAIL [EMAIL PROTECTED] babbled: Hi, This is an updated set of patch for the current CVS head that provide : - cache_improvements.diff: Fix some cache bug (At least the one reported by captainigloo), Cleanup the code, Add some new functionnality that will ease merging engine and make it possible to support 16bpp image also, Reduce file stat request. what bug? - i fixed one while offline - a pretty nasty one. the cache usage was caluclated wrongly and went into 0 land and thus the cache would have a lot of data but think it was empty. i don't want to bring that back - this patch is fairly big. - sdl_improvements.diff: Use as much as possible SDL_FIllRect, use new cache API. i'll put this on hold pending the cache above patch :) - soft16_common.diff: Use new cache API, Move all soft16 common function inside engine directory. - soft16_engine.diff: Use new cache API, add SDL 16bpp engine. You will need to apply all patch if you want to use 16bpp engine or SDL engine. Good review :) gustavo - 16bpp changes ok in principle (assuming the cache patch above goes in)? -- Cedric BAIL -- - 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 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] Blender fullscreen mode
On Sun, 30 Dec 2007 13:56:45 +0100 Andreas Volz [EMAIL PROTECTED] babbled: hmm - is blender MANUALLY resizing its window? can o0ther people reproduce? me - i just am happily having my whole xserver segv when any opengl app is run at the moment so i can;'t test until i fix this. Hello, I'm not sure if there's a bug in the E17 fullscreen policy or in Blender, so I'll ask here before filing a bug. blender --help ... Window options: -wForce opening with borders (default) -WForce opening without borders -p sx sy w h Open with lower left corner at sx, sy and width and height w, h Both options work well with other window managers (e.g. Metacity). But they both doesn't work as I expect with E17. If I use option -w it opens in a maximized window, but the window in as big as the complete screen and stays below my lower shelf. To get the desired result I need to resize the window to a small size and then maximize the window again with the maximize button. The option -W is also not working really good. The window is maximized without border, but does still stay below the bar. I know there're much possible configuration settings that influence this. But I'm very confused to finding out the correct ones. BTW: See my next mail about that topic. regards Andreas - 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 -- - 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 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] Ecore_Fb + libts
On Sat, 05 Jan 2008 21:02:52 +0100 Tobias [EMAIL PROTECTED] babbled: Hi all, I've played around with Ecore_Fb on my zaurus and I've run into some problems with events getting through to evas. First, there were some comments about libts support in ecore a couple of weeks ago, this libts implementation (ecore_fb_ts_c) seems to be very ipaq specific, and is not used anywhere and deprecated. that's the code compiled if u don't have tslib support. #ifdef HAVE_TSLIB builds the tslib specific code, and otherwise its the old code i wrote originally for my ipaq 3660 touchscreen etc. frankly at the time i didn't abstract it much at all - i was just happy to make it work :) I've altered it and attach patches here to enable it again and only support the libts mouse events and remove all the ipaq backlightning,led,brightnes...etc stuff, I've also removed the calibration. seems mostly the patches just remove the old ipaq code (most of whihc is dormant) and only leave the tslib specific code - thats really just a old feature cleanup - not sure how it makes things work as opposed to not work (if u built with tslib support). removing the led blink etc. calls are probably good - it's an ipaq specific thing. but what was wrong? if u had tslib - then it should be using it, not ipaq specific touchscreen stuff? Now ecore_event_handler_add(ECORE_FB_EVENT_MOUSE_*...) events works, but I can't get any evas_object_event_callbacks to work (subsequently edje files don't receive any mouse events either). I've tried evas_event_feed_mouse in an app but I can't get any more events than mouse_in and mouse_out fed to the evas_object. I'm not sure I grok evas_event_feed*. these feed in raw events - ecore_evas_fb should have all that hooked up for you - *IF* it is getting events from ecore_fb at all. i'd printf in ecore_fb when it adds events and see if events are being produced at all. Any hints to solve this would be very appreciated, I've looked at ecore_evas_fb.c but can't find anything wrong with it. /Cheers Tobias -- - 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 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] EET and EDJE improvements
On Thu, 10 Jan 2008 08:53:25 -0600 Nathan Ingersoll [EMAIL PROTECTED] babbled: On Jan 10, 2008 7:53 AM, Cedric BAIL [EMAIL PROTECTED] wrote: In the current eet file format, string are inside the directory structure, so they don't have a fixed size and it's usefull during reading to know the size of all directory entries (It's not the direct result of some math, but it need the reading of all directory). With my proposal, I don't think we will need this information neither the size of all stored string. There are no other variable size types stored in the directory structure? not the dir struct - no. the only variably things are: strings (eet dir entry names). we can put these into a single chunk near the start of the file as cedric suggests. then they should pack together into 1,2 or so pages of memory. as they are all unique we can't do much to share them :) the # of directory entries. each one per the changes cedric proposes would become fixed size itself. so technically it would be very easy/fast to decode. if we make sure the table is 32bit aligned in the file we can avoid the EXTRACT_INT stuff to handle aligning them and just read (and byteswap if needed) into memory. this chunk of info should be smaller than the strings so it should gain us something. -- - 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 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
[E-devel] Gevas (was: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 ))
Ben Martin wrote: Unfortunately its too early to demo gevas on meamo and its integration... maybe in 6 months You've been doing or will do more work on that? Great! I'm very interested in combining glib and ecore mainloops. What's your general experience with that? (yes, I've seen gevas in CVS). Regards, :M: -- Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de - 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] Call for help: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 )
On Jan 18, 2008 11:15 PM, Ben Martin [EMAIL PROTECTED] wrote: On Sat, 2008-01-19 at 12:58 +1100, Carsten Haitzler wrote: On Fri, 18 Jan 2008 14:00:53 +1000 Ben Martin [EMAIL PROTECTED] babbled: Also if emotion works well on the n8x0 I'd have that going as part of a demo loop or available for easy exhibition. i actually haven't built libxine and/or emotion for the n800 or my neo(s). :/ it likely will NOT run that well... :( Well, a sub 200mhz smart phone can pull off about 15fps depending on how things are encoded. So I'm still optimistic that an n800 can do acceptably for some video playback... but I'll get back to you on that sometime :) Forget about it. N8xx devices have lots of problems, like a huge screen resolution, slow memory bandwidth, video card problems... to name a few. MPlayer, the best player so far, have lots of optimizations, JIT scaler optimizations, use of double pixel, writes to framebuffer directly in YUV, and can barely play real things. At INdT we really want to backport MPlayer changes to libxine, since we could use it instead of dealing with MPlayer stdout/in and slave mode. Also, it does gapless playback, something we want. But this port is just as simple as compile and run, you need to do some (lots?) of code. And this would solve the problem for regular playback using Xv (maybe FB) and YUV, not going YUV - RGB to be used in Emotion, you have the conversion AND will work with more data, so it's slower on N8xx :-( -- 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 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] Gevas (was: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 ))
On Sat, 2008-01-19 at 10:21 +1100, Carsten Haitzler wrote: while i have nothing against adding locks on primitives - if we do it in one place (ecore) we will need to start doing it everywhere. locks will add overhead. those on limited computing (embedded devices) will feel it most. also if we look at the work needed to add it everywhere - that's not a small undertaking at all. i have decided in the past not to bother as gustavo put this clearly - i kind of expect people to have threads do entirely independent things outside the main gui thread and communicate back cleanly via pipes - glib expects people to use threads with glib and has primitives for making them interact directly with the main loop from a thread. different design approaches there. right now i (personally) thing the best way to integrate is to have ecore main loop and glib main loop run in separate threads, with them communicating via pipes used to glue them together. maybe some pipe wrapping/handling stuff in ecore might help with this? That last one will be my fallback position of adding the needed stuff into glib2 becomes to hard / difficult. 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] Gevas (was: E + SCALE ( http://www.socallinuxexpo.org/ Feb 8-10 2008 ))
On Fri, 2008-01-18 at 17:57 +0100, Michael 'Mickey' Lauer wrote: Ben Martin wrote: Unfortunately its too early to demo gevas on meamo and its integration... maybe in 6 months You've been doing or will do more work on that? Great! I'm very interested in combining glib and ecore mainloops. What's your general experience with that? (yes, I've seen gevas in CVS). I always plan to do more work on gevas, finding the time to actually make it happen is another story. I have long planned to force the ecore/glib thing somehow (or maybe in two ways and let the user choose). I don't see that adding the idle_enter stuff to glib2 would be end-of-the-world difficult but I guess time will tell. At the moment the integration is mainly with edje and gevas but if I'm to be tinkering around with a gevas + maemo combo then having a full ecore-gevas hookup would make things easier. 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
[E-devel] Enlightenment actions
Hi, I have a question about enlightenment window manager : I've saw in the source code that some actions were defined, but never enabled : zone_desk_flip_by, zone_desk_flip_to, zone_desk_linear_flip_by and zone_desk_linear_flip_to. In revision 1.88 of e_actions.c , theses functions were completly disabled (cvs comment : #if 0 unused code.) Is it a problem if I submit a patch which re-enable theses functions ? (maybe there is a reason why theses actions had been commented out ?) I wan't to use theses actions to switch desktop on all xinerama screens at the same time. I know some e17 users that may be happy with this behaviour :) Thanks Mat - 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] Call for help: E + SCALE ( http://www.socallinuxexpo.org / Feb 8-10 2008 )
What: Gareth from SCALE has really kindly offered Enlightenment.org (that's use guys) free floor/booth space @ SCALE ( http://www.socal linuxexpo.org/ ) Next February (2008). So it looks like I will be there. Also Nathan of EWL fame and work will likely be there. Is there anyone else in the area (This is southern califronia) who wants to join and help put together/man a booth and at an expo? Hands up now? I can make it there if need be. Suggestions on things to do are welcome. How about taking the opportunity to discuss what could be done to improve the project, to address its weaknesses, to enhance its strenghts, etc.? How about coming up with some concrete short and long-term goals that people can see as real things that can be worked on? (and I don't mean just e17-todos) I'll even start it here by listing some of the next-generation projects in e's cvs. 1. The core efl libs: evas, ecore, eet, embryo, edje, and some language bindings. 2. The utility libs: esmart, efreet, e_dbus, epsilon, evfs, exml, ...? What else belongs here? 3. The main toolkits: ewl, etk, and some language bindings. What are utility libs for these? 4. The important apps: e17, entrance, ...? What else belongs here? 5. The utility apps: edje_cc, ... What else should go here? 5. Other apps: What should go here? What are short/long-term goals, aims, roadmaps, progress, ... for these things? What about for how they 'fit together'? What's important in E and what's just incidental? Let's take epsilon for example. There was recent discussion on how to perhaps improve epsilon in this or that way, some ideas and whatnot... But, will anything come of that? Why should anything be done to this lib at all? I'm starting to think that having certain of these special- purpose libs is a bad thing. It just seems to lead to projects falling by the wayside because there's little or no mechanism, or community built around them, to ensure that their fires keep on burning. It might've been better if epsilon had been an 'ecore_thumb'. Maybe then there would've been more attention paid to it over time. Ecore may be a mish-mash of things, and some dependencies there might be a bit twisted... But it's ONE identifiable important thing that many people look at and work on. Much the same could be said about e17 as well.. it at least manages to stay focused and un-fragmented. jose. _ Chart your path to success with a smart new business plan. Click here! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nojL2rIySqaVgJajQyq8UopyPUUiwgkMYrxPeEyvcbDFiAI/ - 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] patch: max in textblocks
El Sunday 13 January 2008 22:45:33 Carsten Haitzler escribió: On Sun, 9 Dec 2007 19:36:03 -0300 andres [EMAIL PROTECTED] babbled: I had a problem with textblocks in Edje, even when text.max was set to true for both axis, on resize it was being ignored. ... http://pastebin.com/m1f173f3c hmm - what happened to this - pastebin has it no longer? I submited a bug in bugzilla about this. In the patch I basically copied the the code that dealt with the min property and changed min to max. Feels nasty but it worked for me. See: http://bugzilla.enlightenment.org/show_bug.cgi?id=349 Shameless plug. I'm working on a book about Edje, this is THE moment for feedback. Specially if you think I omitted something or that it's all a bounch of crap. See: http://wiki.enlightenment.org/index.php/User:Dresb - 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] [RFC] get-e.org integration in wallpaper configuration module
On Fri, 18 Jan 2008 00:27:44 +0100 Massimiliano Calamelli [EMAIL PROTECTED] babbled: ok first the bad (it's short): 1. initial size of the dialog is tiny - no space for the website list or thumbail list. need to have it be a sane size at the start. 2. you have parse bugs and segv's. use valgrind and see :) 3. i might just rename websites button to online - really minor, and websites frame to sources. so you need to fix #1 and #2 first :) 3 is minor. now the good. this is fantastic. nice nice nice! i had hoped to eventually get to this - maybe in e18. bringing in online content in a very easy way. vry nice!. this of course opens a bit of a floodgate. for now - lets not do themes and other things. lets ONLY make an online wallpaper fetcher and make it good - use it as our prototype/test case. many things here come out of this can of worms. 1. http procies. yes libcurl will use HTTP_PROXY environment vars - but there is no way for a user to set this with e - they have to edit their shell env. we probably need to have e be able to set this env var itself from its own config - if the user desires to have a proxy set. a proxy config settign in e and a config module to set it would be good/useful here. 2. no way to add more sites (yet) need this. a user should be able to type in a url, and if the site handles the same RSS feed format and data - then it should work. this would allow for other people to provide their own data feeds online. 3. i'd LOVE to see a way for a user to... SUBMIT content. lets say they make a nice wallpaper of their own - they want to submit it for the repository/feed - they just press the submit button and the code does the rest (does an http post or upload with the data etc.) 4. as suggested bu laurent - being able to vote a wallpaper as good or bad - or any content might be nice. 5. you want to make a .tmp/ directory in the download dir for the thumbnails/previews. why? AS they download efm will keep getting file changed events and keep trying to generate thumbnails. you want to create an invisible .tmp/ dir and download into there - then when the download is done, rename() (mv) the file from the .tmp dir into the parent. then it will appear in 1 go when done cleanly and efficiently. renames are atomic in unix so this should be exactly what you need 6. this may lead to wanting to make a much more abstracted bit of code for downloading and previewing content. so we could have a core piece of shared code that does the: * rss fetching, caching, parsing and building of a list of content to download * downloading of previews, generating a directory of preview content with filenames and the whole rename() and .tmp dir stuff as well as caching. * downloading of the real content once selected and any download status (progress/whatever) as needed. * handles a generic way to submit content * handles a generic way to add new repositories via a dialog and a user typing in a URL * have a central list of all known repositories also online somewhere (get-e.org or enlightenment.org) and a way for anyone to submit their repo to it. this way users can update/get new repositories whenever they become available. as long as we make it really fast easy to have your repository added without fuss - this should work well. note - i don't see this as a must for e17 - but if this can get done nicely and well before e17 release - i am more than happy to include it. once we have this right and done well for wallpapers we can expand to themes, icons and anything else - even modules (this gets a bit complex as u need to have the module compiled for your particular architecture/os or u have to compile it after download which is just nasty). so you basically have done something that is fairly small and simple - but incredibly cool and with a huge amount of potential. Hi, here's the result of my first work on E's internals (and widgets): i wrote a simple addon that allow to select a wallpaper directly from get-e.org, actually only from static backgrounds. Requirements: ecore_file with libcurl support(updated 14 january) How it works: My module get and parse a RSS feed from get-e.org, obtaining a list of images of static backgrounds that actually are available on get-e.org, downloading all images and shows it in efm. When you choose an image and click OK, the module get the real background you've choose, already in edj format, and copy it into ~/.e/e/backgrounds. Now the new wallpaper is available in the first window of wallpaper configuration dialog. Status: This is a preview. It works (just tested 5 minutes ago), and it works fine also without DSL connection (i'm testing it with GPRS/UMTS). I'm sure that something can be done in a better way, and it miss some cool features, like caching of results to avoid useless connections, and proxy support (i'm not sure but i think that it will be done by libcurl internals). Todo: Implement a way to use a image cache to
Re: [E-devel] Call for help: E + SCALE ( http://www.socallinuxexpo.org / Feb 8-10 2008 )
On Fri, 18 Jan 2008 17:55:11 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: What: Gareth from SCALE has really kindly offered Enlightenment.org (that's use guys) free floor/booth space @ SCALE ( http://www.socal linuxexpo.org/ ) Next February (2008). So it looks like I will be there. Also Nathan of EWL fame and work will likely be there. Is there anyone else in the area (This is southern califronia) who wants to join and help put together/man a booth and at an expo? Hands up now? I can make it there if need be. why don't you come just to hang out - since you're there :) Suggestions on things to do are welcome. How about taking the opportunity to discuss what could be done to improve the project, to address its weaknesses, to enhance its strenghts, etc.? How about coming up with some concrete short and long-term goals that people can see as real things that can be worked on? (and I don't mean just e17-todos) at SCALE? that would require enough people are there to make that talk productive as such. that's really hard with everyone so distributed and most people not going to make it there. I'll even start it here by listing some of the next-generation projects in e's cvs. 1. The core efl libs: evas, ecore, eet, embryo, edje, and some language bindings. e./org's trac is 100% intended for this kind of discussion. not day to day bug hunting and such - but a set of things to enhance/fix/do and when (eg do it for e17 - do it for e18, do this post evas 1.0.0 etc.) 2. The utility libs: esmart, efreet, e_dbus, epsilon, evfs, exml, ...? What else belongs here? 3. The main toolkits: ewl, etk, and some language bindings. What are utility libs for these? 4. The important apps: e17, entrance, ...? What else belongs here? 5. The utility apps: edje_cc, ... What else should go here? 5. Other apps: What should go here? What are short/long-term goals, aims, roadmaps, progress, ... for these things? What about for how they 'fit together'? What's important in E and what's just incidental? Let's take epsilon for example. There was recent discussion on how to perhaps improve epsilon in this or that way, some ideas and whatnot... But, will anything come of that? Why should anything be done to this lib at all? someone needs to take the ideas and discussion and basically - turn it into code. if someone is going to do that - and ACTUALLY do it (follow through) then they should speak up and so we know who is doing it :) it's not going to be me - as i said before i need to keep myself limited to what i already have on my plate :/ I'm starting to think that having certain of these special- purpose libs is a bad thing. It just seems to lead to projects falling by the wayside because there's little or no mechanism, or community built around them, to ensure that their fires keep on burning. possibly. It might've been better if epsilon had been an 'ecore_thumb'. Maybe then there would've been more attention paid to it over time. possibly. Ecore may be a mish-mash of things, and some dependencies there might be a bit twisted... But it's ONE identifiable important thing that many people look at and work on. Much the same could be said about e17 as well.. it at least manages to stay focused and un-fragmented. mostly - but splitting can be good too - things that die then just die - they dont follow as dead-weight baggage. you can have separate development timelines and so on. so tis a give and take there of gains and losses. -- - 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 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] Call for help: E + SCALE ( http://www.socallinuxexpo.org / Feb 8-10 2008 )
I can make it there if need be. why don't you come just to hang out - since you're there :) I'm quite far away actually, so while that would be nice, it's not something I'd really consider all that lightly. _ Click to learn about options trading and how to make more money from the pros. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m5bjLdjZYwGQpXLBHsC8LyJMFBgd0XhaorJvqQs53NURr8s/ - 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] Epsilon problems
Man, we all say some silly things in time, but this has to be one of the good ones from you. :) It's a 'load option' so it's fine for this to be 'optionally' implemented in a loader? Wow! correct. load options include things like DPI settings. do you expect every loader to now scale images based on DPI - the loader doesnt even know what the DPI of most image formats is - will it fake one (eg 75dpi) just to make this work ? these options are Yes, because that's exactly what we did (for the one and only loader that respects that, the svg one), except I believe it was 90 dpi not 75 that we used. I can understand some 'option' so particular to a format that it had absolutely no relevance to other formats.. eg. a format might support various kinds of de-compressions, speed vs quality kinds of things or whatnot.. but that's just not what's being adressed here. We're talking about, essentially, about image sizes - likely the most common attribute you can think of for images. there if the loader can do something easily/for free while loading. for some formats like SVG rendering at a DPI is part of loading - or at a size, so it comes for free. for jpeg scaling down by 2, 4 or 8 in each dimension is for free. if every loader implements this i also need to add controls over the scalign quality (smooth or samples for example). None of this has any real bearing on the issue at hand - ie. wether evas itself should do the re-sizing on load, or let everyone who needs it have to copypaste your e17 solution. But it's your call so we'll leave at that. :) _ Live your dreams. Click here to find information on becoming a lawyer. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oFGmcsTG5zvq2NKKrizxPBJOtoZSV14O43SGaQcKaICuQqc/ - 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] E CVS: echo englebass
Enlightenment CVS wrote: Enlightenment CVS committal Author : englebass Project : e_modules Module : echo Dir : e_modules/echo/m4 Modified Files: .cvsignore Log Message: ignore files from gettext === RCS file: /cvs/e/e_modules/echo/m4/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -3 -r1.1 -r1.2 --- .cvsignore9 Jan 2008 23:07:58 - 1.1 +++ .cvsignore18 Jan 2008 18:08:51 - 1.2 @@ -1,28 +1,28 @@ -.deps -.libs -Makefile -Makefile.in -aclocal.m4 -autom4te.cache -config.guess -config.h -config.h.in -config.log -config.rpath -config.status -config.sub -configure -depcomp -install-sh -libtool -m4 -missing -mkinstalldirs -ltmain.sh -stamp-h1 -*.lo -*.la -*.edj -*.spec -*.tar.gz -module.desktop +codeset.m4 +gettext.m4 +glibc21.m4 +iconv.m4 +intdiv0.m4 +intmax.m4 +inttypes-pri.m4 +inttypes.m4 +inttypes_h.m4 +isc-posix.m4 +lcmessage.m4 +lib-ld.m4 +lib-link.m4 +lib-prefix.m4 +longdouble.m4 +longlong.m4 +nls.m4 +po.m4 +printf-posix.m4 +progtest.m4 +signed.m4 +size_max.m4 +stdint_h.m4 +uintmax_t.m4 +ulonglong.m4 +wchar_t.m4 +wint_t.m4 +xsize.m4 W3RD !!! ALLL about ignoring the get-ext . BS imo...pros on the commit !!! :) - 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] E CVS: echo englebass
Enlightenment CVS wrote: Enlightenment CVS committal Author : englebass Project : e_modules Module : echo Dir : e_modules/echo Modified Files: .cvsignore Log Message: Don't ignore m4 dir. === RCS file: /cvs/e/e_modules/echo/.cvsignore,v retrieving revision 1.2 retrieving revision 1.3 diff -u -3 -r1.2 -r1.3 --- .cvsignore10 Jan 2008 20:34:57 - 1.2 +++ .cvsignore18 Jan 2008 18:05:34 - 1.3 @@ -15,7 +15,6 @@ depcomp install-sh libtool -m4 missing mkinstalldirs ltmain.sh Why not ? Most deps there just bogust BS...I know one lang..how may ya reaAIVY leed?? M4 dir++just inc the .m4 au want?? m4.atttr ? dh - 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] E CVS: apps/emprint englebass
Enlightenment CVS wrote:
Enlightenment CVS committal
Author : englebass
Project : e17
Module : apps/emprint
Dir : e17/apps/emprint/src/bin
Modified Files:
main.c
Log Message:
Fix compiler warnings.
===
RCS file: /cvs/e/e17/apps/emprint/src/bin/main.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -3 -r1.9 -r1.10
--- main.c6 Jan 2008 21:32:24 - 1.9
+++ main.c18 Jan 2008 19:41:03 - 1.10
@@ -451,7 +451,7 @@
ecore_x_window_show(input_window);
/* set the mouse pointer */
- if (cursor = ecore_x_cursor_shape_get(ECORE_X_CURSOR_CROSS))
+ if ((cursor = ecore_x_cursor_shape_get(ECORE_X_CURSOR_CROSS)))
ecore_x_window_cursor_set(input_window, cursor);
/* setup handler to recieve click event */
@@ -491,7 +491,7 @@
_em_cb_mouse_down, NULL);
/* set the mouse pointer */
- if (cursor = ecore_x_cursor_shape_get(ECORE_X_CURSOR_CROSS))
+ if ((cursor = ecore_x_cursor_shape_get(ECORE_X_CURSOR_CROSS)))
ecore_x_window_cursor_set(input_window, cursor);
/* create the rubber band */
@@ -654,7 +654,7 @@
if (opts-region)
{
_em_grab_region_end();
- return;
+ return 1;
}
ev = event;
Proges on the event checkhow is the parans en.ediff??
dh
-
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] E CVS: apps/emprint englebass
Enlightenment CVS wrote: Enlightenment CVS committal Author : englebass Project : e17 Module : apps/emprint Dir : e17/apps/emprint Modified Files: .cvsignore Log Message: ignore++ === RCS file: /cvs/e/e17/apps/emprint/.cvsignore,v retrieving revision 1.2 retrieving revision 1.3 diff -u -3 -r1.2 -r1.3 --- .cvsignore4 Jan 2008 17:27:41 - 1.2 +++ .cvsignore18 Jan 2008 19:41:50 - 1.3 @@ -16,3 +16,4 @@ INSTALL config.h config.h.in +stamp-h1 Ho [EMAIL PROTECTED] :) dh - 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] E CVS: echo englebass
Enlightenment CVS wrote: Enlightenment CVS committal Author : englebass Project : e_modules Module : echo Dir : e_modules/echo/src Modified Files: e_mod_alsa.c e_mod_config.c e_mod_main.c Log Message: Fix compile errors. - int err, i = -1; + int i = -1; DunnoLooks similar to me :) dh - 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] E CVS: libs/e_dbus englebass
Enlightenment CVS wrote:
Enlightenment CVS committal
Author : englebass
Project : e17
Module : libs/e_dbus
Dir : e17/libs/e_dbus/src/bin
Modified Files:
notification_daemon.c
Log Message:
parameter is now unsigned
===
RCS file: /cvs/e/e17/libs/e_dbus/src/bin/notification_daemon.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -3 -r1.1 -r1.2
--- notification_daemon.c 29 Oct 2007 02:20:47 - 1.1
+++ notification_daemon.c 18 Jan 2008 18:39:43 - 1.2
@@ -130,7 +130,7 @@
}
void
-cb_close_notification(E_Notification_Daemon *daemon, int notification_id)
+cb_close_notification(E_Notification_Daemon *daemon, unsigned int
notification_id)
{
Daemon_Data *dd;
E_Notification *n;
OkWHY ??? Glad ya notified my before changing my codeTHANKS :P
sh
-
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
