Re: [E-devel] [e-users] Integrating an OpenGL render Window within an Evas canevas.
On Sat, 3 Nov 2007 21:21:36 -0400 Flo <[EMAIL PROTECTED]> babbled: this is going to suck for you... but... you can't do what you are trying to do :( sorry :( > Dear all: > > My name's florent and although I'm rather new to the EFLs world, and > thanks to some great examples over the internet (from Gustavo Sverzut > Barbieri and Raoul Hecky), I already managed to achieved nice results > using Evas. > > However, after investigating evas's (endless) possibility as a GUI > I'm hitting a wall while trying to do the following: > > I want to integrate an OpenGL render window within my Evas UI, this > Evas UI handling every callbacks (mouse and keyboard events) whether > from the evas canevas or the openGL render window. > > The example I tried to achieved, but failed so far, would be to > integrate a glxgears render window (from the famous linux glxgears > OpenGL render app) in a simple Evas canevas contaning a button that > would launch the openGL render window. > > I would appreciate any idea/code/direction on how to achieve this as, > from my internet digging, I did not find any example. > > thanks for your help. > > florent. > > > - > 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-users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] GCC attributes usage
On Sun, 4 Nov 2007 18:56:43 -0300 "Ulisses Furquim" <[EMAIL PROTECTED]> babbled: > Hi, > > On 11/4/07, Sebastian Dransfeld <[EMAIL PROTECTED]> wrote: > > e_dbus and efreet now has EAPI support, and E can be run with > > -fvisibility=hidden! > > Heh, I was going to do exactly that but you beat me. Nice, thanks. :-) > > I think we could also add 'extern "C"' to e_dbus headers (efreet > already has it) to be more convenient to C++ programmers and to be > coherent with the rest of the E libraries. no good reason not to have these - instant c++ accessibility for almost no work. > -- Ulisses > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Discussion about Evas perfs for scrolling
On Sat, 3 Nov 2007 16:35:52 +0100 Simon TRENY <[EMAIL PROTECTED]> babbled: ok - yes. for evas it has no concept of blitting the canvas contents directly (scrolling). i have known this for a long time - it's the weakest point. now solving this is NOT trivial. my original preferred solution is literally detecting motion vectors (looking at all objects, their properties and looking to see if groups of them move together - if they do, mark a motion vector that the engine, if it is possible, can punt off to the target display system to do a hardware blit as opposed to a re-draw). i have code that does this. you are right. it's expensive. it is not hyper-fast. it is quite possible we will spend more cycles detecting blits than just doing redraws. for large canvases (1600x1200) it still would be a win as the expense of a redraw could be quite nasty. but for smaller ones we almost definitely will lose. i have held off on this basically hoping hardware catches up (doing redraws with 3d chipsets these days is so fast - blitting is almost pointless). so that goes to your other suggestion - viewports. in the very beginning i did intend these for scrolling - but the way things have developed this really didn't pan out. we now put multiple regions within a canvas that could scroll independently - this means we need another solution. so what is that? well there are 2 things we need. 1. a scale cache. this will just make rescaling much cheaper (if its smooth scaling). this requires we have a tiled cache system that can take an input primitive/object/image/whatever and then be able to create output tiles given input properties (eg a scale, rotate, etc. etc.). the tiles will get populated as they are needed and a certain number of tiles will be kept by the system in cache. this means only output regions intersecting tiles get rendered. making a choice to cache a tile or just raw scale and render is where the efficiency is going to get tricky - if we cycle the cache too much it will be a slowdown, not speedup. this can ALSO speed up fancy text rendering BTW. this will make a redraw of a big screen simpler/faster/cheaper. 2. a scheme of doing blit (scroll) detection that is FAST. as above - the scheme of detecting based on ALL objects and their properties just isn't going to work. we need another scheme. we need some form of "collector" object - much like a smart object, but SPECIFICALLY for scrolling/containering. a method to set the child object offset will then allow for detecting blits easily (all objects WITHIN the scroller object just get a blit - IF you are in 32bpp. 16 and 8bpp can't do this if they have dithering though). remember scrolling/blitting can only really be done if the region is solid. the moment it has an alpha channel on top of something underneath, you have no choice but to redraw. these 2 things can be worked on separately though. if we just add the "Scroller" object now and reduce scrolls to redraws - we have the API and etk/ewl will have a chance to move to it and change. it will not be a benefit - UNTIL we add actual blit support. i always wanted this. the problem here is - there are a million things we could do to improve evas. scrolling is definitely important. the real question is - how important? i think the most important bit is a simplification of the engine API - and turran's new eneism work could be part of that. along with work jose has done a lot of before. better vector support would be great. AA polygons are right on the top of my list. fixing bugs in the gradient filling code is important. man - there's SOOO much. :):) one day we will need to add z axis support - it will make life incredibly complicated (yes 3d. i have kept out of it because to do that and make it fast is NOT easy. we can do so much without it). > 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,
[E-devel] News from the E stables
First. I need to offer some big apologies. I have been pretty bad at being responsive and attentive to E for a while now. I can give you a million reasons (excuses) - but that not fair. I've basically been "paying the rent" with Jobs - and they have not had anything to do with E (first) and then nothing to do with Open source OR E. This means E swindled into a small corner of my world. I've been bad to respond to mail or provide any form of direction ,feedback - or for that matter - leadership. Please accept my sincerest apologies. It's my fault and my problem. I need to fix this. And fix it I shall. That is my intent. So launching into fixing, I shall do below. So bear with me. First on to some news. It may has snuck out before and it's now official. I'm @ OpenMoko ( http://www.openmoko.org ) now. Why? Back to OpenSource roots - and for that matter, back to Linux, X11 and Graphics... and E! For those who don't know what OpenMoko is - read the link. It's exciting. This mans I now will have more time. Right now I will be all over the place - I am shifting countries again, so I'll be sporadic with E-mail and reachability, but that will settle. I'm moving (partly) back to Sydney, Australia, and the other half of my time i will be in Taipei or other locations. But I do intend to have more focus and support on E. Now why? OpenMoko is convinced the technology behind E is what it takes to make exciting mobile phones that are Linux based and OpenSource.This amounts to what is commercial support for E. This makes me excited. This opens doors for us. In addition to the work Nokia's INDT are doing, Terrasoft, and now gOS with Everex - this is a growing list of companies putting their faith in us. Some of you may be suspicious of this - please do not be. In E land we have believed in freedom - not a limited brand of it, but one that ALSO gives freedom to those producing commercial products to do whatever it is they need or want to do. I believe that in the end, they will come back to the fold and not close and hide their source, because the cost of maintaining a fork is just too high. I belive with support will come resources, and resources will mean development of the things you need and want. Everyone wins. One thing people may notice is that E is getting some splits. Desktop vs. "Embedded". Apps vs libraries and multiple libraries and projects. I don't think E will ever really totally split - it will just have lots of useful libraries, tools and apps - different ones aiming for different directions. One thing I hope to do is keep E together - even if there are different directions. I also see the team growing - this is great, but it serves to just increase communication traffic, and that in turn means less coding gets done. The traditional solution here is to start some hierarchy and "reporting lines". I don't want to do this though - this will server to create splits where once there was fluid freedom. If we must - we must. Any suggestions? I'm thinking of maybe just formalising a bit more of our developer "Relations", involvement and teamwork. Some Ideas for people-things: 1. Identify people who WANT to be leaders and shape the direction of E - and are willing to spent the effort. Some of you do it as a hobby and love just that, some do it for a job, others are in half-way houses. 2. Lets have actual weekly or monthly developer meetings - literally all-in live discussions - maybe IRC? Have actual agendas in meetings. Minutes. 3. Have regular community meetings where people can tell us what they like and don't - give feedback or whatever. 4. Try an organise some annual get-together. An "E meet" (I think I'll just call it "The Rave" for now - it fits with the whole E thing). So Literally find a place on the planet we all can/want to go to - go there. 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. 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 fo
Re: [E-devel] E and mplayer
Le mardi 6 novembre 2007, Nelson Silva a écrit : > Hi guys, > I knew E for quite sometime but never really had the change to work on it. > After seem some of your really great desktops, i had to give it a shot. > I'm trying to put mplayer inside a E widget using evas and edje. > Mplayer needs a wid (window id) to be able to work, pretty much as winId > from QT. Is there a way ? using evas? > > thk Hi, Why not using Emotion? it's a lib used to embed video into Evas objects, and it can use either xine backend or gstreamer backend. -- Raoul Hecky - 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] E and mplayer
Hi guys, I knew E for quite sometime but never really had the change to work on it. After seem some of your really great desktops, i had to give it a shot. I'm trying to put mplayer inside a E widget using evas and edje. Mplayer needs a wid (window id) to be able to work, pretty much as winId from QT. Is there a way ? using evas? thk -- Nelson Silva - - 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 and mplayer
On Tue, 6 Nov 2007 11:48:03 + Nelson Silva <[EMAIL PROTECTED]> babbled: > Hi guys, > I knew E for quite sometime but never really had the change to work on it. > After seem some of your really great desktops, i had to give it a shot. > I'm trying to put mplayer inside a E widget using evas and edje. > Mplayer needs a wid (window id) to be able to work, pretty much as winId > from QT. Is there a way ? using evas? no - you can't. there are no window id's. take a look at emotion. no it doesn't use mplayer. emotion supports either libxine or gstreamer as back-ends. (modular so you choose which you want and when). > thk > > -- > Nelson Silva > - > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] Integrating an OpenGL render Window within an Evas canevas.
On Nov 5, 2007 10:28 AM, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Sat, 3 Nov 2007 21:21:36 -0400 Flo <[EMAIL PROTECTED]> babbled: > > this is going to suck for you... but... you can't do what you are trying to do > :( sorry :( Hi, he mailed me and I asked him to mail this list... I proposed the following "solutions", but I don't know if they will work: 1 - create an opengl X11 window and make the parent be the evas window. Maybe using ARGB windows and composite manager to handle transparency. 2 - create an offscreen opengl window, use it with evas_object_image_data_set(). any of those help, raster? -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore + XIM working
Hello, It seems my original patch did not go out. The files are here: http://www.shorne-pla.net/uploads/ecore_xim.diff http://www.shorne-pla.net/uploads/xim_ecore.c New function ecore_x_window_input_context_init(win, "Root"); Lately I have been working on shutdown code. I still need to fix it so that if the XIM server dies and comes back only all input_context objects will be recreated automatically. Still working on other preedit types, only Root is working now. I am thinking now that IM callbacks should be handled with ecore_events instead of having to actually register callbacks. -Stafford On Sat, 3 Nov 2007 13:00:13 +0900 Stafford Horne <[EMAIL PROTECTED]> wrote: > Hi All, > > Just want to let you know that I got the first steps of ecore XIM integration > done and basic functionality is working. > > Attached is a diff for ecore_x and a small sample application. Currently > there is only one extra method needed to be called to add an input_context to > your window. The method takes one argument which should be the type for > preedit style (OverTheSpot, OnTheSpot, Root, Callbacks, etc.) but only Root > works for now. > > void ecore_x_window_input_method_init(const char *input_style); > > Please, if someone can just check my approach and api and give comments I > will be happy. I have a few ideas for how to handle setting up position > callbacks, rendering callbacks and other things, but ill try to catch up in > IRC later. > > -Stafford > - 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 and mplayer
On Nov 6, 2007 8:48 AM, Nelson Silva <[EMAIL PROTECTED]> wrote: > Hi guys, > I knew E for quite sometime but never really had the change to work on it. > After seem some of your really great desktops, i had to give it a shot. > I'm trying to put mplayer inside a E widget using evas and edje. > Mplayer needs a wid (window id) to be able to work, pretty much as winId > from QT. Is there a way ? using evas? Use ecore_x to create a Ecore_X_Window (it's an alias for X11 Window), then attach it to the parent. You'll need a bit of work to listen to evas "move" and "resize" events and then issue ecore_x_window_move_resize(). It's a bit of work, so I'd recommend you to use either Emotion or ask on #freevo (irc.freenode.net) what Tack is using for mplayer... he probably have some special mplayer video output. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2007-11-06 07:14:14 -0800
Build log for Enlightenment DR 0.17 on 2007-11-06 07:14:14 -0800 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: engage http://download.enlightenment.org/tests/logs/engage.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log Packages with no supported build system: esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, cpu, deskshow, eclair, ecore, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emu, engrave, engycad, enhance, enity, enterminus, enthrall, entice, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, exhibit, exml, expedite, express, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, net, news, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.net email is sponsored by: 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] Moving to GIT?
Hi guys, Since now raster is happy and all, maybe it's the time to propose moving to GIT? :-) Now seriously, I'm keeping GIT repositories at http://staff.get-e.org/ and it's going quite well, but since we have to commit to CVS later, it doesn't help that much. Many people on IRC was pro to this change, with some against. So I'd like to ask those that are against, what reasons, do you see any showstoper? Reasons to move to GIT: - it's fast, very fast. diff, log, commit are impressively fast. - offline operations. this helps a lot when you're on a plane... I often write code in these situations, probably raster will do a lot now. - distributed environment: - allows you to revert your commits (no more commits: fix typo, missing file) - per-user branches, very fast and also very easy to do merges those are my main points, you can google for git versus cvs or so to get comparisons. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Moving to GIT?
Who would be responsible for the 'main branch'? On 11/6/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > Hi guys, > > Since now raster is happy and all, maybe it's the time to propose > moving to GIT? :-) > > Now seriously, I'm keeping GIT repositories at http://staff.get-e.org/ > and it's going quite well, but since we have to commit to CVS later, > it doesn't help that much. > > Many people on IRC was pro to this change, with some against. So I'd > like to ask those that are against, what reasons, do you see any > showstoper? > > Reasons to move to GIT: > - it's fast, very fast. diff, log, commit are impressively fast. > - offline operations. this helps a lot when you're on a plane... I > often write code in these situations, probably raster will do a lot > now. > - distributed environment: >- allows you to revert your commits (no more commits: fix typo, missing > file) >- per-user branches, very fast and also very easy to do merges > > those are my main points, you can google for git versus cvs or so to > get comparisons. > > -- > Gustavo Sverzut Barbieri > -- > Jabber: [EMAIL PROTECTED] >MSN: [EMAIL PROTECTED] > ICQ#: 17249123 > Skype: gsbarbieri > Mobile: +55 (81) 9927 0010 > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Zachary Goldberg Computer Science Major School of Engineering at the University of Pennsylvania Philadelphia PA - 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 and mplayer
On Tue, 6 Nov 2007, raoul wrote: Le mardi 6 novembre 2007, Nelson Silva a écrit : Hi guys, I knew E for quite sometime but never really had the change to work on it. After seem some of your really great desktops, i had to give it a shot. I'm trying to put mplayer inside a E widget using evas and edje. Mplayer needs a wid (window id) to be able to work, pretty much as winId from QT. Is there a way ? using evas? thk Hi, Why not using Emotion? it's a lib used to embed video into Evas objects, and it can use either xine backend or gstreamer backend. mplpayer is sometimes the only player than can render streams fast enough (for example hd content compressed with a h264 codec) Vincent- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Moving to GIT?
There is a good chance that we would lose our primary repository hosting if we made this transition, which means additional load on our two servers. While they are not struggling under the current load, it is something to keep in mind. On 11/6/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > Hi guys, > > Since now raster is happy and all, maybe it's the time to propose > moving to GIT? :-) > > Now seriously, I'm keeping GIT repositories at http://staff.get-e.org/ > and it's going quite well, but since we have to commit to CVS later, > it doesn't help that much. > > Many people on IRC was pro to this change, with some against. So I'd > like to ask those that are against, what reasons, do you see any > showstoper? > > Reasons to move to GIT: > - it's fast, very fast. diff, log, commit are impressively fast. > - offline operations. this helps a lot when you're on a plane... I > often write code in these situations, probably raster will do a lot > now. > - distributed environment: >- allows you to revert your commits (no more commits: fix typo, missing > file) >- per-user branches, very fast and also very easy to do merges > > those are my main points, you can google for git versus cvs or so to > get comparisons. > > -- > Gustavo Sverzut Barbieri > -- > Jabber: [EMAIL PROTECTED] >MSN: [EMAIL PROTECTED] > ICQ#: 17249123 > Skype: gsbarbieri > Mobile: +55 (81) 9927 0010 > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - 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-users] News from the E stables
On 11/5/07, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > I also see the team growing - this is great, but it serves to just increase > communication traffic, and that in turn means less coding gets done. The > traditional solution here is to start some hierarchy and "reporting lines". I > don't want to do this though - this will server to create splits where once > there was fluid freedom. If we must - we must. Any suggestions? I'm thinking > of > maybe just formalising a bit more of our developer "Relations", involvement > and > teamwork. Some Ideas for people-things: Formalising can be a good thing, I think. We could even try to change our workflow and start using git. What do you think? > 1. Identify people who WANT to be leaders and shape the direction of E - and > are willing to spent the effort. Some of you do it as a hobby and love just > that, some do it for a job, others are in half-way houses. > 2. Lets have actual weekly or monthly developer meetings - literally all-in > live > discussions - maybe IRC? Have actual agendas in meetings. Minutes. Please, let's use IRC. > 3. Have regular community meetings where people can tell us what they like and > don't - give feedback or whatever. > 4. Try an organise some annual get-together. An "E meet" (I think I'll just > call it "The Rave" for now - it fits with the whole E thing). So Literally > find > a place on the planet we all can/want to go to - go there. Sounds good! :-) > 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. Andres (dresb) already did a major writing/rewriting/reorganization on the wiki. It's a good starting point.. > 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. When I first saw the gold bling it was awesome! :-) But after some time it became annoying, I have to say. > 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. Nice! > I hope that everyone can be just as excited. I know I am. I smell a new age > of... Enlightenment. :) Let's start this new age, then. :-) -- Ulisses - 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] Moving to GIT?
On Nov 6, 2007 1:43 PM, Zachary Goldberg <[EMAIL PROTECTED]> wrote: > Who would be responsible for the 'main branch'? Ok, you already put the "main branch" into quotes, that's important because there is no such thing. But we could agree that someone else would aggregate others changes, test and then publish. Who would step up to do that? I surely can do, since I already read most of the patches to commits list. Maybe someone else with more "house-time" would prefer to do that? Raster? Anyone else? The point is: one could easily create a new branch, import someone's else repository, test and choose if it should keep or not. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Moving to GIT?
On Nov 6, 2007 2:24 PM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote: > There is a good chance that we would lose our primary repository > hosting if we made this transition, which means additional load on our > two servers. While they are not struggling under the current load, it > is something to keep in mind. Well, we could do the opposite of I'm doing today: develop on GIT and have public access using CVS, setting up a bridge GIT->CVS is more reliable than CVS->GIT. Well, the load will be lower, since every developer will have the copy of the whole repository, no operations other than pull/push will go to server. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} News from the E stables
On Mon, 5 Nov 2007, Carsten Haitzler (The Rasterman) wrote: > 2. Lets have actual weekly or monthly developer meetings - literally all-in > live > discussions - maybe IRC? Have actual agendas in meetings. Minutes. We are doing irc meetings about xcb, and it's always very useful. > 4. Try an organise some annual get-together. An "E meet" (I think I'll just > call it "The Rave" for now - it fits with the whole E thing). So Literally > find > a place on the planet we all can/want to go to - go there. The french developpers have already met deveral times. Actually not for thinking about E but for dining in a good restaurant :) > Now we also need to fix up enlightenment.org a bit - I intend to sink a bit of > time into solidifying some content. The Wiki has a fair bit. Anyone is welcome > to contribute as they see fit. imho, the enlightenment web site is not good. It's quite difficult to find informations. The horizontal menu is too small. In that page: http://www.enlightenment.org/p.php?p=download&l=en the paragraph about e17 is not clear enough (there are 2 links without explanation. Why doing a small page to say : go to other small pages) etc... > But the primary thing of importance is getting E17 out the door. It's actually > looking petty good. Only 2 really big TODO items left. I'm doing a theme > revamp. The Default theme has very much aged. The gold bling isn't incredibly > popular. I'm working on something I think people will love - and it still > shows > off E. It will replace the current default - and will also knock off some of > the "comment the default theme so its better documented for people to build > new > themes from and learn Edje. I was just wondering if it was the right time to start a new theme, which is a big big work. regards Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Moving to GIT?
On Nov 6, 2007 2:24 PM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote: > There is a good chance that we would lose our primary repository > hosting if we made this transition, which means additional load on our > two servers. While they are not struggling under the current load, it > is something to keep in mind. Just to remember: we have other options for hosting. There's the http://repo.or.cz which is the default free git hosting around. Or even better, since Enlightenment is a project on freedesktop.org, we could use their full infrastructure for hosting git repos (and also for users personal repos, similar to what we have in staff.get-e.org). Cheers, Caio Marcelo - 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] Moving to GIT?
Thats the whole point :). We would need to have an equivalent of 'linus's tree' which we could consider to be the publishing branch. Just a matter of having somebody high up there do it. But, it is a responsibility because that person is responsible for pulling worthwhile patches from other branches which is a fairly significant responsibility (and perhaps time commitment); hopefully you or whomever else is okay with that. My suggestion is we do as WINE does: Have a separate "patches" list-serv whereas devs can develop on their own branch, make changes etc. then submit a diff of all their work after feature x is complete to the patches list-serv -- making life easier for the 'main branch' guy (For wine its Alex Juillard) to find changes and pull as appropriate. On 11/6/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > On Nov 6, 2007 1:43 PM, Zachary Goldberg <[EMAIL PROTECTED]> wrote: > > Who would be responsible for the 'main branch'? > > Ok, you already put the "main branch" into quotes, that's important > because there is no such thing. But we could agree that someone else > would aggregate others changes, test and then publish. > > Who would step up to do that? I surely can do, since I already read > most of the patches to commits list. Maybe someone else with more > "house-time" would prefer to do that? Raster? Anyone else? > > The point is: one could easily create a new branch, import someone's > else repository, test and choose if it should keep or not. > > -- > Gustavo Sverzut Barbieri > -- > Jabber: [EMAIL PROTECTED] >MSN: [EMAIL PROTECTED] > ICQ#: 17249123 > Skype: gsbarbieri > Mobile: +55 (81) 9927 0010 > -- Zachary Goldberg Computer Science Major School of Engineering at the University of Pennsylvania Philadelphia PA - 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] Moving to GIT?
On Nov 6, 2007 5:13 PM, Zachary Goldberg <[EMAIL PROTECTED]> wrote: > Thats the whole point :). We would need to have an equivalent of > 'linus's tree' which we could consider to be the publishing branch. > Just a matter of having somebody high up there do it. But, it is a > responsibility because that person is responsible for pulling > worthwhile patches from other branches which is a fairly significant > responsibility (and perhaps time commitment); hopefully you or > whomever else is okay with that. This responsability could be "distributed": the maintainter could pull from a few subprojects maintainers, which would incorporate contributions from others. And, of course, since everyone has a repo, if someone disappear for a while he could pull from someone else and go on. A more subtle question is how we are could split the CVS? There is a "natural split" of the CVS repo in staff.get-e.org, having ecore, evas, edje all in different repos. So the "main branch" is actually a collection of repos, and the "main branch maintainer" would mantain this set of repos. More separated libs like Etk and Ewl could have different maintainers. Cheers, Caio Marcelo - 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 and mplayer
On Tue, 6 Nov 2007 18:08:30 +0100 (CET) Vincent Torri <[EMAIL PROTECTED]> babbled: > > > On Tue, 6 Nov 2007, raoul wrote: > > > Le mardi 6 novembre 2007, Nelson Silva a écrit : > >> Hi guys, > >> I knew E for quite sometime but never really had the change to work on it. > >> After seem some of your really great desktops, i had to give it a shot. > >> I'm trying to put mplayer inside a E widget using evas and edje. > >> Mplayer needs a wid (window id) to be able to work, pretty much as winId > >> from QT. Is there a way ? using evas? > >> > >> thk > > > > Hi, > > > > Why not using Emotion? it's a lib used to embed video into Evas objects, and > > it can use either xine backend or gstreamer backend. > > mplpayer is sometimes the only player than can render streams fast enough > (for example hd content compressed with a h264 codec) we dont use xvideo for display- that does put a dent in the video output speed already. unless you use the GL engine and have a fragment-shader capable card (nv6xxx and up for example), you will be using software for yuv->rgb and scaling and that will... take its toll. unfortunately mplayer provides NO way to use/integrate it with another app (other than swallowing its window). it provides no way to have it provide yuv data via a shm segment or whatever (without patching mplayer), that i know of, thus it can't be used. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] Integrating an OpenGL render Window within an Evas canevas.
On Tue, 6 Nov 2007 11:11:38 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled: > On Nov 5, 2007 10:28 AM, The Rasterman Carsten Haitzler > <[EMAIL PROTECTED]> wrote: > > On Sat, 3 Nov 2007 21:21:36 -0400 Flo <[EMAIL PROTECTED]> babbled: > > > > this is going to suck for you... but... you can't do what you are trying to > > do :( sorry :( > > > Hi, he mailed me and I asked him to mail this list... I proposed the > following "solutions", but I don't know if they will work: > > 1 - create an opengl X11 window and make the parent be the evas > window. Maybe using ARGB windows and composite manager to handle > transparency. that's work - but you won't be able to layer the window within the evas canvas space - you have a whole lump of special case code just for that window. i was trying to give a simple answer though :):) > 2 - create an offscreen opengl window, use it with > evas_object_image_data_set(). possible - but u'd be reading back data and that'd just royally suck performance-wise > any of those help, raster? > > -- > Gustavo Sverzut Barbieri > -- > Jabber: [EMAIL PROTECTED] >MSN: [EMAIL PROTECTED] > ICQ#: 17249123 > Skype: gsbarbieri > Mobile: +55 (81) 9927 0010 > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: 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-users] Integrating an OpenGL render Window within an Evas canevas.
On Nov 4, 2007 2:21 AM, Flo <[EMAIL PROTECTED]> wrote: > Dear all: > > My name's florent and although I'm rather new to the EFLs world, and > thanks to some great examples over the internet (from Gustavo Sverzut > Barbieri and Raoul Hecky), I already managed to achieved nice results > using Evas. > > However, after investigating evas's (endless) possibility as a GUI > I'm hitting a wall while trying to do the following: > > I want to integrate an OpenGL render window within my Evas UI, this > Evas UI handling every callbacks (mouse and keyboard events) whether > from the evas canevas or the openGL render window. > > The example I tried to achieved, but failed so far, would be to > integrate a glxgears render window (from the famous linux glxgears > OpenGL render app) in a simple Evas canevas contaning a button that > would launch the openGL render window. > > I would appreciate any idea/code/direction on how to achieve this as, > from my internet digging, I did not find any example. > > thanks for your help. > > florent. > Hi, don't know if this might help you, but i did something similar with the fb engine (if i understood correctly): i make the engine "export" the private engine data (i.e the fb pointer) to my evas application, then i do an obscure rectangle in the part of the fb that i will access so evas wont draw there (the mouse and everyhting wont be drawn too) and use my own gfx routines to draw there (the obscure / redraw code in evas isnt perfect, some small parts of the obscure rectangle are redrawn, but its ok). With this you can use opengl functions on that area and still use evas' ones on the other part of the window. This is a good reason to change how evas behaves with engines, some engines allocate the data by themselves and you can't access it from outside and to others you provide them with the required engine data. regards > > - > 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-users mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > - 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-users] Integrating an OpenGL render Window within an Evas canevas.
On Nov 6, 2007 9:26 PM, Flo <[EMAIL PROTECTED]> wrote: > well, thanks for your answers and ideas. > I have to find my way to do this anyways otherwise no more E17/Evas > and beauty for me ! Indeed, for the kind of applications I am writing > (research in 3D Imaging processing - filtering and so on) there is no > way I can keep going without 3D openGL Renderers ! > > I thought of maybe attaching my OpenGL renderer window to a GTK > canvas, through the gtk-opengl extension, and as well integrating my > Evas UI through gevas2. - that is lots of dirty hacks for an end > result that might be way too far from the kinda really nice Evas UI I > was looking for ! No, don't go this route. Given your software, seems that your best bet is to attach a new X window with ecore_x_window_new(), it's quite easy to do so. > I, personally, don't understand why there are not more ppl interested > in doing so. To me, this would definitely bring the EFLs to the top > UI option, at least for ppl with a little bit of taste. well, Linux 3d is still far from good, so it's far from being really used... so ... you got it. But sure, it deserves more attention. We really plan to integrate 3d as a first class citizen, but it will not happen that soon. > Anyways, thanks for your time, let me know if you have other > ideas ... and more importantly, I will let you know if I come up with > a solution, then an elegant solution ;-) ! Ok, if you develop a simple helper around ecore_x_window_new(), then let us know, publish the code somewhere. Hints for implementation: X is async, you need to wait for commands to complete and given back to your process, so you need to use ecore_event_handler_add() for some events, otherwise you'll get errors from X. But ecore makes this quite simple. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] Integrating an OpenGL render Window within an Evas canevas.
On Nov 6, 2007 10:51 PM, Flo <[EMAIL PROTECTED]> wrote: > Thanks for the hints. > I will provide the E-mailing list with my code/hacks or else as soon > as I have something working. > > By 3D, I mean 3D as in OpenGL object made of voxels, not 3D desktop > like XGL/compiz or whatever the new things are which, anyways, I > don't use ;-) Voxels? AFAIU, voxels are 3d pixels, could be represented as a cube, but AFAIK gfx cards don't handle voxels directly... at least they didn't when I did my voxel visualization tool at university 2-3 years ago :-) -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] {Spam?} Re: E and mplayer
On Wed, 7 Nov 2007, Carsten Haitzler (The Rasterman) wrote: > On Tue, 6 Nov 2007 18:08:30 +0100 (CET) Vincent Torri <[EMAIL PROTECTED]> > babbled: > >> >> >> On Tue, 6 Nov 2007, raoul wrote: >> >> mplpayer is sometimes the only player than can render streams fast enough >> (for example hd content compressed with a h264 codec) > > we dont use xvideo for display- that does put a dent in the video output speed > already. unless you use the GL engine and have a fragment-shader capable card > (nv6xxx and up for example), you will be using software for yuv->rgb and > scaling and that will... take its toll. > > unfortunately mplayer provides NO way to use/integrate it with another app > (other than swallowing its window). it provides no way to have it provide yuv > data via a shm segment or whatever (without patching mplayer), that i know of, > thus it can't be used. my comment was not about emotion, but for all the players available (xine, totem with gstreamer and vlc) mplayer is better that these with hd content with a video stream coded with h264 algo. Vincent - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
