Re: [E-devel] Edje gradient rel1/rel2
On Tue, 7 Oct 2008 13:37:39 +0200 (CEST) Dave Andreoli [EMAIL PROTECTED] babbled: Hi all it seems to me that in edje the rel1 and rel2 properties of gradients are unused now. Gradient always use the fill properties, is this right? can I remove that unused props? offset_x/y in the gradient rel1/2 are still used... :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: illogict trunk/e/src/modules/conf_interaction
On Tue, 7 Oct 2008 08:55:59 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: On Tue, Oct 7, 2008 at 2:57 AM, Enlightenment SVN [EMAIL PROTECTED] wrote: Log: Some work on interaction settings: - group on a thumbscroll framelist; - threshhold ?\226?\134?\146 threshold; - add check changed. that's awesome, I see people liked the check_changed, we should add this to other dialogs as well. something else I'd like to see is to move, where possible, layouts to edje with swallow parts, that way we can have special layouts in embedded systems like illume. Side effect is to simplify code a lot. What do you think? at some point - but edje doesnt solve it all - for embedded (small screen) uis' u really need to possibly drop entire content and re-think it. i intend to do this for a chunk of dialogs anyway so their default is more small-screen friendly. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] EET crypto
On Wed, 8 Oct 2008 16:12:13 +0200 Cedric BAIL [EMAIL PROTECTED] babbled: On Wed, Oct 8, 2008 at 4:02 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 10:19 AM, Cedric BAIL [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 3:00 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-10-08 at 14:46 +0200, Cedric BAIL wrote: Hi, As it seems like a good time to break the EFL agains :-). I would like to discuss API/ABI break of eet. I am currently working on adding crypto to eet. My current code only require a key and generate the needed salt and IV for the encryption. So I need to add one more parameter (the key) to all read and write operation of eet. I have currently two possibilities, double the number of function, or just change the existing one. Of course the later solution sounds a little bit cleaner, but it will break all eet applications. A quick search of eet_open in the svn give me 43 differents file using it. Sounds like not a big deal to break it. This could be also be a good time to cleanup the parameters of eet_data_descriptor_element_add also. So guys, what do you think of this move ? Wasn't eet 1.0 released a couple of weeks ago? Breaking the API after the supposed stable 1.0 release just screams wrong in so many ways. Yeah, I know, that's why I asked. I just don't like the idea of not breaking the API/ABI and adding code to work around for marketing issue. Just looking at the TODO. We are planning to add : - support for scripting langage to convert from their object type to eet data and from eet data to script object. - streaming API for both audio and video. The only draw back on switching to 2.0 branch on Eet, is that we currently have one standing bug covered by the test case, that I can find a way to fix (bug in dump/undump) and this will mean that at some point we will need to make another release of the 1.0 branch. Do we need a different key for each read/write operation? I see this being more a key per file, in that case make an eet_key_set(ef, key) and check for the set pointer inside read/write operations. the existing parameters are really one per entry, like compression. I am not really planning to cypher all the data of the file, but just on a entry basis. So you can cypher eet data, but not picture for example. And I want to add this to eet_data_descriptor_decode and encode too. Between it will be a good time to also remove eet_data_descriptor2_new and eet_data_descriptor3_new. hmm an api break... hmmm. hmmm. very soon after a 1.0.0 (i knew it was too soon!). ok - here's my deal. remove descriptor2/3 and merge that all into 1 so fix that mess and you get your cypher key - as long as it doesnt break apps (eet using apps and libs) :) maybe you want to postpone this until all the eina stuff is done? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] language module patch
On Mon, 13 Oct 2008 09:45:53 -0700 Michael Jennings [EMAIL PROTECTED] babbled: On Monday, 13 October 2008, at 18:30:04 (+0200), Quaker wrote: Hi, i created a simple patch for the language module in E-MODULES-EXTRA. The problem in default language module is that the module needs /etc/X11/xkb/rules. Some distros haven't got it, because it is only a symlink to /usr/share/X11/xkb/rules - on Ubuntu this module works, because it has that symlink, but on Debian Lenny not for example. That's why i created this patch - It modifes the source to read files from default /usr/share/X11/xkb/rules. Can any developer apply it please? :) /etc/X11/xkb is the most correct path for portability. But ultimately any patch which can only handle a single path (or merely changes the single path currently handled) is just the same problem all over again and should not be applied. The correct fix is to support a series of possible paths. correct. all this patch will do is fix for you, and then break for others. a patch that adds a searchpath and a list of places to look would be right :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Is there any efl object instead of gtk.drawingarea ?
hi all, You know that Gstreamer video often is displayed in drawingarea which is created by gtk.Drawingarea() function, Is there any efl object instead of this function to create a drawingarea to display Gstreamer video. Any examples would be welcome :) Thanks! BRS! - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] some questions/propositions on evas/ewl/epsilon
Carsten Haitzler (The Rasterman) wrote: On Sun, 21 Sep 2008 17:58:52 +0200 Hendrik Siedelmann [EMAIL PROTECTED] babbled: 2008/9/20 The Rasterman Carsten Haitzler [EMAIL PROTECTED]: ok basically scrolling. not likely to happen. the problem with the test code is - it may have the ability to detect motion vectors but it also adds constant overhead. in the end i am doubtful if it would be that useful in the long-run. right now as we are basically awaiting a lot of re-do in the engine-space i dont think i'll be touching this as it would directly fiddle with the engines and their api. really you suffer from the hardware platform being 1. very slow with the cpu and 2. with a really slow video bus. gtk apps only are smooth as scrolling is one of the few things accelerated and thus they use it. the problem is scrolling in a more general setup with alpha blending etc. ends up being a redraw - and evas just always does it this way. Okay that's a no-go for evas in general :(. But as it stands I am programming for the FR. In fact I found the cpu pretty fast (if not blocked by glamo...). So is there a way to upload pixmaps using evas and ecore? I found ecore_x_pixmap_paste but don't know how to get pixmap from evas, or the graphic context ... ok. it's possible - you're going to have to manually set up evas , a idle_enterer to render etc, (or just render whenever you want). you can render to a pixmap. ecore_evas oes this for you to handle backing pixmaps etc. so you can look there for setup, but just set the target drawable as the pixmap and evas will happily render to it. :) as for epsilon, it does the fdo standard, and this requires thumbnails to be png. yes - writing jpeg thumbnasils is faster, uses less space etc. - it'd be possible to extend espilon to write .eet thumbs using jpeg lossy encoding (and thus also have an alpha channel available), but then you'd have thumbnails not according to the spec. so it'd be possible to do this, just the png writing code in epsilon needs a little abstraction - patches accepted! (sorry - this isn't on my focus right now so will have to just wait for patches):) No problem, I have some patches which convert epsilon to simple jpeg writing with fdo naming conventions. Making it a runtime option like the size looks simple. But it's not finished, I don't quite get epsilon_thumbd, it completely breaks. as for evas loaders, documentation - no, except samples - many of them. they are very simple though. look at the ppm ones (pmaps). they are simple file formats. doesnt include a saver there. but.. for the jpeg loader using embedded thumbnails - no support (would need to know about all the exif tags and extension data), BUT you can use the more generic load options which can play a trick of pre-scaling on load ANY jpeg image (embedded thumbnail or not) and it basically just loads and decodes only part of the jpeg data. you can get up to a 1/8th scale for free (in fact it loads much faster than a full load). e17's e_thumb uses this (evas_object_image_load_size_set for example). it requests the image to be loaded at that size (scaling done on load). :) Jep I know of that. And using it (evas is simply great). Still slow (actually fast enough, but but faster thumbnails never hurt). I'll look at the samples, used libexif before to extract thumbnails, and also dcraw and I'd love to do a extract-loader with libexif and dcraw, which would itself then utilize the jpeg and ppm loaders. Well in some distant future ;). wouldn't we all love more features! :) only so many hours a day... :) Yeah. And btw, remember to warn people when using the image load options, that like the jpg lib itself, though you can set any scaling fraction you want, you might not always get the output size intended.. or at least that that might not be implemented anytime soon. :) Click here for free search of religious schools located near you. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oJxrJ7dnvwzIn5l7IED9uLo0rdOnWc08zKuiUZwJLeRbSqQ/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] e_fm: fix single-click on folders
On Tue, 28 Oct 2008 20:36:06 +0100 thomasg [EMAIL PROTECTED] babbled: Hi, the attached patch fixes the single-click feature of e_fm, so you can use single-click on folders, not just on files. It also removes the strdup in the affected functions that seems useless here. Would be nice if someone could check/review and commit it. in svn :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 dbus support
2008/11/3 The Rasterman Carsten Haitzler [EMAIL PROTECTED] On Sat, 27 Sep 2008 11:37:34 +0200 Albin Tonnerre [EMAIL PROTECTED] babbled: the real problem is the enlightenment.desktop file - the way we ship it it JUST runs enlightenment_start. enlightenment_start (its a front-end binary to launch the real e that doesnt have library dependencies etc.) probably should be in charge of doing this. the problem is dbus-launch may not be installed, so i'd say what we need are patches to enlightenment_start to launch e itself with dbus-launch if it exists or just e raw (like now) if it doesn't :) Uhm, yes, I really believe it would be great to have it. Completely agree :) Luca - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efreet mime default application patch
On Tue, 28 Oct 2008 23:06:58 +0100 (CET) Dave Andreoli [EMAIL PROTECTED] babbled: - Nick Hughart [EMAIL PROTECTED] ha scritto: This is not yet an fdo specification so I'm not going to put it in just yet. It seems to have promise and is a fairly simple format, but for now we have our own methods of choosing default applications and it is similar to how they choose as well (given the user is not making this file on their own). When opening a file in EFM, if that mimetype has not been opened previously you will be given a list of apps that support that mimetype and a list of all apps as well just in case. Once you have chosen an app, EFM remembers this and will use that app until you pick a different app by using Open With. So for now we have our own methods of doing this, but if it does become a specification it may be good to adopt this as it would help with those doing packaging and distribution. Where EFM store the user preference, is it possible to others to access this data? I think we need a centralised way to keep this information, or the user need to choose a preferred application for every apps/module that need to open a filemanager or a browser. I know this is not a standard yet. But this doesn't mean we can't have our method to storing this user preference. I have also done a module that add a configuration dialog to set your preferred apps. Its very simple, but it make no sense if there are not a shared place to store the informations. Don't you think this is a must have module?? So IMHO we need to define witch is the E way to store the mime/application associations, and have the code in some lib (maybe not efreet for now). In this way we can have all the apps/module work the same way and we can also change the lib to fit a final freedesktop standard without touching modules. If we don't do this now all the apps/modules will do the associations in a different way and when the fdo standard will become a reality we need to redo everything. well within e it's easy - there are calls to find this info, but outside of e + modules it's buried deep in e's own config somewhere. now how do we want to do this? 1. config everyone cal look at OR 2. opening service. e.g. a dbus call- u send an array (list) of file paths and say open them please - e will open them for you. this way you also recycle the exec method and child process tracking etc. if the target file is a directory - it opens a directory window, etc. is #2 perhaps not better? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EWL fb engine won't compile - patch
On Wed, 29 Oct 2008 09:23:17 + Quaker [EMAIL PROTECTED] babbled:
i don't see how it wouldn't work. code seems ok to me - builds for me too... :/
Hi,
i tried to compile EWL with sources from 26.10, it didn't work..
i am not a C coder, but i tried to correct it, i modifed a source file of
EWL framebuffer engine and it compiled without errors.. so here is the
patch:
--- ewl_engine_evas_fb.c2008-10-29 09:55:51.0 +
+++ ewl_engine_evas_fb.c2008-10-29 09:47:05.0 +
@@ -50,7 +50,7 @@
if (!engine)
DRETURN_PTR(NULL, DLEVEL_STABLE);
-if (!ee_init(EWL_ENGINE(engine), argc, argv))
+if (!ee_init(EWL_ENGINE(engine)))
{
FREE(engine);
DRETURN_PTR(NULL, DLEVEL_STABLE);
@@ -60,7 +60,7 @@
}
static int
-ee_init(Ewl_Engine *engine, int *argc, char ** argv)
+ee_init(Ewl_Engine *engine)
{
Ewl_Engine_Info *info;
char *display = 0;
@@ -71,19 +71,6 @@
if (ee_key_down_handler)
DRETURN_INT(TRUE, DLEVEL_STABLE);
-if (argc argv)
-{
-int i;
-for (i = 1; i *argc; i++)
-{
-if (!strcmp(argv[i], -display))
-{
-if (++i *argc)
-display = argv[i];
-}
-}
-}
-
if (!ecore_fb_init(display))
{
fprintf(stderr, Unable to initialize Ecore FB.\n
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
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 the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Theme/Wallpaper dialog suggestion
This has been fixed anyway! Toma 2008/11/3 The Rasterman Carsten Haitzler [EMAIL PROTECTED]: On Mon, 22 Sep 2008 13:46:23 +0800 Toma [EMAIL PROTECTED] babbled: Howdee, Since these 2 dialogs are most probably the most used ones around, it would be a good idea to have them operate in mostly the same way. Heres the dialogs at smallest size. http://members.iinet.net.au/~haste/e17/e17-ui1.png The only issue really is the centre aligned buttons for Import and online. Here are the same dialogs sized bigger. http://members.iinet.net.au/~haste/e17/e17-ui2.png As you can see, the sizing in inconsistent, with wallpaper doing the better job. Here is a mockup of what they should do. http://members.iinet.net.au/~haste/e17/e17-ui3.png The preview widget gets resized, and the file list grows too. This way you get to see the long filenames and the preview in a bigger view. There might be some issues making the preview widget work properly with resize. yeah. dialogs need some love. i intend to give the wallpaper and theme dialogs a lot of love and re-org before release. for the moment - let's let the rough bits slide as it's going to get an overhaul :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?
On Mon, 3 Nov 2008, thomasg wrote: Emotion is an Evas Smartobject and can do what you're looking for (it has gstreamer support). However, it's not well maintained, so you might not only run into problems, it might not even work at all (depends I guess). I can only quote raster: 'i think it needs a weekend of love sometime'. a weekend of 4 or 5 days... There are lots of things to do in the gstreamer backend. The first one is to use the new ecore_pipe :) Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?
hi, thanks, I think you should know about canola I think the media part of it is implemented by Gstreamer. Am I right ? BRS! 2008/11/3 Vincent Torri [EMAIL PROTECTED] On Mon, 3 Nov 2008, thomasg wrote: Emotion is an Evas Smartobject and can do what you're looking for (it has gstreamer support). However, it's not well maintained, so you might not only run into problems, it might not even work at all (depends I guess). I can only quote raster: 'i think it needs a weekend of love sometime'. a weekend of 4 or 5 days... There are lots of things to do in the gstreamer backend. The first one is to use the new ecore_pipe :) Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?
- Nicolas Aguirre [EMAIL PROTECTED] ha scritto: 2008/11/3 Gustavo Sverzut Barbieri [EMAIL PROTECTED]: Gstreamer just sucks to play video on nokia devices, and doing extra copies or transformation from YUV to RGB is no-go on those hardwares. That's why canola uses atakabe to play media, it will handle mplayer, gstreamer... mplayer is optimized and outputs YUV at half resolution using double-pixel directly to framebuffer (in fullscreen mode). While in windowed mode, Canola just use ecore_x to reparent MPlayer's window to the required position (it's a black rectangle in the theme). Exactly what I do with libplayer/mplayer in Enna :) But in this way you can't have evas objects on top of the mplayer window... What about the vlc backend? It seem the better way for me as, for what I have understand, vlc doesn't use gstreamer. Someone have tryed it? -- Nicolas Aguirre Mail: [EMAIL PROTECTED] Web: http://www.digital-corner.org - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?
On Mon, Nov 3, 2008 at 11:44 AM, Dave Andreoli [EMAIL PROTECTED] wrote: - Nicolas Aguirre [EMAIL PROTECTED] ha scritto: 2008/11/3 Gustavo Sverzut Barbieri [EMAIL PROTECTED]: Gstreamer just sucks to play video on nokia devices, and doing extra copies or transformation from YUV to RGB is no-go on those hardwares. That's why canola uses atakabe to play media, it will handle mplayer, gstreamer... mplayer is optimized and outputs YUV at half resolution using double-pixel directly to framebuffer (in fullscreen mode). While in windowed mode, Canola just use ecore_x to reparent MPlayer's window to the required position (it's a black rectangle in the theme). Exactly what I do with libplayer/mplayer in Enna :) But in this way you can't have evas objects on top of the mplayer window... yes, that's the problem with such approach, but on that platform it's the only option, really, you don't have much cpu power. What about the vlc backend? It seem the better way for me as, for what I have understand, vlc doesn't use gstreamer. Someone have tryed it? it's totally buggy, needs fixing. AFAIR it calls back from thread, which is not allowed in EFL, but people spotted different problems as well. Also, vlc is not an option on that platform, gstreamer is the official media player and uses dsp for audio decoding, but mplayer is was optimized by a guy and is the best, it does this framebuffer tricky and also have an ARM JIT compiler for scale. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster IN trunk/ecore: . src/lib/ecore
On Mon, Nov 3, 2008 at 11:13 AM, Peter Wehrfritz [EMAIL PROTECTED] wrote: Gustavo Sverzut Barbieri schrieb: On Mon, Nov 3, 2008 at 3:42 AM, Enlightenment SVN [EMAIL PROTECTED] wrote: Log: add patch to add a pipe handler for glueing threads to the core main loop via pipes - makes it save for a thread to send a message to the main loop and not need lots of thread locks etc. ok, this code have some minor problems, I should have looked at it before, maybe I can fix it during my flight tomorrow, but: - read/write need to catch errors, be them EINTR and EAGAIN since fd is marked non-blocking. For EAGAIN we could either just retry or we must keep size and todo in Ecore_Pipe as well as an allocated buffer of required size, just dispatch when everything is read. (same for write). As Sachiel said, raster took the wrong patch. I'll commit the other one this evening. I don't claim that that one is perfect, but it does some error checking. - for consistency, we should have handler() to return an int and return that int in _ecore_pipe_read(). And what should we do if the handler returns ECORE_CALLBACK_CANCEL? Should we only cancel the callback or also del (free) the whole pipe? I guess so, like other ecore functions do. - example contais code that does not even compile, I spotted at least ecore_pipe_write(pipe, arg0); but that function takes 3 parameters, last one must be sizeof(void *) since you're writing the pointer, but possible more stuff is missing. Yes, I changed the examples in the other patch, too. good! -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EWL fb engine won't compile - patch
Carsten Haitzler (The Rasterman) schrieb: On Wed, 29 Oct 2008 09:23:17 + Quaker [EMAIL PROTECTED] babbled: i don't see how it wouldn't work. code seems ok to me - builds for me too... :/ Sorry, my bad. I haven't answered to the list. I fixed it some days ago. So indeed it should work fine now :). - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: pfritz trunk/ecore/src/lib/ecore
On Mon, Nov 3, 2008 at 11:57 AM, Enlightenment SVN
[EMAIL PROTECTED] wrote:
+ /* first write the len into the pipe */
+ do
+ {
+ ret = pipe_write(p-fd_write, nbytes, sizeof(nbytes));
+ if (ret == sizeof(nbytes))
+ {
+retry = ECORE_PIPE_WRITE_RETRY;
+break;
+ }
+ else if (ret 0)
+ {
+/* XXX What should we do here? */
+fprintf(stderr, The length of the data was not written complete
+ to the pipe\n);
try to read what's missing, you'll end with EAGAIN if there is no data
yet. In that case you either try a busy loop or you save number of
read bytes and what's missing and continue on next next fd_handler.
+ else
+ {
+fprintf(stderr, An unhandled error (ret: %d errno: %d)
+ occured while writing to the pipe the length\n,
+ ret, errno);
please, use strerror(errno) to make it easier to figure out what's happened.
+ }
+ }
+ while (retry--);
+
+ if (retry != ECORE_PIPE_WRITE_RETRY)
+ return 0;
this termination condition is weird, if it's retry it should mean we
should retry, not that it finished fine.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: [EMAIL PROTECTED]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?
2008/11/3 Gustavo Sverzut Barbieri [EMAIL PROTECTED]: Gstreamer just sucks to play video on nokia devices, and doing extra copies or transformation from YUV to RGB is no-go on those hardwares. That's why canola uses atakabe to play media, it will handle mplayer, gstreamer... mplayer is optimized and outputs YUV at half resolution using double-pixel directly to framebuffer (in fullscreen mode). While in windowed mode, Canola just use ecore_x to reparent MPlayer's window to the required position (it's a black rectangle in the theme). Exactly what I do with libplayer/mplayer in Enna :) -- Nicolas Aguirre Mail: [EMAIL PROTECTED] Web: http://www.digital-corner.org - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster IN trunk/ecore: . src/lib/ecore
On Mon, Nov 3, 2008 at 3:42 AM, Enlightenment SVN [EMAIL PROTECTED] wrote: Log: add patch to add a pipe handler for glueing threads to the core main loop via pipes - makes it save for a thread to send a message to the main loop and not need lots of thread locks etc. ok, this code have some minor problems, I should have looked at it before, maybe I can fix it during my flight tomorrow, but: - read/write need to catch errors, be them EINTR and EAGAIN since fd is marked non-blocking. For EAGAIN we could either just retry or we must keep size and todo in Ecore_Pipe as well as an allocated buffer of required size, just dispatch when everything is read. (same for write). - for consistency, we should have handler() to return an int and return that int in _ecore_pipe_read(). - example contais code that does not even compile, I spotted at least ecore_pipe_write(pipe, arg0); but that function takes 3 parameters, last one must be sizeof(void *) since you're writing the pointer, but possible more stuff is missing. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?
On Mon, Nov 3, 2008 at 1:20 PM, thomasg [EMAIL PROTECTED] wrote: Because of that and many many other reasons it would be really cool, to have a mplayer backend for emotion. :) But I know, it's really tricky to find a good solution, because mplayer isn't meant to be just a backend. you'd have to write an Evas vo for mplayer and do sync of both processes somehow. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?
On Mon, Nov 3, 2008 at 9:49 AM, dongmei zhou [EMAIL PROTECTED]wrote: hi all, You know that Gstreamer video often is displayed in drawingarea which is created by gtk.Drawingarea() function, Is there any efl object instead of this function to create a drawingarea to display Gstreamer video. Any examples would be welcome :) Emotion is an Evas Smartobject and can do what you're looking for (it has gstreamer support). However, it's not well maintained, so you might not only run into problems, it might not even work at all (depends I guess). I can only quote raster: 'i think it needs a weekend of love sometime'. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efreet mime default application patch
- Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] ha scritto: On Tue, 28 Oct 2008 23:06:58 +0100 (CET) Dave Andreoli [EMAIL PROTECTED] babbled: - Nick Hughart [EMAIL PROTECTED] ha scritto: This is not yet an fdo specification so I'm not going to put it in just yet. It seems to have promise and is a fairly simple format, but for now we have our own methods of choosing default applications and it is similar to how they choose as well (given the user is not making this file on their own). When opening a file in EFM, if that mimetype has not been opened previously you will be given a list of apps that support that mimetype and a list of all apps as well just in case. Once you have chosen an app, EFM remembers this and will use that app until you pick a different app by using Open With. So for now we have our own methods of doing this, but if it does become a specification it may be good to adopt this as it would help with those doing packaging and distribution. Where EFM store the user preference, is it possible to others to access this data? I think we need a centralised way to keep this information, or the user need to choose a preferred application for every apps/module that need to open a filemanager or a browser. I know this is not a standard yet. But this doesn't mean we can't have our method to storing this user preference. I have also done a module that add a configuration dialog to set your preferred apps. Its very simple, but it make no sense if there are not a shared place to store the informations. Don't you think this is a must have module?? So IMHO we need to define witch is the E way to store the mime/application associations, and have the code in some lib (maybe not efreet for now). In this way we can have all the apps/module work the same way and we can also change the lib to fit a final freedesktop standard without touching modules. If we don't do this now all the apps/modules will do the associations in a different way and when the fdo standard will become a reality we need to redo everything. well within e it's easy - there are calls to find this info, but outside of e + modules it's buried deep in e's own config somewhere. now how do we want to do this? 1. config everyone cal look at OR 2. opening service. e.g. a dbus call- u send an array (list) of file paths and say open them please - e will open them for you. this way you also recycle the exec method and child process tracking etc. if the target file is a directory - it opens a directory window, etc. is #2 perhaps not better? The #2 is powerfull but will work only if E is running, and this is bad for applications, that should work also outside E. I prefer the #1, put the config where everyone can look...what about the defaults.list file ? ;) (it's not yet a fdo standard, but it's a simple and clear way to store the info) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: pfritz trunk/ecore/src/lib/ecore
Gustavo Sverzut Barbieri schrieb:
On Mon, Nov 3, 2008 at 11:57 AM, Enlightenment SVN
[EMAIL PROTECTED] wrote:
+ /* first write the len into the pipe */
+ do
+ {
+ ret = pipe_write(p-fd_write, nbytes, sizeof(nbytes));
+ if (ret == sizeof(nbytes))
+ {
+retry = ECORE_PIPE_WRITE_RETRY;
+break;
+ }
+ else if (ret 0)
+ {
+/* XXX What should we do here? */
+fprintf(stderr, The length of the data was not written complete
+ to the pipe\n);
try to read what's missing, you'll end with EAGAIN if there is no data
yet. In that case you either try a busy loop or you save number of
read bytes and what's missing and continue on next next fd_handler.
It is actually a case that should never happen, i think. Anyway I added
code to pass the rest of the length again.
+ else
+ {
+fprintf(stderr, An unhandled error (ret: %d errno: %d)
+ occured while writing to the pipe the length\n,
+ ret, errno);
please, use strerror(errno) to make it easier to figure out what's happened.
k
+ }
+ }
+ while (retry--);
+
+ if (retry != ECORE_PIPE_WRITE_RETRY)
+ return 0;
this termination condition is weird, if it's retry it should mean we
should retry, not that it finished fine.
Indeed, it was not very readable. I changed the logic abit.
Index: ecore_pipe.c
===
--- ecore_pipe.c (Revision 37441)
+++ ecore_pipe.c (Arbeitskopie)
@@ -326,7 +326,8 @@
ecore_pipe_del);
return NULL;
}
- ecore_main_fd_handler_del(p-fd_handler);
+ if (p-fd_handler)
+ ecore_main_fd_handler_del(p-fd_handler);
close(p-fd_read);
close(p-fd_write);
data = (void *)p-data;
@@ -348,7 +349,13 @@
ssize_t ret;
size_t already_written = 0;
int retry = ECORE_PIPE_WRITE_RETRY;
+ union {
+ unsigned int isize;
+ unsigned char bytes[sizeof(nbytes)];
+ } size;
+ size.isize = nbytes;
+
if (!ECORE_MAGIC_CHECK(p, ECORE_MAGIC_PIPE))
{
ECORE_MAGIC_FAIL(p, ECORE_MAGIC_PIPE,
@@ -358,35 +365,30 @@
/* first write the len into the pipe */
do
{
- ret = pipe_write(p-fd_write, nbytes, sizeof(nbytes));
- if (ret == sizeof(nbytes))
- {
- retry = ECORE_PIPE_WRITE_RETRY;
- break;
- }
- else if (ret 0)
- {
- /* XXX What should we do here? */
- fprintf(stderr, The length of the data was not written complete
- to the pipe\n);
- return 0;
- }
+ ret = pipe_write(p-fd_write, size.bytes[already_written],
+sizeof(nbytes) - already_written);
+ if (ret == (ssize_t)(sizeof(nbytes) - already_written))
+ break;
+ else if (ret = 0)
+ already_written += ret;
else if (ret == -1 errno == EINTR)
/* try it again */
;
else
{
- fprintf(stderr, An unhandled error (ret: %d errno: %d)
+ fprintf(stderr, An unhandled error (ret: %d errno: %s)
occured while writing to the pipe the length\n,
- ret, errno);
+ ret, strerror(errno));
}
}
while (retry--);
- if (retry != ECORE_PIPE_WRITE_RETRY)
+ if (retry 0)
return 0;
/* and now pass the data to the pipe */
+ already_written = 0;
+ retry = ECORE_PIPE_WRITE_RETRY;
do
{
ret = pipe_write(p-fd_write,
@@ -397,7 +399,7 @@
return 1;
else if (ret = 0)
{
- already_written -= ret;
+ already_written += ret;
continue;
}
else if (ret == -1 errno == EINTR)
@@ -405,9 +407,9 @@
;
else
{
- fprintf(stderr, An unhandled error (ret: %d errno: %d)
+ fprintf(stderr, An unhandled error (ret: %d errno: %s)
occured while writing to the pipe the length\n,
- ret, errno);
+ ret, strerror(errno));
}
}
while (retry--);
@@ -435,28 +437,48 @@
*/
if (p-len == 0)
{
- /* read the len of the passed data */
- ret = pipe_read(p-fd_read, p-len, sizeof(p-len));
+ union {
+ unsigned int isize;
+ unsigned char bytes[sizeof(unsigned int)];
+ } size;
+ size_t already_read_len = 0;
- /* catch the non error case first */
- if (ret == sizeof(p-len))
- ;
- else if (ret 0)
+ for (;;)
{
- /* XXX What should we do here? */
- fprintf(stderr, Only read %d bytes from the pipe, although
- we need to read %d bytes.\n, ret, sizeof(p-len));
+ /* read the len of the passed data */
+ ret = pipe_read(p-fd_read, size.bytes[already_read_len],
+ sizeof(p-len) - already_read_len);
+
+ /* catch the non error case first */
+ if (ret == sizeof(p-len))
+ {
+ p-len = size.isize;
+ break;
+ }
+ else if (ret 0)
+ already_read_len += ret;
+ else if (ret == 0
+ || (ret == -1 (errno == EINTR || errno == EAGAIN)))
+ {
+ if (!already_read_len)
+ return ECORE_CALLBACK_RENEW;
+ }
+ else
+ {
+
Re: [E-devel] Rage TODO items
On Sat, 01 Nov 2008 20:13:21 +0100 Tim Felgentreff [EMAIL PROTECTED] babbled: Hi, I am atm trying to help a little for the first time, working on the TODO list of Rage. I have started on two items already. One is simple oh cool! rage has been on the backburner for a long time. i really wrote it to solve my i can watch movies problem then stopped :) mouse control for rage, and the other is work on the settings menu. I would like to hear what you think. I would also like to add support for an eet configfile to rage, if that's okay with the maintainer. Both patches apply cleanly to revision 37377, they're not interrelated. Regards, Tim patches seem cool - i'll put them in svn. :) continue merrily with your work! :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] EET crypto
On Mon, Nov 3, 2008 at 9:05 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Wed, 8 Oct 2008 16:12:13 +0200 Cedric BAIL [EMAIL PROTECTED] babbled: On Wed, Oct 8, 2008 at 4:02 PM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 10:19 AM, Cedric BAIL [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 3:00 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Wed, 2008-10-08 at 14:46 +0200, Cedric BAIL wrote: Hi, As it seems like a good time to break the EFL agains :-). I would like to discuss API/ABI break of eet. I am currently working on adding crypto to eet. My current code only require a key and generate the needed salt and IV for the encryption. So I need to add one more parameter (the key) to all read and write operation of eet. I have currently two possibilities, double the number of function, or just change the existing one. Of course the later solution sounds a little bit cleaner, but it will break all eet applications. A quick search of eet_open in the svn give me 43 differents file using it. Sounds like not a big deal to break it. This could be also be a good time to cleanup the parameters of eet_data_descriptor_element_add also. So guys, what do you think of this move ? Wasn't eet 1.0 released a couple of weeks ago? Breaking the API after the supposed stable 1.0 release just screams wrong in so many ways. Yeah, I know, that's why I asked. I just don't like the idea of not breaking the API/ABI and adding code to work around for marketing issue. Just looking at the TODO. We are planning to add : - support for scripting langage to convert from their object type to eet data and from eet data to script object. - streaming API for both audio and video. The only draw back on switching to 2.0 branch on Eet, is that we currently have one standing bug covered by the test case, that I can find a way to fix (bug in dump/undump) and this will mean that at some point we will need to make another release of the 1.0 branch. Do we need a different key for each read/write operation? I see this being more a key per file, in that case make an eet_key_set(ef, key) and check for the set pointer inside read/write operations. the existing parameters are really one per entry, like compression. I am not really planning to cypher all the data of the file, but just on a entry basis. So you can cypher eet data, but not picture for example. And I want to add this to eet_data_descriptor_decode and encode too. Between it will be a good time to also remove eet_data_descriptor2_new and eet_data_descriptor3_new. hmm an api break... hmmm. hmmm. very soon after a 1.0.0 (i knew it was too soon!). ok - here's my deal. remove descriptor2/3 and merge that all into 1 so fix that mess and you get your cypher key - as long as it doesnt break apps (eet using apps and libs) :) maybe you want to postpone this until all the eina stuff is done? I need crypto support soon, so I will provide a patch that doesn't break API. Before breaking eet API, I agree that we should first finish this move to eina, currently postponed for around 2 weeks as I have some deadline. But I have a little bad news, we will need more than just breaking eet API. There are currently 2 bugs regarding eet dump/undump function, one that I almost know how to solve and another one that I don't understand yet what is going on. The first one is just the dump/undump part of list/array/hash of strings bug. The problem is in that case that we loose the information in the eet data that the chunk is an item part of a list/array/hash and not only a string. Solving it is easy... we just need to change eet data format so we always store simple type and the group type. I think we can make it backward compatible, by just handling both current and new format with a new magic string. I have just starting to work on a fix, but it's not high enough on my TODO list at the moment. So don't expect complete fix before a few weeks. The second bug is due to undumping struct of struct which doesn't result in the same eet data as the dumped one. My guess is that this bug is related to EET_G_UNKNOWN case in _eet_data_dump_encode. But I wasn't able to find a fix nor really understand what is going on in that case. So eet TODO list is quite nice at the moment and need a little bit of work before any major release :-) -- Cedric BAIL - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net
Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?
Because of that and many many other reasons it would be really cool, to have a mplayer backend for emotion. :) But I know, it's really tricky to find a good solution, because mplayer isn't meant to be just a backend. On 11/3/08, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Mon, Nov 3, 2008 at 11:44 AM, Dave Andreoli [EMAIL PROTECTED] wrote: - Nicolas Aguirre [EMAIL PROTECTED] ha scritto: 2008/11/3 Gustavo Sverzut Barbieri [EMAIL PROTECTED]: Gstreamer just sucks to play video on nokia devices, and doing extra copies or transformation from YUV to RGB is no-go on those hardwares. That's why canola uses atakabe to play media, it will handle mplayer, gstreamer... mplayer is optimized and outputs YUV at half resolution using double-pixel directly to framebuffer (in fullscreen mode). While in windowed mode, Canola just use ecore_x to reparent MPlayer's window to the required position (it's a black rectangle in the theme). Exactly what I do with libplayer/mplayer in Enna :) But in this way you can't have evas objects on top of the mplayer window... yes, that's the problem with such approach, but on that platform it's the only option, really, you don't have much cpu power. What about the vlc backend? It seem the better way for me as, for what I have understand, vlc doesn't use gstreamer. Someone have tryed it? it's totally buggy, needs fixing. AFAIR it calls back from thread, which is not allowed in EFL, but people spotted different problems as well. Also, vlc is not an option on that platform, gstreamer is the official media player and uses dsp for audio decoding, but mplayer is was optimized by a guy and is the best, it does this framebuffer tricky and also have an ARM JIT compiler for scale. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster IN trunk/ecore: . src/lib/ecore
On Mon, Nov 3, 2008 at 8:46 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Mon, Nov 3, 2008 at 3:42 AM, Enlightenment SVN [EMAIL PROTECTED] wrote: Log: add patch to add a pipe handler for glueing threads to the core main loop via pipes - makes it save for a thread to send a message to the main loop and not need lots of thread locks etc. ok, this code have some minor problems, I should have looked at it before, maybe I can fix it during my flight tomorrow, but: - read/write need to catch errors, be them EINTR and EAGAIN since fd is marked non-blocking. For EAGAIN we could either just retry or we must keep size and todo in Ecore_Pipe as well as an allocated buffer of required size, just dispatch when everything is read. (same for write). There was another patch that did check for errors. - for consistency, we should have handler() to return an int and return that int in _ecore_pipe_read(). - example contais code that does not even compile, I spotted at least ecore_pipe_write(pipe, arg0); but that function takes 3 parameters, last one must be sizeof(void *) since you're writing the pointer, but possible more stuff is missing. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?
On Mon, Nov 3, 2008 at 9:58 AM, dongmei zhou [EMAIL PROTECTED] wrote: hi, thanks, I think you should know about canola I think the media part of it is implemented by Gstreamer. Am I right ? Gstreamer just sucks to play video on nokia devices, and doing extra copies or transformation from YUV to RGB is no-go on those hardwares. That's why canola uses atakabe to play media, it will handle mplayer, gstreamer... mplayer is optimized and outputs YUV at half resolution using double-pixel directly to framebuffer (in fullscreen mode). While in windowed mode, Canola just use ecore_x to reparent MPlayer's window to the required position (it's a black rectangle in the theme). -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E moudule API BREAK proposal
On Sat, 11 Oct 2008 20:48:04 +0200 (CEST) Dave Andreoli
[EMAIL PROTECTED] babbled:
Hi all,
I want to make an e17 module that expose simple edje objects as gadgets.
The idea is that people can download edje file from the net(calculator,
clocks and whatever next), put it in the right directory and then my module
can expose this objects as they was gadgets (they must appear in the available
gadgets list of the shelf or the gadman). So that the user can use the object
where they want.
This can be a really easy way to create and distribute simple gadgets as you
don't have to compile the edje object for different arch (thinking about
exchange can also host gadgets, without platform problem!).
In the future my module can also make some advanced stuff, for example execute
a bash, python (or what you like) script that is contained in the edje file,
making the simple gadgets more functional... but this is another story...
This was the good part of the post, now comes the bad :(
I can't find a way to do this module without changing the E GADCON API.
From the module I create an E_Gadcon_Client_Class for each 'simple widget'
found in the right directory, and I call e_gadcon_provider_register()
as many times as needed. But then when E ask me for the label, the icon and
the id I can't know for witch 'simple widget' he need the information.
This is how it is done now:
struct _E_Gadcon_Client_Class
{
int version;
const char *name;
struct
{
E_Gadcon_Client *(*init) (E_Gadcon *gc, const char *name, const
char *id, const char *style); void (*shutdown) (E_Gadcon_Client
*gcc); void (*orient) (E_Gadcon_Client *gcc);
char *(*label) (void);
Evas_Object *(*icon) (Evas *evas);
const char *(*id_new) (void);
void (*id_del) (const char *id);
} func;
char *default_style;
};
As you can see the function label(void) don't have params and my module
is lost on this (for witch widget you want the label??). The same apply
to the icon and id_new functions.
So this is my proposed API
struct _E_Gadcon_Client_Class
{
int version;
const char *name;
struct
{
E_Gadcon_Client *(*init) (E_Gadcon *gc, const char *name, const
char *id, const char *style); void (*shutdown) (E_Gadcon_Client
*gcc); void (*orient) (E_Gadcon_Client *gcc);
char *(*label) (E_Gadcon_Client_Class *class);
Evas_Object *(*icon) (Evas *evas, E_Gadcon_Client_Class
*class); const char *(*id_new) (E_Gadcon_Client_Class *class);
void (*id_del) (const char *id);
} func;
char *default_style;
};
I simple add the E_Gadcon_Client_Class *class params to some functions.
ok one thng. for consistency make E_Gadcon_Client_Class the first param for icon
() and also for id_del() even if we don't use it - at least it's consistent :)
I think that this kind of functionality (a single module that expose more
than one gadgets) could be useful in future, for example we can then make a
module that handle gadgets from different source (think of google_gadgets,
OSX dashbord widget...and so on) like KDE4 seems to do. WE then access a
really HUGE set of just done gadgets :)
What do you think about all this? It make sense?
maybe someone know how to do this without the break?
Hope you like my idea, and also hope that this mail is clear enough...
as always my English is not so good ;)
hmm - it makes sense. i guess if we break - break before e17 is released. so
lets do it. i'm in. do your stuff! :)
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
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 the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
Re: [E-devel] E SVN: raster IN trunk/ecore: . src/lib/ecore
Gustavo Sverzut Barbieri schrieb: On Mon, Nov 3, 2008 at 3:42 AM, Enlightenment SVN [EMAIL PROTECTED] wrote: Log: add patch to add a pipe handler for glueing threads to the core main loop via pipes - makes it save for a thread to send a message to the main loop and not need lots of thread locks etc. ok, this code have some minor problems, I should have looked at it before, maybe I can fix it during my flight tomorrow, but: - read/write need to catch errors, be them EINTR and EAGAIN since fd is marked non-blocking. For EAGAIN we could either just retry or we must keep size and todo in Ecore_Pipe as well as an allocated buffer of required size, just dispatch when everything is read. (same for write). As Sachiel said, raster took the wrong patch. I'll commit the other one this evening. I don't claim that that one is perfect, but it does some error checking. - for consistency, we should have handler() to return an int and return that int in _ecore_pipe_read(). And what should we do if the handler returns ECORE_CALLBACK_CANCEL? Should we only cancel the callback or also del (free) the whole pipe? - example contais code that does not even compile, I spotted at least ecore_pipe_write(pipe, arg0); but that function takes 3 parameters, last one must be sizeof(void *) since you're writing the pointer, but possible more stuff is missing. Yes, I changed the examples in the other patch, too. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: illogict trunk/e/src/modules/conf_interaction
On Mon, Nov 3, 2008 at 5:56 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Tue, 7 Oct 2008 08:55:59 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: On Tue, Oct 7, 2008 at 2:57 AM, Enlightenment SVN [EMAIL PROTECTED] wrote: Log: Some work on interaction settings: - group on a thumbscroll framelist; - threshhold ?\226?\134?\146 threshold; - add check changed. that's awesome, I see people liked the check_changed, we should add this to other dialogs as well. something else I'd like to see is to move, where possible, layouts to edje with swallow parts, that way we can have special layouts in embedded systems like illume. Side effect is to simplify code a lot. What do you think? at some point - but edje doesnt solve it all - for embedded (small screen) uis' u really need to possibly drop entire content and re-think it. i intend to do this for a chunk of dialogs anyway so their default is more small-screen friendly. sure, sure! but for some dialogs we can just make it vertical and it will work. some dialogs will have to move to multi-step, like choose something and then you're presented with options relevant to that mode, but maybe this is good for desktops as well.. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eet wrapper
Am Mon, 3 Nov 2008 09:56:45 +0100 schrieb Jonathan MULLER: Hello Jonathan, would be nice if you do that. And best provide a path to integrate it into eflpp. BTW: Seems you're not a member of enlightenment-devel@lists.sourceforge.net list. You should join the list if you like to post anything regards Andreas Hi Andreas, I understand those problematics of course. The dependency is on tuple classe with 3 elements ... we could in a first time considering a std::pair of std::pair boost::tuple Ty, int, bool ~ std::pair std::pair Ty, int , bool It will be a bit more heavy for the user ... but I can have a look to develop this. I have to say adding a dependncy on boost would be a great idea. Regards, Jonathan Muller. On Sun, Nov 2, 2008 at 12:03 PM, Andreas Volz [EMAIL PROTECTED] wrote: Am Sat, 1 Nov 2008 21:14:57 +0100 schrieb Jonathan MULLER: Hello Jonathan, I reviewed the source code short and this it looks good. But there's a little problem. Until now the eflpp library hasn't any boost dependency. Using your eet wrapper would create a dependency to boost for all applications based on eflpp. For me personal this isn't a big problem as my main application is yet based on boost for some other reasons. The positive would be that it allows to replace some other stuff in eflpp with boost code. But as this is a design decision I'm not sure about it. At least I like to discuss that topic on the list. I added the list to Cc. Meanwhile you could think about if it's not possible to rewrite your wrapper with STL classes. Any other opinions from the list? regards Andreas BTW: I didn't attach the source code to this E-Mail. You've to ask Jonathan about it. Hi Andreas, You will find in as attached file the wrapper. execute make to build the 2 executables and make test to run first the writing test and the the readin test. And take a look at the code ;) I am waiting for your feedbacks. I do not have rights to commit in the SVN tree that's why I send you this first approach. Note : you have to have the boost tuple library. Regards, John aka Bhaal22. On Fri, Oct 31, 2008 at 9:09 PM, Andreas Volz [EMAIL PROTECTED] wrote: Am Mon, 27 Oct 2008 16:01:30 +0200 schrieb Jonathan MULLER: Hello Jonathan, I'm interested in your wrapper. Do you've a patch based on existing eflpp code base? It should fit into the eflpp design. regards Andreas Hi Andreas, I wrote a little C++ wrapper around Eet library compliant with STL. I can use STL algorithm to iterate over keys, entries ... I wrote some operators to access items in a user friendly way. I can show you if you want. Regards, Jonathan Muller. -- Drylm Founder http://www.drylm.org -- Technical Blog http://andreasvolz.wordpress.com/ -- Drylm Founder http://www.drylm.org -- Technical Blog http://andreasvolz.wordpress.com/ -- Drylm Founder http://www.drylm.org - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?
On Mon, 3 Nov 2008, Gustavo Sverzut Barbieri wrote: On Mon, Nov 3, 2008 at 1:20 PM, thomasg [EMAIL PROTECTED] wrote: Because of that and many many other reasons it would be really cool, to have a mplayer backend for emotion. :) But I know, it's really tricky to find a good solution, because mplayer isn't meant to be just a backend. you'd have to write an Evas vo for mplayer and do sync of both processes somehow. i wanted to write one at some point, but i have so few time that i gave up Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?
2008/11/3 Gustavo Sverzut Barbieri [EMAIL PROTECTED]: On Mon, Nov 3, 2008 at 1:20 PM, thomasg [EMAIL PROTECTED] wrote: Because of that and many many other reasons it would be really cool, to have a mplayer backend for emotion. :) But I know, it's really tricky to find a good solution, because mplayer isn't meant to be just a backend. you'd have to write an Evas vo for mplayer and do sync of both processes somehow. We should look at libplayer (libplayer.geexbox.org), which is a wrapper that controls mplayer process in slave mode, After that, as Gustavo said, write a buffer vo for mplayer like it's done in vlc. AFAIR mplayer can be only controlled in slave mode. my 2 cents. -- Nicolas Aguirre Mail: [EMAIL PROTECTED] Web: http://www.digital-corner.org - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efreet mime default application patch
On Mon, 3 Nov 2008 14:39:05 +0100 (CET) Dave Andreoli [EMAIL PROTECTED] wrote: - Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] ha scritto: On Tue, 28 Oct 2008 23:06:58 +0100 (CET) Dave Andreoli [EMAIL PROTECTED] babbled: - Nick Hughart [EMAIL PROTECTED] ha scritto: This is not yet an fdo specification so I'm not going to put it in just yet. It seems to have promise and is a fairly simple format, but for now we have our own methods of choosing default applications and it is similar to how they choose as well (given the user is not making this file on their own). When opening a file in EFM, if that mimetype has not been opened previously you will be given a list of apps that support that mimetype and a list of all apps as well just in case. Once you have chosen an app, EFM remembers this and will use that app until you pick a different app by using Open With. So for now we have our own methods of doing this, but if it does become a specification it may be good to adopt this as it would help with those doing packaging and distribution. Where EFM store the user preference, is it possible to others to access this data? I think we need a centralised way to keep this information, or the user need to choose a preferred application for every apps/module that need to open a filemanager or a browser. I know this is not a standard yet. But this doesn't mean we can't have our method to storing this user preference. I have also done a module that add a configuration dialog to set your preferred apps. Its very simple, but it make no sense if there are not a shared place to store the informations. Don't you think this is a must have module?? So IMHO we need to define witch is the E way to store the mime/application associations, and have the code in some lib (maybe not efreet for now). In this way we can have all the apps/module work the same way and we can also change the lib to fit a final freedesktop standard without touching modules. If we don't do this now all the apps/modules will do the associations in a different way and when the fdo standard will become a reality we need to redo everything. well within e it's easy - there are calls to find this info, but outside of e + modules it's buried deep in e's own config somewhere. now how do we want to do this? 1. config everyone cal look at OR 2. opening service. e.g. a dbus call- u send an array (list) of file paths and say open them please - e will open them for you. this way you also recycle the exec method and child process tracking etc. if the target file is a directory - it opens a directory window, etc. is #2 perhaps not better? The #2 is powerfull but will work only if E is running, and this is bad for applications, that should work also outside E. I prefer the #1, put the config where everyone can look...what about the defaults.list file ? ;) (it's not yet a fdo standard, but it's a simple and clear way to store the info) I agree, we should follow the spec on this one as it will ease the burden on distributors who need to setup these types of options for all desktops. The proposed FDO specification needs some work, but hopefully becomes useful. We'll see :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Rage TODO items
On Mo, 2008-11-03 at 23:42 +1100, Carsten Haitzler wrote:
patches seem cool - i'll put them in svn. :) continue merrily with your work!
:)
Thanks a lot!
I have extended the settings patch to use a eet-configfile now.
Also I have fixed a warning about evas_smart_new being deprecated by
replacing it with evas_smart_class_new as suggested in the warning.
Both patches apply cleanly here at revision 37444, compile and run fine
(as far as I've tested).
Please tell me what you think.
diff --git a/src/bin/Makefile.am b/src/bin/Makefile.am
index d72c001..88793d4 100644
--- a/src/bin/Makefile.am
+++ b/src/bin/Makefile.am
@@ -35,7 +35,9 @@ e_table.h \
e_layout.c \
e_layout.h \
e_flowlayout.c \
-e_flowlayout.h
+e_flowlayout.h \
+conf_options.c \
+conf_options.h
rage_LDADD = @my_libs@ @EVAS_LIBS@ @ECORE_LIBS@ @EDJE_LIBS@ @EMOTION_LIBS@
diff --git a/src/bin/conf_options.c b/src/bin/conf_options.c
new file mode 100644
index 000..3161b8f
--- /dev/null
+++ b/src/bin/conf_options.c
@@ -0,0 +1,90 @@
+#include conf_options.h
+#include main.h
+
+void
+config_option_fullscreen(void *data)
+{
+ Ecore_Evas *ee = (Ecore_Evas *)data;
+ int *i = malloc(sizeof(int));
+
+ if (ecore_evas_fullscreen_get(ee))
+ {
+ i[0] = 0;
+ ecore_evas_fullscreen_set(ee, 0);
+ ecore_evas_cursor_set(ee, NULL, 0, 0, 0);
+ eet_write(eet_config, /config/fullscreen, i, sizeof(int), 0);
+ }
+ else
+ {
+ i[0] = 1;
+ ecore_evas_fullscreen_set(ee, 1);
+ ecore_evas_cursor_set(ee, , 999, 0, 0);
+ eet_write(eet_config, /config/fullscreen, i, sizeof(int), 0);
+ }
+}
+
+void
+config_option_themes(void *data)
+{
+}
+
+void
+config_option_modes_switch(void* data)
+{
+ int mode = (int)data;
+ eet_write(eet_config, /config/mode, mode, sizeof(int), 0);
+ main_reset();
+}
+
+void
+config_option_modes(void *data)
+{
+ menu_push(menu, Modes, NULL, NULL);
+ if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_SOFTWARE_X11))
+ menu_item_add(icon/x11, Software,
+ NULL, NULL, config_option_modes_switch,
+ (void*)0, NULL, NULL, NULL);
+ if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_OPENGL_X11))
+ menu_item_add(icon/mesa, Mesa OpenGL,
+ NULL, NULL, config_option_modes_switch,
+ (void*)1, NULL, NULL, NULL);
+ if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_SOFTWARE_FB))
+ menu_item_add(icon/fb, Software Framebuffer,
+ NULL, NULL, config_option_modes_switch,
+ (void*)2, NULL, NULL, NULL);
+ if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_XRENDER_X11))
+ menu_item_add(icon/xr, XRender Extension,
+ NULL, NULL, config_option_modes_switch,
+ (void*)3, NULL, NULL, NULL);
+ if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_DIRECTFB))
+ menu_item_add(icon/dfb, DirectFB,
+ NULL, NULL, config_option_modes_switch,
+ (void*)4, NULL, NULL, NULL);
+ if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_SDL))
+ menu_item_add(icon/sdl, SDL Engine,
+ NULL, NULL, config_option_modes_switch,
+ (void*)5, NULL, NULL, NULL);
+ /* WINDOWS ENGINES - maybe later
+ if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_SOFTWARE_DDRAW))
+ menu_item_add(icon/x11, Software,
+ NULL, NULL, config_option_modes_switch,
+ 6, NULL, NULL, NULL);
+ if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_DIRECT3D))
+ menu_item_add(icon/x11, Direct3D,
+ NULL, NULL, config_option_modes_switch,
+ 7, NULL, NULL, NULL);
+ if (ecore_evas_engine_type_supported_get(ECORE_EVAS_ENGINE_SOFTWARE_16_WINCE))
+ menu_item_add(icon/x11, Software,
+ NULL, NULL, config_option_modes_switch,
+ 7, NULL, NULL, NULL);
+ */
+
+ menu_go();
+ menu_item_select(Software);
+}
+
+void
+config_option_volumes(void *data)
+{
+}
+
diff --git a/src/bin/conf_options.h b/src/bin/conf_options.h
new file mode 100644
index 000..f991fae
--- /dev/null
+++ b/src/bin/conf_options.h
@@ -0,0 +1,10 @@
+#ifndef conf_options_h
+#define conf_options_h
+
+void config_option_fullscreen(void *data);
+void config_option_themes(void *data);
+void config_option_modes(void *data);
+void config_option_volumes(void *data);
+
+#endif
+
diff --git a/src/bin/main.c b/src/bin/main.c
index c366a4f..3a8d9bb 100644
--- a/src/bin/main.c
+++ b/src/bin/main.c
@@ -10,6 +10,7 @@ struct _Mode
Evas*evas = NULL;
char*theme = NULL;
char*config = NULL;
+Eet_File*eet_config = NULL;
Ecore_Timer* mouse_timeout = NULL;
static double start_time = 0.0;
@@ -35,13 +36,14 @@ static void main_menu_audio(void *data);
static void main_menu_photo(void *data);
static void main_menu_scan(void *data);
static void main_menu_tv(void *data);
+static void main_get_config(void);
int
main(int argc, char **argv)
{
Evas_Object *o;
- int mode = 0, fullscreen = 0;
- int i;
+ int fullscreen, mode;
+ int i, size;
Re: [E-devel] E moudule API BREAK proposal
- Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] ha scritto:
On Sat, 11 Oct 2008 20:48:04 +0200 (CEST) Dave Andreoli
[EMAIL PROTECTED] babbled:
Hi all,
I want to make an e17 module that expose simple edje objects as
gadgets.
The idea is that people can download edje file from the
net(calculator,
clocks and whatever next), put it in the right directory and then my
module
can expose this objects as they was gadgets (they must appear in the
available
gadgets list of the shelf or the gadman). So that the user can use
the object
where they want.
This can be a really easy way to create and distribute simple
gadgets as you
don't have to compile the edje object for different arch (thinking
about
exchange can also host gadgets, without platform problem!).
In the future my module can also make some advanced stuff, for
example execute
a bash, python (or what you like) script that is contained in the
edje file,
making the simple gadgets more functional... but this is another
story...
This was the good part of the post, now comes the bad :(
I can't find a way to do this module without changing the E GADCON
API.
From the module I create an E_Gadcon_Client_Class for each 'simple
widget'
found in the right directory, and I call
e_gadcon_provider_register()
as many times as needed. But then when E ask me for the label, the
icon and
the id I can't know for witch 'simple widget' he need the
information.
This is how it is done now:
struct _E_Gadcon_Client_Class
{
int version;
const char *name;
struct
{
E_Gadcon_Client *(*init) (E_Gadcon *gc, const char
*name, const
char *id, const char *style); void (*shutdown)
(E_Gadcon_Client
*gcc); void (*orient) (E_Gadcon_Client *gcc);
char *(*label) (void);
Evas_Object *(*icon) (Evas *evas);
const char *(*id_new) (void);
void (*id_del) (const char *id);
} func;
char *default_style;
};
As you can see the function label(void) don't have params and my
module
is lost on this (for witch widget you want the label??). The same
apply
to the icon and id_new functions.
So this is my proposed API
struct _E_Gadcon_Client_Class
{
int version;
const char *name;
struct
{
E_Gadcon_Client *(*init) (E_Gadcon *gc, const char
*name, const
char *id, const char *style); void (*shutdown)
(E_Gadcon_Client
*gcc); void (*orient) (E_Gadcon_Client *gcc);
char *(*label) (E_Gadcon_Client_Class
*class);
Evas_Object *(*icon) (Evas *evas,
E_Gadcon_Client_Class
*class); const char *(*id_new) (E_Gadcon_Client_Class
*class);
void (*id_del) (const char *id);
} func;
char *default_style;
};
I simple add the E_Gadcon_Client_Class *class params to some
functions.
ok one thng. for consistency make E_Gadcon_Client_Class the first
param for icon
() and also for id_del() even if we don't use it - at least it's
consistent :)
Ok and I will also add the param orientation to the function orient().
So we also can orient gadgets on the desktop :)
Dave
I think that this kind of functionality (a single module that expose
more
than one gadgets) could be useful in future, for example we can
then make a
module that handle gadgets from different source (think of
google_gadgets,
OSX dashbord widget...and so on) like KDE4 seems to do. WE then
access a
really HUGE set of just done gadgets :)
What do you think about all this? It make sense?
maybe someone know how to do this without the break?
Hope you like my idea, and also hope that this mail is clear
enough...
as always my English is not so good ;)
hmm - it makes sense. i guess if we break - break before e17 is
released. so
lets do it. i'm in. do your stuff! :)
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK win
great prizes
Grand prize is a trip for two to an Open Source event anywhere in
the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
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]
[E-devel] Python Binding Broken?
The python bindings are broken ? I'm trying to compile the python binding for evas from trunk, but I get this error: building 'evas.c_evas' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/local/include/eina-0 -I/usr/local/include/eina-0/eina -Iinclude -I/usr/include/python2.5 -c evas/evas.c_evas.c -o build/temp.linux-i686-2.5/evas/evas.c_evas.o gcc: evas/evas.c_evas.c: No such file or directory gcc: no input files error: command 'gcc' failed with exit status 1 I already tried to use the python bindings of PyPi, they compile but doen't work, I get this error: File /usr/lib/python2.5/site-packages/python_ecore-0.3.0-py2.5-linux-i686.egg/ecore/evas/__init__.py, line 20, in module import c_ecore_evas File c_evas.pxd, line 585, in ecore.evas.c_ecore_evas (ecore/evas/ecore.evas.c_ecore_evas.c:17576) File /usr/lib/python2.5/site-packages/python_evas-0.3.0-py2.5-linux-i686.egg/evas/__init__.py, line 20, in module import c_evas ImportError: /usr/lib/python2.5/site-packages/python_evas-0.3.0-py2.5-linux-i686.egg/evas/c_evas.so: undefined symbol: evas_list_free Any help would be appreciated. Regards, - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eet wrapper
Ok andreas,
I will do it with a pair of pair ... but I found the syntax very
heavier than with boost::tuple.
Take a look at the example in attached file, this is the approach I
will take to replace the boost::tuple.
And this approach is not very usable if we have to extend the tuple.
Regards,
jonathan Muller.
On Mon, Nov 3, 2008 at 8:02 PM, Andreas Volz [EMAIL PROTECTED] wrote:
Am Mon, 3 Nov 2008 09:56:45 +0100 schrieb Jonathan MULLER:
Hello Jonathan,
would be nice if you do that. And best provide a path to integrate it
into eflpp.
BTW: Seems you're not a member of
enlightenment-devel@lists.sourceforge.net list. You should join the
list if you like to post anything
regards
Andreas
Hi Andreas,
I understand those problematics of course.
The dependency is on tuple classe with 3 elements ... we could in a
first time considering a std::pair of std::pair
boost::tuple Ty, int, bool ~ std::pair std::pair Ty, int ,
bool
It will be a bit more heavy for the user ... but I can have a look to
develop this.
I have to say adding a dependncy on boost would be a great idea.
Regards,
Jonathan Muller.
On Sun, Nov 2, 2008 at 12:03 PM, Andreas Volz
[EMAIL PROTECTED] wrote:
Am Sat, 1 Nov 2008 21:14:57 +0100 schrieb Jonathan MULLER:
Hello Jonathan,
I reviewed the source code short and this it looks good. But
there's a little problem. Until now the eflpp library hasn't any
boost dependency.
Using your eet wrapper would create a dependency to boost for all
applications based on eflpp. For me personal this isn't a big
problem as my main application is yet based on boost for some other
reasons.
The positive would be that it allows to replace some other stuff in
eflpp with boost code. But as this is a design decision I'm not sure
about it. At least I like to discuss that topic on the list. I added
the list to Cc.
Meanwhile you could think about if it's not possible to rewrite your
wrapper with STL classes.
Any other opinions from the list?
regards
Andreas
BTW: I didn't attach the source code to this E-Mail. You've to ask
Jonathan about it.
Hi Andreas,
You will find in as attached file the wrapper.
execute
make to build the 2 executables
and make test to run first the writing test and the the readin
test. And take a look at the code ;)
I am waiting for your feedbacks.
I do not have rights to commit in the SVN tree that's why I send
you this first approach.
Note : you have to have the boost tuple library.
Regards,
John aka Bhaal22.
On Fri, Oct 31, 2008 at 9:09 PM, Andreas Volz
[EMAIL PROTECTED] wrote:
Am Mon, 27 Oct 2008 16:01:30 +0200 schrieb Jonathan MULLER:
Hello Jonathan,
I'm interested in your wrapper. Do you've a patch based on
existing eflpp code base? It should fit into the eflpp design.
regards
Andreas
Hi Andreas,
I wrote a little C++ wrapper around Eet library compliant with
STL. I can use STL algorithm to iterate over keys, entries ...
I wrote some operators to access items in a user friendly way.
I can show you if you want.
Regards,
Jonathan Muller.
--
Drylm Founder
http://www.drylm.org
--
Technical Blog http://andreasvolz.wordpress.com/
--
Drylm Founder
http://www.drylm.org
--
Technical Blog http://andreasvolz.wordpress.com/
--
Drylm Founder
http://www.drylm.org
--
Drylm Founder
http://www.drylm.org
#include utility
#include iostream
template typename _Ty
struct A
{
typedef std::pair_Ty, int type;
};
template typename _Ty
struct B
{
typedef typename A_Ty::type internal_type;
typedef std::pair internal_type, bool type;
};
template typename _Ty
typename A_Ty::type make_a (_Ty ty, int i)
{
//typename A_Ty::type f (ty, i);
return typename A_Ty::type (ty, i);;
}
template typename _Ty
typename B_Ty::type
make_b (_Ty ty, int i, bool b)
{
return typename B_Ty::type ( make_a(ty, i), b);
}
int main (int argc, char **argv)
{
Aint::type x = make_a (12, 12);
Bint::type b;
b.first = std::make_pair (12, 13);
b.second = false;
Bint::type b2 = make_b(12, 13, false);
Bint::type b3 = make_b(25, 15, true);
std::cout x.first x.second std::endl;
std::cout b2.first.first b2.first.second b2.second std::endl;
std::cout b3.first.first b3.first.second b3.second std::endl;
return 0;
}
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
Re: [E-devel] FOSDEM 2009
Hi guys! fosdem.org says: FOSDEM will *NOT take place on 21st and 22nd February 2009*. Do you know anything about this? It would be bad if they modified the date since I've already bought my plane tickets... Minden jót, Sevcsik András On Thu, Oct 23, 2008 at 8:49 PM, Vincent Torri [EMAIL PROTECTED] wrote: My holiday just started, so I can get to coding now. Great ! I've also described what to do for a symbian port of evas. Are you still motivated ? We can discuss about that when you have some time, if you want. The main priority is on eyesight now (because of FOSDEM), but i'm still motivated. I haven't had time to get familiar with the symbian sdk yet. Ok. You're right, priority to eyesight. So first, i think that you should fix the events. There are some garbage in the code right now. And what's up with you? I'm pushing in the Windows CE direction, to obtain native code. The main part of the work is already done. It's more tweaking than really big code. But that OS is an horror. Evil, Eina, Eet, Evas and Embryo are compiling. It remains one problem in e, though. Next will be Ecore. Edje should be easy. Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Python Binding Broken?
On Mon, Nov 3, 2008 at 6:17 PM, Daniel Martins [EMAIL PROTECTED] wrote: The python bindings are broken ? I'm trying to compile the python binding for evas from trunk, but I get this error: building 'evas.c_evas' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/local/include/eina-0 -I/usr/local/include/eina-0/eina -Iinclude -I/usr/include/python2.5 -c evas/evas.c_evas.c -o build/temp.linux-i686-2.5/evas/evas.c_evas.o gcc: evas/evas.c_evas.c: No such file or directory gcc: no input files error: command 'gcc' failed with exit status 1 you need both Cython AND Pyrex, that's due python setuptools assuming pyrex is installed to be able to compile .pyx into .c, even if we use Cython to do the proper work. I already tried to use the python bindings of PyPi, they compile but doen't work, I get this error: File /usr/lib/python2.5/site-packages/python_ecore-0.3.0-py2.5-linux-i686.egg/ecore/evas/__init__.py, line 20, in module import c_ecore_evas File c_evas.pxd, line 585, in ecore.evas.c_ecore_evas (ecore/evas/ecore.evas.c_ecore_evas.c:17576) File /usr/lib/python2.5/site-packages/python_evas-0.3.0-py2.5-linux-i686.egg/evas/__init__.py, line 20, in module import c_evas ImportError: /usr/lib/python2.5/site-packages/python_evas-0.3.0-py2.5-linux-i686.egg/evas/c_evas.so: undefined symbol: evas_list_free Any help would be appreciated. PyPI is too old for current SVN, we moved from evas_list to eina_list, you need python-efl from svn as well. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] UDP client/server support
On Sun, Nov 2, 2008 at 11:53 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Sat, 4 Oct 2008 23:27:33 -0400 Matt Barclay [EMAIL PROTECTED] babbled: hmm - you know what might have been cleaner... on data in get a CLIENT_ADD event and literally add a client then instantly post data from that client in a CLIENT_DATA and then a CLIENT_DEL immediately after. it sounds a big heavy BUT... it's clean. 1. it looks just like tcp/unix socket connections except the connection is only alive for 1 packet (lump of data). 2. it solves your ability to preserve client info and all calls works just as if it were tcp or unix socket. you know just where to send the data back to as u have a client handle. :) 3. it's clean what do you think? I like it, thanks for the feedback! I'm traveling early this week, but I will have a look on Wednesday. I'll keep an eye on the list in case someone beats me to it. Regards, Matt Hello, With this patch, ecore will have full UDP client/server support. Tooling UDP into the framework wasn't the easiest thing in the world because a UDP server has a single socket (i.e. file handle) that is used to handle all clients, whereas a TCP server generates a new socket for each client that encapsulates all the details of the connection. So here's how I implemented it: UDP Server (Unicast and Multicast): 1. When there is data on the socket, the callback uses recvfrom() to read the datagram and client address (struct sockaddr_in) 2. Create a new Ecore_Con_Client and save the client address (sockaddr_in) details with the data field. Leave the fd, buf, and fd_handler fields NULL. 3. Create a new Ecore_Con_Event_Client_Data and save the datagram in the data field, and the client in the client field 4. ecore_con_client_send() is updated to check for a client-server-type of ECORE_CON_REMOTE_UDP and use sendto() with client-data as the destination instead of appending the buffer to client-buf 5. relevant portions of ecore_con_client_del() and _ecore_con_event_client_data_free() are updated to ensure the client and data memory are freed The use of recvfrom() and sendto() feels a little dirty to me, but I'm not sure how else to preserve the client address so that packets can be sent back to the client. AFAIK, there isn't any way to do an accept() on a UDP socket such that a new file handle is created that encapsulates the end points of the UDP socket. Would appreciate some enlightenment on this topic if I'm wrong. ;) UDP Client support fits nicely into the framework as a new socket is created each time ecore_con_server_connect() is called. A UDP Server example program is included with the patch, and examples of multicast and UDP client support can be found in SVN: TEST/orig/ecore/ Regards, Matt -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas fill-transform patch
On Tue, 07 Oct 2008 19:05:16 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled: ok. in svn. just a summer (as in my svn log): 1. nearest scaling is now broken - it's always linear interpolation. this will lead to slowdowns. i need to fix this - a must. 2. i think it's time i put in a transformed image cache that can cache an image object at a transform (and share it) automatically. 3. transforms in non-software-engines will not work - broken. need to at least do xrender and gl engines. any volunteers to help? thanks jose! :) Attached is a patch to add support for fill transforms to evas image objects (plus new modifications to grad2s and some other minor things). Let me note a few aspects of this, since it it a rather 'big' change in some ways for evas internals. First of all, ALL engines but the software based ones are broken by this patch. It should be very easy to bring them all to doing what they did before, but it would be much better for the various engineers to take this opportunity (as with grda2) to enable this new capability for their engine of choice (I've only mofified the relevant engine funcs for the gl-x11 and xrender-x11 engines to build correctly, but they don't draw anything). The semantics of the fill-transform for images is simple: It should be equivalent to first scaling the image to the given fill size (preserving borders as need be), and then apply the (inverse) transform to that, with the fill x,y being an initial translation. Note that only affine transforms need be supported, and that the origin is to be taken relative to the image object's top-left. See raster, cedric, jorge, and gustavo for examples on how to use this.. :) The performance will vary somewhat here and there, but should be roughly the same as before when restricted to un-transformed images.. The one exception to that being the case of when the 'not-smooth-scale' property is set, since for now the patch always does a certain amount of smoothness, with the 'smooth-scale' now referring to whether or not to to a full sampling of the source when down-scaling. In a few days I'll add support for non-smooth scaling/transforming, but it will be controlled via the general object 'anti-alias' property -- ie. if one sets the image object to not anti-aliased, then all scaling/transforming will be non-smooth, regardless of any separate setting on 'smooth-scale'. This may seen a more complex setup, but it actually gives somewhat greater flexibility as regular 'smooth' (with aa on) is often a good substitute for fully sampled downscaling but considerably faster. The attached patch itself contains a diff against current svn evas, plus additional files that need to be added to the evas 'canvas' and 'common' src dirs. Good luck.. :) Click to book your dream cruise. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nL6YNozEjo63hzckCPak13wUAemocABJ5VZntA2XthxICVq/ -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efreet mime default application patch
On Mon, 3 Nov 2008 14:39:05 +0100 (CET) Dave Andreoli [EMAIL PROTECTED] babbled: 1. config everyone cal look at OR 2. opening service. e.g. a dbus call- u send an array (list) of file paths and say open them please - e will open them for you. this way you also recycle the exec method and child process tracking etc. if the target file is a directory - it opens a directory window, etc. is #2 perhaps not better? The #2 is powerfull but will work only if E is running, and this is bad for applications, that should work also outside E. I prefer the #1, put the config where everyone can look...what about the defaults.list file ? ;) (it's not yet a fdo standard, but it's a simple and clear way to store the info) technically - any app/desktop/wm could provide the same dbus service... a stand-alone app could too. the problem with #1 is that if e decides to change config, format, versioning, keys, break it etc. every app is stuck catching up. putting it into a lib and formalising it sets the config in stone as u cant go change it as u are going to break format/api. a very limited config is possible, but i think it's a bit premature to go formalising this - for e it is i think. also this means the config now can't use e's normal config schemes. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] UDP client/server support
On Mon, 3 Nov 2008 14:36:15 -0800 Matt Barclay [EMAIL PROTECTED] babbled: On Sun, Nov 2, 2008 at 11:53 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Sat, 4 Oct 2008 23:27:33 -0400 Matt Barclay [EMAIL PROTECTED] babbled: hmm - you know what might have been cleaner... on data in get a CLIENT_ADD event and literally add a client then instantly post data from that client in a CLIENT_DATA and then a CLIENT_DEL immediately after. it sounds a big heavy BUT... it's clean. 1. it looks just like tcp/unix socket connections except the connection is only alive for 1 packet (lump of data). 2. it solves your ability to preserve client info and all calls works just as if it were tcp or unix socket. you know just where to send the data back to as u have a client handle. :) 3. it's clean what do you think? I like it, thanks for the feedback! I'm traveling early this week, but I will have a look on Wednesday. I'll keep an eye on the list in case someone beats me to it. :) i'm slow on catching up with my email backlog - but i've now done it - i'm going to be busy cleaning up the aftermath of transforms :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 dbus support
On Mon, 3 Nov 2008 09:59:46 +0100 Luca De Marini [EMAIL PROTECTED] babbled: 2008/11/3 The Rasterman Carsten Haitzler [EMAIL PROTECTED] On Sat, 27 Sep 2008 11:37:34 +0200 Albin Tonnerre [EMAIL PROTECTED] babbled: the real problem is the enlightenment.desktop file - the way we ship it it JUST runs enlightenment_start. enlightenment_start (its a front-end binary to launch the real e that doesnt have library dependencies etc.) probably should be in charge of doing this. the problem is dbus-launch may not be installed, so i'd say what we need are patches to enlightenment_start to launch e itself with dbus-launch if it exists or just e raw (like now) if it doesn't :) Uhm, yes, I really believe it would be great to have it. Completely agree :) i just added it :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] EET crypto
On Mon, 3 Nov 2008 11:03:38 +0100 Cedric BAIL [EMAIL PROTECTED] babbled: maybe you want to postpone this until all the eina stuff is done? I need crypto support soon, so I will provide a patch that doesn't break API. Before breaking eet API, I agree that we should first finish this move to eina, currently postponed for around 2 weeks as I have some deadline. But I have a little bad news, we will need more than just breaking eet API. There are currently 2 bugs regarding eet dump/undump function, one that I almost know how to solve and another one that I don't understand yet what is going on. The first one is just the dump/undump part of list/array/hash of strings bug. The problem is in that case that we loose the information in the eet data that the chunk is an item part of a list/array/hash and not only a string. Solving it is easy... we just need to change eet data format so we always store simple type and the group type. I think we can make it backward compatible, by just handling both current and new format with a new magic string. I have just starting to work on a fix, but it's not high enough on my TODO list at the moment. So don't expect complete fix before a few weeks. The second bug is due to undumping struct of struct which doesn't result in the same eet data as the dumped one. My guess is that this bug is related to EET_G_UNKNOWN case in _eet_data_dump_encode. But I wasn't able to find a fix nor really understand what is going on in that case. So eet TODO list is quite nice at the moment and need a little bit of work before any major release :-) well.. looks like we have a small reprieve then :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Rage TODO items
On Mon, 03 Nov 2008 21:06:51 +0100 Tim Felgentreff [EMAIL PROTECTED] babbled: I have extended the settings patch to use a eet-configfile now. Also I have fixed a warning about evas_smart_new being deprecated by replacing it with evas_smart_class_new as suggested in the warning. Both patches apply cleanly here at revision 37444, compile and run fine (as far as I've tested). Please tell me what you think. in svn :):):) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is there any efl object instead of gtk.drawingarea ?
On Mon, 3 Nov 2008 16:20:23 +0100 thomasg [EMAIL PROTECTED] babbled: Because of that and many many other reasons it would be really cool, to have a mplayer backend for emotion. :) that is impossible as mplayer has no interface to provide yuv data to a caller. thus no backend exists. until mplayer has such a facility (out of the box - without patching mplayer) an emotion engine can never exist. emotion is not the most efficient video player - in software rendering it does software yuv-rgb(32) conversion then scales in rgba space. the performance is actually quite astounding considering how much it actually does going the long way. if you use the gl engine its the same efficiency as mplayer/xine with xv. the yuv-rgb + scaling is done in hardware (with a fragment shader) and the upload to video mem is the same path as xv pretty much, so you'll see the same cpu overhead there with full emotion + scaleable/fadable/layerable objects and just regular boring xv. But I know, it's really tricky to find a good solution, because mplayer isn't meant to be just a backend. On 11/3/08, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: On Mon, Nov 3, 2008 at 11:44 AM, Dave Andreoli [EMAIL PROTECTED] wrote: - Nicolas Aguirre [EMAIL PROTECTED] ha scritto: 2008/11/3 Gustavo Sverzut Barbieri [EMAIL PROTECTED]: Gstreamer just sucks to play video on nokia devices, and doing extra copies or transformation from YUV to RGB is no-go on those hardwares. That's why canola uses atakabe to play media, it will handle mplayer, gstreamer... mplayer is optimized and outputs YUV at half resolution using double-pixel directly to framebuffer (in fullscreen mode). While in windowed mode, Canola just use ecore_x to reparent MPlayer's window to the required position (it's a black rectangle in the theme). Exactly what I do with libplayer/mplayer in Enna :) But in this way you can't have evas objects on top of the mplayer window... yes, that's the problem with such approach, but on that platform it's the only option, really, you don't have much cpu power. What about the vlc backend? It seem the better way for me as, for what I have understand, vlc doesn't use gstreamer. Someone have tryed it? it's totally buggy, needs fixing. AFAIR it calls back from thread, which is not allowed in EFL, but people spotted different problems as well. Also, vlc is not an option on that platform, gstreamer is the official media player and uses dsp for audio decoding, but mplayer is was optimized by a guy and is the best, it does this framebuffer tricky and also have an ARM JIT compiler for scale. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ 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 the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] FOSDEM 2009
On Mon, 3 Nov 2008 22:58:17 +0100 Sevcsik András [EMAIL PROTECTED] babbled: Hi guys! fosdem.org says: FOSDEM will *NOT take place on 21st and 22nd February 2009*. Do you know anything about this? It would be bad if they modified the date since I've already bought my plane tickets... looks like you are in trouble and may need to look to refund your tickets or possibly reschedule. looks like fosdem is having trouble getting off the ground for 2009. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas fill-transform patch
On Tue, 4 Nov 2008, Carsten Haitzler (The Rasterman) wrote: On Tue, 07 Oct 2008 19:05:16 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled: ok. in svn. just a summer (as in my svn log): 1. nearest scaling is now broken - it's always linear interpolation. this will lead to slowdowns. i need to fix this - a must. 2. i think it's time i put in a transformed image cache that can cache an image object at a transform (and share it) automatically. 3. transforms in non-software-engines will not work - broken. need to at least do xrender and gl engines. any volunteers to help? I'll try to make my student wrk on the direct3d engine, if he can fix it. Otherwise, I think i will have to do it. Vincent - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas fill-transform patch
On Tue, 4 Nov 2008 01:24:43 +0100 (CET) Vincent Torri [EMAIL PROTECTED] babbled: On Tue, 4 Nov 2008, Carsten Haitzler (The Rasterman) wrote: On Tue, 07 Oct 2008 19:05:16 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled: ok. in svn. just a summer (as in my svn log): 1. nearest scaling is now broken - it's always linear interpolation. this will lead to slowdowns. i need to fix this - a must. 2. i think it's time i put in a transformed image cache that can cache an image object at a transform (and share it) automatically. 3. transforms in non-software-engines will not work - broken. need to at least do xrender and gl engines. any volunteers to help? I'll try to make my student wrk on the direct3d engine, if he can fix it. Otherwise, I think i will have to do it. cool. first i'm going to fix nearest (non-smooth) scaling in software so its back to fast then look at xrender and gl - not in that order - not sure which to do first. maybe xrender :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efreet mime default application patch
On Tue, 4 Nov 2008 11:01:10 +1100 Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: On Mon, 3 Nov 2008 14:39:05 +0100 (CET) Dave Andreoli [EMAIL PROTECTED] babbled: 1. config everyone cal look at OR 2. opening service. e.g. a dbus call- u send an array (list) of file paths and say open them please - e will open them for you. this way you also recycle the exec method and child process tracking etc. if the target file is a directory - it opens a directory window, etc. is #2 perhaps not better? The #2 is powerfull but will work only if E is running, and this is bad for applications, that should work also outside E. I prefer the #1, put the config where everyone can look...what about the defaults.list file ? ;) (it's not yet a fdo standard, but it's a simple and clear way to store the info) technically - any app/desktop/wm could provide the same dbus service... a stand-alone app could too. the problem with #1 is that if e decides to change config, format, versioning, keys, break it etc. every app is stuck catching up. putting it into a lib and formalising it sets the config in stone as u cant go change it as u are going to break format/api. a very limited config is possible, but i think it's a bit premature to go formalising this - for e it is i think. also this means the config now can't use e's normal config schemes. I agree here, thus why I didn't bother applying this patch yet. I want to make sure there is a specification set before we do anything. They may end up using dbus or they may keep it simple. I really think dbus is complete overkill for matching mimetypes to applications though. No need to have a daemon running that is going to sit idle 99.9% of the time. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Gadcon V3 *BREAK*
Ok, I have committed the gadcon_client_class V3.
ALL THE MODULES around need to be patched (just add
the new params).
I have updated all the internal modules and I will do
all the EXTRA modules shortly. All the modules outside
need to be fixed.
Sorry for the inconvenience.
Dave
This is the new class:
#define GADCON_CLIENT_CLASS_VERSION 3
/* Version 3 add the *client_class param to icon(),label(),id_new(), id_del() */
/* and the *orient param to orient() */
struct _E_Gadcon_Client_Class
{
int version;
/* All members below are part of version 1 */
const char *name;
struct
{
E_Gadcon_Client *(*init) (E_Gadcon *gc, const char *name, const
char *id, const char *style);
void (*shutdown) (E_Gadcon_Client *gcc);
void (*orient) (E_Gadcon_Client *gcc, E_Gadcon_Orient
orient);
char*(*label)(E_Gadcon_Client_Class *client_class);
Evas_Object *(*icon) (E_Gadcon_Client_Class *client_class, Evas
*evas);
/* All members below are part of version 2 */
/* Create new id, so that the gadcon client can refer to a config set
inside the module */
const char *(*id_new) (E_Gadcon_Client_Class *client_class);
/* Del an id when a gadcon client is removed from the system */
void (*id_del) (E_Gadcon_Client_Class *client_class,
const char *id);
/* All members below are part of version 3 */
} func;
char *default_style;
};
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fw: Re: Copyleft-style
Was this exception ever decided? On Thu, Oct 16, 2008 at 5:46 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: (forgot AUTHORS in cc list) PLEASE REPLY (authors on CC list). yes or no to adding static linking exception below? On Fri, 17 Oct 2008 00:53:29 +0200 Michael Feiri [EMAIL PROTECTED] babbled: this got debated to hell. the alternative was going to be watching developers leave - ones wanting to add in better code but only wanting to do so if they know their code will be free and improvements to it given back. if we added the static linking exception - which imho would not violate the spirit of the LGPL, would this be good enough? (nb - if apple decide to place all these nasty nasty nasty restrictions on developers and applications - all the best to them, but i know i have zero interest in becoming part of that world as long as apple basically say you do just what we say, what we want, and if we don't like you we'll just ban your app from the platform because you may possibly compete with us or be the wrong shade of pink for steve jobs). i definitely buy the ecos (static linking) argument. i've explicitly cc'd all the AUTHORS for eina. do you guys agree to adding an ecos-style static linking exception (here it is for you guys): ...As a special exception, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other works to produce a work based on this file, this file does not by itself cause the resulting work to be covered by the GNU General Public License. However the source code for this file must still be made available in accordance with section (3) of the GNU General Public License. This exception does not invalidate any other reasons why a work based on this file might be covered by the GNU General Public License On monday, starting with revision 36622, all vital EFL components have been configured to depend on copylefted code (eina is licensed under LGPLv2.1). This is unfortunate, as it renders the existing BSD-style license agreement essentially worthless. It is especially unfortunate as the EFL seems to be unique as the only successful GUI environment under a BSD-style license. I have used Evas as a component in a proof-of-concept for an embedded project using the eCos operating system. No patches or other information have been published yet, because the project is not yet released. But I do expect to have patches for EFL ready upon release in order to avoid the advertisement clause. Now, eCos is owned by the FSF and is licensed under the GPLv2 with a linking exception that makes it completely non-viral. This exception is more powerful than the LGPL, because the LGPL does require dynamic linking or the distribution of linkable object files and additional modification and reverse engineering rights. These obligations would infect a project that would otherwise just use a non-viral GPLv2 with linker exception. So I want to ask you to please consider keeping the core EFL components and non-optional dependencies under the existing BSD-style license or consider a non-viral copyleft like the GPLv2 with a linking exception in oder to keep the EFL usable with eCos and similar free embedded operating systems (FreeRTOS and RTEMS both use GPLv2 with linking exceptions too). Dynamic linking is not an option for deeply embedded operating systems. Often we dont even have a filesystem. Additionally I might mention that the BSD-style license of the EFL could mean that the EFL might technically be the only serious option for a free 3rd party GUI library on things like the iPhone. Dynamic linking does seem to exist on this platform but things like forced codesigning, bans on externally loadable code, and restrictions on reverse engineering and modification rights make the use of copylefted code questionable at best. MfG, Michael - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ 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 the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world
Re: [E-devel] Fw: Re: Copyleft-style
On Mon, 3 Nov 2008 22:36:06 -0600 Nathan Ingersoll [EMAIL PROTECTED] babbled: i'm still waiting on any replies/comments. imho it makes sense. it doesnt violate the spirit. it simple defines an exception where building a statically compiled os image for things like ecos, the same rules as dynamic linking apply. Was this exception ever decided? On Thu, Oct 16, 2008 at 5:46 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: (forgot AUTHORS in cc list) PLEASE REPLY (authors on CC list). yes or no to adding static linking exception below? On Fri, 17 Oct 2008 00:53:29 +0200 Michael Feiri [EMAIL PROTECTED] babbled: this got debated to hell. the alternative was going to be watching developers leave - ones wanting to add in better code but only wanting to do so if they know their code will be free and improvements to it given back. if we added the static linking exception - which imho would not violate the spirit of the LGPL, would this be good enough? (nb - if apple decide to place all these nasty nasty nasty restrictions on developers and applications - all the best to them, but i know i have zero interest in becoming part of that world as long as apple basically say you do just what we say, what we want, and if we don't like you we'll just ban your app from the platform because you may possibly compete with us or be the wrong shade of pink for steve jobs). i definitely buy the ecos (static linking) argument. i've explicitly cc'd all the AUTHORS for eina. do you guys agree to adding an ecos-style static linking exception (here it is for you guys): ...As a special exception, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other works to produce a work based on this file, this file does not by itself cause the resulting work to be covered by the GNU General Public License. However the source code for this file must still be made available in accordance with section (3) of the GNU General Public License. This exception does not invalidate any other reasons why a work based on this file might be covered by the GNU General Public License On monday, starting with revision 36622, all vital EFL components have been configured to depend on copylefted code (eina is licensed under LGPLv2.1). This is unfortunate, as it renders the existing BSD-style license agreement essentially worthless. It is especially unfortunate as the EFL seems to be unique as the only successful GUI environment under a BSD-style license. I have used Evas as a component in a proof-of-concept for an embedded project using the eCos operating system. No patches or other information have been published yet, because the project is not yet released. But I do expect to have patches for EFL ready upon release in order to avoid the advertisement clause. Now, eCos is owned by the FSF and is licensed under the GPLv2 with a linking exception that makes it completely non-viral. This exception is more powerful than the LGPL, because the LGPL does require dynamic linking or the distribution of linkable object files and additional modification and reverse engineering rights. These obligations would infect a project that would otherwise just use a non-viral GPLv2 with linker exception. So I want to ask you to please consider keeping the core EFL components and non-optional dependencies under the existing BSD-style license or consider a non-viral copyleft like the GPLv2 with a linking exception in oder to keep the EFL usable with eCos and similar free embedded operating systems (FreeRTOS and RTEMS both use GPLv2 with linking exceptions too). Dynamic linking is not an option for deeply embedded operating systems. Often we dont even have a filesystem. Additionally I might mention that the BSD-style license of the EFL could mean that the EFL might technically be the only serious option for a free 3rd party GUI library on things like the iPhone. Dynamic linking does seem to exist on this platform but things like forced codesigning, bans on externally loadable code, and restrictions on reverse engineering and modification rights make the use of copylefted code questionable at best. MfG, Michael - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ 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
Re: [E-devel] Evas fill-transform patch
On Tue, 04 Nov 2008 01:42:30 -0500 Jose Gonzalez [EMAIL PROTECTED] babbled: Carsten Haitzler (The Rasterman) wrote: On Tue, 07 Oct 2008 19:05:16 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled: ok. in svn. just a summer (as in my svn log): 1. nearest scaling is now broken - it's always linear interpolation. this will lead to slowdowns. i need to fix this - a must. Yes, and as I mentioned in the original email, I have a subsequent patch to add the 'nearest' case. However, there (at least) two ways you could enable this. yup. i know. that's just a sore point for the software engines and performance. :) Given that you have the possibility to do: oh gee. i was just looking into making it work :) if you have a patch.. that saves me the effort :) 1. Nearest scaling/transforming, 2. Simple box filter sampling (with lin interp for both the scaling and transf). 3. Full src pixel sampling when fill scaling down, and box filter sampling for the transfs and up-scaling. This means that you could keep the current 'smooth-scaling' flag to enable 3, and default to 2, and further enable 1 via the genral object no-aa state. well as it was before u have only #1 or #3 to choose from. now we also have a #2. But you could also extend 'smooth-scaling' so it's not just a bool, and instead have it take three states, say: NONE, GOOD, and BEST. i'd rather extend smooth to be an enum with 0 == #1, 1 == #3 and 2 == #2, so EVAS_SMOOTH_NONE = 0 EVAS_SMOOTH_BEST = 1 EVAS_SMOOTH_GOOD = 2 this would remain compatible with everything we already have and just add the #2 as GOOD :) The former option would be fairly intuitive and leave the api as is, but would break the semantics (since no smooth-scaling means box-filter sampling not simple nearest sampling). The latter option breaks the api since you have to change smooth-scaling to no longer be a bool. this should be a trivial break - abi will break, api won't though really (a recompile will fix it) :). doing it the aa flag way means semantics break and someoen has to go adding code to get back nearest as it was - so it's going to be more work and really seems a bit evil to me as it splits the scaling algorithm used into 2 separate flags and the combination thereof defines the algorithm. Either way you prefer it'd be solved in evas, in things like edje you have a further option on ho to proceed, since there for example you could do the latter approach regardless of what's done in evas. i'd also take the latter approach. it's compatible and i can just make it an enum that accepts these: 0 (NEAREST) 1 (BEST) NEAREST (NEAREST) OFF (NEAREST) BEST (BEST) GOOD (GOOD) LINEAR (GOOD) etc. :) Your choice - I've already added the core stuff to evas, just decide how you prefer to control things... and note that it does give an extra degree of freedom for controlling things which can be useful in some cases. sure. i'd go using the smooth flag myself :) 2. i think it's time i put in a transformed image cache that can cache an image object at a transform (and share it) automatically. Something like that could be useful in various ways.. good luck. this also obviates the need for forcing scale on load to be the exact size as its taken care of generically :) 3. transforms in non-software-engines will not work - broken. need to at least do xrender and gl engines. any volunteers to help? That's right... It's trivial though to get things to just ignore transforms and do what they used to do. But to get the most of this, for both images and that'd be the first thing - just to make them work again - with no transforms. just for now. that's an immediate need. gradient2 - and mind you this is basically a start to what can fairly easily be added to allow for stroke/fill texturing of shapes, and for general object-level transforms -- to get the most of this, people would have to invest in supporting the various engines, xrender in particular is fairly easy, gl will likely need rtt (unless you're clever enough to find a way to use meshes for border related stuff). yeah. that'd be the next step - full support. The semantics is simple enough, as I mentioned in the original email. thanks jose! :) You're quite welcome, and I hope it will be useful to this project.. HOWEVER, you may want to REVERT this patch, and in fact all the earlier grad2 and transforms stuff. Regrettably, due to persistent issues that I find with this project, things like license issues, issues on the aims and progress of the project, and others, I no longer feel committed to continuing with this or even supporting it in the future, or other future work for this project in its current form. Again, I will send you that 'nearest' patch if you like, and I hope you can find the work useful to the project.. maybe Jorge, Cedric, Gustavo, and you and others will continue with it.. but
Re: [E-devel] Evas fill-transform patch
Carsten Haitzler (The Rasterman) wrote: On Tue, 07 Oct 2008 19:05:16 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled: ok. in svn. just a summer (as in my svn log): 1. nearest scaling is now broken - it's always linear interpolation. this will lead to slowdowns. i need to fix this - a must. Yes, and as I mentioned in the original email, I have a subsequent patch to add the 'nearest' case. However, there (at least) two ways you could enable this. Given that you have the possibility to do: 1. Nearest scaling/transforming, 2. Simple box filter sampling (with lin interp for both the scaling and transf). 3. Full src pixel sampling when fill scaling down, and box filter sampling for the transfs and up-scaling. This means that you could keep the current 'smooth-scaling' flag to enable 3, and default to 2, and further enable 1 via the genral object no-aa state. But you could also extend 'smooth-scaling' so it's not just a bool, and instead have it take three states, say: NONE, GOOD, and BEST. The former option would be fairly intuitive and leave the api as is, but would break the semantics (since no smooth-scaling means box-filter sampling not simple nearest sampling). The latter option breaks the api since you have to change smooth-scaling to no longer be a bool. Either way you prefer it'd be solved in evas, in things like edje you have a further option on ho to proceed, since there for example you could do the latter approach regardless of what's done in evas. Your choice - I've already added the core stuff to evas, just decide how you prefer to control things... and note that it does give an extra degree of freedom for controlling things which can be useful in some cases. 2. i think it's time i put in a transformed image cache that can cache an image object at a transform (and share it) automatically. Something like that could be useful in various ways.. good luck. 3. transforms in non-software-engines will not work - broken. need to at least do xrender and gl engines. any volunteers to help? That's right... It's trivial though to get things to just ignore transforms and do what they used to do. But to get the most of this, for both images and gradient2 - and mind you this is basically a start to what can fairly easily be added to allow for stroke/fill texturing of shapes, and for general object-level transforms -- to get the most of this, people would have to invest in supporting the various engines, xrender in particular is fairly easy, gl will likely need rtt (unless you're clever enough to find a way to use meshes for border related stuff). The semantics is simple enough, as I mentioned in the original email. thanks jose! :) You're quite welcome, and I hope it will be useful to this project.. HOWEVER, you may want to REVERT this patch, and in fact all the earlier grad2 and transforms stuff. Regrettably, due to persistent issues that I find with this project, things like license issues, issues on the aims and progress of the project, and others, I no longer feel committed to continuing with this or even supporting it in the future, or other future work for this project in its current form. Again, I will send you that 'nearest' patch if you like, and I hope you can find the work useful to the project.. maybe Jorge, Cedric, Gustavo, and you and others will continue with it.. but otherwise, I'd sincerely advise you to let it go. Attached is a patch to add support for fill transforms to evas image objects (plus new modifications to grad2s and some other minor things). Let me note a few aspects of this, since it it a rather 'big' change in some ways for evas internals. First of all, ALL engines but the software based ones are broken by this patch. It should be very easy to bring them all to doing what they did before, but it would be much better for the various engineers to take this opportunity (as with grda2) to enable this new capability for their engine of choice (I've only mofified the relevant engine funcs for the gl-x11 and xrender-x11 engines to build correctly, but they don't draw anything). The semantics of the fill-transform for images is simple: It should be equivalent to first scaling the image to the given fill size (preserving borders as need be), and then apply the (inverse) transform to that, with the fill x,y being an initial translation. Note that only affine transforms need be supported, and that the origin is to be taken relative to the image object's top-left. See raster, cedric, jorge, and gustavo for examples on how to use this.. :) The performance will vary somewhat here and there, but should be roughly the same as before when restricted to un-transformed images.. The one exception to that being the case of when the 'not-smooth-scale' property is set, since for now the patch always does a certain
