Re: [E-devel] etk?
Hi guys, About the current situation of Etk, I don't think I will work on it anytime soon for several reasons. First of all, for the last months, I haven't really had so much free time to dedicate to Etk, I have been kept quite busy by a lot of things such as school, personnal projects, friends... I also have somehow lost faith in this whole project (not only Etk, but the whole E project), I won't tell more about it, but I don't think the current situation suits me. And another important reason is that I don't think that Etk is innovative enough to be a real step forward... let's face it, it's just another toolkit such as Gtk or Qt, that uses the EFL ok, but there is nothing really innovative about it. I've recently started to work on another project that I find more innovative and interesting. It'll be something like Adobe Flash, but with a real toolkit inside it. It'll be used to create real customized GUI for application, but also to create some gadgets or some games. In fact, something like Edje, but with widgets and with a more powerful scripting language that will allow to have a real control on the animation. I really have nothing to show yet and almost no code written, just a lot of ideas in my head. I'll probably use a lot of code from Etk for the widget side of the project. Anyway.. if anybody who already contributed to Etk wants to become the new maintainer, I'd be glad to hear that the project is not totally dead. I just don't think I'll work on it anymore... Simon Selon Jose Gonzalez [EMAIL PROTECTED]: The recent discussions here about toolkit theming and such has brought up, to me at least, the question of the future of the etk gui-toolkit. From what I can see, there has been little or no work done on this lib in a looong time -- it appears abandoned or maybe just plain un-maintained right now. Simon, etk's maintainer, hasn't been seen in a long time.. and yet there are apps out there that depend on it, eg. edje-editor which I've noticed has a bug report stating that it's impossible to enter text correctly. Moom is working on this in etk...thanks. So, does anyone know what's up with etk.. is it dead, or sleeping, or planning big-things, or what? - 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 - 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] Ecore Split
Is there actually any project that is still using ecore_config? Maybe it could be removed. Ecore_Desktop should be removed too since it's deprecated now. Simon On Mon, 19 Nov 2007 16:46:29 +0100, Jorge Luis Zapata Muga [EMAIL PROTECTED] wrote : Hi, as the ecore split topic is around the ml again, after talking to dj2 on irc there was a crucial point to decide what should stay and what should be split and that's what core means. i agree different people can have different views of what core means. So here is a list of all ecore subsystems and in my opinion what should be moved. Please fill this poll with your own comments so we can have a consensus :) I = inside ecore O = outside ecore ecore I ecore_data I ecore_con I ecore_config O ecore_desktop (wasnt it deprecated by efreet?) ecore_directfb O ecore_evas O ecore_fb O ecore_file I ecore_ipc O ecore_job I ecore_sdl O ecore_txt I ecore_win32 O ecore_x O - 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] News from the E stables
On Wed, 14 Nov 2007 20:44:59 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : Simon wrote: I hope that everyone can be just as excited. I know I am. I smell a new age of... Enlightenment. :) :) I'm really excited about this too! Especially about the new communication plan! I actually even think we should do more on the communication point. It would be great to establish a roadmap for example, with a list of items to get done in priority, for the different release-candidates, with eventually some mock-ups. It would also be good to have a place where designers or users could share easily some UI ideas. And not only for Enlightenment itself, but for all the libs/apps around E. A good thing to do too would be to *really* define the scope of the project. Are we just doing a WM, or are we aiming at something bigger? If this is something bigger, what should be the caracteristics of an E-app? Should it just use EFL? Should it be sexy? These questions would have to be answered if we want to get somewhere imo. Ok, so what is it that you want raster to tell you here? He's already made it clear that his main interest is in the wm and the core efl libs, and that's likely all he really has time for - besides everything else. I'm not interested *only* by raster's opinion as you seem to think! I know these questions have to be answered by *all* the developers: we would have to agree on a common project and we would all have to share the same goals. Currently, there is no limitations, no well-defined bounds and the E project sometimes (often?) goes in several directions that are sometimes opposed, which may result in a big waste of our dev-time. But again, since he's the project leader, things like this keep being thrown at him. Do you really want him to be responsible for the direction of etk too? Or maybe just bless it as the 'official' raster-sanctioned gui toolkit? Being a leader doesn't mean you have to take *all* the decisions! It's not because Raster may only want to work on the WM that our project should only be about getting a working WM. He will not forbid the development of a full desktop-environment that would use E17 as a WM. If all the devs agree on a common desktop-environment project that would be coherent with e17, I see no reason why raster would refuse it. But Raster will/should always make the final decisions about the dev of E17 as it is his baby, as I will always make the decisions about the directions taken by Etk. You can't take away the power of decision from the creator of a project just for the name of community-development. What happens when something like etk or ewl, or some other large 'thing' whose scope in many ways overlaps or even overwhelms the scope of something like the wm, is also part of the E project? If raster says ...we need to..., or ... I'd like to see..., or something similar, then is he speaking for all e, all projects, or just for e-the-wm, or what? Or if he doesn't say anything about 'myProject' then is it irrelevant to E? As I said, imo devs should agree on a common project. Now, if a new sub-project doesn't respect the project's definition or if it is redundant with an existing project, it should not be a part of our common project. That would be the rule to apply with new sub-projects. For existing projects, the problem is more complex, as you can't decide and say to a developer that his own project no longer belongs to our project. But I think that sooner or later, we will have to make choices. There is no good reason to have three different toolkits in the same project, as there is no good reason for several video players or several image-viewers. An application should follow the guidelines set by the project-definition, and there should not be two applications/libraries with the same purpose belonging to the same project. You're the project leader of etk Simon. What do you want to do? How about a framework like javaFX, or Mozilla's xul, or MS's xaml? Would that be something you'd like to see? What are your thoughts on the future of graphical UIs? Do you have a 'roadmap' for etk+whatever? I think the first step to accomplish would be to get all the current widgets usable. For now, some widgets are really far from being finished. The next big step would be to integrate a tool like evolve to be able to build really-customizable UI from a descriptive file. This tool should be directly part of Etk, and it should have a really good and easy-to-use editor. With that, we could start to build really nice apps quite easily, that would be as themable as native Edje apps. It would have to be far more detailled, but that is globally the roadmap I have in mind. jose. _ It pays to Discover. 0% Intro APR. 5% cashback bonus. Apply now!
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 Simon TRENY - 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] E CVS: libs/evas raster
On Tue, 13 Nov 2007 12:15:39 +1100, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : On Wed, 10 Oct 2007 18:23:56 +0200 Christian Hunke [EMAIL PROTECTED] babbled: Its only the out-commenting of the constants in evas_object_main.c. When you just undo this it already works: http://enlightenment.org/viewvc/e17/libs/evas/src/lib/canvas/evas_object_main.c?r1=1.60r2=1.61sortby=date yes - those changes broke etk. there is no good reason i can think of why they should beak it. unless its some reliance on behavior that wasn't necessarily good/intended, but the changes are an improvement to evas. i found things that broke in e17 and fixed them. they were silly things that were bugs waiting to happen, so the changes were good. Actually, Etk uses the smart resize-callback to update a widget when the widget has to be updated (by calling evas_object_resize(widget-smart, widget-w, widget-h). Since the callback is not called anymore if the widget has not really been resized, it broke down Etk when widgets needed a content-update while the widget was not resized. To fix this, now we just call manually the resize-callback when we need to update a widget that has not been resized. Simon - 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] News from the E stables
is the current lack of communication. We do not communicate about anything. People just don't know what is going on. Having weekly meetings with a short summary/report would really help imho! I'm really excited about this idea! :) 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. Imo, e.org is a bit messy. Dan has done a great job to get it simpler, but the section About (which is the most important one) is not well structured imo. 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. Once E17 is out I intend to work hard on taking E mobile. That mans giving it the ability to run beautifully on tiny 1-4 screens or so, from 320x240 up to 800x480 or beyond but work like a charm with touchcreens, stylus's or fingers, with or without a keyboard or other buttons. But above all - it has to be sexy. This will simply be extending E - adding hooks, modules or module replacements. This will not mean E for the desktop is abandoned by me - it means it is simply a parallel focus - I use it every day of my life on every machine I have. Now I want it in the palm of my hand too. I hope that everyone can be just as excited. I know I am. I smell a new age of... Enlightenment. :) I'm really excited about this too! Especially about the new communication plan! I actually even think we should do more on the communication point. It would be great to establish a roadmap for example, with a list of items to get done in priority, for the different release-candidates, with eventually some mock-ups. It would also be good to have a place where designers or users could share easily some UI ideas. And not only for Enlightenment itself, but for all the libs/apps around E. A good thing to do too would be to *really* define the scope of the project. Are we just doing a WM, or are we aiming at something bigger? If this is something bigger, what should be the caracteristics of an E-app? Should it just use EFL? Should it be sexy? These questions would have to be answered if we want to get somewhere imo. Simon TRENY 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] Themes (Was: News from the E stables)
On Tue, 13 Nov 2007 23:36:52 +0100, Morten Nilsen [EMAIL PROTECTED] wrote : Simon TRENY wrote: 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.. :)) My personal favorites are gant and blue eyed.. Found a screenshot of Detour by means of google*, and I guess that theme also looks OK, I just think the recessed 3D-buttons are a bit much, and a candy cane percent bar doesn't really speak to me.. *) http://tinyurl.com/2w3wg4 You can have a more recent screenshot of the Detour theme here: http://mtreny.free.fr/detour.png - 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] Discussion about Evas perfs for scrolling
On Mon, 5 Nov 2007 20:21:05 +0100, Cedric BAIL [EMAIL PROTECTED] wrote : On Sunday 04 November 2007 17:00:27 Gustavo Sverzut Barbieri wrote: On 11/4/07, Simon TRENY [EMAIL PROTECTED] wrote: On Sat, 3 Nov 2007 22:36:49 -0300, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote : On 11/3/07, Simon TRENY [EMAIL PROTECTED] wrote: But with the second solution (the viewport one), you actually have two Evas: one Evas for the application itself (including the view-borders, the scrollbars, the view-background), and one Evas for the content of the view. The second Evas is rendering into a buffer (through the buffer engine), and this buffer is then rendered into the first Evas, inside the scrolled-view. This way, the second Evas (the one where you'll just move the viewport in order to perform scrolling) just contains the objects of the view-content, and so, there will never be any problem when translating the pixels. No broken background. We could even have a semi-transparent overlay over the view, and it would still be possible to do the translation-thing with no artefacts. And this solution should be quite easy to implement in Evas (just need to support viewports that are not located at 0,0). It would increase mem-consumption since you have to render into a buffer, but you still have the choice not to do that for your scrolled-views, so it won't change anything for existing apps. Only the second solution seems usefull, but if we create a full size buffer, we will use much more memory than today. Perhaps it could be possible to have a small buffer that will be near the viewport size plus a delta in each direction. When scrolled, only the hidden part are redraw and some are hidden. If the scrolled part are moved outside of the delta, we just do a memove of the content and we update all the needed part. It's a little bit more complex, but it should require less memory and still provide better performance (A draw back could be that we will not have linear performance, but that's already not the case). Yes, my idea was to only have memory for the viewport geometry. No need to allocate memory for the full Evas since it's not entirely visible. The delta-thing could be great to improve the case where the user scrolls back-and-forth by small offsets, but it would be harder to implement and would require a second buffer (containing only the pixels visible by the viewport, not the delta-borders). So I'm not sure it's worth it. so, it's a optimization that will not help that much. We're doing 800x480 at more than 24fps using an 230Mhz ARM... so I _really_ disagree it's a problem. Well.. on a 1600x1200 view, you have 5 times more pixels to draw. And scrolling a fullscreen tree containing a lot of objects on this resolution is really laggy-ish on my Athlon 1300MHz. And it would even be worse if the resolution goes higher (which tend to be the case with recent screens). With a MIPS at 200Mhz and a screen of 720x576x32, it's really slow when you are require to move many part of the screen. What would help here is a general render-cache, I already discussed this with raster for styled-text and scaled images. Basic idea is quite simple: count the number of times you do certain operation on some object (scale, recolor, text styles... things that are not optimimum) and if some flag is set (cacheable==1) you would create a new buffer and cache this effect, next time you just use it. If you run out of cache space, it would be deleted and no problem. This would help to save lots of expensive operations, but it's quite boring to implement and test. So I'll avoid it until I really need... :-) Yes, it might be useful indeed! :) Regarding the cache mecanism, I really agree that we need to improve it. It should not be to difficult to add scale image to the cache (I already have some idea regarding this). The others (recolor, styled-text) are not yet part of the cache mecanism, and will require more work. But I don't see where you want to put this cacheable flag and when/how you want to set it. You could perhpas describe how you see this new cache function (including recolor and styled-text). 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
[E-devel] Discussion about Evas perfs for scrolling
Hi guys! Evas is a really great lib with very good performances to render a lot of objects, but I think it has one major drawback: it is quite slow when we have to scroll contents (iconbox, list-view, text-view, ...). Indeed, for now, in order to implement this scrolling effect, we have to move all the objects contained in the view. This means that the *entire* view has to be redrawn each time the user scrolls, even by a 1-pixel offset. And if this is a fullscreen view on a 1600x1200 screen, it will require a very powerful CPU in order to have a really smooth scrolling, and I don't think this is acceptable. If we compare the scrolling performances of Evas with the ones of GTK or QT, it's easily noticeable than GTK/QT are *far* more efficient for scrolling! So.. how do they do that? Well, it seems they just don't redraw the entire view, but just the elements that were not previously visible in the view, and that now are visible. Indeed, when scrolling, a big part of the content was already visible and then rendered, and would just require to be translated to the right position. There is indeed no need to redraw the whole view, but just the elements that weren't visible on the previous frame. Now, how can we do this in Evas? I see two solutions here: 1/ We try to detect the areas that can be just translated instead of being redrawn. It would imply no change in current applications in order to get benefit of it, but the algorithm behind it is far from being simple, and it may even use more CPU than it would save from avoiding the whole redraw thing. So, I don't think it's the good way to do that. 2/ We could also use the viewport feature of Evas for this. When scrolling, instead of moving the objects, we could simply move the viewport in the opposite direction. For example, if we'd like a long-scrolled iconbox, we would have a huge Evas containing all the icon-objects of the iconbox, but with a small viewport representing the iconbox-view. Now, when scrolling, no need to move all the icon-objects, we would just have to move the viewport. When moving the viewport, we could then translate all the pixels that are common to the two viewport's geometries, and redraw only the areas that were not in the previous viewport-geometry. This can be done really easily Advantages: it should be a lot easier to implement in Evas, and it will probably give better results. Drawbacks: - Apps would need some adaptations in order to get benefit of this and the scrolled-views would have to use their own buffer-engined Evas (which would mean a bigger memory consumption, but the first solution would also increase memory consumption anyway). - Evas and Evas' engines would need to support viewports that are not placed at 0,0, and viewports that can be moved. But I don't think it should be too hard So, what do you think about this? Any other solution in mind? I'll be glad to hear your opinions! :) Cheers, Simon TRENY 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] New SDL, FB and X11 etk engine with one window.
On Fri, 19 Oct 2007 17:22:11 +0200, Cedric BAIL [EMAIL PROTECTED] wrote : Hi, Follow a patch that use my previous Etk Engine to provide a generic engine for Ecore engine that don't support multiple window (like FB and SDL). It suffer the same bugs of the original Etk SDL engine. So it something in Etk or the way I use Etk. The only hack I don't really like in this patch, is the need to call engine_init a second time with feedback from the sub engine. But it work ! Cedric Hi Cedric, I will probably not have time to review your code this week. I'll try to read it as soon as possible, but it may be in more than a week. Sorry! Thanks for your work! :) Simon TRENY 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] E CVS: libs/etk barbieri (about recent Etk changes)
On Wed, 26 Sep 2007 00:58:05 -0400 (EDT), Enlightenment CVS [EMAIL PROTECTED] wrote : Enlightenment CVS committal Author : barbieri Project : e17 Module : libs/etk Dir : e17/libs/etk/src/lib Log Message: Structures fields reorder to avoid holes and save memory. Have all Etk_Bool inside structures to be a bitfield, reorder fields to provide better packing. Packaging was aided by pahole 1.0 on x86 (http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git) Tested with etk_test and edje_viewer, both still work. PS: bugs may appear due Etk_Bool size change, values like 2 (10b) will now be evaluated as false. That was already a bug, just being exposed now, the fix is easy: use !! (double negative) before the value, example: visible = obj_ptr; becomes visible = !!obj_ptr;. Can I ask you how many bytes per widget do you gain with such a change? I don't really expect it to be more than 300b per widget. Since in an Etk app, you'll most probably never have more than 300 widgets, you'll gain 100kb max, and I'm being **VERY** generous here! :) And I don't think 100kb is really important nowadays, even on embedded devices (whose apps will never have 300 widgets anyway...). So, if you don't mind, I'm going to revert this change, as it introduces code changes that I personally find really ugly (such as visible = !!obj_ptr;...) And, it would have been great if this change had been discussed on the dev ML before being committed. I know I haven't been really active these last weeks, I've been quite busy with school and other projects, but I'd still like to have the opportunity to give my opinion before such a change happens. More generally, there has been a lot of important changes recently in Etk internals, some of them are great, but there also have been changes that I really don't like. I would have appreciated if you (i.e. developers who made these changes) had discussed them publicly and *waited* for my response before committing them. Regards, Simon TRENY 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] Starting programming in EFL
matter, without partiality and without people trolling one toolkit with false arguments only for the sake of convincing us to choose their own toolkit. I think the best you can do to make your choice is too run both ewl_test and etk_test and try all the widgets, and compare the look-and-feel. Simple widgets will obviously feel the same (a button will feel the same way with the two toolkits), but try more complex widgets. If you don't feel any difference, then look at the code of the test apps, and choose the toolkit with the API that you prefer. Open source is also about having choices. It may sometimes (often?) seem messy, but it's all about freedom. You have several browsers, several audio players, several WM, and... several toolkits. That's just the way it is, and it's not gonna change. People are doing this first because they enjoy to do it. Regards, Simon TRENY MoOM Nope. Michael - 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] Evas smart-objects future plans?
On Tue, 21 Aug 2007 08:50:46 +0200, Peter Wehrfritz [EMAIL PROTECTED] wrote : Simon TRENY schrieb: Hi, I've seen in Evas.h that most of the methods of Evas_Smart_Class are marked as to-be-deleted in the future (FIXME: DELETE ME). This concerns show(), hide(), color_set(), clip_set() and clip_unset(). I think it will be indeed a really great thing to do since when we implement these methods for a new smart-object, we basically always do the same thing (i.e clipping member-objects against the parent's clipper in clip_set(), hiding the member-objects in hide_set()...). It will also simplify a lot the code of Etk_Widget as I tried to make these things done automatically but since Etk doesn't have access to Evas internals, it is quite a mess. I'm totally against the idea to clip all smart members to the smart object geometry. I can understand that this is the common case in the view of a toolkit author. But in fact there are many exception I can think of. For example an animation that overlaps the geometry of the smart object, a shadow that overhangs the area of an swallow part, etc.. In elitaire I use this for the cards. The logical card has always the same size, but when you switch on shadows, the card image has an offset outside of this area and only the shadow has the same geometry (position and size) like the smart object. That make it very handy to handle movements of the card and animations like lifting the card at the same time. I don't think we should sacrifice the power of evas smart objects because of a common case that 90% of the smart object use. Think of the remaining 10% percent. This cases need to be handled, too. You could write an convenience object, maybe called evas_object_group, where you only have to set the resize callback and the rest is done internally. But please let the the smart objects as they are. There are many cases where you need the versatility of them. You're right, member-objects should not be clipped to the smart-object geometry, but, I never said they would! I only talked about clipping the member-objects against the smart-object clipper, if there is one. This is definitely not the same, and it makes sense imho (if you clip a card against a rect, you want the shadow to be clipped too). But you will still be able to have parts outside of a Edje group. Simon TRENY MoOm Peter - 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] Evas smart-objects future plans?
On Tue, 21 Aug 2007 10:26:16 +0200, Peter Wehrfritz [EMAIL PROTECTED] wrote : Chady Kassouf schrieb: On 8/21/07, Peter Wehrfritz [EMAIL PROTECTED] wrote: Simon TRENY schrieb: Hi, I've seen in Evas.h that most of the methods of Evas_Smart_Class are marked as to-be-deleted in the future (FIXME: DELETE ME). This concerns show(), hide(), color_set(), clip_set() and clip_unset(). I think it will be indeed a really great thing to do since when we implement these methods for a new smart-object, we basically always do the same thing (i.e clipping member-objects against the parent's clipper in clip_set(), hiding the member-objects in hide_set()...). It will also simplify a lot the code of Etk_Widget as I tried to make these things done automatically but since Etk doesn't have access to Evas internals, it is quite a mess. I'm totally against the idea to clip all smart members to the smart object geometry. I can understand that this is the common case in the view of a toolkit author. But in fact there are many exception I can think of. For example an animation that overlaps the geometry of the smart object, a shadow that overhangs the area of an swallow part, etc.. In elitaire I use this for the cards. The logical card has always the same size, but when you switch on shadows, the card image has an offset outside of this area and only the shadow has the same geometry (position and size) like the smart object. That make it very handy to handle movements of the card and animations like lifting the card at the same time. I don't think we should sacrifice the power of evas smart objects because of a common case that 90% of the smart object use. Think of the remaining 10% percent. This cases need to be handled, too. You could write an convenience object, maybe called evas_object_group, where you only have to set the resize callback and the rest is done internally. But please let the the smart objects as they are. There are many cases where you need the versatility of them. The proposal is NOT for clipping to the parent object's geometry, but to the parent object's clipper. Yes, your case if very valid, but if you're going that route, you probably will have your parent clipper account for the shadows by making it that much bigger to not clip the shadows. Ah, then I misunderstood Simon. So you have a function evas_object_smart_clipper_set() to set the clipper and control the clipper on your own? That could work for me, but I still would prefer to have this in an evas object group or something similar. I don't know, however, if that makes the implementation too complicated. No, you'll still use evas_object_clip_set() to clip the smart-object. And in that case, the member-objects will be clipped automatically against the same clip object. Simon TRENY MoOM Peter - 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] Evas smart-objects future plans?
On Tue, 21 Aug 2007 10:02:03 +1000, Brett Nash [EMAIL PROTECTED] wrote : On Tue, 2007-08-21 at 00:58 +0200, Simon TRENY wrote: Hi, I've seen in Evas.h that most of the methods of Evas_Smart_Class are marked as to-be-deleted in the future (FIXME: DELETE ME). This concerns show(), hide(), color_set(), clip_set() and clip_unset(). I think it will be indeed a really great thing to do since when we implement these methods for a new smart-object, we basically always do the same thing (i.e clipping member-objects against the parent's clipper in clip_set(), hiding the member-objects in hide_set()...). I disagree here. You are correct in that 95+% of cases are just hide/show the clip and the like. However we have a number of widgets that do things like stop animations, release resources or similar actions on hide calls, also more complex widgets delay layout recalculations until the show call. About doing stuff on show, you'll still be able to do this. You'll just need to have a callback to the SHOW event of the smart-object (with evas_object_event_callback_add()). As for evas_object_hide(), maybe you just shouldn't call it for what you are doing. You could have a function my_smart_object_hide() that will do all the animations, and that will finally call evas_object_hide() on the smart-object at the end of the animations. Imho, evas_object_hide() should really hide the object. And since smart-objects have been designed to form a logical group from compound evas-objects, evas_object_hide() should hide the smart-object and all its member-objects. It wouldn't be coherent to have evas_object_visible_get(smart) returning 0, and still have a member-object being visible. The state of the member-objects should automatically inherit from the state of their parents if we want to keep things logical imho. Regards, Simon TRENY MoOm However being able to set the calls to NULL, and allow evas to do the obvious things in these cases. Regards, nash - 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
[E-devel] Evas smart-objects future plans?
Hi, I've seen in Evas.h that most of the methods of Evas_Smart_Class are marked as to-be-deleted in the future (FIXME: DELETE ME). This concerns show(), hide(), color_set(), clip_set() and clip_unset(). I think it will be indeed a really great thing to do since when we implement these methods for a new smart-object, we basically always do the same thing (i.e clipping member-objects against the parent's clipper in clip_set(), hiding the member-objects in hide_set()...). It will also simplify a lot the code of Etk_Widget as I tried to make these things done automatically but since Etk doesn't have access to Evas internals, it is quite a mess. I'm willing to try to implement those things in Evas, but first I'd like to be sure of the behaviour to respect: - A member-object should be really visible only if its parent is visible and if it is set as visible (evas_object_visible_get() == 1). It would remove the need for show() and hide() - A member-object should be clipped by the intersection of its clipper and of its parent's clipper. It would remove the need for clip_set() and clip_unset() - The member-objects' color should be automatically multiplied by its parent's color at rendering (-- no more need for color_set()). Actually, I'm not sure about this last point. What if the user would absolutely want to have a member-object always green for example, regardless to the color of its parent? I can see a use for this: in estickies, the window is semi-transparent while the text is opaque, and yet, the text is a member-object of the window. Are you ok with this? Do you have any other requirements for the smart-objects? Regards, Simon TRENY 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] evas_list_free API change
Instead of this, I would prefer to have: evas_list_free_cb_set(Evas_List *list, void (*free_cb)(void *data, void user_data), void *user_data); This way, you don't break the API and the free-callback could be called also when an item is removed from the list with evas_list_remove(). Simon On Fri, 27 Jul 2007 08:08:55 +0200, Sebastian Dransfeld [EMAIL PROTECTED] wrote : Does someone mind if I change evas_list_free(list); to evas_list_free(list, free_cb); We would save a lot of lines in E if we could do evas_list_free(list, e_object_del); Sebastian - 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
[E-devel] Is this a community project?
Hi guys, Recent discussions about config dialogs being moved to modules leads me to a question I've been asking myself quite often recently. I'm working on the E-project for at least a couple of years now, and actually, I still can't tell what is the scope of this project? How would you define it? Are we just working on a WM or are we trying to have a decent desktop environment? If we are working on a WM, should it include a FM (well.. it seems so..), should it have its own toolkit (it seems so too...)? Does it aim to be a WM for desktop configs or for embedded devices? And if this project is about getting a nice desktop environment, what apps should be part of it? What should be the point in common of all these apps? Is using the EFL enough to be a part of the environment? Or maybe we should have guidelines that all the apps would have to respect (like the Gnome HIG)?! I'm pretty sure that we can't find two devs with the exact same definition of the project. We all see it differently! In these conditions, how can we work together on this? If this a one-man project, it's ok to share nothing.. But since it *tends* to be a community project, we need to share ideas and to establish a common project on which we all agree! If I could have known two years ago that e17 would now have its own toolkit, its own FM, its config dialogs moved to modules, shelves and a lot of other recent changes that I don't necessarily agree with, I would probably have not spent so much time on this project.. And I know I'm not the only dev feeling like this right now... It would be nice if evolutions were discussed publicly on the ML. For now, it just seems that when one dev wants a new feature, he implements it without asking others what they think about it. And most of these new features were not even in the TODO list before... Personally, I don't think I will ever commit any other code to this CVS (on Etk mainly) if I don't feel the situation has changed (i.e. if we don't have a precise roadmap and if we don't have defined precisely the scope of the project). I'll probably just move Etk and other projects I have in mind to another place. It's not a threat or blackmail (anyway, I'm pretty sure most of the devs working on e17 don't even care about Etk...), I just don't see why I would share a CVS with a project that I can't even define and that I can't even tell where it is heading toward.. Regards, Simon - 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] RFC evas_object_transform()
On Sat, 19 May 2007 09:35:25 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : On Sat, 12 May 2007 10:58:26 +0200 Simon TRENY [EMAIL PROTECTED] babbled: On Sat, 12 May 2007 07:14:04 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : Carsten wrote: personally, as an intermediate-step i'd like to simply be able to modify the FILL of an image (or text object) so the FILL can be transformed (we need to be able to disable tiling for images). this will then allow for us to provide transformed image data but within a rect - allowing us to worry about events later but get the benefits of the visual elements now. I've already done all this. No need to 'disable tiling', that's what the fill-spread modes are for. Recall the shaped-gradient I once sent? Same thing.. except that here we take into account borders and hq down scaling (for the software engines). The gl engine is still a problem - if one wants to do things strictly with gl - since I need code to render to a texture buffer (though it may be possible to use a quad mesh or some such?). For the GL engine, you can probably modify the texture matrix to transform the filling of an image. I'm not sure how well it would work with borders though (but actually, what borders mean when the fill is transformed?) that is a good question. what do borders mean then? i would say that borders remain unscaled at the bounds of the transformed quad (the quad being the bounds of the image post-transform). Actually, I think it would make more sense if the borders were applied before the transform. Imo, borders describe how the original texture should scale. If the texture is already transformed when borders are applied, it won't be easy/intuitive to predict the result. And it would allow to rotate a bordered-scaled-rectangle for example. If the borders were applied after the transform, the borders of the rectangle would look really weird. yup. you can convert a scale + rotate INTO a transform matrix, but not the other way around (easily). Not difficult - it's impossible in general.. and much depends on the order one wants the transforms to be applied. jose. - 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 - 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 - 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] RFC evas_object_transform()
On Sat, 12 May 2007 07:14:04 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : Carsten wrote: personally, as an intermediate-step i'd like to simply be able to modify the FILL of an image (or text object) so the FILL can be transformed (we need to be able to disable tiling for images). this will then allow for us to provide transformed image data but within a rect - allowing us to worry about events later but get the benefits of the visual elements now. I've already done all this. No need to 'disable tiling', that's what the fill-spread modes are for. Recall the shaped-gradient I once sent? Same thing.. except that here we take into account borders and hq down scaling (for the software engines). The gl engine is still a problem - if one wants to do things strictly with gl - since I need code to render to a texture buffer (though it may be possible to use a quad mesh or some such?). For the GL engine, you can probably modify the texture matrix to transform the filling of an image. I'm not sure how well it would work with borders though (but actually, what borders mean when the fill is transformed?) yup. you can convert a scale + rotate INTO a transform matrix, but not the other way around (easily). Not difficult - it's impossible in general.. and much depends on the order one wants the transforms to be applied. jose. - 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 - 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] [RFC] SDL Engine
On Mon, 30 Apr 2007 12:34:25 +0900,
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote :
On Wed, 25 Apr 2007 01:17:56 +0200 Simon TRENY [EMAIL PROTECTED]
babbled:
On Tue, 24 Apr 2007 14:41:22 +0900,
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote :
On Mon, 9 Apr 2007 10:16:56 +0200 Simon TRENY
[EMAIL PROTECTED] babbled:
On Fri, 6 Apr 2007 15:21:52 +0200,
Cedric BAIL [EMAIL PROTECTED] wrote :
I did visit the sdl website, and there seems to be
mention of using OpenGL with SDL... Is it possible to
maybe also have a gl_sdl version of the engine.. ie. one
which would presumably use some gl rendering?
I did think about that also, but I must have some priority. So
first I want to have an Ecore with all others EFL running
cleany with the software_sdl. So it's definitively possible
in my opinion, but not really on top of my TODO list :)
I have some experience with SDL + OpenGL and there is nothing
different between using OpenGL with SDL and using OpenGL with an
X11 window (OpenGL-wise). The only differences are the calls
that depends on the windowing system: the creation of the GL
context and the swapping of the front/back buffers. But I don't
think it's worth it to create an Evas engine for OpenGL+SDL. It
will be exactly the same as the GL-X11 engine (i.e just a
wrapper of the GL-common engine).
agreed. in fact the sdl engine is strange. it allocates sdl
surfaces for images
- but really doesnt do anything more than the software engine.
there is not any good reason for this, and really the sdl engine
shouldnt need to be any more than just an sdl wrapper handling
the windowing system interfacing and display of ARGB32 data to
the screen - the rest can be the software engine as-is.
Actually, I don't think there should be a GL-X11 engine in Evas
at all. Just the GL-common engine should be enough. Then all
the code to create the GL-context and to swap the buffers (that
is to say, all the code that is currently in the GL-X11 engine)
should be moved to Ecore_Evas imho. This way, if we'd like to
use OpenGL+SDL or OpenGL+Win32, there will be no need to create
a new Evas engine. We would just have to create the window, the
GL-context and to use it with the GL-common engine of Evas (all
of these could be done in Ecore_Evas). And it will make it
possible to use Evas in your own OpenGL app which already has
its own GL context: for example, you could use Evas for the GUI
of an OpenGL game, which could be really cool imho :)
i disagree. currently the engine does the swaps because that is
the onyl sane way to get performance with gl. in theory it should
render updates like the software engines do - render the update
regions to a pbuffer/texture then copy to the frontbffer instead
of allocating a whole backbuffer for the window. the problem is
that if you expose this, this mechanism is no longer tweakable by
the engine. the software engines dont force you to do anything
special before or after rendering to make them display, and the
gl engine shouldnt either imho.
I see what you mean, and actually, it's just a design problem.
But the thing is, because of this design issue, the GL engine is
far more limited that what it could actually do. The only thing we
would need to make it as powerful as it could be would be to change
Ecore_Evas_GL_X11 from this:
1. Creation of a drawable
2. Creation of the GL-engine from the drawable
3. While (1) do { engine-render() }
to this:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
2. Creation of the GL-engine
3. While (1) do { engine-render(); swap_buffers(GL-context) }
but by doing this you ASSUME the mechanism for updating IS a
glxswapbuffers - what if it isn't? what if we change it to do what i
said (render to texture/pbuffer, then copy that to the frontbuffer) -
maybe it might do things differently based on the driver (some
drivers might be able to accelerate this, some may not).? the gl
engine in this regard is no less limited than the software_x11 -
EXCEPt it doesnt allow alternate drawable targets (pixmaps). what YOU
want is the ability for the gl engine to render to a texture or
pbuffer - and you get to specify that texture/pbuffer. that is what
you really want. it would then work no differently to the software
and xrender engines that can have pixmaps specified as targets (as a
pixmap and window are the same for rendering purposes here).
Actually, what I really want is a GL engine that is not aware of the
rendering-target, i.e. an engine that can render indifferently to the
backbuffer, to the fronbuffer, to a texture, to a pbuffer... and
independently of the windowing system used. Here would be the different
schemes to do these things with this generic GL engine:
Backbuffer + double
Re: [E-devel] itask engaged - pre alpha release
On Wed, 25 Apr 2007 10:18:46 +0200, Thomas Kuther [EMAIL PROTECTED] wrote : On Mi, 25.04.07 00:18 Simon TRENY [EMAIL PROTECTED] wrote: On Tue, 24 Apr 2007 08:39:06 +0200, Igor \FeR\ Scabini [EMAIL PROTECTED] wrote : Daniel Kasak ha scritto: Hannes Janetzek wrote: Hi, itask_ng starts to get usable. So if someone wants to try it's available from svn: http://itask-module.googlecode.com/svn/trunk/ itask-module/itask_ng a video is here (it looks better in reality, this was recorded with 4fps) http://video.google.de/videoplay?docid=-1525947350649682737 there's a README that explains how to set up the shelf correctly. Looks good :) Actually I'd like to see the engage-like scaling in an app *launcher* as well as a task manager, but anyway ... it's good. I assume the goal is to drop the 116-pixel requirement for making it look nice? I still have a problem that I can replicate very well: sometimes when I left-click on an icon in itask module the shelv menu open and the app too, so this *feature* is only annoing me, not stopping using this module. The README file did spark some questions though: you need to have composite manager running like for example xcompmgr, bling, egloo or bang I'll be good and not ask when bang is coming :) But what is egloo? I googled for it and found absolutely nothing. Not announced yet? Dan You can find egloo here: http://mtreny.free.fr/egloo/ I don't know anything about the author and development plan, from the video it loooks good. The code that can be found here is not supposed to work at all. It is totally outdated and was only here as a backup in case I have a problem with my harddrive... :) And egloo doesn't even handle alpha-ed windows yet, so it has no use with itask (nice module btw :)) Simon Hehe, beside a segfault on restart, it works here (and I have to disable dropshadow module) Great, could you tell me which graphic-card you are using? And are using it with XGL or directly with the classic Xorg server? The mosaic is such a great usability++, I really love it (already from beryl and OS X). If this could be integrated into bling, or the other way round, this would plain rock! (Why not join efforts there btw?) I don't think bling and egloo have the same goals. But maybe Egloo and Bang could be one unique project (I thought bang was dead) And it's very nice to see engage returning in some way. itask is great, so was engage. itask_ng will kick ass then :) Cheers. Tom - 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] Ideas for a new 'desklet'-module api
On Wed, 25 Apr 2007 08:07:27 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : On Wed, 25 Apr 2007 00:13:22 +0200 Simon TRENY [EMAIL PROTECTED] babbled: On Tue, 24 Apr 2007 15:11:42 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : On Wed, 18 Apr 2007 21:29:05 +0200 Hannes Janetzek [EMAIL PROTECTED] babbled: simple answer: 1. use gadcon 2. add a generic layout layout smart to gadcon so it can use that instead of the linear one it uses for the shelf 3. make the desktop advertise a gadcon layout. I'm going to try to work on points 2 and 3 in the next few days. Raster, If I remember correctly, you wanted the generic layout to work well with resolution changes. Any requirements for that? I see two possibilities here: - 1/ When the resolution is changed, the gadgets keep their relative position, i.e. if the horizontal alignement of a gadget was 0.5 (center), it will stay centered regardless to the screen resolution yup. actually see the existing linear one. it hooks gadcon clients to one 1 3 points (left, center or right / top/center/bottom if vertical). then they are remembered to be N pixels offset from those points, so things i stick in a corner of my screen stay in that corner in that exact sizing and arrangement irrespective of screen size changes. this is the way to go. it's kind of a combination of 1 2. so if i have: +-+ |A BC| |D| |E| |F| |G H IJ| +-+ and i resize the Screen (or gadcon layout object) i end up with: +---+ | A BC| | D| | | | E | | | |F | |G H IJ| +---+ now the problem comes when you resize DOWN - +-+ | ABC| |F E D| |G HIJ| +-+ now things begin to overlap - but still are ok. as long as you remember their location and hook point WHEN a user moves them - and ONLY then (not when a resize happens) then when you resize back you go back to the original state, not a new modified one. now if you resize down to: +---+ |FAC| |GHK| +---+ i now don't have room for a lot of elements. you will need to find some way to squeeze elements or shuffle/move them if possible. Ok, I'll do it this way. Thanks :) - 2/ When the resolution is changed, the gadgets keep their absolute position, i.e if a gadget was at pos 200,300, it will stay at 200,300. If the gadget is no longer entirely visible, it will be moved in order to get visible again. The first one seems better to me. Regards, Simon TRENY MoOm done. existing modules and gadgets will then also work there. Hi, I started to make a new taskbar-module based on engage. For now it uses gadcon, but this has several disadvantages. The problem is that the shelf is intended to hold more than one gadcon-client and therefore the clients should be changed on changes to the shelf. In my case the module should control the size, hiding and style of the shelf and futhermore it doesn't make sense to have more than one client in its shelf. In short: there are a bunch of other modules that need to control how and where they appear on the desk; modules which might have multiple instance configurations to store. I would say engage, devian, calendar and all this desklet-stuff falls in this category for example. So what interfaces could be needed by such a module and how should the user configure these modules? Ok, one could implement all the window- and instance-handling-configuration for each module, but i think this will cause a very incosistent configuration of such modules in the end. So I would do it like this, as one example: 'Module Settings' - 'Engage' - Configure - 'add Instance' From the user perspective I think it would make more sense if one adds a module like this just like shelfs. So the add Button from the shelf settings would show a select-window to add a shelf or an engage bar, etc. 'Shelf Settings' - add - 'Engage' On the interface side. Just some ideas i had so far for this new kind of shelf. Module provides information to the 'shelf': - a name (to show in the select window) - which orientations are possible (float, edge,..) - if size is set by the module Module can cause the 'shelf' - to resize - to show/hide 'Shelf' provides funtionality - move window / setting the edge - hiding - 'abstracts' if the module instance draws on the desk or a popup (as is does now already) I know there is the gadcon between the client and the shelf. Though for this kind of shelf gadcon could be much simplified, since it has only to handle with one module. Are there any
Re: [E-devel] [RFC] SDL Engine
On Tue, 24 Apr 2007 17:33:11 -0500,
Nathan Ingersoll [EMAIL PROTECTED] wrote :
On 4/24/07, Simon TRENY [EMAIL PROTECTED] wrote:
from this:
1. Creation of a drawable
2. Creation of the GL-engine from the drawable
3. While (1) do { engine-render() }
to this:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
2. Creation of the GL-engine
3. While (1) do { engine-render(); swap_buffers(GL-context) }
Is there any reason that this could not be controlled simply by the
engine info passed at setup time?
If the info contains a GL-context, use the passed context and don't
call swap_buffers, otherwise use the current behavior. Seems like you
would get the best of both worlds and the usual case would still be
just as simple as it is now.
Actually, the GL-context is almost only used to swap the buffers, so
passing the context to the engine if the engine doesn't call the
swap_buffers() functions is not really coherent I think.
And since there is no generic GL-context type (each windowing system
implements its own type for the GL-context: GLXContext for GLX, HGLRC
for Windows...), we still couldn't have a generic GL-engine (we would
still need one GL-engine per windowing system).
Simon
-
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] [RFC] SDL Engine
On Wed, 25 Apr 2007 17:19:25 +0200,
Sebastian Dransfeld [EMAIL PROTECTED] wrote :
Simon TRENY wrote:
On Tue, 24 Apr 2007 17:33:11 -0500,
Nathan Ingersoll [EMAIL PROTECTED] wrote :
On 4/24/07, Simon TRENY [EMAIL PROTECTED] wrote:
from this:
1. Creation of a drawable
2. Creation of the GL-engine from the drawable
3. While (1) do { engine-render() }
to this:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
2. Creation of the GL-engine
3. While (1) do { engine-render(); swap_buffers(GL-context) }
Is there any reason that this could not be controlled simply by the
engine info passed at setup time?
If the info contains a GL-context, use the passed context and don't
call swap_buffers, otherwise use the current behavior. Seems like
you would get the best of both worlds and the usual case would
still be just as simple as it is now.
Actually, the GL-context is almost only used to swap the buffers, so
passing the context to the engine if the engine doesn't call the
swap_buffers() functions is not really coherent I think.
And since there is no generic GL-context type (each windowing system
implements its own type for the GL-context: GLXContext for GLX,
HGLRC for Windows...), we still couldn't have a generic GL-engine
(we would still need one GL-engine per windowing system).
Implement swap_buffers as a callback?
It would indeed make the engine generic but then, if the engine swaps
the buffers by itself, the Evas couldn't be integrated in an OpenGL
application: here is how we could embed an Evas in an OpenGL app, if the
engine wasn't swapping the buffers:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
3. Creation of the GL-engine
3. While (1)
{
game-scene-render();
evas-engine-render();
game-overlay-render();
swap_buffers(GL-context);
}
Now, if the engine swaps the buffers at the end of the rendering
process (which is currently the case), the overlay can't be rendered
anymore (or you'll have to put the overlay-render() call in the
swap_buffers() callback, but it's kind of tricky imho)
Simon
Sebastian
-
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
-
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] [RFC] SDL Engine
On Wed, 25 Apr 2007 18:56:25 GMT,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote :
Cedric's sdl engine email/patch has been hijacked into
a bitter battle over evas and opengl :)
Simon wrote:
It would indeed make the engine generic but then, if the engine
swaps the buffers by itself, the Evas couldn't be integrated in
an OpenGL application: here is how we could embed an Evas in an
OpenGL app, if the engine wasn't swapping the buffers:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
3. Creation of the GL-engine
3. While (1)
{
game-scene-render();
evas-engine-render();
game-overlay-render();
swap_buffers(GL-context);
}
Now, if the engine swaps the buffers at the end of the rendering
process (which is currently the case), the overlay can't be rendered
anymore (or you'll have to put the overlay-render() call in the
swap_buffers() callback, but it's kind of tricky imho)
Ok, this assumes that the game-render() itself is rendering
to the gl front/back buffer and that it too doesn't flush things.
But if that's the case, then why can't the evas gl engine in question
be rendering to a pbuffer or texture say, and then draw that to the
main render buffer (eg. as a textured quad), and then flush things?
Indeed, it assumes that game-scene-render(), evas-engine-render()
and evas-overlay-render() doesn't manipulate directly the GL
context (for swapping or for changing the active GL-context, for
example), but I see no reason why they would need to do that.
They should behave as independant gl objects: they should only use
OpenGL functions, and they should keep the current GL state unchanged
(this could be done easily with glPop/PushAttribs()). This is the
only way I know to do modular OpenGL programming.
About your second point, The gl-engine can render to a texture or a
pbuffer, there is no problem with this, as long as it doesn't swap the
buffers. But as raster said, it is not possible if we want to get good
performances with OpenGL, rendering to a texture is slow as hell
(don't know muck about pbuffers). And actually, it doesn't solve the
current problem at all (buffers will still have to be swapped somewhere)
No matter how much you want to put evas canvases into a
gl based rendering context, you are also going to want to do the
opposite - use gl rendering in an evas gl canvas.
Yes indeed, and this is possible with the above scheme: you
can do your gl-rendering in the game-overlay-render() function, all
the GL primitives that will be drawn in this function will be drawn
over the Evas GL canvas (you may just need to clear the Z-buffer)
The cleanest way to do these kinds of things, wether it's
gl based or xrender based or cairo based or your-software-routines
or via some 3D-game-engine (or even, egods, a raytracer!), is to
have evas engine specific buffers to draw to.
This is why the software engines are so powerful/versatile,
it provides a full circle - you can draw to a display target via
the software engines, and you can draw to a software buffer target,
and you can set such a buffer as 'data' for image objects.
This kind of completeness would be very desirable as well,
at least withing the context of engines driven by a given rendering
backend - software, xrender, gl, cairo, ...
Agreed :)
Simon
jose.
-
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
-
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] itask engaged - pre alpha release
On Tue, 24 Apr 2007 08:39:06 +0200, Igor \FeR\ Scabini [EMAIL PROTECTED] wrote : Daniel Kasak ha scritto: Hannes Janetzek wrote: Hi, itask_ng starts to get usable. So if someone wants to try it's available from svn: http://itask-module.googlecode.com/svn/trunk/ itask-module/itask_ng a video is here (it looks better in reality, this was recorded with 4fps) http://video.google.de/videoplay?docid=-1525947350649682737 there's a README that explains how to set up the shelf correctly. Looks good :) Actually I'd like to see the engage-like scaling in an app *launcher* as well as a task manager, but anyway ... it's good. I assume the goal is to drop the 116-pixel requirement for making it look nice? I still have a problem that I can replicate very well: sometimes when I left-click on an icon in itask module the shelv menu open and the app too, so this *feature* is only annoing me, not stopping using this module. The README file did spark some questions though: you need to have composite manager running like for example xcompmgr, bling, egloo or bang I'll be good and not ask when bang is coming :) But what is egloo? I googled for it and found absolutely nothing. Not announced yet? Dan You can find egloo here: http://mtreny.free.fr/egloo/ I don't know anything about the author and development plan, from the video it loooks good. The code that can be found here is not supposed to work at all. It is totally outdated and was only here as a backup in case I have a problem with my harddrive... :) And egloo doesn't even handle alpha-ed windows yet, so it has no use with itask (nice module btw :)) Simon - 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] [RFC] SDL Engine
On Tue, 24 Apr 2007 14:41:22 +0900,
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote :
On Mon, 9 Apr 2007 10:16:56 +0200 Simon TRENY [EMAIL PROTECTED]
babbled:
On Fri, 6 Apr 2007 15:21:52 +0200,
Cedric BAIL [EMAIL PROTECTED] wrote :
I did visit the sdl website, and there seems to be
mention of using OpenGL with SDL... Is it possible to maybe
also have a gl_sdl version of the engine.. ie. one which
would presumably use some gl rendering?
I did think about that also, but I must have some priority. So
first I want to have an Ecore with all others EFL running cleany
with the software_sdl. So it's definitively possible in my
opinion, but not really on top of my TODO list :)
I have some experience with SDL + OpenGL and there is nothing
different between using OpenGL with SDL and using OpenGL with an
X11 window (OpenGL-wise). The only differences are the calls that
depends on the windowing system: the creation of the GL context and
the swapping of the front/back buffers. But I don't think it's
worth it to create an Evas engine for OpenGL+SDL. It will be
exactly the same as the GL-X11 engine (i.e just a wrapper of the
GL-common engine).
agreed. in fact the sdl engine is strange. it allocates sdl surfaces
for images
- but really doesnt do anything more than the software engine. there
is not any good reason for this, and really the sdl engine shouldnt
need to be any more than just an sdl wrapper handling the windowing
system interfacing and display of ARGB32 data to the screen - the
rest can be the software engine as-is.
Actually, I don't think there should be a GL-X11 engine in Evas at
all. Just the GL-common engine should be enough. Then all the code
to create the GL-context and to swap the buffers (that is to say,
all the code that is currently in the GL-X11 engine) should be
moved to Ecore_Evas imho. This way, if we'd like to use OpenGL+SDL
or OpenGL+Win32, there will be no need to create a new Evas engine.
We would just have to create the window, the GL-context and to use
it with the GL-common engine of Evas (all of these could be done in
Ecore_Evas). And it will make it possible to use Evas in your own
OpenGL app which already has its own GL context: for example, you
could use Evas for the GUI of an OpenGL game, which could be really
cool imho :)
i disagree. currently the engine does the swaps because that is the
onyl sane way to get performance with gl. in theory it should render
updates like the software engines do - render the update regions to a
pbuffer/texture then copy to the frontbffer instead of allocating a
whole backbuffer for the window. the problem is that if you expose
this, this mechanism is no longer tweakable by the engine. the
software engines dont force you to do anything special before or
after rendering to make them display, and the gl engine shouldnt
either imho.
I see what you mean, and actually, it's just a design problem. But the
thing is, because of this design issue, the GL engine is far more
limited that what it could actually do. The only thing we would need to
make it as powerful as it could be would be to change Ecore_Evas_GL_X11
from this:
1. Creation of a drawable
2. Creation of the GL-engine from the drawable
3. While (1) do { engine-render() }
to this:
1. Creation of a drawable
2. Creation of a GL-context from the drawable
2. Creation of the GL-engine
3. While (1) do { engine-render(); swap_buffers(GL-context) }
Indeed, the engine would no longer be self-sufficient since if you
don't swap the buffers, nothing would be drawn (actually it would still
be drawn on the backbuffer, but not on the screen), but if you see the
engine as GL object, these new steps make sense.
And I think accepting this design-problem is worth it if you look at
what it would make possible:
- Since the engine would behave as a GL-object, you could insert
one or several Evas-es in your GL programs, meaning you could use
for example, Evas in a 3D game to render the HUD, or in a 3D modeler
to draw the the GUI and *more important*, I could use Evas in
Egloo... which could be really cool, from a totally selfish point of
view :)
- We would also be able to draw GL primitives over an Evas (as long as
it uses the GL-engine), which was the subject of a thread on the
Dev-ML some months ago.
- The GL engine would be totally portable and independent from the
windowing system used, so we could use it with Windows, SDL, XCB,
XLib without changing one line of code. Otherwise, we would need as
many Evas enginges as there are windowing systems that we want to
support.
So, can I just ask you to reconsider this? :)
Simon TRENY MoOm
I've already discussed this with raster and he told me the only
reason to bind the GL-Context with the Evas engine is because the
context is stateful and if the context were to be shared between
the Evas-engine and the application
Re: [E-devel] Ideas for a new 'desklet'-module api
Hi, I quite agree with you, I think that for now, modules are rather limited. Either a module is contained by a shelf by providing a gadcon client, or it has to do everything by itself (for example, if we want to put a module on the background, we have to handle its placement, the creation/deletion of the instances, the config for each instance...) and as you said, it would lead to inconsistencies. I think it would be great if we could place freely modules on the background, as it was possible with the old gadman thing. It would allow to have desklets like the ones in adesklets (ie. a cpu monitor with an histogram for example). Shelf are great for small modules, but not for modules that are supposed to display a lot of info (or it would need to use a popup, as the weather module does). Adding the possibility to add modules on the background should not be too difficult imo, as a lot of the code has already been written for the gadcon system. All we would have to handle is the placement/size of the gadcon clients on the background (well... I guess...). And actually, I think it would be great if modules (their gadcon-client actually) could specify if they can be placed in a shelf, on the background or in/on both. For instance, the engage module can only be placed on the background, not in a shelf. And it would be great if a gadcon-client could behave differently whether it is placed in a shelf or in the background. For example, the weather module could display full info if it is placed on the bacground, and just a small icon representing the current weather if it is placed in a shelf. Same for the clock, it could have a gold border if it is placed on the background (as before), and it could have its current look if it is placed in the shelf. raster: if you are ok with this idea, and have no time to do it, I can try to code it if you want. Regards, Simon On Wed, 18 Apr 2007 21:29:05 +0200, Hannes Janetzek [EMAIL PROTECTED] wrote : Hi, I started to make a new taskbar-module based on engage. For now it uses gadcon, but this has several disadvantages. The problem is that the shelf is intended to hold more than one gadcon-client and therefore the clients should be changed on changes to the shelf. In my case the module should control the size, hiding and style of the shelf and futhermore it doesn't make sense to have more than one client in its shelf. In short: there are a bunch of other modules that need to control how and where they appear on the desk; modules which might have multiple instance configurations to store. I would say engage, devian, calendar and all this desklet-stuff falls in this category for example. So what interfaces could be needed by such a module and how should the user configure these modules? Ok, one could implement all the window- and instance-handling-configuration for each module, but i think this will cause a very incosistent configuration of such modules in the end. So I would do it like this, as one example: 'Module Settings' - 'Engage' - Configure - 'add Instance' From the user perspective I think it would make more sense if one adds a module like this just like shelfs. So the add Button from the shelf settings would show a select-window to add a shelf or an engage bar, etc. 'Shelf Settings' - add - 'Engage' On the interface side. Just some ideas i had so far for this new kind of shelf. Module provides information to the 'shelf': - a name (to show in the select window) - which orientations are possible (float, edge,..) - if size is set by the module Module can cause the 'shelf' - to resize - to show/hide 'Shelf' provides funtionality - move window / setting the edge - hiding - 'abstracts' if the module instance draws on the desk or a popup (as is does now already) I know there is the gadcon between the client and the shelf. Though for this kind of shelf gadcon could be much simplified, since it has only to handle with one module. Are there any objections to add something like this to e? I mean, it could simplify the work to create a desklet-like module a lot. If there is a better way to achieve what i want, please let me know! Best Regards, Hannes 'jeffdameth' Janetzek - 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 - 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.
Re: [E-devel] Ideas for a new 'desklet'-module api
On Thu, 19 Apr 2007 16:04:24 -0500, Brian Mattern [EMAIL PROTECTED] wrote : On Thu, Apr 19, 2007 at 08:51:43PM +, [EMAIL PROTECTED] wrote: Simon wrote: I think it would be good to have freely placed modules in e17... but I just wonder if this should be the main method for having large numbers of interesting desklets kinds of things in e. Write an app that sets ecore_evas_alpha_set(ee, 1); ecore_evas_borderless_set(ee, 1); and run a compositor? Then, if desired set them to stack 'always below', and either alt-drag them around or use esmart_draggies? True, but having a standard way to do this with modules would provide several advantages: - consistent behavior - smart placement (position/size automatically saved/restored, resolution change would be automatically handled, ...) - standard way to set keybindings to specific module actions - module's theme can be changed when e17's theme is changed - possibility to communicate with the wm, to listen to its events, and even to change its default behavior... Of course it has some drawbacks, the biggest I can see is that modules are dependent to e17 but... who cares, we use e17 :) Who ever has enough empty screen space to see their desktop anyway? Modules are not bound to be stucked on the desktop: we could have a key to bring all the desktop modules on foreground for example (like what MacOS X does with the gadgets). Simon Brian - 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 - 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] [RFC] SDL Engine
On Fri, 6 Apr 2007 15:21:52 +0200, Cedric BAIL [EMAIL PROTECTED] wrote : I did visit the sdl website, and there seems to be mention of using OpenGL with SDL... Is it possible to maybe also have a gl_sdl version of the engine.. ie. one which would presumably use some gl rendering? I did think about that also, but I must have some priority. So first I want to have an Ecore with all others EFL running cleany with the software_sdl. So it's definitively possible in my opinion, but not really on top of my TODO list :) I have some experience with SDL + OpenGL and there is nothing different between using OpenGL with SDL and using OpenGL with an X11 window (OpenGL-wise). The only differences are the calls that depends on the windowing system: the creation of the GL context and the swapping of the front/back buffers. But I don't think it's worth it to create an Evas engine for OpenGL+SDL. It will be exactly the same as the GL-X11 engine (i.e just a wrapper of the GL-common engine). Actually, I don't think there should be a GL-X11 engine in Evas at all. Just the GL-common engine should be enough. Then all the code to create the GL-context and to swap the buffers (that is to say, all the code that is currently in the GL-X11 engine) should be moved to Ecore_Evas imho. This way, if we'd like to use OpenGL+SDL or OpenGL+Win32, there will be no need to create a new Evas engine. We would just have to create the window, the GL-context and to use it with the GL-common engine of Evas (all of these could be done in Ecore_Evas). And it will make it possible to use Evas in your own OpenGL app which already has its own GL context: for example, you could use Evas for the GUI of an OpenGL game, which could be really cool imho :) I've already discussed this with raster and he told me the only reason to bind the GL-Context with the Evas engine is because the context is stateful and if the context were to be shared between the Evas-engine and the application code, the application could change/corrupt the context's state and it could break the Evas engine. That's a good point, but actually, there is a way to save/restore the current state of a GL-context with glPushAttrib(GL_ALL_ATTRIB_BITS)/glPopAttrib(GL_ALL_ATTRIB_BITS). It saves the current viewport, the current matrices, and all the current states. I just don't know if it is efficient and if it's available on all the GL cards. Raster, what do you think about creating a generic GL-engine for Evas (with the glPushAttrib()/glPopAttrib() thing), and to move the existing code of the GL-X11 engine (creation of the context and buffer-swapping) to Ecore_Evas_GL_X11? If this is ok, I'm willing to do it if you want. Regards, Simon TRENY MoOm Cedric - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] edje_extern_object_*() sets swallow_params and trigger recalc
Does this mean, we don't have to unswallow/reswallow a swallowed object anymore when we change its size with edje_extern_object_*() ? Simon On Wed, 4 Apr 2007 21:43:24 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : On Wed, 28 Mar 2007 19:01:17 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: this seems fine looking at it - patch in cvs. :) This patch marks swallowed objects and when edje_extern_object_*() functions are called on these objects, swallow_params are set and _edje_recalc() is called. This patch was originally written by rephorm, but had small bugs, which I've fixed. His original patch is http://rephorm.com/files/patches/edje_extern.diff edje_util.c | 47 +++ 1 file changed, 47 insertions(+) -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] edje_extern_object_*() sets swallow_params and trigger recalc
On Wed, 4 Apr 2007 10:48:53 -0500, Brian Mattern [EMAIL PROTECTED] wrote : On Wed, Apr 04, 2007 at 06:36:41PM +0200, Simon TRENY wrote: Does this mean, we don't have to unswallow/reswallow a swallowed object anymore when we change its size with edje_extern_object_*() ? Yes, that's the idea. Great :) Just curious, if you knew about the issue, why did you work around it instead of reporting it / fixing it? :) I didn't report it because it was raster who told me about this issue and how to work around it, so I knew it was an already known issue (or at least... I knew raster knew it :)) And I didn't fix it because at the time I had to use edje_extern_object_*(), I had no time to fix it. And then, I totally forgot about it. Simon Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: Re: [collab4] eclair improvements
On Tue, 27 Mar 2007 19:08:33 +0200, Peter Parkanyi [EMAIL PROTECTED] wrote : Inspired by the latest E17 gui toolkits discussion on e-devel, i would gladly work on eclair, and improve it, add the file add dialog, and maybe library support, drop the XMMS-style playlist, and instead design a new one, maybe theme fixes(the current doesn't have blurs on the corners, so it's ugly, I think). It could be a very good, custom ETK application. Hi Peter, All the changes you are describing are actually the reasons why I started coding Etk: I needed a toolkit library to add a filechooser and a collection manager to Eclair. Etk was just more work than I first thought it would be, and I've never been able to work on Eclair again. So, if you want to add those features, feel free to do it :) The library support is even started, all the songs are already stored in a database with sqlite. If you even think eclair should be rewritten, go ahead, I'll probably never work on it again. Regards, Simon Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On Fri, 23 Mar 2007 13:21:33 +0100, Laurent Ghigonis [EMAIL PROTECTED] wrote : Thu, 22 Mar 2007 00:10:33 +0100, Simon TRENY [EMAIL PROTECTED] wrote : There is something I'd like to discuss here although I'm not sure it's really the right place to do so.. Since Etk and Ewl have begun to be usable enough, there has been a lot of new apps using one of these too. The thing is, too often those apps only copy existing apps and I just don't think this the right way. A lot of these apps would have been a lot better if they hadn't used a toolkit but if they had used directly Edje (and using Etk/Ewl only for the config dialogs). For example, if we want to have a nice, original and innovative image viewer, I really think its main interface should be directly coded with Edje (like what entice did but in a more complete way). Same thing for a filemanager, for an audio/video player or for an IM client... Toolkits are nice for config dialogs or for apps that need to offer a lot of control. If we really want to have a nice and innovative Enlightenment desktop environment, we should be different from the other desktop environments. We should have apps with a really nice and well-designed interface, and most of the time, this is just not possible with a toolkit. Elicit is a good example of an innovative application that blows your mind away when you first launch it. If it were using Etk or Ewl, it would just have been a common application. Hi, I agree with you that edje is a very powerful tool to create applications, and we should use it to create innovative user interfaces like in elicit or rage. But what about consistency between applications ? Do you have ideas how to maintain some king of consistency between apps, when creating you're own edje interfaces, or when using custom widgets in toolkits ? For example sharing color classes ... I agree, the biggest problem with Edje is the consistency issues: different looks, different behaviors... A glade-like tool could greatly help on this point I think. A tool like Glade, that would allow us to build interfaces made of Edje objects and Etk (or Ewl) widgets may be a part of the solution, but i believe it should be done at library level, not in a gui creator tool. What do you mean by at library level? There will indeed be functions to load the interface (in Etk, in Enhance, or in another lib, I don't know yet) but we'll still need a tool to build the interface (the tool will be used to assemble Edje objects and widgets/containers). Simon Just my thoughts =) laurent - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On Fri, 23 Mar 2007 09:21:40 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : It'd be good to see a real example of this combined use of toolkit-widgets + custom-edje-widgets in an app like rage or entrance or elicit or whatever. src/bin/ewl_embed_test.c shows how to do this. It's a simple application, but it does show how the interaction can work. Ok, took a look.. and also at a similar 'embed_test' in etk. I imagined this completely backwards. You guys are 'embedding' toolkit widgets into evas objects! That's why Simon was talking about putting entry widgets into entrance's main edje. Ummm The embed test of Etk indeed Embed widgets into an Evas object, but embedding Evas object in widgets is is also possible and even easier. You know, Simon's suggestion for 'a tool that would allow us to build interfaces made of Edje objects and Etk (or Ewl) widgets' would be a great chance for both of you guys to work together and get something REALLY useful here - especially since a description format for such could be toolkit-agnostic. Yes, it could be great to have a format that would be compatible with the both toolkits and it should be possible I guess. There just might be some problems for features that are supported by one toolkit and not by the other but I don't think there are a lot of these actually. I'll try to make a quick version of the tool and of the file format, we could discuss this later. For now, I'll use a xml-like format. Simon jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On Wed, 21 Mar 2007 22:41:28 -0400, dan sinclair [EMAIL PROTECTED] wrote : On 21-Mar-07, at 7:10 PM, Simon TRENY wrote: In Etk, as in Ewl I think, you can change the theme of a specific widget or change globally the theme used by all the widgets. About custom widgets, it's indeed possible to build your own widget directly in the app's code, the only difficulty here will be the themability: either you use theme-parts from existing widgets and there will be no problem, or you use your own theme-file for this widget but it may look wrong with some Etk/Ewl themes. Ewl will allow you to specify the .edj file on a per widget basis if desired. Each widget has a /file along with a /group key that can be set. There is the same system in Etk as well. dan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On Thu, 22 Mar 2007 04:13:35 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : From Nathan's, Simon's, and Dan's replies, it seems that both ewl and etk do have mechanisms for allowing app-specific theme overriding of the toolkit widgets, and in fairly general ways. Wow. So, one could write an app, to start with, that uses only the toolkit themes, and if desired one could then extend this to allow for further app-specific mods. Best of both worlds. Ok, could one take say raster's rage and do this? ie. could it be written with ewl/etk to use only (or mostly) the toolkit widgets/themes and then extend it to duplicate whatever its current theming? What about the same for say, entrance? Rage could be written quite easily with Etk (and Ewl I think), it would only require to implement a new container for the list of medias. But the thing is, there is no point of writting Rage with Etk/Ewl rather than directly with Edje. For Entrance, it's a bit more complicated since it doesn't have a fixed layout. With Etk/Ewl, you can theme each widgets individually, but you can't theme the layout. With Etk, you can still use glade + enhance to make the layout a bit themable, but it would never be as flexible as with Edje. Simon writes: In a slightly different vein.. Is there something like the equivalent of e17's modules for the gui-toolkits -- does something like that even make sense? I'm not sure I understand what you mean here. You can have loadable widgets from a library, but there is no such things as modules (i.e. plugins that may change the behavior of an Etk apps). It may be a good idea, but I don't really see a use for this for now. Well, let's say 'gui-modules' as loadable libs that would provide additional interesting (but possibly somewhat more specific) functionality than buttons/menus/... For example, et's say we have an rss feed module, or a wether/forecast one, or just a clock, ... and that these could be embedded in normal toolkit widgets (in a menu or bar or whatnot). Yes, you can have additionnal widgets (clocks, rss, whatever, ...) in loadable libraries. In fact, you can build external widgets because you have access to all the methods for this in the Etk headers. Nathan writes: This seems like a higher level function, like the KParts you mention below. Ummm... Yeah, but possibly something more 'lightweight' would be good as well. I just took a quick look at kparts, this seems to be a mechanism for allowing functionality that some apps may have to be shared by others. It seems to require that 'part' to be given as a loadable shared lib with certain kinds of interfaces that are known, and the rest (gui controls) to be specified in an xml file in certain ways. This is something that doesn't seem to need a source app at all, but likely obtained that way from existing ones. It also seems to me that this kind of thing could be achieved via a sufficiently extended notion of a 'vfs'. Anyway... it does seem to be a useful idea. Simon writes: There is something I'd like to discuss here although I'm not sure it's really the right place to do so.. Since Etk and Ewl have begun to be usable enough, there has been a lot of new apps using one of these too. The thing is, too often those apps only copy existing apps and I just don't think this the right way. A lot of these apps would have been a lot better if they hadn't used a toolkit but if they had used directly Edje (and using Etk/Ewl only for the config dialogs)... Ummm.. I know what you're trying to say.. But there are several sides to this. One is that most people will find it MUCH easier to use a toolkit, and that seems to me to be the way to start unless you want a mostly stand-alone app, and are very good with edje. If e can have nearly as many apps written in its toolkits as there are now for gtk.. then I'd say that alone would be great achievement! Actually, I see no real point in coding with Etk/Ewl an aplication that already exists with Gtk or Qt. It would only offer more consistency with an E desktop, and some eye-candy effects but it's quite a waste of time imho. We should try to think differently, because we have tools (Edje/Evas) that allow us to do things differently. But some apps can't indeed be done really differently (for example, an Email client or a FTP client in Gnome/Kde/E will always look the same, we can't be really innovative here). If indeed one can extend ewl/etk in the ways you mention, then one could later optionally extend the theming and/or widgetry to be as unique as desired - hence allowing for both app-unique and toolkit-common 'lookfeel' for a large number of apps that people may be inclined to write. Actually, when the basic widgets will be completely done in Etk, I'm planning to add a bunch of other widgets which only aims to
Re: [E-devel] E and gui-toolkits.
On Thu, 22 Mar 2007 09:59:02 -0500, Brian Mattern [EMAIL PROTECTED] wrote : On Thu, Mar 22, 2007 at 02:31:57PM +, [EMAIL PROTECTED] wrote: Simon writes: Actually, I see no real point in coding with Etk/Ewl an aplication that already exists with Gtk or Qt. It would only offer more consistency with an E desktop, and some eye-candy effects but it's If no 'existing' gtk/qt apps are ever written with ewl/etk, then there never going to be any image viewer apps, any text editors, or any of the other 20,000+ apps that exist -- you're going to have to think real hard to make up a 'brand new' kind of app that no one has ever done before in gtk/qt, just to make it 'worth' doing in e's toolkits?? quite a waste of time imho. We should try to think differently, because we have tools (Edje/Evas) that allow us to do things I think the sentiment he's trying to get across, which is one I share, is that there is little point in rewriting a gtk/kde app in an e widget set if it looks and functions exactly the same. E.g. using emphasis (or whatever the glade lib is) with a gnome app's glade file is a lot of effort (recreating the backend functionality) with the only gain being glinty buttons. Exactly what I meant :) Btw, the glade-like lib is enhance, emphasis is the mpd client (audio player). Actually, one thing that could be really cool would be a tool like Glade, but that would allow us to build interfaces made of Edje objects and Etk (or Ewl) widgets. For example, for Entrance, we could have the main interface still be an Edje object but we could replace the entry/buttons by themed Etk widgets. With the tool, we could place the widgets wherever we want in the interface (no fixed layout anymore). Same for elicit, the spinners could be spinners from Etk (just an example). The apps will look exactly the same, and will still be as themable as before, but it would combine the advantages of the both libraries (Edje and Etk): the high themability of Edje and the ease of use of Etk (there would be no need to reimplement the behavior of an entry or of a spinner in the code, there would natively be keyboard-navigation between the different widgets of the interface, ...). I'm not sure I'm clear here, but I really think it would be really nice thing to have. Simon The point is NOT that we can't use new, innovate image viewers, text editors, etc. But, we need to sit and think about how we can improve on the current 'desktop app' idioms. Elicit is a simple enough application that it can have its gui entirely defined in edje. I've thought several times about breaking some of its layout out into some smart objects (e.g. the a simple notebook smartobj). However, this would severly dampen what is possible from the theming standpoint. Tokyo has done some amazing versions of pared down single panel (no tabs) themes for elicit. You'll also notice that elicit has no proper configuration dialogs. So, if a theme doesn't provide a theme selector, then you can't switch themes. For small apps like this, this is an arena where traditional packed widgets fit in. Many larger apps (image viewers, music players, etc) could probably be done in a similar fashion. E.g. a free form edje ui for the primary functionality, with a packed widget set for dialogs. But, it really depends on the app in question (and the imagination of the author). rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On Wed, 21 Mar 2007 21:37:12 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : I'd like to bring up some things about 'e' and gui-toolkits. I know this has been a source of some friction here before, but I'd like to be able to discuss various aspects in a serious and rational way.. Hopefully, the toolkit devs themselves will be able to help in this and see areas of interest they'd like to bring up. There are many aspects to something as complex as a high- level gui-toolkit lib, but one that is important for 'e' is themability. This allows for consistent and yet variable 'look feel' for apps built with them. I wonder though if one can write apps with e's toolkits that would allow for 'overriding' the toolkit's theme (with an app-provided edje goup say), for a given toolkit widget? Also, is it possible to build 'custom widgets' that can be given app-specific theming? Just how flexible can/should 'theming' be? In Etk, as in Ewl I think, you can change the theme of a specific widget or change globally the theme used by all the widgets. About custom widgets, it's indeed possible to build your own widget directly in the app's code, the only difficulty here will be the themability: either you use theme-parts from existing widgets and there will be no problem, or you use your own theme-file for this widget but it may look wrong with some Etk/Ewl themes. In a slightly different vein.. Is there something like the equivalent of e17's modules for the gui-toolkits -- does something like that even make sense? I'm not sure I understand what you mean here. You can have loadable widgets from a library, but there is no such things as modules (i.e. plugins that may change the behavior of an Etk apps). It may be a good idea, but I don't really see a use for this for now. There are of course many other aspects of interest, not necessarily related to theming, and I wonder if the toolkit devs have any thoughts or ideas they feel would be interesting, or things they feel 'e' should support, ... There is something I'd like to discuss here although I'm not sure it's really the right place to do so.. Since Etk and Ewl have begun to be usable enough, there has been a lot of new apps using one of these too. The thing is, too often those apps only copy existing apps and I just don't think this the right way. A lot of these apps would have been a lot better if they hadn't used a toolkit but if they had used directly Edje (and using Etk/Ewl only for the config dialogs). For example, if we want to have a nice, original and innovative image viewer, I really think its main interface should be directly coded with Edje (like what entice did but in a more complete way). Same thing for a filemanager, for an audio/video player or for an IM client... Toolkits are nice for config dialogs or for apps that need to offer a lot of control. If we really want to have a nice and innovative Enlightenment desktop environment, we should be different from the other desktop environments. We should have apps with a really nice and well-designed interface, and most of the time, this is just not possible with a toolkit. Elicit is a good example of an innovative application that blows your mind away when you first launch it. If it were using Etk or Ewl, it would just have been a common application. I just wish that when someone will want to start a new application, he will consider making it using Edje and not jumping directly on Etk or Ewl. Or Enlighenment apps will just be a copy of Gnome/Kde apps (with some glint on the buttons though :)) Simon TRENY MoOm eg. I've sometimes seen references to kde's kio slaves and kparts... Can anyone tell me exactly what these things are and why they are considered useful? Are these kinds of things something that a gui-toolkit should have, or are they more like an ecore-lib? Is there a coherent relationship between such things and say e_dbus, evfs, ?? Much of this looks like a kind of multi-tiered jigsaw-puzzle to me... What is the big picture here? And how do the pieces fit together? jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php
Re: [E-devel] [PATCH] Etk combobox
Hi Chady! Why exactly do you need these two functions? To insert new items in a combobox? If that's so, couldn't you just do what you did with row insertion in an Etk_Tree? iirc you fixed row insertion by using directly etk_tree_row_fields_set(). Since there is no etk_tree_row_fields_nth_set() in the Etk_Tree API, couldn't it be possible to do something similar for the combobox? The problem with these two functions is that they don't really make sense except for Etk-Perl. I don't see any use for them since we already have etk_combobox_item_fields_set/get(). Regards, Simon On Fri, 9 Mar 2007 10:27:20 +0200, Chady Kassouf [EMAIL PROTECTED] wrote : Since there is work going on the combobox now, I thought this might go in (or something like it) This patch introduces two functions: etk_combobox_item_fields_nth_set and etk_combobox_item_fields_nth_get to get/set a specific column's widget of the combobox. This is needed for perl bindings. Regards, - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Viewport feature removed from evas
On Fri, 2 Mar 2007 16:38:48 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : Carsten wrote: Recently (as of 0.9.9.036 I think), evas no longer has the ability to have a viewport size that differs from the output size. This was a feature we (Freevo) relied on -- what was the motivation for removing this feature? Is there any alternative method to achieve equivalent functionality in evas? ok. here's why. . . 3. the viewport actually doesn't give you anything you can't really achieve by just scaling objects. Yes, except that they won't be able to scale everything as might be desired. eg. for image borders one'd need an evas api func to set 'image_border_fill' (lw,rw,th,bh kind of inputs), and for text.. Well, the most satisfying way of dealing with this would be to use freetype to pick an idex that best fits a given x,y scale (though I'm not sure how well that would work with bitmap font glyphs). But without automatic viewport scaling, it would mean an api func for setting a text obj's 'scaling' somehow. I'm not sure I understand what viewports really are since I've never used them, but from what I understand, you can still use the buffer engine of Evas to render your objects into an image, and then use this image object as a viewport (it can be scaled, moved, and even be blended). But maybe it's not as efficient as the previous viewport feature. Regards, Simon TRENY MoOm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje data speedup
On Fri, 2 Mar 2007 09:12:54 -0600, Nathan Ingersoll [EMAIL PROTECTED] wrote : On 3/2/07, Tilman Sauerbeck [EMAIL PROTECTED] wrote: IIRC there's one global data section, and every collection/group does have its own data section, too. So we can't get away with a single hash table. Not that it matters much :) Right, the proposed change was only for the global data section and not the group data sections. My thinking was that with per-group data collections, you are much less likely to have many items in the list since they are a much smaller scope for each. Maybe the hash could be created only if there is a certain number of items in the data section. For example, if there are more than 20 items, you build the hash, otherwise you keep the linked-list. And that could be applied for both global and group data-sections. Simon - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Window client list submenus added....
On Sun, 18 Feb 2007 00:47:15 -0500, Christopher Michael [EMAIL PROTECTED] wrote : Ravenlock wrote: Hello, The attached patch will affect the client list seen when using the middle mouse button on the desktop. The list will continue to have the current desktops clients at the top, while all other desktop's clients will be contained within a submenu named after the desktop. In cvs, slightly modified :) It's a nice feature, but I think it would be better if it could be configured to get the previous layout. It was faster imho to find a window with the previous layout, because there was no need to look into each submenus. To avoid having an empty config dialog just for this option, maybe we could also add an option to list only the windows of the current vdesk in the Windows menu. Simon Cheers, dh - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Clock module patch
Hi guys,
Here is a small patch that makes the clock a bit easier to be read, by
adding a small label displaying the current time when the mouse is
over it (same way as labels in the ibox).
I know that Raster wants to keep the clock module as minimal as
possible, so I understand if it's not committed but I just thought that
maybe it could interest other people.
Here is how the clock looks like when the mouse is over it:
http://mtreny.free.fr/e17_clock.png
Regards,
Simon TRENY MoOmIndex: default_clock.edc
===
RCS file: /cvs/e/e17/apps/e/data/themes/default_clock.edc,v
retrieving revision 1.13
diff -u -r1.13 default_clock.edc
--- default_clock.edc 23 Aug 2006 03:39:01 - 1.13
+++ default_clock.edc 14 Feb 2007 05:55:01 -
@@ -187,6 +187,7 @@
script {
public clock_cb(val) {
new buf[11];
+ new bufh[11], bufm[11], bufs[11];
new year, month, day, yearday, weekday, hour, minute;
new Float:second;
new v;
@@ -209,12 +210,21 @@
if (v 10) {snprintf(buf, 10, 0%i, v);}
else{snprintf(buf, 10, %i, v);}
set_state(PART:minutes, buf, 0.0);
-
- v = ((hour % 12) * 5) + ((minute * 5) / 60);
+
+ v = ((hour % 12) * 5) + ((minute * 5) / 60);
buf[0] = 0;
if (v 10) {snprintf(buf, 10, 0%i, v);}
else{snprintf(buf, 10, %i, v);}
set_state(PART:hour, buf, 0.0);
+
+ if (hour 10) {snprintf(bufh, 10, 0%i, hour);}
+ else {snprintf(bufh, 10, %i, hour);}
+ if (minute 10) {snprintf(bufm, 10, 0%i, minute);}
+ else {snprintf(bufm, 10, %i, minute);}
+ if (second 10) {snprintf(bufs, 10, 0%i, round(second));}
+ else {snprintf(bufs, 10, %i, round(second));}
+ snprintf(buf, 10, %s:%s:%s, bufh, bufm, bufs);
+ set_text(PART:time_label, buf);
}
}
parts {
@@ -526,6 +536,49 @@
}
}
}
+ part {
+ name: time_label;
+ type: TEXT;
+ effect: SOFT_SHADOW;
+ mouse_events: 0;
+ description {
+ state: default 0.0;
+ align: 0.5 0.5;
+ rel1 {
+ relative: 0.0 1.0;
+ offset: 0-1;
+ }
+ rel2 {
+ relative: 1.0 1.0;
+ offset: -1-1;
+ }
+ color: 255 255 255 0;
+ color3: 0 0 0 0;
+ color_class: module_label;
+ text {
+ text: Tesyou;
+ font: Edje-Vera-Bold;
+ size: 9;
+ min: 1 1;
+ align: 0.5 0.5;
+ text_class: module_normal;
+ }
+ }
+ description {
+ state: visible 0.0;
+ inherit: default 0.0;
+ rel1 {
+ relative: 0.0 0.0;
+ offset: 00;
+ }
+ rel2 {
+ relative: 1.0 1.0;
+ offset: -1-1;
+ }
+ color: 255 255 255 255;
+ color3: 0 0 0 42;
+ }
+ }
}
programs {
program {
@@ -535,6 +588,22 @@
script {
clock_cb(0);
}
+ }
+ program {
+ name:show_time_label;
+ signal: mouse,in;
+ source: bg;
+ action: STATE_SET visible 0.0;
+ transition: SINUSOIDAL 0.5;
+ target: time_label;
+ }
+ program {
+ name:hide_time_label;
+ signal: mouse,out;
+ source: bg;
+ action: STATE_SET default 0.0;
+ transition: SINUSOIDAL 1.0;
+ target: time_label;
}
}
}
-
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=lnkkid=120709bid=263057dat=121642___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] What are E_Manager/Container/Zone ?
Hi everyone, I'm writing a module for e17 and I have some difficulties to understand the differences between E_Manager, E_Container and E_Zone. It seems E_Manager contains several E_Containers which contain several E_Zones. E_Zone seems to be divided in several E_Desk's (the virtual desktops) so I would think that the E_Zones are the actual screens. But then, what are the E_Containers and the E_Managers? And what exactly do e_manager/container/zone_current_get(). If a E_Zone corresponds really to a screen, how could a screen be the current one? Thanks in advance Simon - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] What are E_Manager/Container/Zone ?
Thanks, things are a lot clearer now :) There is just one thing that I still don't understand. Why the E_Desks are contained by a E_Zone and not by a E_Manager directly? I thought that when you join two physical screens with xinerama, they both share the same virtual desktops no? (I never used Xinerama so I may be wrong...) Or maybe the E_Desks from 2 E_Zones that belong to the same E_Container are the same? Thanks for your help :) Simon On Sun, 04 Feb 2007 17:18:59 +0100, Sebastian Dransfeld [EMAIL PROTECTED] wrote : Simon TRENY wrote: Hi everyone, I'm writing a module for e17 and I have some difficulties to understand the differences between E_Manager, E_Container and E_Zone. It seems E_Manager contains several E_Containers which contain several E_Zones. E_Zone seems to be divided in several E_Desk's (the virtual desktops) so I would think that the E_Zones are the actual screens. But then, what are the E_Containers and the E_Managers? And what exactly do e_manager/container/zone_current_get(). If a E_Zone corresponds really to a screen, how could a screen be the current one? 1 manager for each root display. 1 container for each virtual root (e17 does not support virtual roots, so 1 container for each manager). 1 zone for each screen (xinerama with two physical screens will result in 2 zones for each container). A standard setup will have 1 manager, 1 container and 1 zone. current() will give you the active one, typically where the pointer is. Sebastian - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Etk_Tree model fields setting
On Wed, 24 Jan 2007 18:07:35 -0200, Chady Kassouf [EMAIL PROTECTED] wrote : Hi, In order to fully implement the new Etk_Tree in Etk-Perl, I need to be able to set the fields of each model individually because I cannot manipulate va_lists in the xs code. Here's a patch that introduces two functions to set the fields of the model. Patch applied :) I just changed the syntax of etk_tree_row_model_fields_set(): the columns no longer have to be passed since the models are already linked to a column. And I've added etk_tree_row_model_fields_get() too. Thanks for the patch :) Simon - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] etk_colorpicker patch to add alpha slider ... and also a problem to solve :)
On Wed, 17 Jan 2007 23:41:27 +0100, DaveMDS [EMAIL PROTECTED] wrote : Hi attached a patch to add an alpha slider to etk_colorpicker. If someone need I can also make an option to disable the slider. (an application could not handle alpha channel and so could want to hide the slider) There is a problem in the way the current color is displayed in the dialog. I have this problem also in edje_editor and really I can't figure out how to solve. evas_object_color_set() don't draw the alpha in the right way: if the color is black the alpha are good, if the color is white the alpha never change until 0 is reached(and then disappear) Seems that evas always make the transparency on a white background. What problem is this? is evas? is etk? or I missed something Hope someone can help me, becouse I'am really out of idea :( Dave Sorry Dave, because of exams period, I won't have time to review the patch but if you need it for Edje Editor, you can commit the code and we'll improve it later if it needs so. I should have more time in one week. Thanks for the patch :) Simon - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_Evas and desktop translucency...
On Sun, 14 Jan 2007 01:29:55 -0600, Ed Presutti [EMAIL PROTECTED] wrote : Is there any way to do desktop translucency with the available Evas engines? I know i'm asking for a lot here and that this has been discussed in the past, but my current project would benefit greatly from it. (It's an EFL-powered desktop widget library) I've tried the software_x11 and xrender_x11 engines with no luck in either using the ecore_evas_alpha_set() call. What i'd really like is to not set the alpha at all from the C code and just let Evas determine when to do alpha based on the code in the edje file. (That way, my widget developers can control when they want alpha) you should indeed call ecore_evas_alpha_set() on the Ecore Evas, but it's not enough. You also need a composite manager that will perform the translucency effect. The bling module of e17 does that, but you can also use xcompmgr or any window manager that supports composite natively. Also, if there is a way to do it, will it work in other environments besides E17? If it doesn't work in the POS Compiz/Beryl environments, i'm totally okay with that. :-) Thanks in advance, Ed Presutti (ekrunch on freenode) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_Evas and desktop translucency...
On Sun, 14 Jan 2007 01:29:55 -0600, Ed Presutti [EMAIL PROTECTED] wrote : Is there any way to do desktop translucency with the available Evas engines? I know i'm asking for a lot here and that this has been discussed in the past, but my current project would benefit greatly from it. (It's an EFL-powered desktop widget library) I've tried the software_x11 and xrender_x11 engines with no luck in either using the ecore_evas_alpha_set() call. What i'd really like is to not set the alpha at all from the C code and just let Evas determine when to do alpha based on the code in the edje file. (That way, my widget developers can control when they want alpha) you should indeed call ecore_evas_alpha_set() on the Ecore Evas, but it's not enough. You also need a composite manager that will perform the translucency effect. The bling module of e17 does that, but you can also use xcompmgr or any window manager that supports composite natively. Also, if there is a way to do it, will it work in other environments besides E17? If it doesn't work in the POS Compiz/Beryl environments, i'm totally okay with that. :-) Thanks in advance, Ed Presutti (ekrunch on freenode) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Etk_Entry issue
On Sun, 07 Jan 2007 03:57:47 +0100, DaveMDS [EMAIL PROTECTED] wrote : Hi all I can't make the function etk_entry_clear() to work as expected: the text wont be cleared correctly .The caret is placed correctly but the text doesn't disappear. and also: etk_entry_text_set(entry,); and etk_entry_text_set(entry,NULL) doesn't works I have done a patch for etk_entry_test.c that show this issue. Is the error occur also on other system or is a problem of mine? Thanks Dave That's fixed. Thanks for the report :) Simon - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas GL engine patch
On Fri, 29 Dec 2006 10:55:28 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : On Sun, 10 Dec 2006 12:37:20 +0100 Simon TRENY [EMAIL PROTECTED] babbled: Hi, The GL engine of Evas has an annoying bug when you want to create several windows using this engine: when you create or resize a window, all the other windows already created are not redrawn correcly, only the last created/resized window has no problem. I've attached a shot that shows what happens when you create a new window while there is an existing window that already uses the GL engine. Please have a look at it if you want to understand the problem. So, in this example, the Etk Test Application is created first, and when the Entry button is clicked, the Etk Entry Test window is created. You can see that the Etk Test Application is no longer rendered correctly. Actually, only the part of the window that is inside the red rectangle (added with the Gimp) is correctly refreshed, the other part of the window does not refresh anymore. You can also notice that the red rectangle has exactly the same size as the Etk Entry Test window. In fact, the problem is that when you create/resize a window, _evas_gl_common_viewport_set() is called, and this function changes the GL viewport and the view matrices. The thing is, these changes affect all the windows, not only the created/resized window. A way to fix that would be to call _evas_gl_common_viewport_set() each time a window is rendered, before the rendering process begins (at the start of the function evas_render_updates_internal() for example). Only thing, I can't see a function that is called at the start of the rendering process in the engine API (something like pre_render()). I've written a small patch that calls _evas_gl_common_viewport_set() in the eng_output_redraws_rect_add() method of the gl_x11 engine (because this method is called at the start of the rendering process) just as a proof that it could fix the bug, but this is definitely not the place to put this code. The patch is attached. Please tell me what you think. that patch will do (not perfect - i think it's just masking the problem, but it shouldn't cause problems, and if ti fixes it for now - good). patch into my local tree - when i commit my latest changes it will go in. :) The patch that I submitted was just some sort of proof that it could work. As I said, it calls evas_gl_common_context_resize() in the output_redraws_rect_add() method of the gl_x11 engine, which is definitely not a good idea since this function is called several times at the start of the rendering process. A better way to avoid this would be to add a pre_render() method to the engine API, and to call this method once at the start of the rendering process. We could then call evas_gl_common_context_resize() in this method. This way, the viewport will be reset only once during the rendering process. Do you want me to write a patch that does that?? It'll be a lot cleaner imho. Simon TRENY MoOm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas GL engine patch
On Fri, 29 Dec 2006 11:25:28 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : On Sat, 16 Dec 2006 10:57:48 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: One thing though.. If one needs to have the 'viewport' and 'view matrices' set for each rendering pass, then I would say that this should maybe be done per obj, ie. in the internal engine render functions of each object... ?? Or does this only affect the way the gl render buffer gets 'put' on the screen? Yes, changing the GL viewport only affects the place where the whole scene is rendered in the window. You can for example create two viewports if you want to split the screen in 2 parts, like in multiplayer games on game consoles. I see... Thanks Simon. Well, even if you think your patch doesn't put those calls in the 'best' place they could be, if it solves the current gl drawing problems then I'd vote for applying it. Maybe you and rene (aka. centipede) can get together and see if you guys can do something more for the gl engine... :) i've actually been doing a bit lately. i know a few of the things it needs and as i just found recently - in order to sanely support fragment shaders for yuv-rgb i seem to need a gf6600 - my 5500fs just wont do fragment shaders (at a sane speed - software beats the 5500fx by like 200fps in software vs 0.4fps for gl in my yuv-rgb video surface test). so given this - i'm actually tempted to upgrade the iminimum requirements for gl engines. that is - REQUIRES non-power-of-2 textures. (not nv_rectangle - but npo2). requires anisotropic filtering, requires fragment shaders (glsl) etc. i can remove some nasty code to handle only power-of-2 textures for example and for nv_rectangle textures (as the text coords are different for these) Making the GL engine requires a GLSL card is really too restrictive imho, especially since (at least for now) GLSL is only used for yuv-rgb conversion, which is only used by Emotion. And this conversion can still be easily done in software if there is no GLSL support (we already have the code to do it). I have personally two GL cards and none of them support GLSL. I know that having to handle all the possible hardware configs is a lot of pain, but requiring GLSL is definitively too restrictive imho (actually even requiring anisotropic filtering is restrictive, it seems to be supported only since GeForce3 cards). jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje_editor: first snapshot!
Selon DaveMDS [EMAIL PROTECTED]: Hi all, I have done a first snapshot of the edje_editor source . this is the link http://www.gurumeditation.it/edje_editor-0.1-beta3.tar.gz It's the very first release so expect various segv just type make and RUN IN PLACE. NOTE: The file you are workin on must have a name, so save at least once before inserting parts Hope you like the work. DaveMDS PS: the program need glib2 to run and complile. This is because I have started the project with a gtk interface. And I have made intensive use of gstring. Hope I will make a version without glib in a short time. I haven't tested the app and read the code yet, but maybe you could use Etk_String instead of gstring. It supports most of the things supported by GString iirc. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas GL engine patch
Selon [EMAIL PROTECTED] [EMAIL PROTECTED]: One thing though.. If one needs to have the 'viewport' and 'view matrices' set for each rendering pass, then I would say that this should maybe be done per obj, ie. in the internal engine render functions of each object... ?? Or does this only affect the way the gl render buffer gets 'put' on the screen? Yes, changing the GL viewport only affects the place where the whole scene is rendered in the window. You can for example create two viewports if you want to split the screen in 2 parts, like in multiplayer games on game consoles. I see... Thanks Simon. Well, even if you think your patch doesn't put those calls in the 'best' place they could be, if it solves the current gl drawing problems then I'd vote for applying it. Well... for now, it's really dirty: it resets the viewport each time an update-rectangle is added by Evas (Evas does it several times in the rendering process so the viewport is reset several times...). But we can easily do it cleanly by resetting the viewport in a pre-render method of the engine API. I'm just waiting raster's opinion about the pre-render thing (where precisely should it be called in the rendering process? is there a better way to do that? ...) Maybe you and rene (aka. centipede) can get together and see if you guys can do something more for the gl engine... :) I don't know much about OpenGL, all I do is dirty tricks. :) But when I have more time, maybe I'll try to work on it. So if Rene is willing to work on it too, that'd be cool :) jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas GL engine patch
Quoting [EMAIL PROTECTED] [EMAIL PROTECTED]: In fact, the problem is that when you create/resize a window, _evas_gl_common_viewport_set() is called, and this function changes the GL viewport and the view matrices. The thing is, these changes affect all the windows, not only the created/resized window. A way to fix that would be to call _evas_gl_common_viewport_set() each time a window is rendered, before the rendering process begins (at the start of the function evas_render_updates_internal() for example). Only thing, I can't see a function that is called at the start of the rendering process in the engine API (something like pre_render()). I've written a small patch that calls _evas_gl_common_viewport_set() in the eng_output_redraws_rect_add() method of the gl_x11 engine (because this method is called at the start of the rendering process) just as a proof that it could fix the bug, but this is definitely not the place to put this code. The patch is attached. Please tell me what you think. Cheers, Simon TRENY MoOm I've never been able to actually use the evas gl engine due to something about my glx setup which is mysterious to me (and which I don't have the patience to try and resolve). On top of that, the OpenGl lib is something I have no familiarity with at all, so I can't tell you much of anything myself. One thing though.. If one needs to have the 'viewport' and 'view matrices' set for each rendering pass, then I would say that this should maybe be done per obj, ie. in the internal engine render functions of each object... ?? Or does this only affect the way the gl render buffer gets 'put' on the screen? Yes, changing the GL viewport only affects the place where the whole scene is rendered in the window. You can for example create two viewports if you want to split the screen in 2 parts, like in multiplayer games on game consoles. However, something like an engine level 'pre-render' function seems potentially useful.. I believe that raster has mentioned this somewhere as well. jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Putting GL-textures into Etk, Evas, bla bla... How to choke a horse with words.
On Tue, 14 Nov 2006 10:42:55 +0100, Rene Jensen [EMAIL PROTECTED] wrote : Simon, thanks, it worked! Next I'll see how well one can get away with mixing Etk with this. With a little luck it is just a matter of calling glViewport and glScissor before painting (and resetting them again afterwards of course). Here is a really simple code that shows how to make it work in Etk. It's still heavy experimentation, really dirty and it has some problems. To make it work, you still need the Evas patch (the flush callback thing) and the latest Etk to have the GL-X11 engine of Etk (I've just committed it). To compile it: gcc -o etk_gl_proto etk_gl_proto.c `etk-config --libs --cflags` -Wall -lGL -lGLU and to execute it, you have to say to the app that you'd like to use the GL-X11 engine, so the command is: ./etk_gl_proto --etk-engine=ecore_evas_gl_x11 It should work but it's a bit buggy (probably because I don't reset all the GL states before drawing the cube, so sometimes blending is enabled, sometimes scissor-test is enabled, ... it would be useful to have a command to reset all the GL-states to their default value...) I know this is a hack, but experimentation first, then we can start thinking about a clean solution that is OK with the lead developers. A way to make it cleaner and more generic would be to do as Jose said: render the OpenGL scene in a buffer, and render the buffer content in an Evas image. This should even be compatible with all the engines, but it may be a lot slower (I don't know, I never did something like that). Simon Regards Rene Simon TRENY wrote: Here is a fixed version of the test code. It fixes the back-face culling and some glPush/Pop*() bugs. Simon On Sun, 12 Nov 2006 18:21:09 +0100, Simon TRENY [EMAIL PROTECTED] wrote : Hi Rene, The main problem we have here is that what you'd like to do is definitely engine-specific whereas Evas tends to abstract totally the engine layer. Anyway, with some Evas engines it should be quite easy to use OpenGL to render 3D stuff. Here is how to do it with the GL-X11 engine of Evas (which is obviously the most appropriate engine to do that since it already provides the GL context). So, with the GL-X11 engine of Evas, all you have to do basically is to call all your OpenGL functions before glXSwapBuffers() gets called. glXSwapBuffers() is called by the output_flush() method of the GL-X11 engine, which is called by evas_render_updates_internal(). So the problem is that we need to be somehow notified before evas_render_updates_internal() calls the output_flush() method, and, for now, there is no way to do that. I have written a small patch for Evas to add a callback called each time before output_flush() is called. The function to set this callback is evas_flush_callback_set(). The Evas patch is joined with this email (this patch should not be applied to the CVS repository of Evas, it's a quick'n'dirty hack!!). Now, all you have to do is to make the calls to the OpenGL functions in the flush-callback. I have attached a a small code that shows how to do it. It's totally dirty and hacky but it works quite well :) There is just a small problem with the Zbuffer of with the backbface culling I guess (the cube looks weird...), but it shouldn't be hard to fix. To compile this code, you have to apply the patch to Evas, and to compile it with: gcc -o evas_gl_proto evas_gl_proto.c `ecore-config --cflags --libs` -lGL -lGLU -Wall Note that the GL engine of Evas has some serious problems though. Here is a list of the know problems written by raster some times ago: 1. a font with glyphs 256x256 pixels will just break. 2. images that are bigger than max texture size simply won't show (need to build a mesh) 3. cards that don't support rectangular textures will end up with nasty scaling results when scaling stretched or squashed mostly in 1 dimension (mipmap issues basically when used for 2d) 4. scaling down even with smooth scaling is ugly (need to use anisotropic filtering if possible) 5. doesn't support destination alpha (easy-ish to fix) 6. need pbuffer support implemented for the future (we need to be able to render to an intermediate buffer) 7. if the window is fullscreen glx may choose to do page flipping not copy from back to front buffer. in this case evas's assumption that the buffer was exactly as it left it when it last rendered is wrong - as it actually is as it was rendered 2 frames ago, not the last frame. There is also a problem when you have several windows using the GL engine in your program, but I think it's probably a problem with Ecore_Evas_GL. The Glitz engine that raster seems to be writting should fix most of these problems :) Regards :) Simon On Sun, 12 Nov 2006 12:40:37 +0100, Rene Jensen [EMAIL PROTECTED] wrote : WARNING: LONG POST AHEAD
Re: [E-devel] Putting GL-textures into Etk, Evas, bla bla... How to choke a horse with words.
Hi Rene, The main problem we have here is that what you'd like to do is definitely engine-specific whereas Evas tends to abstract totally the engine layer. Anyway, with some Evas engines it should be quite easy to use OpenGL to render 3D stuff. Here is how to do it with the GL-X11 engine of Evas (which is obviously the most appropriate engine to do that since it already provides the GL context). So, with the GL-X11 engine of Evas, all you have to do basically is to call all your OpenGL functions before glXSwapBuffers() gets called. glXSwapBuffers() is called by the output_flush() method of the GL-X11 engine, which is called by evas_render_updates_internal(). So the problem is that we need to be somehow notified before evas_render_updates_internal() calls the output_flush() method, and, for now, there is no way to do that. I have written a small patch for Evas to add a callback called each time before output_flush() is called. The function to set this callback is evas_flush_callback_set(). The Evas patch is joined with this email (this patch should not be applied to the CVS repository of Evas, it's a quick'n'dirty hack!!). Now, all you have to do is to make the calls to the OpenGL functions in the flush-callback. I have attached a a small code that shows how to do it. It's totally dirty and hacky but it works quite well :) There is just a small problem with the Zbuffer of with the backbface culling I guess (the cube looks weird...), but it shouldn't be hard to fix. To compile this code, you have to apply the patch to Evas, and to compile it with: gcc -o evas_gl_proto evas_gl_proto.c `ecore-config --cflags --libs` -lGL -lGLU -Wall Note that the GL engine of Evas has some serious problems though. Here is a list of the know problems written by raster some times ago: 1. a font with glyphs 256x256 pixels will just break. 2. images that are bigger than max texture size simply won't show (need to build a mesh) 3. cards that don't support rectangular textures will end up with nasty scaling results when scaling stretched or squashed mostly in 1 dimension (mipmap issues basically when used for 2d) 4. scaling down even with smooth scaling is ugly (need to use anisotropic filtering if possible) 5. doesn't support destination alpha (easy-ish to fix) 6. need pbuffer support implemented for the future (we need to be able to render to an intermediate buffer) 7. if the window is fullscreen glx may choose to do page flipping not copy from back to front buffer. in this case evas's assumption that the buffer was exactly as it left it when it last rendered is wrong - as it actually is as it was rendered 2 frames ago, not the last frame. There is also a problem when you have several windows using the GL engine in your program, but I think it's probably a problem with Ecore_Evas_GL. The Glitz engine that raster seems to be writting should fix most of these problems :) Regards :) Simon On Sun, 12 Nov 2006 12:40:37 +0100, Rene Jensen [EMAIL PROTECTED] wrote : WARNING: LONG POST AHEAD... (Sigh) After having posted on both IRC and the webforum, I get the distinct feeling that this community has been worn down by daft requests for getting fancy window drawing using OpenGL. This is a serious shame because now even the smallest utterance of that API makes it's author look guilty. The developers forget that end-users asking for something XGL'ish is a far cry from application developers asking for their favorite API for graphics/GLGPU programming, which they need to make video/3D applications using Ewl/Etk. However, as an application developer, I feel that: 1) Etk/Edje is perfect for the job. The efficiency is the reason I am choosing E if I can get away with it in the first place. I need a strong and themable GUI. I *LOVE* Efl's well-organized style! 2) The window manager and graphics lib should NOT squander my precious GPU cycles on needless features. If I could make a 3D in a console window, I'd do that. 3) An extra GL layer is actually another source of errors! Once I made a small 3D paint-program that used GL for the painting procedures, http://artcamilla.dk/centipede. I spend a LOT of time tracking down a bug in Windows where I use Nvidias desktop switcher. All that was drawn on my screen was a frame delayed. Turned out that when I switched off the desktop switcher or even turned off screen rotation (I have a tablet-pc), the bug dissappeared. Wasn't in my program after all. Incidently, the above mentioned program used my own OpenGL based mini-GUI. Guess why I am looking for another GUI with a strong support of themes ;-) 4) It will be hard to write any program at all in the video/3D industry without having support for OpenGL. Ok, enough ranting. This is a verbatim copy of the forum post I made few days ago. By the end of this mail, I have already answered some of it: I've learned
Re: [E-devel] Putting GL-textures into Etk, Evas, bla bla... How to choke a horse with words.
Here is a fixed version of the test code. It fixes the back-face culling and some glPush/Pop*() bugs. Simon On Sun, 12 Nov 2006 18:21:09 +0100, Simon TRENY [EMAIL PROTECTED] wrote : Hi Rene, The main problem we have here is that what you'd like to do is definitely engine-specific whereas Evas tends to abstract totally the engine layer. Anyway, with some Evas engines it should be quite easy to use OpenGL to render 3D stuff. Here is how to do it with the GL-X11 engine of Evas (which is obviously the most appropriate engine to do that since it already provides the GL context). So, with the GL-X11 engine of Evas, all you have to do basically is to call all your OpenGL functions before glXSwapBuffers() gets called. glXSwapBuffers() is called by the output_flush() method of the GL-X11 engine, which is called by evas_render_updates_internal(). So the problem is that we need to be somehow notified before evas_render_updates_internal() calls the output_flush() method, and, for now, there is no way to do that. I have written a small patch for Evas to add a callback called each time before output_flush() is called. The function to set this callback is evas_flush_callback_set(). The Evas patch is joined with this email (this patch should not be applied to the CVS repository of Evas, it's a quick'n'dirty hack!!). Now, all you have to do is to make the calls to the OpenGL functions in the flush-callback. I have attached a a small code that shows how to do it. It's totally dirty and hacky but it works quite well :) There is just a small problem with the Zbuffer of with the backbface culling I guess (the cube looks weird...), but it shouldn't be hard to fix. To compile this code, you have to apply the patch to Evas, and to compile it with: gcc -o evas_gl_proto evas_gl_proto.c `ecore-config --cflags --libs` -lGL -lGLU -Wall Note that the GL engine of Evas has some serious problems though. Here is a list of the know problems written by raster some times ago: 1. a font with glyphs 256x256 pixels will just break. 2. images that are bigger than max texture size simply won't show (need to build a mesh) 3. cards that don't support rectangular textures will end up with nasty scaling results when scaling stretched or squashed mostly in 1 dimension (mipmap issues basically when used for 2d) 4. scaling down even with smooth scaling is ugly (need to use anisotropic filtering if possible) 5. doesn't support destination alpha (easy-ish to fix) 6. need pbuffer support implemented for the future (we need to be able to render to an intermediate buffer) 7. if the window is fullscreen glx may choose to do page flipping not copy from back to front buffer. in this case evas's assumption that the buffer was exactly as it left it when it last rendered is wrong - as it actually is as it was rendered 2 frames ago, not the last frame. There is also a problem when you have several windows using the GL engine in your program, but I think it's probably a problem with Ecore_Evas_GL. The Glitz engine that raster seems to be writting should fix most of these problems :) Regards :) Simon On Sun, 12 Nov 2006 12:40:37 +0100, Rene Jensen [EMAIL PROTECTED] wrote : WARNING: LONG POST AHEAD... (Sigh) After having posted on both IRC and the webforum, I get the distinct feeling that this community has been worn down by daft requests for getting fancy window drawing using OpenGL. This is a serious shame because now even the smallest utterance of that API makes it's author look guilty. The developers forget that end-users asking for something XGL'ish is a far cry from application developers asking for their favorite API for graphics/GLGPU programming, which they need to make video/3D applications using Ewl/Etk. However, as an application developer, I feel that: 1) Etk/Edje is perfect for the job. The efficiency is the reason I am choosing E if I can get away with it in the first place. I need a strong and themable GUI. I *LOVE* Efl's well-organized style! 2) The window manager and graphics lib should NOT squander my precious GPU cycles on needless features. If I could make a 3D in a console window, I'd do that. 3) An extra GL layer is actually another source of errors! Once I made a small 3D paint-program that used GL for the painting procedures, http://artcamilla.dk/centipede. I spend a LOT of time tracking down a bug in Windows where I use Nvidias desktop switcher. All that was drawn on my screen was a frame delayed. Turned out that when I switched off the desktop switcher or even turned off screen rotation (I have a tablet-pc), the bug dissappeared. Wasn't in my program after all. Incidently, the above mentioned program used my own OpenGL based mini-GUI. Guess why I am looking for another GUI with a strong support of themes ;-) 4) It will be hard to write any program at all
Re: [E-devel] E CVS: libs/evas raster
On Wed, 1 Nov 2006 07:56:12 -0500 (EST),
Enlightenment CVS [EMAIL PROTECTED] wrote :
Enlightenment CVS committal
Author : raster
Project : e17
Module : libs/evas
Dir : e17/libs/evas/src/lib/engines/common
Modified Files:
evas_font_main.c
Log Message:
evas utf8 patch broke e17's about box. revert
Oops.. evas_common_font_utf8_get_prev() was indeed broken. Here is a
new patch that fixes that.
I agree that for window titles, it would be better to detect the
encoding and then to convert it to UTF-8 but there is some cases where
you can not know for sure the encoding used (as I said, media
metadata, subtitles, or even filenames). For example, without this
patch, with the file manager of e17, the accented filenames on my
Fat32 partition are cut off.
Simon--- evas_font_main.orig.c 2006-09-06 09:33:40.0 +0200
+++ evas_font_main.c 2006-11-01 15:45:44.0 +0100
@@ -120,34 +120,34 @@
* the decoded code point at iindex offset, and advances iindex
* to the next code point after this.
*
-* Returns 0 to indicate an error (e.g. invalid UTF8)
+* Returns 0 to indicate there is no next char
*/
- int index = *iindex, r;
+ int index = *iindex, len, r;
unsigned char d, d2, d3, d4;
d = buf[index++];
if (!d)
return 0;
- if (d 0x80)
+
+ while (buf[index] ((buf[index] 0xc0) == 0x80))
+ index++;
+ len = index - *iindex;
+
+ if (len == 1)
+ r = d;
+ else if (len == 2)
{
- *iindex = index;
- return d;
- }
- if ((d 0xe0) == 0xc0)
- {
- /* 2 byte */
- if (((d2 = buf[index++]) 0xc0) != 0x80)
- return 0;
+ /* 2 bytes */
+d2 = buf[*iindex + 1];
r = d 0x1f; /* copy lower 5 */
r = 6;
r |= (d2 0x3f); /* copy lower 6 */
}
- else if ((d 0xf0) == 0xe0)
+ else if (len == 3)
{
- /* 3 byte */
- if (((d2 = buf[index++]) 0xc0) != 0x80 ||
- ((d3 = buf[index++]) 0xc0) != 0x80)
- return 0;
+ /* 3 bytes */
+d2 = buf[*iindex + 1];
+d3 = buf[*iindex + 2];
r = d 0x0f; /* copy lower 4 */
r = 6;
r |= (d2 0x3f);
@@ -156,11 +156,10 @@
}
else
{
- /* 4 byte */
- if (((d2 = buf[index++]) 0xc0) != 0x80 ||
- ((d3 = buf[index++]) 0xc0) != 0x80 ||
- ((d4 = buf[index++]) 0xc0) != 0x80)
- return 0;
+ /* 4 bytes */
+d2 = buf[*iindex + 1];
+d3 = buf[*iindex + 2];
+d4 = buf[*iindex + 3];
r = d 0x0f; /* copy lower 4 */
r = 6;
r |= (d2 0x3f);
@@ -169,6 +168,7 @@
r = 6;
r |= (d4 0x3f);
}
+
*iindex = index;
return r;
}
@@ -177,37 +177,37 @@
evas_common_font_utf8_get_prev(unsigned char *buf, int *iindex)
{
/* Reads UTF8 bytes from @buf, starting at [EMAIL PROTECTED] and returns
-* the decoded code point at iindex offset, and advances iidnex
-* to the next code point after this.
+* the decoded code point at iindex offset, and advances iindex
+* to the prev code point after this.
*
-* Returns 0 to indicate an error (e.g. invalid UTF8)
+* Returns 0 to indicate there is no prev char
*/
- int index = *iindex, r, istart = *iindex;
+ int index = *iindex, len, r;
unsigned char d, d2, d3, d4;
- d = buf[index++];
- if (d 0x80)
- {
- r = d;
- }
- else if ((d 0xe0) == 0xc0)
+ if (iindex = 0)
+ return 0;
+ d = buf[index--];
+
+ while ((index 0) ((buf[index] 0xc0) == 0x80))
+ index--;
+ len = *iindex - index;
+
+ if (len == 1)
+ r = d;
+ else if (len == 2)
{
- /* 2 byte */
- d2 = buf[index++];
- if ((d2 0xc0) != 0x80)
- return 0;
+ /* 2 bytes */
+d2 = buf[index + 1];
r = d 0x1f; /* copy lower 5 */
r = 6;
r |= (d2 0x3f); /* copy lower 6 */
}
- else if ((d 0xf0) == 0xe0)
+ else if (len == 3)
{
- /* 3 byte */
- d2 = buf[index++];
- d3 = buf[index++];
- if ((d2 0xc0) != 0x80 ||
- (d3 0xc0) != 0x80)
- return 0;
+ /* 3 bytes */
+d2 = buf[index + 1];
+d3 = buf[index + 2];
r = d 0x0f; /* copy lower 4 */
r = 6;
r |= (d2 0x3f);
@@ -216,14 +216,10 @@
}
else
{
- /* 4 byte */
- d2 = buf[index++];
- d3 = buf[index++];
- d4 = buf[index++];
- if ((d2 0xc0) != 0x80 ||
- (d3 0xc0) != 0x80 ||
- (d4 0xc0) != 0x80)
- return 0;
+ /* 4 bytes */
+d2 = buf[index + 1];
+d3 = buf[index + 2];
+d4 = buf[index + 3];
r = d 0x0f; /* copy lower 4 */
r = 6;
r |= (d2 0x3f);
@@ -232,30 +228,8 @@
r = 6;
r |= (d4 0x3f);
}
- if (istart 0)
- {
- index = istart - 1;
- d = buf[index];
- if (!(d 0x80))
- *iindex = index;
- else
- {
- while (index 0)
- {
- index--;
- d = buf[index];
- if ((d 0xc0) != 0x80)
- {
- *iindex = index;
- return r;
- }
- }
- }
- }
- else
- {
- *iindex = -1;
- }
+
+ *iindex = index;
return r;
}
-
Using
Re: [E-devel] Evas Utf-8 patch
On Wed, 1 Nov 2006 08:42:00 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : On Tue, 31 Oct 2006 23:21:46 +0100 Simon TRENY [EMAIL PROTECTED] babbled: Hi, Here is a patch that changes the behaviour of evas_common_font_utf8_get_next() and evas_common_font_utf8_get_pref(): for now, these functions return 0 at the first invalid UTF-8 char met, and do not continue further. With this patch, the functions will try to return a char code even if the char is invalid and they will only return 0 at the end (or at the start for get_prev()) of the string. The returned code will probably be incorrect, but at least, when Evas will render the string, the text won't be cut at the first invalid char position. It happens quite often when we use E17 in an accented language: the accented title of the windows are often incomplete because the title is often encoded in ascii 8-bit (at least for apps in French). It also helps when you have to render text and you don't know the encoding (Metadata, subtitles, ...). Note that with this patch, evas_common_font_utf8_get_next() will return valid char code if the string is encoded in ascii 8-bit. i think this is more a matter that with e we need to convert whatever local encoding for icccm props (if the app isnt using utf8 for its string encodings of properites like titme) and convert to utf8. ecore_x SHOULD be doing that, so it ALWAYS presents utf8 text, but does not. fair enough to be more forgiving of malformed utf8 strings - but the problem just changes from being cut off to garbage in the middle of the string. Thanks, I see that you applied the patch :) Another solution to avoid garbage could be to skip every malformed characters. If the string is malformed, I see no other solutions than to try to guess what the character is (which is done with this patch) but it may result in garbage, or to skip the char. Simon - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Subtitles in Emotion ?
On Sun, 29 Oct 2006 10:13:15 +0900,
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote :
On Sat, 28 Oct 2006 22:44:07 +0200 Charles de Noyelle
[EMAIL PROTECTED] babbled:
Hello,
My post is about .srt subtitles in Emotion.
I tried to look into the code, and I *think* that nothing is done
to read subtitles. What I expected and look for is kind of
EAPI void emotion_object_{subtitles,spu}_file_set ( Evas_Object
*obj, const char *filename )
I saw the emotion_object_spu_channel_count(Evas_Object *obj) But
I could not figure out what it was used for... DVD's subs ?
yes - dvd subtitles are handled by libxine as video overlays - they
do work if turned on. there is no way to use external files.
The thing is that needs some changes in Emotion EAPI, and maybe, a
such thing is not wanted (read subtitles in Emotion).
What do you thing about it? Would that be easy to do? Is it
necessary?
i suggest first looking at gstreamer and xine api's to see if you can
put it there as the subtitles also need to be timed to the video.
I had implemented .srt support for eclair some times ago and it was
working quite well but it is now broken since it still uses the old
textblock API. I know that the API of xine allow to load external
subtitles, and gstreamer's probably does too, but those substitles
won't look as good as if we use an evas' text object to render them:
xine and gstreamer directly render the subtitles in the YUV data, so
when the video is stretched, the subtitles are stretched too. With
evas' text object, we could also make the subtitles transparent, glow,
cast a shadow, ... So I would probably be a good idea to make emotion
render its own subtitles.
Now there are several problems that I met when I implemented that in
eclair. First the text encoding: Evas requires UTF-8 whereas .srt
files doesn't seem to follow a standard: some times they uses 8-bit
ascii, some times UTF-8, ..., and it's not specified in the files. So
we would need to be able to auto-detect the encoding of a text. Is
there a way to do that? And also, I noticed that when you render an
incorrectly UTF-8 encoded text with Evas, Evas only renders the text up
to the first incorrect character, the following characters are not
rendered. It may be good to just ignore the incorrect character, and to
continue to render the others (I don't know if it's easy to do though, I
just know that GTK and QT do that so it should be possible :))
Other problem: there are a lot of subtitle formats (srt, ssa, txt, ...)
so we would need a lot of loaders if we want to support them all. Srt
seems to be the most used by far (and it is really easy to load), so we
should probably start with it.
I will try to add .srt support to emotion this week end.
Simon
-
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=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Etk] Evas Premul - Please do not fix
Hi there, As Jose's premul-color patch has hit the cvs, some Etk widgets might now look wrong. I have currently a *huge* patch for Etk waiting to be committed (I still need to finish some things) so I'd really appreciate if you could avoid to fix Etk for now, or it'll be a pain for me to commit my patch (I will commit from a Windows machine, over SSH, so it won't be fun if I have a lot of conflicts to fix...). I will probably commit it during the week. Thanks :) Simon TRENY MoOm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: sebastid sebastid
Sebastian is probably one of the developers who done the most for e17 and the EFL (a lot of useful and painful work on ecore_x and e17), and there is no way he's going to leave for reasons like these (this problem should have been sorted out privately, there was really no need to publicly criticize/insult Seb imho...) So Seb, if you read this, come back, we definetely need you here. It' an ORDER!! :) Simon - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje canvas objects
Quoting [EMAIL PROTECTED] [EMAIL PROTECTED]: Jason writes: Much ado about gradients, but hopefully all this will make it easier to work with grads in current edje and otherwise. Forgive me for chiming in when I haven't read the full thread nor grokked the context, but does any of your work allow being able to set gradients as clipping objects? The ability to clip a text object with a gradient to allow fading text out is something I've wanted to be able to do for a long time. :) Cheers, Jason. The short anwser is no. Only rectangle objs work as clip objs in evas at this time. The longer anwser is that yes, there is a way you can do this right now - if you use a buffer evas for your text output. You would setup your buffer evas (make sure it's set to have-alpha). Then add your text obj and add a suitable grad obj on top of that -- AND set the grad obj's render-op to EVAS_RENDER_MUL. Just thought I'd follow up on this a bit... Note that in the above one can also use an image object, indeed all renderable objects respect the various render-ops (only for buffer-engine based evases right now, though the 'mul' render-op only behaves like 'clipping' for non-shape like objs, eg. images/grads). Likely evas will have general obj clipping not too far away, but 'buffer evases' are also interesting and useful (hence the ecore sub-canvases). I think it would be indeed really useful to have such objects: I may be wrong but I think this kind of objects is the way to go if we want to support blitting in Evas. It should improve the perfs a lot when we have to scroll large areas of screen (the scrolling part would just be a subcanvas, so, in order to scroll, we would just have to move this subcanvas. No need to redraw all the objects of the subcanvas). We could maybe implement this in the smart objects: A smart object could render (if we say so) in a subcanvas, so moving the smart object won't require to redraw all the sub objects. Regards, Simon TRENY MoOm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore shorne
On Thu, 7 Sep 2006 19:38:58 +0800, Stafford Horne [EMAIL PROTECTED] wrote : On Tue, 5 Sep 2006 02:54:33 +0200 Simon TRENY [EMAIL PROTECTED] wrote: Any reason to do this actually? Ecore_FB is not dead/unmaintained, Jorge has recently worked on it, and it now works really well (thanks Jorge :)). If you have noticed any bug with it, please tell us :) Simon, We had a discussion about this earlier. It was both in the e-users and e-devel mailing lists under the subject: [E-devel] Fw: [e-users] compiling ecore on a system running 2.4.x kernel Essentially, The ecore_fb code does not build on some machines. We have agreed (i believe jorge did as well) that the build system needs a bit more testing before its ready to work by default. I have not had time to fix the build system at the time so we decided to disable it. Once it gets fixed there will be no problem allowing it by default. That's ok then :) -Stafford - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: Edje drag and drop, random translations
On Mon, 4 Sep 2006 17:54:23 +1000,
Alysander Stanley [EMAIL PROTECTED] wrote :
Hello, I have been experimenting with edje and had some odd
behaviour with drag and drop in edje.
After clicking and draging a part through dragable { }, and then
(without moving the mouse) clicking and then dragging again, the part
translates in an unpredictable way so that it is no longer underneath
the cursor. This is within edje_viewer and also from within a
compiled evas. Does anyone else experience this problem?
Sample .edc attached
It won't help, but I've noticed the same problem. It seems to be a bug
in Edje.
Simon
-
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=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore shorne
On Thu, 17 Aug 2006 19:41:48 -0400 (EDT), Enlightenment CVS [EMAIL PROTECTED] wrote : Enlightenment CVS committal Author : shorne Project : e17 Module : libs/ecore Dir : e17/libs/ecore Modified Files: configure.in Log Message: Disabiling ecore-fb and ecore-evas-fb by default. Everyone can still enable it by using --enable-ecore-fb or --enable-ecore-evas-fb with the autogen.sh or configure scripts. Any reason to do this actually? Ecore_FB is not dead/unmaintained, Jorge has recently worked on it, and it now works really well (thanks Jorge :)). If you have noticed any bug with it, please tell us :) You can give it a try with the Ecore_FB engine of Etk. Just run etk_test --etk-engine=ecore_fb (it should work with other ETK apps too) (the Etk's engine is not finished though) Regards, Simon TRENY MoOm - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Resizing Edje Parts - on the road to entrance preview
On Mon, 21 Aug 2006 14:36:05 +0100, Essien Ita Essien [EMAIL PROTECTED] wrote : Carsten Haitzler (The Rasterman) wrote: On Mon, 21 Aug 2006 13:55:45 +0100 Essien Ita Essien [EMAIL PROTECTED] babbled: no attachment :) but - note the livethumb uses a BUFFER canvas - it sets the resolution of the BUFFER canvas to be higher than the output. make this resolution high enough (eg 800x600) and evas will scale that 800x600 buffer canvas down to the size of the output of the preview. that is how the livethumb works. a that was what CodeWarrior was talking about when he said I could use a buffer... neat. ok.. i'm going back to grok e_livethumb with an eye to steal this new information. :) If you use the buffer engine to do that, you won't be able interact with the mouse (I think you said you wanted that), or you'll have to feed the events yourself (a bit painful). Simon thnx. Hiya Everybody, I've been on a slow road to building a real preview object for entrance_edit_gui. The idea is to always show the full entrance in a small preview window, complete with all the edje effects that the theme or background may have to offer. Eventually too, complete with the greetings, etc. Right now though, all i just want is to display (obviously :) ). Raster and Codewarrior asked me to look thru e_livethumb subsystem. And I discovered i knew nothing of Esmarts and coding that the evas layer, so I went to fix that and I'm better in that regard now. Here I'm attaching minientrance.tar.gz (NOTE: THE ENTRANCE THEME FILE I USED IS HARDCODED, PLEASE MODIFY B4 YOU COMPILE) which is a complete esmart object for entrance that i'm playing with to understand the problem (apparently, there's an incomplete and not used entrance_smart object in entrance right now, but its well... not quite in use, so its rusty). The main problem I have with this smart object and infact, in general is that when I load the edje, the main login box, refuses to resize below its min geometry. I do not know if its possible to *force* an edje part to resize below its min width or so. If you compile minientrance, and resize the window, you'll notice the box just refuses to resize with the rest of the ui. What I was aiming at doing is to instantiate the entrance_smart obj, and give it a size say 100x50, and have it render itself properly as a preview. When I then change the theme or background in the gui config tool, I'll just make the esmart object refresh itself. Basically, i guess once the smart object works well, its all ok. the next issue will be loading it in an etk/ewl canvas or something. But that's another story :) Am I on the right track? Someone, smack me on the head with a solution/idea :) cheers, Essien - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Resizing Edje Parts - on the road to entrance preview
On Mon, 21 Aug 2006 23:32:56 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : On Mon, 21 Aug 2006 16:11:52 +0200 Simon TRENY [EMAIL PROTECTED] babbled: On Mon, 21 Aug 2006 14:36:05 +0100, Essien Ita Essien [EMAIL PROTECTED] wrote : Carsten Haitzler (The Rasterman) wrote: On Mon, 21 Aug 2006 13:55:45 +0100 Essien Ita Essien [EMAIL PROTECTED] babbled: no attachment :) but - note the livethumb uses a BUFFER canvas - it sets the resolution of the BUFFER canvas to be higher than the output. make this resolution high enough (eg 800x600) and evas will scale that 800x600 buffer canvas down to the size of the output of the preview. that is how the livethumb works. a that was what CodeWarrior was talking about when he said I could use a buffer... neat. ok.. i'm going back to grok e_livethumb with an eye to steal this new information. :) If you use the buffer engine to do that, you won't be able interact with the mouse (I think you said you wanted that), or you'll have to feed the events yourself (a bit painful). ecore_evas provides a buffer canvas wrapper that returns an evas image object and does all the event feeding for you :) Oh.. Great :) Simon thnx. Hiya Everybody, I've been on a slow road to building a real preview object for entrance_edit_gui. The idea is to always show the full entrance in a small preview window, complete with all the edje effects that the theme or background may have to offer. Eventually too, complete with the greetings, etc. Right now though, all i just want is to display (obviously :) ). Raster and Codewarrior asked me to look thru e_livethumb subsystem. And I discovered i knew nothing of Esmarts and coding that the evas layer, so I went to fix that and I'm better in that regard now. Here I'm attaching minientrance.tar.gz (NOTE: THE ENTRANCE THEME FILE I USED IS HARDCODED, PLEASE MODIFY B4 YOU COMPILE) which is a complete esmart object for entrance that i'm playing with to understand the problem (apparently, there's an incomplete and not used entrance_smart object in entrance right now, but its well... not quite in use, so its rusty). The main problem I have with this smart object and infact, in general is that when I load the edje, the main login box, refuses to resize below its min geometry. I do not know if its possible to *force* an edje part to resize below its min width or so. If you compile minientrance, and resize the window, you'll notice the box just refuses to resize with the rest of the ui. What I was aiming at doing is to instantiate the entrance_smart obj, and give it a size say 100x50, and have it render itself properly as a preview. When I then change the theme or background in the gui config tool, I'll just make the esmart object refresh itself. Basically, i guess once the smart object works well, its all ok. the next issue will be loading it in an etk/ewl canvas or something. But that's another story :) Am I on the right track? Someone, smack me on the head with a solution/idea :) cheers, Essien - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list
Re: [E-devel] Getting the window containing an e17 widget
Thanks raster, that works great, the entry of e17 now supports copy/paste :) About the pointer push/pop thing, I've seen that you didn't use the special_pointer boolean. Have you actually fixed that directly in E_Pointer? I have the same problem with Etk, sometimes mouse_out is just not emitted, and that makes the pointer be stuck in a special pointer. Do you have any idea why mouse_out is not emitted? Thanks, Simon On Sun, 20 Aug 2006 14:10:36 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : On Sun, 20 Aug 2006 12:24:39 +0900 Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] babbled: ok - actually - added this: E_Pointer *p; p = e_widget_pointer_get(my_widget); :) then push/pop pointers there :) On Sat, 19 Aug 2006 23:15:59 +0200 Simon TRENY [EMAIL PROTECTED] babbled: Hi, actually- scrap that - it was ecore_evas that has the data attach call with a key - serves me right for programming in an email client :) i will work on something. I'm working on the entry of e17 and I'm currently implementing copy/paste support. For this, I need to call the ecore_x_selection_clipboard_*() functions which require an Ecore_X *. Since the entry is just a simple Evas smart object, there is no way to get this Ecore_X pointer. I would also need this to change the pointer of the mouse when the mouse enters the entry, using the e_pointer_*() functions. e_pointer_*() requires an E_Pointer * pointer. Both Ecore_X * and E_Pointer * could be accessed if I could get the E_Border * containing the widget. Do you have any idea how could I get the border (or another struct that would allow me to get what I need) that contains the entry? Thanks, Simon TRENY MoOM - 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=lnkkid=120709bid=263057dat=121642 ___ 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 (東京 日本) - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Getting the window containing an e17 widget
Hi, I'm working on the entry of e17 and I'm currently implementing copy/paste support. For this, I need to call the ecore_x_selection_clipboard_*() functions which require an Ecore_X *. Since the entry is just a simple Evas smart object, there is no way to get this Ecore_X pointer. I would also need this to change the pointer of the mouse when the mouse enters the entry, using the e_pointer_*() functions. e_pointer_*() requires an E_Pointer * pointer. Both Ecore_X * and E_Pointer * could be accessed if I could get the E_Border * containing the widget. Do you have any idea how could I get the border (or another struct that would allow me to get what I need) that contains the entry? Thanks, Simon TRENY MoOM - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto rhapsodhy
On Wed, 16 Aug 2006 05:18:41 -0400 (EDT), Enlightenment CVS [EMAIL PROTECTED] wrote : Enlightenment CVS committal Author : rhapsodhy Project : e17 Module : proto Dir : e17/proto/entrance_edit_gui/src/widgets Modified Files: _ew_list.c ew_dialog.c ew_dialog.h ew_entry.c ew_group.c ew_messagebox.c ew_messagebox.h ew_notice.c ew_notice.h Log Message: I don't know what is this etk_box_append(), but there were a lot of it, and has to be wiped out, because doesn't exists. Also, fixed the messageboxes, now they work again. You should probably update Etk :) etk_box_pack_start/end() has been replaced by etk_box_append() and other functions. Regards, Simon TRENY MoOm - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e raster
On Sat, 12 Aug 2006 23:37:23 -0400 (EDT),
Enlightenment CVS [EMAIL PROTECTED] wrote :
Enlightenment CVS committal
Author : raster
Project : e17
Module : apps/e
Dir : e17/apps/e/src/bin
Modified Files:
e_border.c
Log Message:
focusout patch from sthitha
This patch makes e17 segfault when I drag an icon to a directory in Rox
Filer. I think it's because the Move window appears and
disappears really quickly. So I guess it happens when a window pops up
and pops down REALLY quickly.
Here is the backtrace:
http://rafb.net/paste/results/WQe3U182.html
and the valgrind log:
http://rafb.net/paste/results/VpdN5T35.html
(this warning is repeated at least 30 times)
Cheers,
Simon TRENY MoOm
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_border.c,v
retrieving revision 1.523
retrieving revision 1.524
diff -u -3 -r1.523 -r1.524
--- e_border.c12 Aug 2006 13:22:48 - 1.523
+++ e_border.c13 Aug 2006 03:37:23 - 1.524
@@ -1351,11 +1351,20 @@
{
if (focused)
{
+ E_Event_Border_Focus_Out *ev;
//printf(unfocus previous\n);
edje_object_signal_emit(focused-bg_object, passive,
); if (focused-icon_object)
edje_object_signal_emit(focused-icon_object,
passive, ); e_focus_event_focus_out(focused);
+
+ ev = calloc(1, sizeof(E_Event_Border_Focus_Out));
+ ev-border = focused;
+ e_object_ref(E_OBJECT(focused));
+
+ ecore_event_add(E_EVENT_BORDER_FOCUS_OUT, ev,
+ _e_border_event_border_focus_out_free,
NULL); +
/* FIXME: Sometimes we should leave the window
fullscreen! */ // if (focused-fullscreen)
e_border_unfullscreen(focused); focused-focused = 0;
-
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=lnkkid=120709bid=263057dat=121642
___ enlightenment-cvs
mailing list enlightenment-cvs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
-
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=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e raster
On Wed, 16 Aug 2006 16:13:13 +0200,
Simon TRENY [EMAIL PROTECTED] wrote :
On Sat, 12 Aug 2006 23:37:23 -0400 (EDT),
Enlightenment CVS [EMAIL PROTECTED] wrote :
Enlightenment CVS committal
Author : raster
Project : e17
Module : apps/e
Dir : e17/apps/e/src/bin
Modified Files:
e_border.c
Log Message:
focusout patch from sthitha
This patch makes e17 segfault when I drag an icon to a directory in
Rox Filer. I think it's because the Move window appears and
disappears really quickly. So I guess it happens when a window pops up
and pops down REALLY quickly.
Here is the backtrace:
http://rafb.net/paste/results/WQe3U182.html
and the valgrind log:
http://rafb.net/paste/results/VpdN5T35.html
(this warning is repeated at least 30 times)
Since the paste on rafb.net are deleted after 24 hours, I post the logs
here:
- Backtrace:
Program received signal SIGSEGV, Segmentation fault.
e_object_unref (obj=0x3a8) at e_object.c:99
99 obj-references--;
(gdb) bt
#0 e_object_unref (obj=0x3a8) at e_object.c:99
#1 0x0807c1d9 in _e_border_free (bd=0x81365a0) at e_border.c:2989
#2 0x080921a9 in e_object_unref (obj=0x3a8) at e_object.c:101
#3 0x0807ac92 in _e_border_event_border_focus_out_free (data=0x0,
ev=0x8179e28) at e_border.c:6650
#4 0xb7e971b3 in _ecore_event_del (event=0x82f0f88) at
ecore_events.c:356 #5 0xb7e97505 in _ecore_event_call () at
ecore_events.c:444 #6 0xb7e9cbfe in _ecore_main_loop_iterate_internal
(once_only=0) at ecore_main.c:639
#7 0xb7e9cdff in ecore_main_loop_begin () at ecore_main.c:79
#8 0x080651c7 in main (argc=1, argv=0xbfb3f804) at e_main.c:713
- Valgrind log:
==4222== Invalid read of size 4
==4222==at 0x8092298: e_object_unref (e_object.c:99)
==4222==by 0x807ACA1: _e_border_event_border_focus_out_free
(e_border.c:6650)
==4222==by 0x40AE1B2: _ecore_event_del (ecore_events.c:356)
==4222==by 0x40AE504: _ecore_event_call (ecore_events.c:444)
==4222==by 0x40B3BFD: _ecore_main_loop_iterate_internal (ecore_main.c:639)
==4222==by 0x40B3DFE: ecore_main_loop_begin (ecore_main.c:79)
==4222==by 0x80651D6: main (e_main.c:713)
==4222== Address 0x47EDB90 is 8 bytes inside a block of size 932 free'd
==4222==at 0x401F199: free (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==4222==by 0x80922B8: e_object_unref (e_object.c:101)
==4222==by 0x807AC71: _e_border_event_border_focus_in_free (e_border.c:6640)
==4222==by 0x40AE1B2: _ecore_event_del (ecore_events.c:356)
==4222==by 0x40AE504: _ecore_event_call (ecore_events.c:444)
==4222==by 0x40B3BFD: _ecore_main_loop_iterate_internal (ecore_main.c:639)
==4222==by 0x40B3DFE: ecore_main_loop_begin (ecore_main.c:79)
==4222==by 0x80651D6: main (e_main.c:713)
Simon
Cheers,
Simon TRENY MoOm
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_border.c,v
retrieving revision 1.523
retrieving revision 1.524
diff -u -3 -r1.523 -r1.524
--- e_border.c 12 Aug 2006 13:22:48 - 1.523
+++ e_border.c 13 Aug 2006 03:37:23 - 1.524
@@ -1351,11 +1351,20 @@
{
if (focused)
{
+E_Event_Border_Focus_Out *ev;
// printf(unfocus previous\n);
edje_object_signal_emit(focused-bg_object, passive,
); if (focused-icon_object)
edje_object_signal_emit(focused-icon_object,
passive, ); e_focus_event_focus_out(focused);
+
+ev = calloc(1, sizeof(E_Event_Border_Focus_Out));
+ev-border = focused;
+e_object_ref(E_OBJECT(focused));
+
+ecore_event_add(E_EVENT_BORDER_FOCUS_OUT, ev,
+_e_border_event_border_focus_out_free,
NULL); +
/* FIXME: Sometimes we should leave the window
fullscreen! */ //if (focused-fullscreen)
e_border_unfullscreen(focused); focused-focused = 0;
-
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=lnkkid=120709bid=263057dat=121642
___ enlightenment-cvs
mailing list enlightenment-cvs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
-
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=lnkkid=120709bid=263057dat=121642
___ enlightenment-devel
mailing list
Re: [E-devel] E CVS: proto essiene
On Wed, 16 Aug 2006 21:06:28 +0100,
Essien Ita Essien [EMAIL PROTECTED] wrote :
Kim Woelders wrote:
Enlightenment CVS wrote:
Enlightenment CVS committal
Author : essiene
Project : e17
Module : proto
Dir : e17/proto/entrance_edit_gui/src/widgets
Modified Files:
ew_entry.c ew_entry.h
Log Message:
- Fix return type warning when getting an etk_entry, it returns a
const char*, but we use normal char*'s everywhere.
===
RCS
file: /cvs/e/e17/proto/entrance_edit_gui/src/widgets/ew_entry.c,v
retrieving revision 1.7 retrieving revision 1.8
diff -u -3 -r1.7 -r1.8
--- ew_entry.c 16 Aug 2006 12:52:01 - 1.7
+++ ew_entry.c 16 Aug 2006 13:13:30 - 1.8
@@ -47,10 +47,10 @@
return ew;
}
-const char*
+char*
ew_entry_get(Entrance_Entry ew)
{
- return etk_entry_text_get(ETK_ENTRY(ew-control));
+ return (char*) etk_entry_text_get(ETK_ENTRY(ew-control));
}
...
You should never (have to) cast away the const modifier. It is
there for a purpose. It tells you (and the compiler) that here is a
pointer to a piece of memory that you are not supposed to modify.
The compiler warns you if you pass a const pointer to a function
that takes non-const pointer arguments, that you may be changing
something you are not supposed to change.
The compiler can also use the const modifier to make certain
assumptions used for optimization, e.g. that the content of an
object is unchanged across calling a function which takes a const
pointer to the object.
If you seem to have to cast away a const pointer to avoid compiler
warnings it is most likely because something is wrong somewhere.
thnx for bringing that up.
the full scenario is etk_entry_text_get() returns a const char*.
ecore_config_string_set, takes a char*,
i have to pass the value returned from etk_entry_text_get() to
ecore_config_string_set(), if i use one variable, there will be
warnings anyhow i do it:
/*warning by ecore_config_string_set*/
const char * try1 etk_entry_text_get(...);
ecore_config_string_set(key, try1);
/*warning by etk_entry_text_get*/
char* try2 etk_entry_text_get(...);
ecore_config_string_set(key, try2);
that's why i did that. anyways... what's the best way to do this? or
just ignore it? its a trivial warning *i tink*
etk_entry_text_get() returns a const char * because it returns the
string used internally by the entry. So you should not by any means
modify it. Now, if you need to modify it, you should probably work on a
copy (created with strdup() or whathever).
But, in your case, I don't think ecore_config_string_set() modifies the
given string, so the better fix would probably be to change the API of
ecore_config to make it use a const char * instead of a char *.
Regards
Simon TRENY MoOm
/Kim
-
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=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] add data set/get of specific columns of an Etk_Combobox_Item
On Fri, 4 Aug 2006 12:00:57 -0200, Chady Kassouf [EMAIL PROTECTED] wrote : Hi, This is to allow people to get/set the widgets on specific columns of the combobox item. Hi Chady, I'm sorry, I still haven't had the time to look at it. Going to look at it in the next days. Thanks for the patch :) Simon - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto essiene
On Wed, 16 Aug 2006 16:28:15 -0400, dan sinclair [EMAIL PROTECTED] wrote : Essien Ita Essien wrote: Anyhoo... who *own* ecore (i.e. who do i have to bug with that recommendation? :) ). Send a patch to the ml. Someone will look at it. HandyAndE is the main author of ecore_config if you're curious. This actually has been fixed recently by Kim. There no reason anymore to use char * instead of const char * in entrance_edit_gui. dan - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore borderless_set in conflict with alpha_set ?
On Fri, 28 Jul 2006 00:11:01 +, Hannes Janetzek [EMAIL PROTECTED] wrote : ee = ecore_evas_software_x11_new(NULL, 0, 0, 0, 200, 200); ecore_evas_borderless_set(ee,1); ecore_evas_alpha_set(ee, 1); ecore_evas_show(ee); If you invert the calling order of ecore_evas_borderless_set() and ecore_evas_alpha_set() (so ecore_evas_alpha_set() is called before ecore_evas_borderless_set()), it works. It's probably a bug of Ecore_Evas. Maybe ecore_evas_alpha_set() resets for some reasons the borderless property of the window. So for now, just call ecore_evas_alpha_set() before ecore_evas_borderless_set(), it should work. Regards, Simon TRENY MoOm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Evas] key_down events' params are not set with accented chars
Thanks for the answer :)
So, when I press the 'é' key (an 'e' with an accent), XLookupString()
returns 'é', and then the conversion returned NULL. My charset is
detected as ANSI_X3.4-1968.
I looked at how Gtk does this, because I can type accented chars in
Gtk's entries, and it seems Gtk does not use XLookupString() at all to
get the UTF-8 string of the pressed key. It gets the keyval (?) from
the params of the X event with gdk_keymap_translate_keyboard_state() and
then convert this keyval to UTF-8 with gdk_keyval_to_unicode() and
g_unichar_to_utf8(). All those functions are called by
translate_key_event() in gdkevents-x11.c. Btw, my charset is also
detected as ANSI_X3.4-1968 by Gdk/Gtk.
I probably could fix that problem by changing my locales, but since it
works with GTK and QT, I think we should make it work in Ecore_X too.
Regards,
Simon TRENY MoOm
On Mon, 10 Jul 2006 08:03:57 +0900,
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote :
On Sun, 9 Jul 2006 18:11:55 +0200 Simon TRENY [EMAIL PROTECTED]
babbled:
Sorry, there was an error in my test code, -key is not set to NULL.
But -string and -compose are still NULL, so the problem is still
here.
compose will always be null as nothing fills it in yet (its intended
for future use with input systems like asian languages use). I can't
say much about the accented chars as i've never had a keyboard with
them nor have i ever tried to get them to work - but the string is a
utf8 translation of whatever string x say was just typed (as opposed
to key symbol/name). x will provide the string in some native locale
and then ecore_x will translate to utf8. see ecore_x_events.c -
around line 199 - that uses XLookupString() to find the typed
string from the key event. then a convert from the current locale to
utf8 and report that as key_compose in ecore_x's event - then
ecore_evas will pass in the keyname, keysymbol and key_compose
(key_compose becomes string). in ecore_evas_x.c around line 468.
either x is providing no string or the utf8 conversion is failing
(maybe its not encoded properly as expected or something). but that
code hasnt changed recently :)
Simon
On Sun, 9 Jul 2006 18:05:38 +0200,
Simon TRENY [EMAIL PROTECTED] wrote :
Hi,
I'm using the string param of the key_down events of Evas
(i.e. event-string) to get the UTF-8 string to insert in the
entries of Etk when a key is pressed.
But it seems the params of the key_down events are no longer set
when an accented key ('é' for example) is pressed: event-key,
event-string and event-compose are all set to NULL. I can be
reproduce the problem in e17: I can't type accented chars in the
entries of e17 although I could do it before.
If I remember correctly, raster told me that -string or -compose
depended on the config of xorg, so maybe it's because my xorg
config is incorrect, but here, even -key is set to NULL.
Regards,
Simon TRENY MoOm
-
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=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
-
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=lnkkid=120709bid=263057dat=121642
___ enlightenment-devel
mailing list enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
-
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=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Evas] key_down events' params are not set with accented chars
Hi,
I'm using the string param of the key_down events of Evas
(i.e. event-string) to get the UTF-8 string to insert in the entries
of Etk when a key is pressed.
But it seems the params of the key_down events are no longer set when
an accented key ('é' for example) is pressed: event-key, event-string
and event-compose are all set to NULL. I can be reproduce the problem
in e17: I can't type accented chars in the entries of e17 although I
could do it before.
If I remember correctly, raster told me that -string or -compose
depended on the config of xorg, so maybe it's because my xorg config
is incorrect, but here, even -key is set to NULL.
Regards,
Simon TRENY MoOm
-
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=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Evas] key_down events' params are not set with accented chars
Sorry, there was an error in my test code, -key is not set to NULL.
But -string and -compose are still NULL, so the problem is still here.
Simon
On Sun, 9 Jul 2006 18:05:38 +0200,
Simon TRENY [EMAIL PROTECTED] wrote :
Hi,
I'm using the string param of the key_down events of Evas
(i.e. event-string) to get the UTF-8 string to insert in the entries
of Etk when a key is pressed.
But it seems the params of the key_down events are no longer set when
an accented key ('é' for example) is pressed: event-key,
event-string and event-compose are all set to NULL. I can be
reproduce the problem in e17: I can't type accented chars in the
entries of e17 although I could do it before.
If I remember correctly, raster told me that -string or -compose
depended on the config of xorg, so maybe it's because my xorg config
is incorrect, but here, even -key is set to NULL.
Regards,
Simon TRENY MoOm
-
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=lnkkid=120709bid=263057dat=121642
___ enlightenment-devel
mailing list enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
-
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=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Tue, 4 Jul 2006 00:11:10 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : every edje design (.edc's) that specifies a color for text or solids, clips etc. any app that sets an object color itself. there are 74 calls to evas_object_color_set in e17. e17's creation of netwm icons would need to do a premul step. 54 in edje. more in ewl, etk etc. etc. now with edje - do we force the .edc's to specify colors in premul? if so there are (evil) 666 instances of colors in e17's default theme - or do we have edje_cc convert to premul on encode - or do we have edje turn into premul runtime?... how far do you go? :) Etk doesn't often use evas_object_color_set() so it will be really easy to port. For .edc files, I really think the colors should remain non-premul RGBA colors since .edc files are made by graphic designers, and designers are used to non-premul RGBA colors (graphic tools give non-premul colors). And using premul colors will really make theming painful imho since themers often try different color settings to see which setting is the best looking. With premul colors, the themers would have to convert to premul colors each time they would like to change a color. Now, whether edje_cc should convert to premul on compilation or do it on runtime, I don't really know. Maybe it could be done during the compilation, so it'll save some work during runtime. Also, what do you think of having an API like that for image_data_set/get()? void evas_object_image_data_set(Evas_Object *obj, void *data, Evas_Colorspace colorspace); void *evas_object_image_data_get(Evas_Object *obj, Evas_Colorspace colorspace, Evas_Bool for_writing); The colorspace param in the data_set() func describes the colorspace of the given data, and in data_get(), it describes the colorspace in which you'd like to get the data. The colorspace in which it's stored by Evas could depend on the engine (it could be colorspace if the engine is optimized for colorspace, or another more adapted colorspace). Perhaps that is what you were already discussing with Jose, I haven't understood very well. Regards, Simon TRENY MoOM 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Sun, 2 Jul 2006 12:35:34 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : what i think might be best is we: 1. add internal premul to non-premul and back conversion routines (need them anyway - may as well make them fast). 2. need to add calls to image objects to get/set the COLORSPACE of the internal object data (the default would be premul and the suggestion would be to leave it alone unless you have very special needs). 3. move default colorspace to ARGB_PREMUL (we can have non-premul space, but it will need conversion to premul before using in routines). 4. i think the best might be we have a evas_colorspace_set(evas, EVAS_COLORSPACE_ARGB_PREMUL); for example and a EVAS_COLORSPACE_ARGB and that leads to EVAS_COLORSPACE_YUVA as well so then evas can do the conversion (if needed) when setting the color of an object on that canvas. this will mean we can port existing code with 1 function call when creating the canvas (set it to the non premul argb). perhaps also per object too (an objects specific colorspace overrides the evas one). then we can begin a migration of code over to premul and remove the call - but still keep it there for the ability to switch into a more convenient colorspace. i am not sure this colorspace should affect image pixels though... that should be per image object as above. I don't really like the idea of having a couple of functions, evas_colorspace_set/get() to change the global colorspace of evas. In my opinion, it will confuse the things a bit more and will make the implementation harder. For example, if I start in the colorspace EVAS_COLORSPACE_ARGB_PREMUL, I set the colors of the objects, the data of the images, and then, I switch the colorspace EVAS_COLORSPACE_ARGB. What do I get when I'll try to get the colors or the data of the objects? Converted colors or the old premul colors? Another confusing situation with edje: if I render an edje object in the ARGB_PREMUL colorspace, will it look the same in the ARGB colorspace (i.e. will Edje directly evas_object_color_set() or will it convert the color?) Imho, the colorspace in which the data of an image is internally stored by Evas should depend on the engine used. For example, the software and the xrender engines should store it in premul colors, the OpenGL engine should store it in normal colors (since I don't think you can have a premul argb texture, but I'm probably wrong) and a XV engine (stupid idea...) should store it in YUV colors. That way, it will be stored the most efficient way in order to be rendered efficiently. There must be some scaling issues but I dont think that storing in an unique colorspace would solve it (since you'll have to do the conversion sooner or later, probably before the scaling transform if you want to benefit from the optimizations of the engine). So I think that an API like that could be good: void evas_object_image_data_set(Evas_Object *obj, void *data, Evas_Colorspace colorspace); void *evas_object_image_data_get(Evas_Object *obj, Evas_Colorspace colorspace, Evas_Bool for_writing); So it's up to the user to choose the colorspace, (using ARGB_PREMUL to avoid a conversion with the 2 most common engines: software and xrender), and he can't be confused since it's he who makes the choice. Now, there is the problem of evas_object_color_set(). Imho, we have to choose, either we ask always for a premul color or always for a non-premul color, but I don't really like the idea of having a function evas_colorspace_set() to switch the current colorspace (and I don't like the idea of having a colorspace by object too). And if we'll have to choose, I'm still for non-premul colors!! :) Regards, :) Simon TRENY MoOm 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Too many Ecore events stop the Ecore's main loop?
Hi everyone,
In Etk, in order to update the widgets when the window is resized, I
use an ecore job: in the Ecore_Evas's resize_cb, I just create an
update job with ecore_job_add() if there is no update job created
yet. This job will resize the widgets.
My problem is that if the window is resized too often (i.e. if I drag
the bottom-right corner of the window, and draw small circles with the
mouse to resize the window), the update job is not called anymore.
When I stop resizing, the job is called again.
I wrote a small code (attached to this mail) to illustrate the problem.
Just try to resize the window of the test prog (by drawing small
circles witht the mouse), and you'll see that sooner or later, the job
won't be called anymore (no more output in the terminal and the purple
rectangle is no longer resized). Jobs are not the only ones affected by
this problem, I tried with timers and animators, they are also not
called. Ecore's main loop just seems to be stopped when the window is
resized?!
For info, my CPU is an Athlon XP 2700+
Could you explain me why this happens?
Regards,
Simon TRENY MoOm#include stdlib.h
#include stdio.h
#include Ecore.h
#include Ecore_Job.h
#include Ecore_Evas.h
static void _resize_cb(Ecore_Evas *ee);
static void _job_cb(void *data);
static Evas_Object *_rect = NULL;
static Ecore_Job *_job = NULL;
static int _count = 0;
int main(int argc, char *argv[])
{
Ecore_Evas *ee;
ecore_evas_init();
ee = ecore_evas_software_x11_new(NULL, 0, 0, 0, 300, 300);
ecore_evas_callback_resize_set(ee, _resize_cb);
ecore_evas_show(ee);
_rect = evas_object_rectangle_add(ecore_evas_get(ee));
evas_object_resize(_rect, 300, 300);
evas_object_color_set(_rect, 0, 128, 128, 255);
evas_object_show(_rect);
ecore_main_loop_begin();
ecore_evas_shutdown();
return 0;
}
/* Called when the window is resized */
static void _resize_cb(Ecore_Evas *ee)
{
if (!_job)
_job = ecore_job_add(_job_cb, ee);
}
/* Executes the job queued by _resize_cb() */
static void _job_cb(void *data)
{
Ecore_Evas *ee;
int w, h;
if (!(ee = data))
return;
printf(Job: Iteration %d\n, _count++);
ecore_evas_geometry_get(ee, NULL, NULL, w, h);
evas_object_resize(_rect, w, h);
_job = NULL;
}
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=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Too many Ecore events stop the Ecore's main loop?
On Mon, 3 Jul 2006 07:59:35 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote : On Sun, 2 Jul 2006 18:40:50 +0200 Simon TRENY [EMAIL PROTECTED] babbled: Hi everyone, In Etk, in order to update the widgets when the window is resized, I use an ecore job: in the Ecore_Evas's resize_cb, I just create an update job with ecore_job_add() if there is no update job created yet. This job will resize the widgets. My problem is that if the window is resized too often (i.e. if I drag the bottom-right corner of the window, and draw small circles with the mouse to resize the window), the update job is not called anymore. When I stop resizing, the job is called again. actually you want to delete the old job, and add a new one each time you get a resize (if an existing job is around). jobs basically piggyback the events system and place an internal event on the queue that will get processed after all current events int he queue are done (but before any new events e finds). they don't use idlers and idle_enterers. Ok, thanks for the tip, I'll do that in Etk :) I wrote a small code (attached to this mail) to illustrate the problem. Just try to resize the window of the test prog (by drawing small circles witht the mouse), and you'll see that sooner or later, the job won't be called anymore (no more output in the terminal and the purple rectangle is no longer resized). Jobs are not the only ones affected by this problem, I tried with timers and animators, they are also not called. Ecore's main loop just seems to be stopped when the window is resized?! For info, my CPU is an Athlon XP 2700+ Could you explain me why this happens? let me test and see. ok - i did this for about a minute (resizing in small circles) - still working... damn. I've just realized that I was using the open-source nv driver for Xorg. Switching to the nvidia driver has solved the problem. Sorry about that :/ Simon 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje not working
Hi Frank, On Fri, 30 Jun 2006 19:41:46 -0700 (PDT), Frank Dischner [EMAIL PROTECTED] wrote : Hi, I'm trying to get the EFL working on a handheld running linux and am having some problems. I've got the libraries compiled and rendering to the framebuffer and I can display images, use timers, get input etc. However, neither edje nor emotion objects are displayed. For example, I compiled eem and by navigating blindly I can change the background, but none of the menu items are shown, though it works perfectly on my desktop. I've read through the code many times, but honestly have no idea where the problem is. Is there something simple I'm missing? I don't know if it makes a difference, but I've compiled the libraries without X. Any ideas? Edje uses Evas for rendering, and is not dependant to X (if I remember correctly). So if Evas works and Edje does not, it is probably an error that occurs during the loading of the .edj file. Use edje_object_load_error_get() to see if a load error occurs. Here are the list of the error codes: EDJE_LOAD_ERROR_NONE = 0, EDJE_LOAD_ERROR_GENERIC = 1, EDJE_LOAD_ERROR_DOES_NOT_EXIST = 2, EDJE_LOAD_ERROR_PERMISSION_DENIED = 3, EDJE_LOAD_ERROR_RESOURCE_ALLOCATION_FAILED = 4, EDJE_LOAD_ERROR_CORRUPT_FILE = 5, EDJE_LOAD_ERROR_UNKNOWN_FORMAT = 6, EDJE_LOAD_ERROR_INCOMPATIBLE_FILE = 7, EDJE_LOAD_ERROR_UNKNOWN_COLLECTION = 8 Tell us what code is returned by edje_object_load_error_get(), maybe it could help. My plan was to write a new menu for the GP2X (www.gp2x.com), but I haven't gotten the efl to do anything useful yet. If I do get something working, then I'll definitely post my progress on the forums at www.gp32x.com. Interesting idea, I wanted to do that too but I haven't had the time (and I still haven't the handheld too :)). I'd be glad if you could post here a video of the handheld running an EFL app once you'll have solve this problem :) Regards, Simon TRENY MoOm Thanks Frank - Yahoo! Music Unlimited - Access over 1 million songs.Try it free. 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Mon, 26 Jun 2006 06:37:21 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : The get/set functions that deal with image data would have to constantly transform from premul to non-premul thus making the use of these very slow.. also, if you want to work with the data doing graphics ops yourself, then you would be better off doing so with it in premul color space, as it's easier and faster there. I would say that most here would thus be convinced that the evas funcs that set/get image data should thus work with the data assumed to be in premul color space. Yeah, I agree image_data_set/get() could gain from using premul alpha colors. And since image_data_set/get() is not used really often, or mainly with alpha=255, it won't break a lot of things. In others, like adding colors to grads, evas could do different things -- it could generate the spectrum by linearly interpolating in non-premul color space, then premul that for compositing, or it could go ahead and transform the inputs to premul colors and generate the spectrum from those... These two will not give the same results -- not even close if there are alphas 255. There are ways to approximate the first using the second, but not the other way around... so, using non-premul colors directly is actually a restriction on what can be obtained. For grads, I would have thought that using premul colors was actually more restrictive than using non-premul colors, mostly because the conversion from non-premul to premul colors is not reversible (i.e if alpha=0, you can't get back the original non-premul color from the converted premul color). So, how can you make a linear grad from opaque red to transparent green with premul colors? With non premul colors, you just have to add 2 colors to the grad: 255 0 0 255 for opaque red and 0 255 0 0 for transparent green. In premul colors, there is no transparent green (well... I agree, transparent green is visually the same color than transparent red, since it's all transparent...) In conclusion -- as I see it, there are three possible paths for e as a whole to follow when it comes to this issue of premul or non-premul color spaces. 1. Do nothing - remain with using non-premul as is now currently the case. 2. Move the internals of the graphics stuff to premul, but leave all, or most, of the interfaces to use non-premul. 3. Move as much of elibs/eapps as feasible to use premul color space. I have tried to give my view above of some of the pros of going with 3, and why I don't want anything to do with 2. I'd rather be for solution 2, i.e. keep all the API functions use non-premul colors, except image_data_set/get(). Simon TRENY MoOm 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Fw: Evas and alpha premul color data
I'm forwarding the messages that Jose sent me because he seems to be detected as a spammer by the ML service. - Forwarded Message - Date: Fri, 23 Jun 2006 23:26:21 GMT From: [EMAIL PROTECTED] [EMAIL PROTECTED] To_: [EMAIL PROTECTED] Cc: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] Evas and alpha premul color data Hi Jose, Mm.. It seems to be a very important change indeed. If I understand correctly, it means that all the apps that calls evas_object_color_set() and every edje theme will have to be updated. This is a problem, but it can be quickly solved. Yes, it sucks... I know. Also every app that calls image_data set/get as well. The most important problem imho is that alpha premul colors are really less intuitive than normal colors, at least for me :) For example, when you are designing an edje theme, you often change the alpha of a part to try different values, and to see which alpha value looks the best. So now, every alpha change will need a change of the r, g, b components too, right? It seems that way because you're so used to thinking in non-premul terms, but yes that's what will have to happen.. and either you do it yourself, or evas is going to do it for you behind your back -- there's no way out of this if evas moves to premul internally. I prefer that you do it yourself so you know exactly what's going on, and become comfortable with thinking premul colors. Another problem, but maybe I'm wrong on that point, is for transition. A simple example, you want an object to fade out. For now, you only have to use a timer that makes the alpha of the object decrease progressively. It's rather intuive for now. But with this change, you'll also have to update the rgb values, no?! Internally it may detect that you're just changing the alpha and perform things in special ways to speed things up.. but yes, you can't arbitrarily decrease the alpha without also decreasing the colors. Again, if you don't do it.. evas will have to do it for you behind your back. However, changing the transparency of an object (image or whatever), so as to make it fade-in or out, is trivial -- just set the obj's color to (a,a,a,a) for whatever 'a', that's all there is to it :) For me, if the only advantage is to avoid some confusion inside the evas's code (so for now, the evas-user is not confused), I think it doesn't worth it. We'll avoid a confusion in the code of evas, but we'll probably confuse the user (i.e. the coder that uses evas). But maybe i'm wrong on the 2 examples I've given, maybe the change is not so important. Regards :) Simon TRENY MoOm Well, internally there are a *lot* of advantages -- Right now, for the blending functions to work 'well', with some semblance of speed, when there's dst alpha.. and for the other render ops besides blend, there's a messy, ugly, slow stuff... Moving to premul internally would eliminate all this, get rid of a 65Kb table, and make the software routines easier, faster, and more accurate. Also, to get things to work with the xrender engine, we have to premul all data we hand to xrender pictures since that's what it expects... same for a cairo engine if someone ever gets around to finishing that. So, if doing this internally is the way to go, and I think it is, then the question is: what about the api interfaces, specifically, the get/set data and color functions? In order for the get/set image data functions to have any usefulness, you'll have to do this with the data being premul, or it'll be so SLOW as to be worthless. Also, if you want to work with image data yourself, then having it premul is the way to go as it makes doing graphics operations easier, faster, ... Ok, then what about the color set/get? Either evas assumes that you're setting premul colors (ie. satisfying a = r,g,b) or it has to force them to be so. What would you prefer? jose. 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Fw: Evas and alpha premul color data
I'm forwarding the messages that Jose sent me because he seems to be detected as a spammer by the ML service. - Forwarded Message - Date: Sat, 24 Jun 2006 00:40:32 GMT From: [EMAIL PROTECTED] [EMAIL PROTECTED] To_: [EMAIL PROTECTED] Subject: Re: [E-devel] Evas and alpha premul color data And I forgot to mention another problem I have in mind. For now, in edje, if you want to do a color transition from color1=255 0 0 255 to color2=0 255 0 0, you have to create 2 states, the first associated to color1, and the second to color2. With alpha premul colors, it will become (if I understand correctly): color1'=255 0 0 255 and color2'=0 0 0 0. So how Edje will guess it has to make a transition from red to green? Or we'll have to keep normal colors in edje, but it won't be coherent with the API of evas :/ Simon Ummm, that's odd... Edje should not consider the color 0 255 0 0 as green. It should be transparent - that's what evas will do with such an input color.. if an obj's color has alpha = 0, the obj is transparent. To transition to green one should set color2 to be, green! ie. 0 255 0 255. If edje is doing otherwise then it has a bug, or something funky :( PS. No email that I send to the edev list is getting thru since someone has taken it upon themselves to report me as 'spam' to the spamblock service that the list uses. I don't have the time or desire to screw around with things like this so unfortunately I won't be sending anything to that list as long as that keeps up :( 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas and alpha premul color data
On Sat, 24 Jun 2006 00:40:32 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : Well, internally there are a *lot* of advantages -- Right now, for the blending functions to work 'well', with some semblance of speed, when there's dst alpha.. and for the other render ops besides blend, there's a messy, ugly, slow stuff... Moving to premul internally would eliminate all this, get rid of a 65Kb table, and make the software routines easier, faster, and more accurate. Also, to get things to work with the xrender engine, we have to premul all data we hand to xrender pictures since that's what it expects... same for a cairo engine if someone ever gets around to finishing that. So, if doing this internally is the way to go, and I think it is, then the question is: what about the api interfaces, specifically, the get/set data and color functions? In order for the get/set image data functions to have any usefulness, you'll have to do this with the data being premul, or it'll be so SLOW as to be worthless. Also, if you want to work with image data yourself, then having it premul is the way to go as it makes doing graphics operations easier, faster, ... Ok, then what about the color set/get? Either evas assumes that you're setting premul colors (ie. satisfying a = r,g,b) or it has to force them to be so. What would you prefer? Maybe we could just use premul alpha for image data, because that's the only critical case where premul alpha color will effectively improve the perfs, and since, afaik, some image formats already store premul alpha colors, it's somehow logical. For the other cases, I don't think it's a good idea to use premul alpha, it will definitively confuse the final user of evas, and it won't really affect the perfs of Evas I guess. And I forgot to mention another problem I have in mind. For now, in edje, if you want to do a color transition from color1=255 0 0 255 to color2=0 255 0 0, you have to create 2 states, the first associated to color1, and the second to color2. With alpha premul colors, it will become (if I understand correctly): color1'=255 0 0 255 and color2'=0 0 0 0. So how Edje will guess it has to make a transition from red to green? Or we'll have to keep normal colors in edje, but it won't be coherent with the API of evas :/ Simon Ummm, that's odd... Edje should not consider the color 0 255 0 0 as green. It should be transparent - that's what evas will do with such an input color.. if an obj's color has alpha = 0, the obj is transparent. To transition to green one should set color2 to be, green! ie. 0 255 0 255. If edje is doing otherwise then it has a bug, or something funky :( 0 255 0 255 is indeed transparent, but since you use a smooth transition, Edje interpolates linearly from 255 0 0 255 to 0 255 0 255. And so, the path to go from 255 0 0 255 to 0 255 0 255 is not the same than the path to go from 255 0 0 255 to 0 0 0 255, even if in the 2 cases, the starting and the ending color are the same. PS. No email that I send to the edev list is getting thru since someone has taken it upon themselves to report me as 'spam' to the spamblock service that the list uses. I don't have the time or desire to screw around with things like this so unfortunately I won't be sending anything to that list as long as that keeps up :( Do you want me to forward your messages to the ML? Regards :) Simon 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas and alpha premul color data
I'm forwarding the messages that Jose sent me because he seems to be detected as a spammer by the ML service. - Forwarded Message - Date: Sat, 24 Jun 2006 07:10:42 GMT From: [EMAIL PROTECTED] [EMAIL PROTECTED] To_: [EMAIL PROTECTED] Subject: Re: [E-devel] Evas and alpha premul color data And I forgot to mention another problem I have in mind. For now, in edje, if you want to do a color transition from color1=255 0 0 255 to color2=0 255 0 0, you have to create 2 states, the first associated to color1, and the second to color2. With alpha premul colors, it will become (if I understand correctly): color1'=255 0 0 255 and color2'=0 0 0 0. So how Edje will guess it has to make a transition from red to green? Or we'll have to keep normal colors in edje, but it won't be coherent with the API of evas :/ Simon Ummm, that's odd... Edje should not consider the color 0 255 0 0 as green. It should be transparent - that's what evas will do with such an input color.. if an obj's color has alpha = 0, the obj is transparent. To transition to green one should set color2 to be, green! ie. 0 255 0 255. If edje is doing otherwise then it has a bug, or something funky :( No, it's ok :) I see what you mean.. How would it know that it should transition thru something half-way that is partly-red partly-green partly-transparent, ie. that at the half-way point of the transition the color should be set to 128 128 0 128 It wouldn't, that's correct. That's part of the problem of dealing with non-premul colors, it gives a bad idea of what is actually going to be displayed. In order to get a transition that varies from opaque-red, to half-opaque-brownish, to transparent, you'd need to transition between these *three* premul colors, ie. you'd need three premul colors to transition from, not just two. The thing about using premul colors is that it gives you a very exact, direct idea of what you'll actually get displayed, whereas non-premul colors give an indirect idea of such. This is why I think it's such a bad idea to mix the two -- it creates confusion as to what should be happenning. If you stick to using premul colors, you always get a good idea of what is going to be displayed. jose. PS. Please feel free to forward/copy these emails to the elist. 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ETK without X possible?
Hi Michael, You can now use the Etk_Embed widget to have Etk's widgets in your evas programs, but Etk is still dependant on X. It means that you can now use Etk widgets in a framebuffer program, but since Etk is still linked to X, you'll need to have X installed, even if it is not used :o Next task will be to move the Ecore_X-dependant code to a different dir, so we could build Etk without X. Regards, Simon TRENY MoOm On Sun, 18 Jun 2006 17:33:22 +0200, Simon TRENY [EMAIL PROTECTED] wrote : Hi Michael, The ./configure script indeed looks for Ecore_X and doesn't complain if Ecore_X is not detected but there are still some pieces of code in Etk that uses Ecore_X without the #ifdef/#endif thing (Etk_Popup_Window for example), so for now, you can't compile Etk for the framebuffer. But we plan to put all the Ecore_X-dependant code in a separated dir (ie the files etk_dnd.c, etk_selection.c, etk_clipboard.c, etk_popup_window.c, ...) so a framebuffer port could be really easily written. Regards, Simon TRENY MoOm Le Sun, 18 Jun 2006 16:50:55 +0200, Michael 'Mickey' Lauer [EMAIL PROTECTED] a _crit : Hi, ecore_x looks like an optional dependency for ETK. Would it be possible to run it without X at all? I already work with framebuffer-only versions of evas, ecore and edje. It would be nice to have access to a full blown widget toolkit without needing X. While I can do a lot of impressive things with edje alone, it's still a bit low-level. ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Edje transition: works only in one direction
Hi Sevcsik
It seems to be a bug of Edje, when a part has no state called default.
Just replace state1 to default and it should work.
But I don't know if it's a wanted behaviour or if it's actually a bug
of Edje. As a rule, to avoid this kind of bug, you should always call
the first state of a part default.
Regards,
Simon TRENY MoOm
On Thu, 22 Jun 2006 20:22:04 +0200,
Andrew Sevcsik [EMAIL PROTECTED] wrote :
Here is everything.
On Thu, 22 Jun 2006 17:52:39 +0200
Simon TRENY [EMAIL PROTECTED] wrote:
Hi Sevcsik
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: binary
Hi Sevcsik
You should send the whole .edc code and the images so we could
compile the animation and test by ourselves.
Regards,
Simon TRENY MoOm
Le Thu, 22 Jun 2006 17:33:19 +0200,
Andrew Sevcsik [EMAIL PROTECTED] a _crit :
Hi list.
I have these programs:
program { /*Programs that do the mouseover animation for
statusimg_bg */ name, statusimg_bg_in;
signal, mouse,in;
source, statusimg_bg_over;
action, STATE_SET state2 1.0;
target, statusimg_bg_over;
transition, LINEAR 0.5;
after, statusimg_bg_in2;
}
program {
name, statusimg_bg_in2;
action, STATE_SET state2 1.0;
target, statusimg_bg;
transition, LINEAR 0.5;
}
program { /* !! TODO: TRANSITION IS NOT WORKING HERE !!!
*/ name, statusimg_bg_out;
signal, mouse,out;
source, statusimg_bg_over;
action, STATE_SET state1 1.0;
target, statusimg_bg;
transition, LINEAR 0.5;
after, statusimg_bg_out2;
}
program {
name, statusimg_bg_out2;
action, STATE_SET state1 1.0;
target, statusimg_bg_over;
transition, LINEAR 0.5;
}
Transition works nicely at mouse,in, but it at mouse,out, it only
wait 0.5 seconds, and change suddenly. These are just alpha
changes, so I don't understand.
statusimg_bg (original)
state1 - visible
state2 - hidden
statusimg_bg (glow)
state1 - hidden
state2 - visible
Thanks for the help.
Sevcsik
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=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
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=lnkkid=120709bid=263057dat=121642
___ enlightenment-devel
mailing list enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
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=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas and alpha premul color data
Hi Jose, Mm.. It seems to be a very important change indeed. If I understand correctly, it means that all the apps that calls evas_object_color_set() and every edje theme will have to be updated. This is a problem, but it can be quickly solved. The most important problem imho is that alpha premul colors are really less intuitive than normal colors, at least for me :) For example, when you are designing an edje theme, you often change the alpha of a part to try different values, and to see which alpha value looks the best. So now, every alpha change will need a change of the r, g, b components too, right? Another problem, but maybe I'm wrong on that point, is for transition. A simple example, you want an object to fade out. For now, you only have to use a timer that makes the alpha of the object decrease progressively. It's rather intuive for now. But with this change, you'll also have to update the rgb values, no?! For me, if the only advantage is to avoid some confusion inside the evas's code (so for now, the evas-user is not confused), I think it doesn't worth it. We'll avoid a confusion in the code of evas, but we'll probably confuse the user (i.e. the coder that uses evas). But maybe i'm wrong on the 2 examples I've given, maybe the change is not so important. Regards :) Simon TRENY MoOm On Fri, 23 Jun 2006 06:20:47 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : Just a note to all here.. Sometime within the next week or three, I may send a very large evas patch (probably in 3 or 4 parts) which entails a very *drastic* semantic change for evas --- namely, it will support only alpha premultiplied image data and colors which are given in argb format. This would cause some pain, and break some things.. but in the long run, I believe it is better. However, one has to learn to think in/with alpha premul colors. What does this mean I'll explain it a bit here. In argb color space where colors are specified by 4-tuples a, r, g, b, representing the alpha, red, green, and blue components of a color, that this is an 'alpha premul' color means that the alpha component 'a' has value = the r,g,b components. That's all it means, nothing more. One way to obtain an alpha premul color from any color, is to replace the old r,g,b values by new r',g',b' values given by r' = (a*r)/255, g' = (a*g)/255, b' = (a*b)/255, hence the term alpha premultiplied. Where will evas be affected by this? Anywhere you see image or gradient objects take argb32 data... this data will now be *assumed* to be alpha premul by default. If you pass in data, or specify colors, that are *not* premul, then you will get mostly junk results. Similarly, any api function that refers to setting a color on an object somehow, it will now be assumed that the color is alpha premul.. If they aren't, you will get mostly junk results. Why not simply keep the interfaces to accept non premul colors, as is now the case, and just do things internally with premul if that's such a great thing...? Because mixing premul and non-premul color spaces leads to immense amounts of confusion, and is error prone.. I have seen very knowledgable and experienced people get wrapped around in the confusion caused by this. Learn to think with alpha premul colors, this may seem drastic.. and it is indeed.. but it's far more consistent for a wide variety of things, and even more 'natural' once one gets used to the change. If this change seems unacceptable to most here - and I can certainly understand that - or would prefer some mixture of premul and non premul... that's fine, I will leave evas alone then. But I personally want nothing to do with mixing these two color spaces. It's a bad idea. jose. 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas and alpha premul color data
And I forgot to mention another problem I have in mind. For now, in edje, if you want to do a color transition from color1=255 0 0 255 to color2=0 255 0 0, you have to create 2 states, the first associated to color1, and the second to color2. With alpha premul colors, it will become (if I understand correctly): color1'=255 0 0 255 and color2'=0 0 0 0. So how Edje will guess it has to make a transition from red to green? Or we'll have to keep normal colors in edje, but it won't be coherent with the API of evas :/ Simon On Fri, 23 Jun 2006 15:44:42 +0200, Simon TRENY [EMAIL PROTECTED] wrote : Hi Jose, Mm.. It seems to be a very important change indeed. If I understand correctly, it means that all the apps that calls evas_object_color_set() and every edje theme will have to be updated. This is a problem, but it can be quickly solved. The most important problem imho is that alpha premul colors are really less intuitive than normal colors, at least for me :) For example, when you are designing an edje theme, you often change the alpha of a part to try different values, and to see which alpha value looks the best. So now, every alpha change will need a change of the r, g, b components too, right? Another problem, but maybe I'm wrong on that point, is for transition. A simple example, you want an object to fade out. For now, you only have to use a timer that makes the alpha of the object decrease progressively. It's rather intuive for now. But with this change, you'll also have to update the rgb values, no?! For me, if the only advantage is to avoid some confusion inside the evas's code (so for now, the evas-user is not confused), I think it doesn't worth it. We'll avoid a confusion in the code of evas, but we'll probably confuse the user (i.e. the coder that uses evas). But maybe i'm wrong on the 2 examples I've given, maybe the change is not so important. Regards :) Simon TRENY MoOm On Fri, 23 Jun 2006 06:20:47 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : Just a note to all here.. Sometime within the next week or three, I may send a very large evas patch (probably in 3 or 4 parts) which entails a very *drastic* semantic change for evas --- namely, it will support only alpha premultiplied image data and colors which are given in argb format. This would cause some pain, and break some things.. but in the long run, I believe it is better. However, one has to learn to think in/with alpha premul colors. What does this mean I'll explain it a bit here. In argb color space where colors are specified by 4-tuples a, r, g, b, representing the alpha, red, green, and blue components of a color, that this is an 'alpha premul' color means that the alpha component 'a' has value = the r,g,b components. That's all it means, nothing more. One way to obtain an alpha premul color from any color, is to replace the old r,g,b values by new r',g',b' values given by r' = (a*r)/255, g' = (a*g)/255, b' = (a*b)/255, hence the term alpha premultiplied. Where will evas be affected by this? Anywhere you see image or gradient objects take argb32 data... this data will now be *assumed* to be alpha premul by default. If you pass in data, or specify colors, that are *not* premul, then you will get mostly junk results. Similarly, any api function that refers to setting a color on an object somehow, it will now be assumed that the color is alpha premul.. If they aren't, you will get mostly junk results. Why not simply keep the interfaces to accept non premul colors, as is now the case, and just do things internally with premul if that's such a great thing...? Because mixing premul and non-premul color spaces leads to immense amounts of confusion, and is error prone.. I have seen very knowledgable and experienced people get wrapped around in the confusion caused by this. Learn to think with alpha premul colors, this may seem drastic.. and it is indeed.. but it's far more consistent for a wide variety of things, and even more 'natural' once one gets used to the change. If this change seems unacceptable to most here - and I can certainly understand that - or would prefer some mixture of premul and non premul... that's fine, I will leave evas alone then. But I personally want nothing to do with mixing these two color spaces. It's a bad idea. jose. 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=lnkkid=120709bid=263057dat=121642
Re: [E-devel] Edje transition: works only in one direction
Hi Sevcsik
You should send the whole .edc code and the images so we could
compile the animation and test by ourselves.
Regards,
Simon TRENY MoOm
Le Thu, 22 Jun 2006 17:33:19 +0200,
Andrew Sevcsik [EMAIL PROTECTED] a _crit :
Hi list.
I have these programs:
program { /*Programs that do the mouseover animation for statusimg_bg
*/ name, statusimg_bg_in;
signal, mouse,in;
source, statusimg_bg_over;
action, STATE_SET state2 1.0;
target, statusimg_bg_over;
transition, LINEAR 0.5;
after, statusimg_bg_in2;
}
program {
name, statusimg_bg_in2;
action, STATE_SET state2 1.0;
target, statusimg_bg;
transition, LINEAR 0.5;
}
program { /* !! TODO: TRANSITION IS NOT WORKING HERE !!! */
name, statusimg_bg_out;
signal, mouse,out;
source, statusimg_bg_over;
action, STATE_SET state1 1.0;
target, statusimg_bg;
transition, LINEAR 0.5;
after, statusimg_bg_out2;
}
program {
name, statusimg_bg_out2;
action, STATE_SET state1 1.0;
target, statusimg_bg_over;
transition, LINEAR 0.5;
}
Transition works nicely at mouse,in, but it at mouse,out, it only wait
0.5 seconds, and change suddenly. These are just alpha changes, so I
don't understand.
statusimg_bg (original)
state1 - visible
state2 - hidden
statusimg_bg (glow)
state1 - hidden
state2 - visible
Thanks for the help.
Sevcsik
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=lnkkid=120709bid=263057dat=121642
___ enlightenment-devel
mailing list enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
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=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ETK without X possible?
Hi Michael, The ./configure script indeed looks for Ecore_X and doesn't complain if Ecore_X is not detected but there are still some pieces of code in Etk that uses Ecore_X without the #ifdef/#endif thing (Etk_Popup_Window for example), so for now, you can't compile Etk for the framebuffer. But we plan to put all the Ecore_X-dependant code in a separated dir (ie the files etk_dnd.c, etk_selection.c, etk_clipboard.c, etk_popup_window.c, ...) so a framebuffer port could be really easily written. Regards, Simon TRENY MoOm Le Sun, 18 Jun 2006 16:50:55 +0200, Michael 'Mickey' Lauer [EMAIL PROTECTED] a _crit : Hi, ecore_x looks like an optional dependency for ETK. Would it be possible to run it without X at all? I already work with framebuffer-only versions of evas, ecore and edje. It would be nice to have access to a full blown widget toolkit without needing X. While I can do a lot of impressive things with edje alone, it's still a bit low-level. ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Re: E CVS: proto moom
Here are my result, on a Duron 1.3Ghz: prof1 (Jose's conversion procedures, without the null checks) real0m11.826s user0m9.945s sys 0m0.440s prof2 (Jose's conversion procedures, with the null checks) real0m12.133s user0m10.401s sys 0m0.088s prof3 (evas conversion procedures: evas_color_hsv_to_rgb() and evas_color_rgb_to_hsv()) real0m13.743s user0m11.865s sys 0m0.092s The difference of speed between the first and the second test (with or without the null checks) is indeed really small (2.5%). But the diffence between the second and the third test is really more important (13.2%). So I will move the procedures of Jose to evas, with the null checks, and use it in Etk. Regards ;) Simon TRENY MoOm Le Fri, 19 May 2006 10:05:12 -0500, Brian Mattern [EMAIL PROTECTED] a _crit : On Friday 19 May 2006 09:18, Enlightenment CVS wrote: Enlightenment CVS committal Author : moom Project : e17 Module : proto Dir : e17/proto/etk/data/themes/default/widgets Modified Files: colorpicker.edc Log Message: * More work on the colorpicker, but it's still incomplete and a bit buggy. It now uses its own optimized hsv -- rgb conversion procedures from Jose. I haven't committed them to Evas because, for optimization purpose, they do not check if the params are valid. Thanks Jose :) I was curious just how much of an optimization leaving off null checks was, so i did a quick profile. Loop through all r,g,b values (0..255) and call rgb_to_hsv, then loop through all h,s,v values (0..360), diving s and v by 360 and call hsv_to_rgb first is without null checks (as in etk) second adds null checks [EMAIL PROTECTED] ~/code $ time ./prof real0m4.521s user0m4.500s sys 0m0.004s [EMAIL PROTECTED] ~/code $ time ./prof2 real0m4.578s user0m4.544s sys 0m0.008s This is on an athlon 64 3000+ So, adding in null checks is about a 1% slowdown. Is that really enough to care about? (Has the added benefit of letting the functions work if you just need one value and don't want to create temp vars for the others -- e.g. rgb_to_hsv(r,g,b,h,NULL,NULL) -- rephorm --- 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel --- 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=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
